How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

文章要点：

• Being a good programmer developer requires attention to details.
• Greatness in a developer does not equate to years of experience.
• Learning different programming languages broadens your skills.
• Collaboration and communication are essential skills for engineers.
• Finding a healthy work-life balance is crucial for long-term productivity.
• Always keep learning and don't underestimate your potential.

The Chopmaice Lon Kotlin. That was predictable. Well, being a good developer. That's a very loaded question. It starts with the definition of good.

Being a good programmer developer takes several qualities. First of all, that's attention to details. Programming is all about small more details like things that you in casual communication or in text when you use a comma or flip a word, stuff like that, it doesn't really matter in your non-development life. But in programming, like just one character in your code or off by one somewhere can be a difference between code that works correctly and code that doesn't work.

So attention to the small details is really what makes professional developers different. And that's the quality that's needed to become a good software developer. I enjoy working with extremely good and at the same time very junior developers who arguably know very little, right? But the way they approach the tasks at hand, the way they learn, the way they are curious and hungry to do things, it’s an amazing experience and I love them as contributors. They're just great junior developers.

So first thing I'll say is that the greatness in this question to me doesn't equate with experience necessarily, especially years of experience. If I think about this, first thing that I'll say, and again this is my personal opinion, it's not like a rule. But first thing I'll say is the fundamentals.

Like if you're using a data structure like a library list or a map or something, do you know how that's working? Like what kind of algorithms are implemented there? Like why is it fast? Do you know how memory is managed in the runtime you're using? Do you know what kind of things are done under the hood to manage concurrency, for example, like synchronized threads and so on, so forth. Do you know how things work under the hood in general?

Looking into that makes you a better engineer because you learn from other engineering decisions made by other people. It makes, it exercises your mind in an analytical way that you really need working on your own code. And it also makes you just knowledgeable. It's much easier for you to figure things out and make connections where they're unobvious.

I remember a question I was interviewed by a startup CTO something 12 years ago. He asked me a question that I then kept asking in my own interviews that I liked very much. The question is simple. So photo web developers. Imagine on the webpage there's a button; you click on it. Next page comes, what happened between the button click and the next page? Think about it for a second. Right?

That onion can have five layers or a thousand. You can spend five minutes answering the question, or you can spend an hour and not be done halfway through because of how many things happen or can happen and depending on what level you decide to stop and speak about. The more layers of that onion you can stop and talk about, knowingly, the better you understand that system and the better a web developer will be.

Things like network protocols, things like database architecture. With so much of software available today being open source, you can be kind of the hood of pretty much any technology that you use. And you should do that, and you should read books and watch presentations about how this type of software works.

I think that the main benefit that brings is that it can help you resolve problems much more confidently and much more quickly than just if you just poke at things and see, like, if I do this, does this work? No? Okay, let me try something else.

Don't tie your identity to a specific technology or set of practices. So I see a lot of people like saying that I'm a Kotlin developer, or I'm a Python developer, or I'm an Android developer, and people who say that kind of things, that people who are not Android developers or not Kotlin developers are not like me.

And probably sometimes I see them as kind of competitors or enemies or something like that. Or maybe they... Or maybe I say that they are stupid and don't know what they are doing and instead they should be using the best language on the planet, which is Kotlin. I don't think this is healthy. I don't think this is good.

I think it's much better to just identify yourself as a developer and learn the tools. Learn what tools exist, learn what tools can benefit you in which cases and use the best tool for their job and base your identity on something else.

Believe me, during your career, you will have to learn many different languages and it is wonderful. Each language is different. Each one can teach you something new and change how you approach programming overall. For example, I wrote very different code when I coded in Java than when I learned Object C; it changed. When I first touched Swift, it once again changed and each language placed its mark on me.

So learn different programming languages, embrace them, and stay open. Don't be afraid to learn something unnecessary. So, for example, speaking of Kotlin, a very common question of people who start to learn Kotlin is: do I have to learn Java? And this, do I have to learn?

I think it's not the best way to put things like "Will learning Java make you a better Kotlin developer?" Yes, definitely. Because you will be easier able to understand the APIs of different libraries that you probably will want to use. You'd better understand how this whole environment works, things like that. You will better understand why things in Kotlin are the way they are and not something else.

So don't be afraid to learn something that isn't necessary. As we advance our careers as engineers — and it doesn't matter whether you're a consultant engineer or a product engineer — you will be working with people more and more. Inevitably you'll be reading their requirements, their stories, their comments.

You'll be writing the same thing; you'll be speaking, you'll be communicating, you'll be explaining, presenting. You'll work with people a lot, sometimes more than you work with code, especially if you measure your time in minutes in the day. The best engineers are also just great at working with people and everything that that entails.

Don't stick to one career. You're not doomed to be a software developer for your whole life. Take me as an example. I learned to be an information security specialist, then I became an Android developer, had to switch to iOS development, then I became a team lead, did some backend development, then I became a manager, and then a product manager.

And now I'm leading the development of a programming language. And that's actually great because in each role you learn different skills that may help you in the main one if you decide to return to it. For example, if you become a product manager, you will be much better at understanding what and why and for whom you are building. It will drastically help you to become a staff-plus engineer because you will not just write code; you will think about business needs.

Or for example, if you are becoming a team lead and then decide to stop doing it, it will teach you other essential skills like how to plan your time and time of other people, or how to make decisions in uncertainty or other things. So don't stick to one career. Your life is long. You can try different things and find the one that suits you the best.

When you are young, it feels like you can work 20 hours a day or 18 hours a day or something like that. And it's a lot of fun to write software. You may end up with your day job and your hobby project, like working for eight hours on one thing and then another eight hours on the second thing. And this is kind of fun.

I did a little bit of that when I was younger, but I think it's very important to not focus on that, not close your eyes to other things, other fun ways to spend the time, other ways to take care of your body, your emotional state, your mind. Read things, go for a walk, do some physical activities.

I think finding a healthy balance between all of these will allow you to sustain your productivity and sustain the joy that software development brings you for a much longer amount of time. Keep learning new things, go deeper, go wider. Look at how things are done nowadays. If there is a new big trend, look into it.

Like nowadays, that's generative AI. Look into that. It will help you stay up to date, it will help you be a better engineer and also just aim higher. In general, a lot of people underestimate themselves and just don't try things they could have succeeded at. And you should do that. You should try, you should experiment with the things that you feel are out, really.

You should apply to jobs you think you're not good enough for, and you should prepare for those interviews and get the job you can. So that's the top piece of advice that I can give in Kotlin.