It is Ok to not be the best programmer

I'm not the best programmer. Like not even close. But I'm a pretty good software engineer. In fact, I recently got promoted.

I got access to a computer pretty early in life, actually even before I turned 13. But I'm not the best programmer around. I've never won coding competitions, I don't think in code, if you asked me to write an algorithm to traverse a binary tree, I'd probably have to Google it. I didn't go to a top ranking college, neither did I drop out of high school to join or start Facebook or Google like companies. I consider myself a pretty good software engineer though. Coding or programming is just one part of software engineering, as there are other aspects equally important to being an effective software engineer. So if you are reading this and suffer from imposter syndrome as I did once, if you are stuck on hackerrank problems as well, let me tell you my story.

When I started my career, I was a copy-paste monkey. Every task was given to me with predefined inputs and expected output, which was okay for the time as I was a junior engineer. My seniors gave me step-by-step instructions to complete a task, sometimes even pseudocode for algorithms. But to grow as an engineer I needed to come up with these proposals myself. My senior would give me a vague problem, like displaying a list of images in a responsive way or figuring out why a component is quirking out, and I'd have to come up with a bunch of concepts, run them through all stakeholders and eventually implement one of them and to do all that I had to learn a few things:

1. Learn to read code: If you try to fix things you don't know how to fix, you ruin it. A lot of senior engineers I met early on weren't some code wizards who had codebase memorized, they would just read a lot of code, they knew the codebase better, but they would still jump from reference to reference in the codebase. They could of course do it faster. I learned that an effective solution is not the most intricate one but the one which follows the framework already established in the codebase.

2. Learn to write: Learn to write effectively, and I am not talking about code. A huge part of software engineering is writing technical stuff down, everything from documenting decisions about how a system is being designed to why you are proposing a change, how some bug can affect a customer or how to use a workaround. You'd be boiling down complex concepts so even an average person with little to no knowledge of them can understand them. This is why some interviewers ask questions like 'Explain Neural Networks or recursion to a five-year-old'. When I started, I couldn't write a single sentence without a spelling or grammar error. Writing blogs on topics that I liked and actively sharing them with friends helped me improve these skills. A decade back my friends used to call me 'Typo Master' for all the typos my written content used to have, but with a combination of practice and technology my writing skills have improved since then.

The better you can write technically and non-technically, the easier it would be to own projects, drive change, and influence stakeholders, and the more written evidence you have of your impact the easier it would be to get promoted. Write often and write well.

3. Write more code: As I started to grow as an engineer I noticed what senior engineers were doing differently when writing code, and I realized they were doing the same stuff but they were doing it more. There is some study that if you do 10,000 hours of practice you'd gain mastery in something or if you write a million lines of code you'd become a pro coder. I'm not sure how true that is for every individual, but doing more of something does make you better. So if hackerrank or leetcode problems give you nightmares, do more of them. Start with easier ones. If some problem is too difficult search youtube, someone probably has explained a truck to solve them For those you have solved already, look for solutions from others. Just write more code.

4. Be a person people love to work with: Someone once told me, that working with other people is the toughest skill you can learn. Building software that millions would use isn't a one-person task. We are working with tech support, product management, UX designers, Quality Analysts, Data scientists, Security engineers, and so many others. It is important to learn their priorities and motivations and learn to compromise to find a solution that works for all. Learning to empathize with their needs but also be confident enough to stand your ground and push back when needed is a necessary skill. Listen more and be a people person. Learning from mistakes isn't about placing blame, it is about learning what happened how and how we can avoid such mistakes in the future.

5. Be more than a software engineer: Involve yourself in initiatives that are aligned with your strengths and interests. Your non-technical contributions are just as valuable as your technical ones. The more senior you get, the more company-wide extra-curricular events start to matter and they usually have more impact than any code you write.

You don't have to be a prodigy to be a successful software engineer. I think focusing on growing personally just as much you focus on growing technically can make you an incredibly effective software engineer.

I hope the things I learned will help you too.

Signing off.

s