The Worst Programmer's Reflection

This is a reflection after reading the original article, The Worst Kind of Programmer.

The author of the article clearly has had similar experiences, so it's not hard to sense his bias in the piece. However, I believe there are quite a few points worth discussing and learning from, which I've noted here.

In the article, he mentions a past project where a Frontend Lead enthusiastically set up the project architecture, opting for Angular, Nx, and Rx, while the backend tech lead chose to incorporate various libraries under the Spring Boot framework. Essentially, they were all about using the cool, trendy technologies.

As project requirements increased, the frontend lead continued to adjust the architecture, attempting to separate business logic from the technical core, leaving only simpler tasks such as API documentation and writing tests to the juniors.

Eventually, this Frontend Lead left the company, and the team started struggling to maintain the overly complex code and had to bring in an expert to firefight, trying to keep development output stable. However, the complexity of the architecture still slowed down the team's productivity. Whether it was refactoring or rewriting, the cost was significant.

Where's the Issue?

In my eyes, this is behavior I'd attribute to inexperienced engineers. (Much like my past self, I confess 🙏)

In the mentioned scenario, the Frontend Lead was earnest, possibly looking to add another impressive entry to his resume. After implementing his changes, he'd leave, inadvertently crippling the entire team's development speed.

I've always agreed that over-designing is the root of all evil. It's not that new frameworks should never be used, but rather the hasty introduction of new frameworks or libraries after reading just a few articles can significantly impact the project.

A good engineering process should always seek simple, appropriate solutions. A favorite example of mine is the evolution of the piano's action mechanism, best explained in this video by Mark Rober, with animations that make it easy to understand.

Why does the piano's action mechanism look so complicated? Why not just hit the string with something? How can you sustain a note by pressing a key and stop it when released?

These questions all start from simple problems and evolve step by step to the current system, not solutions found immediately from the start. Once you understand why, you'll appreciate that the entire mechanism is just the right design. The same principle applies to software development; it's not about introducing various frameworks from the start but finding the best solution for the current problem step by step.

I don't fully agree with some points made towards the end of the article, such as the ability to solve abstract problems, the capability to work long hours, and having a passion for software development, which I think are all great traits. Of course, the willingness to work long hours changes with life's stages, as priorities shift.

Another often overlooked indicator is whether the code is "easy to modify or delete".

When I'm working on a piece of code, can I confidently delete something without causing a cascade of failures, or design in a way that implementations can be easily replaced? Another aspect is whether others can quickly understand and modify the code in the same manner. From this perspective, I really like the adapter pattern, where once the interface is decided, the implementation can vary.

Some people are very strict in Code Review, often criticizing based on personal preferences rather than focusing on overall functionality design and readability improvements.

Not to mention getting hung up on formatting. If most of the team's debates are about formatting, it might be time to review whether the ESLint or Prettier settings are appropriate.

Communication

I believe that in a team, any significant decision should at least be discussed with the team first.

Not everyone must agree, but there's no need to treat other team members as fools, thinking only your solution is the best. Under normal circumstances, everyone wants the product to improve and development to proceed smoothly.

Here are two things to note:

1. Sometimes, opposition arises because team members are accustomed to the current way of doing things. In such cases, provide background and explain why you think the new proposal is better.
2. As a more experienced team member, when you see a new proposal, you can offer more context or historical data for consideration.

In a podcast with Lex Fridman, Jeff Bezos mentioned — disagree and commit.

I absolutely love this concept.

Disagree but support fully. To avoid endless debates, once a decision is made, even if you disagree, you support it fully to ensure progress rather than stagnation, which I think is a fantastic attitude.

Especially when the team is full of smart individuals, usually, the disagreements are minor. (Of course, this assumes a high-caliber team)

Disagree and commit is a really important principle that saves a lot of arguing. There will be disagreements in any endeavor in life where you have teammates. In society, and inside companies, we have a bunch of mechanisms we use to resolve disputes. And a lot of them are really bad. An example of a really bad way of coming to an agreement is compromise.

Bezos mentioned that compromise is the worst way, resulting in a Frankenstein's monster of a solution.

I've felt this deeply myself. Sometimes, when you lack authority or haven't established a reputation, compromise is inevitable, prompting me to think a lot about how software development is often about assessing incoming requirements and then implementing them, with the development team rarely involved in the conceptualization process.

This leads to the situation where despite having good technical skills, creating a product or something users want seems challenging, a dilemma I've been facing lately. I wonder if anyone has good suggestions?