5 lessons I learnt after coding for 10 years

What you are going to read is not advice or suggestions, it's things that I learnt the hard way. It's the anti-conventional-wisdom list so I hope some of the things will offend you and boil your blood.

Since it's my career summarized in a few kilobytes of foreign language that I don't speak all the time, excuse me for missing context on some of the points.

This new language/library/framework will solve the existing problems

Our data is massive, we need the Hadoop ecosystem. We should adopt Kubernetes otherwise we are in deep trouble if our traffic spikes by 1000x (lol). In the next milestone let's remove all technical debt and switch to the serverless architecture. We need server-side rendering to improve the user experience. This new JS framework is 10x better than all other 15,000+ frameworks. We should install Chaos Monkey and test the reliability of our servers.  Let me book all engineers this quarter for (pick any of the above) tasks. We should build our next web app in Go/Rust.

I have seen many Big Data problems that can be solved by a few SQL queries.
Almost every time the solution to your problem is not the tech stack or framework you're not using. We read FMAANG problems on tech blogs and immediately declare that it's the silver bullet, without ever comparing the scale at which these giants are solving problems. Most startups don't operate on this scale. Even these companies were not dealing with such problems at the start. Solve for the user first.

New technology will always have too many unknown unknowns, coding is a liability and maintenance will put you in firefighting mode. Always trust battle-tested boring languages/frameworks for projects that you need to maintain for the next decade. It's cool to run side experiments in new shiny languages to understand the opinion of the new language/framework. But think deeply before plugging them into legacy production monoliths.

Read this recently, there are old coders and there are bold coders, but there are no old-bold coders.

I am a POPULAR-LANGUAGE developer

This trap gets activated in the initial years of our career but loses the charm soon after. It's when you declare in full glory that how you are a part of a cult language group. This has to be the worst marketing idea ever. Saying you are a coder has already lowered the bar, it means you are just a typist with instructions. It's not a hot skill. GPT-3 descendant can be trained to do the same. Stop highlighting Java/Python/JS developer on every visible pixel of the resume.

This trick works at the start when companies are looking for bots who can execute instructions, but it will rarely help you to grow after a point. We are in the business of solving human problems. You are either increasing the value of some business metric or reducing the costs to operate something. You are hired to optimise the machinery and it's a good idea to speak the same language.

I think the origin of the hard-core-language-lover marketing strategy was the early days of computing where people who can code were rarer than unicorns. Being a coder was a USP a few decades back. Today it's equivalent to declaring yourself an expensive typist.

Being a Popular-language developer is an expiring asset, with low shelf life and you are competing with other million people who spent last week in a Bootcamp. It's making you generic not unique.

You are a translator

The trajectory of the Software Engineer carrier starts with grinding leetcode. Everything is dependent on the binary tree that you are going to invert on the whiteboard. Algorithms and Data Structure are worshipped. As you grow over your career, you will reach a stage where every problem can be solved via code theoretically. You can build the solution as the client is describing the problem for the first time over Zoom.

This is (not) the final destination. Real-life problems are not as well defined as leetcode. We engineers believe the world to be binary and it's not.  Technical skills will give you a kickstart but it won't take you far. Coding skills would be the easiest part of your career and would be mentioned in footnotes when you retire.

I often felt in the beginning that code being churned out by me is the most valuable thing. I remember telling my mentor that we have to protect the code at all costs. That some competitors will copy our code and get all the business. The code you are writing is worth nothing. There are open-source projects who are struggling for money and yet they are the building blocks of the billion-dollar giants. Your code is easy to mimic, it's not the competitive edge you are searching for.

When Facebook bought Whatsapp, they gave $19 billion not for the best stack or optimised code. Facebook engineers can code it in a week. Facebook gave billions of dollars to Whatsapp for their network.

Businesses are not concerned with the time complexity of your elegant code. They are optimizing on the cost and value axis. The most important skill of your career will be clear communication. How you can paint the problem being solved by code on the cost-value axis. The edge case you will be handling most of the time is human nature.

Communication would become the showstopper skill of your career. You will reach a point where the most impact would be on how you can align the whole team with the company's goal and vision. You will act as a translator, as a bridge, between people in expensive suits and a bunch of youngsters in hoodies smashing keyboards. Being a storyteller and converting complex problems into simple words would be your superpower.

How vs Why

I love to code. I like the sense of power, where I am the creator. I can tame the machine with a few keystrokes. It's a magical feeling even after 10 years, going into a zone, where time doesn't exist.

The initial years of my career were filled with obsession where I had to crack the how part. How can I solve this technical challenge? How can I code the solution? This is how we are conditioned to operate. I felt happy, whenever I released a new feature to production.

Slowly I realized the pattern then most of the features I am developing are not being used. Although the sense of urgency when the requirement came was so high, I thought our product won't sell if I don't code it over the weekend. This was a surprising discovery.

Every good product is not useful. People don't buy products, they buy the idea, the vision, the way problem is being solved, bigger cause. I was never focused on the why part of anything being built. I thought it was the work of managers and c-suites. My laser focus was on how part, I often used to research the new Github libraries over the weekend and would use them in some way or another during the next week. I loved the mixed salad of technology.

Most products will work when the why part is far stronger than the how part. How is the by-product once the why is accepted by the users? This is why shipping the product is far more important than chasing perfection. When people say built-in public, they mean to bring the feedback loop in development, so that you can adjust the why of your product.

Obsess over the problem, don't fall in love with the solution

Waiting for my creativity spark

This has to be the biggest trap. It's a perfect excuse to cover the laziness. You will not be on cloud-9 all the time. There will often come times when you will feel empty and will question if you are in the right business or not. People find reasons to blame the ecosystem, company, colleagues, situation, or anything you can see. I worked on my first product for 2 years and we were not able to sell it. There are countless utilities that I designed which are not being used by anyone, yet I thought it will be the next big hit.

Passion and creativity spark is a bullshit term designed by some productivity gurus. Consistency is the key, atomic growth is the only way to move forward. You will see compounding effects if you wait long enough.

Motivation is overrated. It's a temporary stimulus that fades away like a drug. Whatever you are doing, keep on adding bit by bit to it. Consistency is one of the best-hidden secrets of the industry.

Make new mistakes

I was the first hire in the department that I now run. Since there was no one around, the internet and books were my only mentor. The feedback was slow, so I have accomplished these achievements too which would never be listed on Joel's test.

• Coded features on production, as there was no development server
• Believed localhost can be accessed by anyone
• Created databases without index and primary keys
• Deployment pipeline was Filezilla
• Wiped production data without active backups
• jQuery was the only library I trusted for Javascript work
• Declared Internet Explorer is not a browser (fun link)
• Brain was the only version control for my code
• Thinking and coding order were reversed
• Shipped code with debug flag on, so that client can simply print screen and email in case of bug
• nbsp was the only solution for all CSS problems
• Bootstrap was godsend
• javascript used to be client-side toy

Everything that needs to be said has already been said. But since no one was listening, everything must be said again - André Gid