1. I still don’t quite understand
“How come you don’t know what BGP is?” “You’ve never heard of Rust?” Most of us have heard this type of statement, probably too often. The reason many of us love software is because we are lifelong learners, and in software, no matter which direction you look, the vast horizon of knowledge stretches in every direction and grows every day. This means you can spend decades in your career and still have a huge knowledge gap compared to someone who has spent decades in a seemingly similar position. The sooner you realize this, the sooner you can start to move away from imposter syndrome and instead enjoy learning from and teaching others.
2. The hardest part of software is building the right thing
I know it's a cliche at this point, but the reason most software engineers don't believe this is that they think it devalues their work. I personally think this is nonsense. Rather, it highlights the complexity and irrationality of our work environment, which exacerbates our challenges. You can design the most technically impressive thing in the world and then have no one want to use it. Happens all the time. Designing software is primarily a listening activity, and we often must be part software engineer, part psychic, and part anthropologist. Investing in this design process, whether through a dedicated UX team member or simply educating yourself, will pay huge dividends. Because how do you really calculate the cost of building bad software? It's not just lost engineering time.
3. The best software engineers think like designers
Good software engineers think deeply about the user experience of their code. They may not think about it in these terms, but rather whether it is an external API, a programming API, a user interface, a protocol, or any other interface; great engineers will think about who will use it, why it will be used, how it will be used, and What is important to these users. Keeping your users’ needs in mind is indeed the core of a good user experience.
4. The best code is no code, or code that does not require maintenance
All I want to say is "programmers can code". If you ask people in any profession how to solve problems, they will all make mistakes in the areas they are good at. It's just human nature. Most software engineers make mistakes all the time when writing code, especially when the non-technical solution is not obvious. The same goes for code that doesn't require maintenance. It’s easy for engineering teams to want to reinvent the wheel when many of them already exist. It's a balancing act and there are many reasons to develop your own, but beware of the toxic "not invented here" syndrome.
5. Software is a means to an end
The first job of any software engineer is to deliver value. Very few software developers understand this, let alone internalize it. Really internalizing this leads to different ways of approaching problems, and different ways of looking at tools. If you truly believe that software is subordinated to results, you'll be ready to truly find the "right tool for the job," which may not be software at all.
6. Sometimes you have to stop sharpening the saw and start cutting shit
Some people tend to jump right into the problem and start writing code. Others tend to want to study and study but are stuck in analysis paralysis. In this case, set yourself a deadline and start exploring solutions. As you start solving problems, you will quickly learn more, which will lead you to iterate towards better solutions.
7. You can’t design a good system if you don’t have a good understanding of the possibilities of the universe
This is a question I often encounter as my responsibilities take me further and further away from my day-to-day job of software engineering. Keeping up with the developer ecosystem is hard work, but understanding what's possible is crucial. If you don't understand what's possible and what's available in a given ecosystem, you'll find it impossible to design sensible solutions to all but the simplest of problems. In summary, be wary of system designers who haven't written any code in a long time.
8. Every system sucks eventually, get over it
Bjarne Stroustrup once said: “There are only two languages: the language that people complain about and the language that no one uses”. This can also be extended to large systems. Without the "right" architecture, you'll never pay off all your technical debt, you'll never design the perfect interface, and your tests will always be too slow. This is not an excuse to make things better, but a way to give you perspective. Worry less about elegance and perfection; instead, strive for continuous improvement and create a livable system where your team enjoys working and creates value sustainably.
9. No one asks enough “why”
Take every opportunity to question assumptions and methods of “the way things have always been done.” Are there new team members joining? Pay attention to where they are confused and the questions they ask. Have a new feature request that doesn't make sense? Make sure you understand the goals and what drives the need for this feature. If you don't get a clear answer, keep asking why until you understand.
10. We should be more concerned with avoiding 0.1x programmers than finding 10x programmers
10x programmers is a silly myth. It's foolish to think that someone can do in one day what another capable, hard-working, similarly experienced programmer can do in two weeks. I've seen programmers write 10x the code and then you have to fix it 10x the number of times. The only way for someone to become a 10x programmer is to compare them to a 0.1x programmer. Someone is wasting time, not asking for feedback, not testing code, not considering edge cases, etc... We should be more concerned about getting 0.1x programmers off our teams than finding the mythical 10x programmers.
11. One of the biggest differences between senior engineers and junior engineers is that they form their own opinions about how things should be
Nothing worries me more than senior engineers having no input on their tools or how to build software. I would rather someone give me an opinion that I strongly disagree with than have them have no opinion at all. If you're using your tools and you don't like or hate them in many ways, then you need to experience them more. You need to explore other languages, libraries, and paradigms. Nothing will improve your skills faster than actively exploring how others use different tools and techniques to accomplish tasks than you do.
12. People don’t really want innovation
People often talk about innovation, but they are usually looking for cheap wins and novelty. If you truly innovate and change the way people do things, expect mostly negative feedback. If you believe in what you're doing and know it will actually improve things, be prepared to fight the long game.
13. Your data is the most important part of your system
I've seen many systems where hope is the primary mechanism for data integrity. In such a system, anything that happens outside the golden path produces partial or dirty data. Handling this data could become a nightmare in the future. Remember, your data will likely outlast your code base. Putting the effort into keeping things organized and clean will pay off well in the long run.
14. Find the tech sharks
The old technology that has always been around is sharks, not dinosaurs. They are able to solve problems well enough to survive the rapid changes that are constantly occurring in the world of technology. Don't bet on these technologies and only replace them if you have a good reason. These tools won't be fancy or exciting, but they'll get the job done without a lot of sleepless nights.
15. Don’t mistake humility for ignorance
There are many software engineers who won't express an opinion unless asked to do so. Never assume that just because someone hasn't presented their opinion in front of you that they have nothing to add. Sometimes the loudest people are the ones we least want to listen to. Talk to the people around you and ask for their feedback and advice. You'll be glad you did.
16. Software engineers should write regularly
Software engineers should regularly blog, journal, document, and do anything that requires them to keep their written communication skills sharp. Writing helps you think about problems and helps you communicate them more effectively to your team and your future self. Good written communication is one of the most important skills any software engineer needs to master.
17. Keep processes as streamlined as possible
Everyone wants to be agile these days, but "agile" is about building things in small chunks, learning, and then iterating. If someone is trying to shoehorn more stuff in, they may be selling something. That’s not to say people don’t need accountability or help working this way, but how many times have you heard someone from your favorite tech company or large open source project brag about how great their Scrum process is? Keep your processes lean until you know you need more. Trust your team and they will deliver.
18. Software engineers, like everyone else, need to feel a sense of ownership
If you separate someone from the product of their work, they will care less about their work. I think this is almost a tautology. This is the main reason why cross-functional teams work so well and why DevOps is so popular. It’s not all handoffs and inefficiencies, but taking ownership of the entire process from start to finish and being directly accountable for delivering value. Give a group of passionate people complete control over designing, building, and delivering a piece of software (or anything really), and magic happens.
19. Interviews are of little value in judging how good a team member one is
It's best to use an interview to get a feel for who someone is and how interested they are in a particular area of expertise. Trying to figure out how good of a team player they would be is a fool’s errand. Trust me, how smart or knowledgeable someone is is not a good indicator that they will be a good team player. No one is going to tell you in an interview that they will be unreliable, abusive, showy, or never show up to meetings on time. People may claim they have "signals" about these things... "If they asked about time off in the first interview, they would never go there!" But that's all bullshit. If you use signals like this, you're just guessing and rejecting good candidates.
20. Always strive to build smaller systems
There are a lot of forces pushing you to build larger systems up front. Budget allocation, inability to decide which features should be cut, desire to deliver the "best version" of the system. All of these things are very powerful incentives for us to build too much stuff. You should fight this. When you build a system, you learn a lot, and you end up iterating on a system that's better than the one you originally designed. Surprisingly, this is a hard sell to most people.