This is page two of the online book "How to Become a Good Software Engineer: Advice from Programmers from Facebook, Amazon, Microsoft and more".
Table of Contents:
- What makes a good software engineer?
- How to become a good software engineer
- Tools of software engineers
- How to develop problem-solving skills
A skillful software engineer is an engineer who is very good in one area. They can be good at delivering a feature faster than others; good at finding abstractions and base classes that simplify the development process (winning time at scale and making the whole team more productive); good at testing, good at asking questions about why things are done as they are and good at finding ways to improve code.
Strong skills can be found in areas in which engineers have a personal, intrinsic interest.
Good software engineers love to dig deeper through the programming language into the platform and down into the hardware, disassembling the code piece by piece, going deeper into the layers of abstraction, from the software part to the hardware.
Here platform means: operating system, browser, cloud computing platforms, compilers, virtualization tools, everything that software is built upon.
The ability to use a debugger and a platform’s diagnostic tools is indispensable, providing the engineer with a bigger picture, including which files are open, what is happening in memory, what processes are running in a CPU, and what packets are moving across the network.
When software does not work as expected (and this happens all the time) knowledge of how to debug allows you to move at a steady speed, despite the constant tendency of systems to become more complex. Knowledge of DevOps helps in this regard.
If you are a backend developer then learn the operating systems. Get to know C and C++ languages, in which most system applications are written. If you are a Java developer, learn the Java Virtual Machine and the Java standard library. If you write object oriented code, make sure you understand Object Oriented Programming (OOP). If you are using a database, go further than learning its query language; find out how it works inside. This forms a great depth of knowledge and helps you to write meaningful and high performant code, build awareness of bottlenecks, aid in software design, and debugging.
If you are a frontend developer then you will get most value from practice, because you don't need as much theoretical knowledge. As a practice, Alex Khismatulin, a Frontend Lead at Squire, brings such things as writing his own code and reading others’ code, but not limiting himself to his teammates' code reviews; also reading code at GitHub.
Strong programmers don’t take facts for granted. They ask the questions “why is this so?” It’s great if there is a colleague who has an answer, but their absence does not stop a strong programmer, who is driven by curiosity.
Curiosity leads deeper. If something doesn’t work as you expect, or you’re just wondering how this or that function works, you look into its source code, then get deeper, even further from the application layer, descending to the level below, down to hardware level. This is how you understand software engineering.
It’s important to be proficient in patterns. This is how Anton Kireev from Avito explains it:
“Programming is like playing chess. You cannot sit down and start playing chess by learning only how the pieces move. Of course, there will be people who can do this... [such people are rare] ...The funny thing is, chess [consists of] patterns that your brain won’t see at first. That is why it is recommended to start with small drills rather [than learning openings and trying to master] the full game [at the beginning], so that the current state of a game seeps into your subconscious, and moves become reflexes. Then you can engage in strategy with ease. Without practice [tactics in chess or patterns in programming], neural connections will not develop in the brain, and you will not be able to freely see and apply patterns to the task that you are facing and to the code that you see.”
Good software engineers are pragmatic; they focus on business, not code. This changes the way they approach problem-solving and technology choices; they become practical. No more new shiny technology for the sake of technology. Good engineers pick a new technology only when it solves the problem and a company has the resources to adopt the technology. And in most cases, developers are more effective with the technology they are most experienced with. Moving from an engineering mindset to a product mindset is an important step to becoming more efficient.
“Choose effective solutions. Even if they are not always the best, they are faster to make and easier to throw away” - Ruslan Torobaev
When developing large products, you often have to throw away your work. Development through experiments and small steps helps to negate this problem.
“Experiment more - go in small steps” - Ruslan Torobaev
A frequent piece of advice from experienced programmers is not to get hooked on “hype” technologies if you are a product programmer. New technologies with exciting success stories are often the same: “they took top-end hardware, new technology, and got a mind-blowing result that everyone should hear of”.
The stories of failures are much more interesting, says Ruslan, as they allow you to find out where the technology cannot be applied, in which cases it does not solve the problem, and what bugs it has.
From Ruslan’s experience, it often happens that a prototype that gets to production will work unchanged for many months.
“You don’t always need an elegant solution, written about in books or talked about at conferences” - Ruslan Torobaev
Vlad Popov, a Software Architect at Kinaxis, at the start of his career, spent two years using a PHP script with one class of 25 lines as a backend for all his Flash projects.
Strong programmers are distinguished by their ability to solve situations that block progress on a task. They are not afraid to ask colleagues questions or ask for help.
Psychological moments play a big role. Self-confidence is another psychological trait of a strong programmer that has helped Vlad.
Personal life problems immediately lead to a drawdown at work. Therefore, balance in life outside of work is as important to a career as the work itself.
Strong programmers are not afraid to change someone else’s code. This is often the case when a programmer starts working on a new project. You have to understand that the code was written before you, by programmers like you who were solving a local problem, and had local knowledge about the product.
When you are sure that you are a strong programmer, regardless of experience, it helps in interviews, communication, writing code and commenting in code reviews.
[DS: I have moments when I doubt whether I made the right decision. Such doubts use up a lot of “mental fuel”, which we have in limited quantities for the day, distracting me from the tasks at hand.]
Write projects to gain confidence. Lots of projects. Build your portfolio and make it public. What was a few nights of programming for you will result in a “wow, did you write this?” response. This is the effect of public portfolios.
[DS: I got into my first serious company thanks to a portfolio of one project.]
At the same time, good software engineers are modest.
“I developed the habit of considering myself as not being smarter than the rest, so there were a lot of people who could correct me. It doesn’t matter if it’s a junior developer or Linus Torvalds. Anyone can teach me something.” - Anton Kireev
Arrogance, the opposite of modesty, can be a mental blocker toward personal development, says Ruslan, giving an example of the Dunning–Kruger effect that can lead to arrogance. Cognitive bias means that people with low ability at a task tend to overestimate their ability. Without self-awareness people cannot objectively evaluate their level of competence. “Arrogance only gets in the way”, Ruslan warns.
The fact that you get paid more than many of your non-tech colleagues can also lead to arrogance - that feeling that we must strive to avoid. Despite being well paid, it is not programmers who bring money into the business.
[DS: Software developers may not make the money for a business, but they could lose $460 million in 45 minutes, as in the case of the largest US stock trader, which went bankrupt due to a dead piece of code.]
All of these traits of a good software engineer are glued together by a love for the craft that we do, and the desire to be a team player.
Next page: How to become a good software engineer