If You Only Take Away One Thing
Here’s the most important lesson in this whole book: you need to own your own career, because no one else will guide you. Good mentorship can be wonderful for the .01% of engineers who find it, but in all likelihood, you are going to teach yourself 99% of everything you’ll learn as a professional; great projects may fall into your lap once in a blue moon, but more often, you’ll have to find your way to them yourself. Therefore, the most important tools in your toolbox are going to be personal responsibility and initiative; those qualities are what make you a trustworthy (and valued) professional, but also how you grow and advance. We’ll discuss this principle in many contexts throughout the book.
<aside> 💡 Software engineers design, build, debug, and maintain software systems, which is to say they write text that tells computers to do useful things.
</aside>
At the time of this writing, these skills are some of the most sought-after in the global economy.
This work can take many forms. Some engineers are generalists, with the skills to make changes in almost any system, while some are specialists with profound expertise in one area; some maintain and improve existing systems, while some write new ones from scratch; some move from project to project, getting things working and moving on, while others own and develop one system for years. Some of us work at companies whose main product is software, while others work on ancillary systems to help produce a non-software product or service. Day to day, though, the foremost qualities of our work are more or less the same:
Building a Career in Software: A Comprehensive Guide to…
Engineering is the enterprise of building and applying technology to solve problems, and I find joy and comfort in the observation that whatever the pros or cons of any one project, the world needs people who build things. My definition of growth derives from this observation: if we exist to solve problems, then growth is being able to solve more tougher, and bigger problems. We do so with a vector of skills built over time:
Clarity, testing, documentation, discipline in scope of diffs, code review (have a sense of what could go wrong), have your coding preferences.
Clear messages/emails (others don’t need to ask again), evangelizing our ideas, engaging presentations (make good slides?), writing skills (post-morterm, incident report, performance review), how to run a meeting effectively (send meeting invite in advance, follow-up, know when and where to cut short on others)
Communicating with your manager
Your manager might not know what you are doing. Hence it is imperative that you prioritize communication with your manager. Share what you are working on and your progress to make sure you are aligned on timeline and expectations and avoid last minute surprises. Share your difficulties and blockers so that your manager can help you fight for more time, manpower, or reduced scope of the project.
Communicating within the team
Effective communication is important when working on a project together with other teammates. Making sure that the work is divided among developers with clear boundaries and responsibilities helps to reduce overhead and confusion. Healthy team dynamics can boost productivity and happiness for everyone in the team.
Communicating with other teams
When communicating with product managers, designers and other functional teams, the ability to clarify business requirements can reduce wasted efforts or even lead to better solutions. Even casual catch-ups and coffee chats can open up new opportunities for cross-team collaboration and projects.
Sharing your work
Sharing your project regularly within your team or during organization wide sharing sessions increases awareness of your work. Such visibility and recognition is important if you are looking for promotion to senior software engineer.
Not dropping balls, prioritizing effectively, managing up, have your checklist, maybe something as simple as the following would work.
The macroscopic design of systems.
Identifying dependencies, updating stakeholders, tracking tasks.
At a level appropriate to their position.
Empathy, confidence, stress management, work–life balance.
👉 Developing on each of those dimensions is certainly growth. And when we apply those skills successfully, we enjoy four pleasing and necessary benefits:
Acquiring each of the above is satisfying and practically beneficial. All of the preceding skills can be dissected in great detail, and much of this book does exactly that. I ask you to remember, though, that everything derives from our essential raison d’être as problem-solvers: the world needs problems solved, so companies need engineers who can solve them, so our impact is the foundation of our career progress.
No one knows a reliable way to measure the difference between a good engineer and a bad one; therefore, no one knows how to interview engineers, and we are obliged to rely on intuition, with all its flaws. Anyone who tells you that they do know how, and many people will, is arrogant; the best you can hope for is a relatively persuasive intuition.
A good interview process would select for engineers that help the company succeed; the rigorous design of that process would require first telling the difference between high-performing engineers and low performers, then identifying qualities that predict good performance. For example, if we asked the same 5 questions of 1,000 hires, and knew which performed well and which poorly, we could try to figure out which questions gave the strongest indication of future success.
In reality, we don’t even know who is truly a high performer and who a low performer; in this domain as well, we rely fully on our intuition—managers basically just use their judgment. And even with the data we do have (i.e., internal performance reviews, flawed though they are), I personally haven’t encountered attempts to assess the predictive power of interviewing methodologies.