This interesting question was recently posed on Quora: What do the top engineers do, that the rest do not? And how do you get the habits to become one?
Anyone can tell you something like “oh you should use source control!”, or “you should comment your code!” or other obvious things like that.
But there is a limit to how much code and how good code you can crank out daily, so how do you actually become better?
Being an engineer is more than just being a good programmer. You may be able to come up with fast algorithms to solve problems, but what about building the architecture for a large scale application, that is both easy to understand but also testable? Or what if you’re showing your web app to the users and they are confused, and keep asking you how to use it?
If the only thing you do is just write code, your job can be outsourced to some cheap programmer in some cheap country, and you don’t want that right? That’s why to be a top engineer that stands way above the cheap mediocre people, you need to look outside the immediately obvious realm of writing code. Top engineers have a much wider range of skills, which they use to understand their client better, provide higher quality solutions, and deliver a lot more value (and as a bonus for them, all this justifies the boss giving them a higher salary).
1. Constant learning
This is the basis of everything. By learning new things, even if you don’t end up using it daily, you will increase your knowledge about what is out there.
Even if something you learn doesn’t have any obvious practical uses, you gain new insights and ideas through it. The wider your range of skills, the better solutions you will be able to provide, and as a result, the more value you can deliver.
Learning adds up: You learn something, and as a result, learning something else is easier. Learning becomes easier the more you learn, and also helps with all other aspects of software engineering.
The trick is to not only learn about programming, but also about other things.
- Learn a new tool – testing tool, automation tool, etc.
- Read a book. It doesn’t have to be about programming, you could for example read about user interface design which is very useful to know
- Talk to other developers – Others know about things you don’t, you’ll get new ideas, or maybe even solutions to problems you’re having
- Write about software engineering. It may sound strange, but writing will help improve many of your skills. To learn more about that, read my article about how you will become a better developer by teaching
- Learn a new language – TypeScript, Haskell, Prolog, C… pick the one that looks most difficult.
I can hear someone say “But I’m busy and don’t have time to do this”. You can take just one hour a week to do this, as long as you do it. If you can’t find a single hour a week to improve yourself, maybe this is not for you.
2. Understand, Solve, Implement
Have you ever started working on something, only to find out you don’t have any idea what to do? Or maybe you got stuck, and had to start from scratch?
This is a typical issue especially with beginners, where they lack the understanding necessary for the task. Experienced engineers often have an understanding, but might lack the solution.
The best engineers will get an understanding of the problem, come up with a solution, and only then implement it.
There are many ways to understand the problem: You can talk to people, use Google, look at other projects which do similar things…
Next step, the solution, is usually more difficult. It doesn’t have to be a concrete solution, a general idea is good enough. Maybe find a library you can use, the documentation you need for an API, or perhaps some necessary hardware…
The last step is usually the fun one: Implementation.
In the end, sometimes things won’t work out. You may have to go back or start again, but by following the understand, solve, implement pattern you have much higher chances of succeeding and not getting stuck in the middle and wasting a lot of time.
3. Have a plan
The best engineers will have a plan. There’s several components to this:
- A high level overview of the project – An overview of the components, modules, and how they interact with each other.
- Understanding and solution for what needs to be done – As explained earlier, get an understanding of the problem and a concept of a solution
- A high level implementation – What components you should add for the feature/fix/whatever, their purposes, and how they integrate with the rest of the project
These combine to allow you to build a solution that doesn’t suck.
The A-Team always had a plan
The high level overview shows you the base: Existing components, any needs for refactoring if you implement a new component, etc.
The understanding and solution help you design a better implementation, as you won’t have to guess.
Finally, the high level implementation idea is so you won’t get stuck. It’s possible the idea will change as you start working on it, but having a guide is helpful.
Without a plan, you are more likely to duplicate existing functionality or add components which integrate poorly. That will lead to a maintenance nightmare if not corrected.
4. Stay objective
Top engineers stay objective. They try to understand the true reasoning behind something, going deeper than just the initial impressions.
When someone talks about “best practices”, do you just take their word for it? Have you ever tried to understand why something is considered a best practice? Or is it actually a bad idea?
Many engineers take things at face value. “This is the best practice!” – OK, I’ll do this then. “Here, these are some good design patterns!” – OK, I’ll just use these everywhere.
Top engineers try to understand the reasoning behind this. What makes this a best practice? What makes these design patterns good? You might not be able to see the reasons easily. This is another reason why you need to learn new and different things constantly, as that will give you a better perspective on analyzing new things. However there is a simple way you can speed this process up: Ask the person who tells you this, or find an expert and ask them. Ask them the difficult questions, like “what makes this a best practice in your opinion?”
Another example of this is PHP: Many engineers have an immediate response of “PHP sucks!” when they hear the name. This is of course not true, there are very, very few things in the development world which are truly bad and should never be used. If you hear someone throw around a lot of nonsense like “language X is crap”, and if they’re serious and not joking, it’s often not a good sign.
- Try to understand why people like or dislike some things – Some tools (like Haskell) are indeed amazing, but it’s useful to know why people feel this way. Using or not using something because of how you feel about it is usually not a good thing, as you might be overlooking something that would be more suitable for the task.
- Don’t get personal – It’s sometimes fun to debate things like favorite editors or languages, which will provide endless heated arguments on the internet. Many will blindly defend their favorite, devolving into personal attacks when they run out of things to say. Try to avoid this, and instead try to understand the other side’s point of view.
- Don’t follow blindly – Best practices, design patterns, all have their uses, but you should try to understand why. You might discover that they’re actually not that good afterall.
5. Understand requirements vs desires
All engineers desire to use their favorite tools with all projects.
Top engineers realize that the project’s requirements dictate what tools you should use, not what you personally desire to use.
A good example of this is blogging software. In such a case, WordPress is a solid choice, but developers don’t like it. I would rather take a nice framework in some nice language and write a custom blogging solution. It would be much more fun to work with, because let’s face it, WordPress’ codebase is pretty bad.
However, if you were to create your own solution, you could be shooting yourself in the foot.
This is why you need to understand when the reason you want to use something is your personal preferences or desires, instead of the requirements for the project.
6. Understand the importance of user interfaces, user experience and usability
I like using the iPhone, but many people don’t understand why. Often especially developers will ask me “but Jani, why would you want to use an iPhone when you could use this amazing Android phone instead?”
The simple reason for this is user experience and usability.
Why do you like using your favorite editor over others? You find it easier to use, you work faster in it, you like the way it looks more than the others… In other words, it has a better user experience for you.
Many engineers work with user interfaces at least to some degree. Great engineers often have to discuss features and implementation with designers or the clients. It pays off to have at least an elementary understanding of UI, UX and usability, as it helps in brainstorming better solutions to problems you need to solve.
7. Understand project management and the business value of your project
Idealistic people will tell you that if you’re a great engineer, you will deliver projects on schedule. While this is a sign of being good, in real life things sometimes go wrong.
This is where understanding of project management and business value comes into play. As the best engineers are often involved project management, at least in a role of advisor to the team lead / boss / client / whoever, understanding which tasks are the most important for the business goals becomes useful.
Deadlines slip sometimes. That’s when you need to be able to find the highest priority parts to deliver. In other words, what are the most useful and important features or fixes for the customer.
Understanding projects and value is also useful for planning schedules, so you can continuously keep delivering new releases. Faster releases means your customer sees progress more often, and you will get feedback on it faster. Many big companies and startups rely on being able to release code into production rapidly, for example Facebook.
- Be more involved in project planning – You get better by practicing. If you can’t do it at work, use something like Trello to do so with your personal projects
- Pay attention to what the customer really wants – For example, if you’re building a web app, what do they gain from it? Will it make some task take less time? Will it help them acquire more customers? Try to understand where the value is
You don’t have to become a project manager or anything. Just having an understanding about these things is useful, as when you understand value, you can focus on where it matters, and give better proposals on features. This again goes back to you delivering more value yourself, by giving the customer a better result.
Conclusion
The first key thing to understand is being a great engineer is not only about programming. There’s a wide variety of other useful skills that contribute to how well you can do your job. Being a great programmer is important, but so are other aspects of software development and the related processes. Learning about them should be high on your to-do list.
The second key thing is understanding yourself. I highlighted some examples of thinking, like understand, solve, implement and remaining objective here, but there is more. Try to identify problems in your thought process and in how you approach problems, as having a better understanding of yourself will allow you to adjust your thinking and become even better.
If you take these two things and try to keep them in mind, you’re well on your way to become one of the best engineers out there.