Choosing a solution for a technical issue is not something new. But get the right direction and understand how to choose the right solution is not an easy job. In my opinion, for choosing a technical solution, there are two important criteria:
- Which exactly problem to be resolved?
- Team capacity
We will go through and explain one by one. But at first, we need to determine one important thing: root cause of the problem.
Determine the exact problem
Almost problems usually come when we do not know exactly the root cause of the current problem. A common signal is, you can not or feed hard to describe easily the problem via both speaking and writing.
The bad thing is, in most cases, as long as investing on one problem, we found many other problems appear. This procedure might take hours or even weeks to have the final solution for the question, what is the root cause.
How can we make sure where is exactly the root cause? In other words, we need to know when the investigation should be stopped.
We need some criteria to determine. In order to have a right answer, with my experience, I usually end up when at least one signal appear:
– Something is not correct with the normal principle of current language or library or framework we are using.
– Something is not correct with the business logic.
I extremely believe resolving the first one is easier. Many developers may think I am a non-tech guy, who have no experience with coding or so, that is why I could say that. In terms of technical point of view, lots of people better than me, yes, it is true. But I will show you the reason why now.
How important of main principle
I saw many developers usually follow these steps when they get stuck on a very specific technical problem:
– Search keyword on google first and click on all results.
– Repeat if they can not see any “good” one. “Good” means the results come from popular website like StackOverflow.
– They copy the “solution” on StackOverflow’s answer and see if it works.
– Repeat these steps again
Of course, not all the developers did exactly the above process. A true senior developer should do the following instead:
– Determine exactly when is the last time the code works. Git made this job easier than ever.
– Ask the guy who actually created that piece of code the reason why they did.
– If that guy can not help, he finds on the official document of current framework or library or whatever the problem belong to.
– Search on Google or StackOverflow like many other people did if official document does not help.
The critical thing here is the understanding of the official document. A senior developer understand the main principle (some other know best practices as well) and they see the problem and try to resolve it from the main principle perspective. Maybe they can take more time than a fresher developer can do, but it is normal. They consider carefully on how everything works together rather than something that can resolve the problem immediately.
I know it is hard and boring if somebody tell you should read hundreds of document pages. Reading document is one of the most crucial factors of a senior developer I can list out. Actually there is no official way to tell how to be good at reading a document, it is still depended on how about it was written and organized. But at least you can try the following things, let say we are reading a specific framework documentation:
- Look at the organized document and try to understand why they made its structure like that.
- Try to create your own clear definition of that framework as simple as you can. Avoid complicated words as much as you can.
- Based on your technical experience, compare to the other similar framework, try to fill out all missing pieces of this framework for common use cases.
- If the document good written enough, they will have a part like “thinking in X framework” or “principle” or “concept”. Try to understand everything in this part.
If you think this is a hard journey, you are wrong. We have another harder thing in the next section.
Business logic is more crucial than you thought
First, I need to clarify one terminology business logic. In the scope of this article, it is the combination of two things: business logic and team communication.
If you are a developer, you probably familiar with this scenario: requirement changes. You stuck at problem X, then try to fix it with hundreds of code lines, and then the requirement changed, everything is useless. That function might not be used once ever.
Finding a good solution in technical, still a lot easier. Spending 10 hours for fixing a bug, still better than 3 hours and your code will never been merged.
Why do we meet this kind of issue in common, and how to improve/fix/avoid it?
You might realize in one day, where changing a thousand lines of code still be easier than changing a single person thought.
In reality, we work with many people, not a single one. That makes everything easy to become messy and hard to be managed. It is not the problem of your Business Analyst (or Product Owner in Scrum), whose main job is clarify all kinds of requirements. It is also, not a single problem from your Project Manager, who make sure everything is on track of the deadline. We have some more factors:
- Project management methodologies: for example Waterfall or Scrum are totally different from each other.
- How many people on your team? Single person is a totally different story with a team has more than fifteen people.
- How teammate work together? Remote or in a single office? Do your teammates work with the same timezone? Other than that, do your team has a primary language? Etc.
- Even when you find something is critical to be fixed, that still may not a real high priority. In real life in a very large company or product, 5% or lower of the users face bug that still an acceptable number. Many A/B testing result accept this number.
- Your teammate technical level is an obvious thing to be considered right?
It is okay if sometimes you feel useless, or even you got wrong when choosing a team or a company. That means you need to improve yourself to see a larger landscape of a real product and understand how a real product works in real life. There is no ideal team for you on this world, only has the suitable team where they can cooperate with you and achieve the successful, all together.
All the above criteria, I called in short team capacity.
Come back to above question, now you may have your own answer. Since this is not only your single problem, it is the whole team problem. A clarified requirement is “good” in your sense, but sometimes, it is not an important thing in real life.
Not only in software development, but also in everything, team capacity is the crucial factor for every problem. Sometimes, the solution for the exact problem does not matter anymore, we choose a solution fit for the current team, that is the better solution. That is the time when we can see a more important thing than just a technical problem. Or, every problem just actually human problems.
Hope you can have a better look on every problem, not only on the technical side.