The 3 most important pieces of advice I got in my career

Everyone wants to be a better engineer. Particularly when you have just started your professional career, you are eager to learn. You see a senior engineer in your team, and you wonder how you can be like the person. The answer is pretty simple: You need to learn and practice more. However, the most effective way to do so is often unclear. You don’t want to spend all of your free time outside work thinking about programming. If you want to, that would be great but at least I don’t want to. I struggled a lot when I first started working because there were so many things that I didn’t know and I didn’t know where to start. In this article, I will talk about 3 pieces of advice I got from my CTO at that time that helped me to figure out what to do to level up my skills.

Read Books

Reading books is arguably the most effective way to level up your skills when you are working. You write code at work, so you already have enough time practicing. What you need is more knowledge that you can apply when you write code. If you don’t know what to pay attention to, then it is hard to get better by just writing code. Interestingly, the fundamentals of software engineering have not changed that much in the last 20 years. You can still learn long-lasting fundamentals from a book written a long time ago. Since there are already lots of articles that recommend books, I will provide just 3 books that cover very different topics in software engineering.

Designing Data-Intensive Applications - Martin Kleppmann

You can’t really talk about modern software without data. If you want to scale your application, the amount of data your application has to handle can be the bottleneck of the app’s performance. It is not very difficult to build Amazon or Facebook that works for only dozens of people, but scaling it to millions of people is a different story. This book will give you an overview of different technologies and things to consider when you build data-intensive applications.

Clean Code - Robert C. Martin

This is a classic book about software engineering. It explains lots of fundamental principles that help you write clean code, as the title suggests. It was written 12 years ago, and the author mainly talks about OOP. If you don’t write Java, some of what he says might not be immediately applicable but I think there are lots of fundamental principles that can apply to your daily work. I would highly recommend reading this at least once in your career.

The DevOps Handbook - Gene Kim, Jez Humble, Patrick Debois, John Willis

You may wonder why the last book I recommend is specifically about DevOps. DevOps is about team culture. It is not just for a DevOps engineer, but all engineers should understand the core concept behind it. If your team doesn’t have a great DevOps culture, you will face a productivity issue at some point even if things are working fine at the moment. If you want to lead a team or start a company in the future, you need to understand how to build a good DevOps culture. Although the field of DevOps has been changing quickly, this book was published fairly recently and covers lots of basic principles of DevOps that are still applicable.

Learn a language with a different paradigm e.g. functional programming

The second piece of advice I got from my former CTO was to learn a functional programming language. At first, I was really skeptical and didn’t understand the point of it until I actually tried. I used JS and Python for my daily work, and I didn’t have a chance to use a functional programming language at work. To me, learning a new language that I don’t use for work didn’t seem that helpful. It took me a while to understand the benefits of it, but here are the things that I learned in the process.

It helps you to differentiate language-specific best practices from universal best practices.

When you write just one or two languages, it is hard to tell what are generic software best practices and what are language-specific best practices. For example, if you are a JS developer, people often tell you that fewer lines of code in one file are generally better. This does not apply to all languages. Fewer lines of code are generally preferred in JS because it reduces the chance of accidentally mutating an object. If you use a functional programming language, it is impossible to mutate an object by design. If you think I’m wrong, check out this video by the inventor of Elm. Learning a functional programming language broadened my perspective on programming languages and enabled me to critically think when I encounter a new design principle.

You can choose a language that is better suited for work.

Many modern systems are moving from monolith to microservices. Of course, there are disadvantages of taking a microservices approach and companies should not split a monolith for no reason. However, it is quite normal to use different languages for each part of an application these days. Learning different paradigms of programming languages helps you to determine the language that is best suited for a given task.

Build your own X

This might be obvious to many people, but if you want to be a better engineer, building something is the best way to learn new things. If you have something you are interested in, then you should build it. However, if you are like me and have a tough time coming up with what you want to build, then this is what usually helps me: Try to build the core logic of existing frameworks/applications from scratch. For example, if you are a front-end engineer using React, try to build your own virtual DOM program. If you’re interested in compiler optimization, then try to build your own interpreter or compiler. Understanding the core logic of an application helps you to understand the advanced topics around the application. Here is an awesome list that helps you to get started when you don’t have any ideas.

These are the things that helped me to grow as an engineer when I first started my career. Everyone has their own way to become a better engineer and I don’t have years of experience, so take these with a grain of salt. If you are working on your side project and want some feedback on your work, then check out Antcode to get reviews on your work from other people.