If you are a visual learner, the video version of this post is available on my YouTube channel. Feel free to watch that instead. If you like reading, read on :)

Don’t Obsess Over a Specific Programming Language

While you need a programming language to communicate with the computer, it isn’t the most critical part. I see a lot of beginner engineers and students fret about what would be the best programming language to learn. Instead, I suggest that you focus on learning the fundamentals and the programming paradigms well. What are the fundamentals you ask? Your core data structures and algorithms, and best practices like S.O.L.I.D principles and some common design patterns. These are language agnostic. That way, you build knowledge to become a good engineer regardless of the programming language, and at the point, the language or framework you use just becomes a means to an end to solve a specific problem at hand. However, the foundational knowledge you learn, remains with you throughout your career.

Pick a Universal IDE

It used to be that each programming language came with its native IDE and it was incredibly difficult to make it work with anything else. Part of being language-agnostic is also being free of the headaches of getting used to a new IDE each time you pick up a new language. Today though, the landscape has changed, and there are multiple great open source IDEs available that work with almost all programming languages. For example, you can learn Visual Studio Code inside out, then use it with any programming language/framework. This saves you time and lets you focus on problem solving instead of learning the nuances of a new IDE.

Nail Down the Data Structures and Algorithms!

This builds on my first point. You need to have a strong understanding of Data Structures and Algorithms. A lot of beginner software engineers are eager to build something quick, so they skip over this, and trust me that is a huge mistake. This is even more true if you aspire to work on big tech companies. I like to use the example of an Autocomplete. If you ever had to add that feature to your app, how would you do it? A common answer is use a library like jQuery Autocomplete, or add something like a Lucene search index on top of your data. Sure, those work and are fine solutions if they solve the problem. But do you really understand how they work? What if you have special requirements for autocomplete that relies on a custom ranking feature instead of just the text? Would you be able to modify it without understanding it? This is where I see a lot of engineers struggle. However, if you had a thorough understanding of data structures and algorithms, you wouldn’t. Because, the underlying data structure behind most autocomplete implementations is a trie. A trie is a type of a tree. And there are various search algorithms to iterate over a tree. With this knowledge, you could build your own autocomplete if you wanted to. I hope this gives you an idea. Don’t skip on data structures and algorithms!

Don’t Just Jump to Coding

Okay so you have mastered your data structures and algorithms, picked a programming language you like, picked a universal IDE and are now raring to build something. You have picked everyone’s favorite first project — the TODO App and are about to code it up. I understand the excitement, but wait! Don’t just jump to coding. TODO is a simple app, but as a beginner software engineer, you need to get into the habit of brainstorming, considering trade offs, thinking about real life implications, scale, tests, use cases and all those things before you even write a single line of code. Trust me, it is much better that way. In fact, I will even say that 80% of your product development time should be non-coding time. Yes, it sounds counter intuitive, and I hear you yelling, “What the hell man! But I am a programmer!” I agree, you are. But, building good software is understanding that things change. If you jump into coding, you will learn things that hard way, then get into the habit of patching things up — not good. If you consider every possible scenario, prototype, talk to stakeholders, iterate, think trade offs, performance at scale … all of that before you even code, by the time you actually get down to coding, chances are less likely that you will need to change a lot. And software that requires little change is good software. So every time you get excited and want to jump to coding, ask yourself, “have you considered all possible cases and are you confident that you are ready to code?”

Put in the Hours

The more you learn, code, build, make mistakes and iterate, the better you get. There is no way around it. So accept it. It takes time to get good. Enjoy the process, be passionate about it. I get asked all the time - “Do you have to work more than 8 hours?” Why does it matter? Sure, you may have personal and family reasons, but if you are just beginning, you should enjoy it and look to spend every extra hour you can towards it — whether it is your work or side project. The more you do something, the better you get at it :)