Today I am going to continue refreshing my knowledge on React JS. Here is the previous article, where we left off.
As I am following along the Pluralsight course, the next topic is about code reuse.
If you are new to programming, this topic is extremely important. If you are working as a programmer for a while now, this is even more important. You won’t believe it, but I see programmers failing this topic even after a decade of experience in the industry.
The basic concepts seem simple, but to master, it is tough. That is where most programmers have problems.
I want to differentiate three kinds of people based on soft skills and personality types. You will meet them all over your career, and you already one of them:
- The first one who only wants to make the job done. He can usually finish the assigned tasks relatively quickly because this type of programmer does not want to take time to see the entire context of the project. It is easy to work like that, but that is the selfish way of working in a team. The good side of that most ticket gets closed quickly the beginning. The business will be happy since the individual is finishing tasks like crazy. But in the bigger context, if you are not solo on the project or the project is not small, where it will kickback. In order to add a new feature, you will have to rewrite most of the previous code. It can be up to 80% of rework if you are lucky, and the feature you have to build upon is relatively new. Sometimes, you have to remove everything and take weeks, because so much dependency was built upon the code, you have to work with. The longer that feature was built without consideration, the more damage was caused. As a team, it is really frustrating if you have to work with someone like that, especially if the project is big, and the deadline is short. Tasks that should be done in 4 hours, could take up a 2-week sprint or even more. I saw that happening more than once.
- The second one is, on the other side of the spectrum is when someone over-architecting. There are multiple techniques and patterns to use, to help yourself decouple code and remove code dependencies to a minimum. This is coming from the developer’s best intention, but working this way has 2 problems. Any feature to complete takes an unnecessary amount of time to complete. The other problem is that small and simple features, that rarely get touched again, get overcomplicated, and hard to understand. To give a context here: the first type of people could solve the problem with two lines of code, while the second type of people would create a dedicated microservice, using as many patterns as possible in the meantime, and hooking up the 2 or more project with REST calls, or any other similar tool that is the newest and best. That could take thousands of lines of code, eating up more than necessary resources on the server. This type of extreme is again, causing the same problems as the first type of extreme.
- The third one is where the sweet spot lays. This is where you have to find the balance between how quick and dirty should the code be, or how well organized and architected. This is dependent on business needs, deadlines, opportunities, available time and money, or any other resources. It can also happen, regardless of how well balanced you try to be, that you will be forced to work in one of the two extremes. The difference is, you are doing it consciously, taking close attention to what the business needs. Considering resources, time, opportunity, the audience (potential customers), and the company vision short and long term. In the first two extremes, you are only a developer, lead by your personal preferences. In the third one, you still have your preferences, but now you give more space for business preferences over your personal developer preferences.
Ok that was a soft-skill detour. I felt the need to express that a good programmer is not only writing good code, measuring it one way or another. A good programmer also needs good soft skills, and needs to understand the priorities of the business including the market the company serves.
In the next article, we are going to continue with hard skills.
