Do you find yourself spending most of your time reading? Spending most of your time figuring out documentations and spends only 20% of your time actually churning out thousands of lines of code? You are not alone.
Interestingly, developers are problem solvers. You want to get your software up, you have to solve your series of problems.
1. What is your business problem?
Every solution starts with a problem. We seek to design software solutions to create value for our end users. Typically, those users are business users. Business users come with business goals and agendas. In the same way, if they wish to reach their goals, they need tools. Business users need to show case their product and services online: they use websites. They need to do transactions online, they use Shopify with Stripe integration. Every tool seeks to serve a business use-case. That is a tool that will generate value for your business.
There will be instances when you have to create your own tools to address the nuances of your business use-case. Thus off-the-shelve solutions may no long be sufficient or these tools could be too complicated for your current use-cases. As such you look towards customised solutions. Always keep your business goals front and centred so you do not lose sight of the purpose in which your solution is created for.
Take the time to figure out your business problem first
2. What is your tools best fit for the use-case?
If you have a hammer, you will see everything as a nail
Always look at yourself like a mechanic engineer. You have an array of tools in your toolkit beside you. Find out what is the problem before deciding which tool is best to address the issue.
If you have a screw stuck in the wall, you use you screw driver to remove it, you dont use a hammer. That is the interesting, yet dangerous part - while you can use technically can use a hammer to put out the screw, it wouldn’t be pretty.
It gets the job done but with much effort and it is not the way with the less effort.
If it is a video application, look for tools that utilises WebRTC. If you want a messaging broker, use rabbitMQ instead. While WebRTC can serve as a message broker to deliver your data over to the other party, it was never purposed for text deliver.
Fundamentally it is about trade offs. In the case of Nginx, while it not fully purposed for load balancing, it does a fairly good job at that; even in production setting. (Correct me if I’m wrong! hehe)
Find out which tool is best for the job. Don’t use a hammer just because you have been using it
3. What are your technical challenges
You definitely will encounter technical challenges when you are developing a technical solution. Haha. Here’s where you consider the algorithms you are choosing to use. Keep the complexity of your code low. What is the smallest Big O notation you can attain with the lowest effort?
In software engineering, we look to the Big O notation to rank the complexity of our code. It is a common language to address code complexity. Check it out here.
tick tock, keep your code’s complexity done will set you up for scale
4. What is your solution’s minimal viable standard?
Are you able to reduce the complexity of your solution by Finding an alternative solution?
For example in your communication application, are you first able to start off with a messaging platform instead of a video exchange service?
The end goal is to get the communication between two parties established first. Consider these incremental steps first.
Find out what is the fastest, cheapest way to ship your product out. Getting it out and get feedback has the most value.
5. What are your deployment challenges
How do you plan to deploy your solution? Assuming a cloud provider, which cloud provider?
What are the differences between the core cloud providers AWS and Azure?
There are numerous articles to address the differences between the cloud solutions. So check them out. Interestingly, I happened to find this article curating all the free tier Saas you can use for your development tests.Free for dev. Check them out!
Given cloud services, deployment is meant to be easy and potentially take short amount of time for simple setups
The importance of R&D, the value of senior developers
You will spend a ton of time reading and addressing your blockers every step of the way. The ability to source for solutions is crucial and grows with experiences.
The value of senior engineers shines when the team has to foresee the possible challenges ahead of time. Recognising these problems ahead of time gives the implementation additional buffer time to research and trial different approaches before deciding on any single implementation. This time to research and ‘play’ with different possible solutions in the sandbox is crucial to reduce sunk cost in the long time. This comes with the luxury of time but definitely a process to set in place when the business has the resources to do so.
Spending most of your time reading and researching is common. Something I wonder if its an issue with my own incompetence or the tasks are generally technically challenging. I would like to think its both and take responsibility for some of the inefficiencies. It is a process. Reach out for help if needed. We may call ourselves individual contributors, but great engineers are not great in isolation.