Copyright ©2014 by David Bryant Copeland - The Senior Software Engineer

Thanks to my wife, Amy, for giving me the space, time, and encouragement to work on this book (as well as her keen copyrighting skills).

Id also like to thank the amazing developers Ive worked with over the years including Jeff Barrett, Thomas Copeland, Patrick Joyce, Jeff Kolesky, and Tom Vaughan, who were kind enough to review a draft of this book. Also, thanks to Adam Morse who designed and build the books website (as well as encouraged me to learn about typography before typesetting this book).

Welcome to the start of a what I hope will be an exciting, enlightening journey that takes you from competent code monkey to truly senior developer. At the end, youll be in charge of your own destiny, able to work with everyone on your team, and even lead them to deliver huge value to your company or organization. The key isnt some new framework or programming language, but to fully embrace the position of software engineer as something more than just writing code.

Dont get me wrong - this isnt a book about being a middle manager of a software team. Its a book about all the skills you never realized you needed to cultivate when writing code. Skills like working well with others who have different priorities than you. Skills like writing. Skills like leading a team without giving up writing code.

At the time of this writing, Ive been a professional programmer for over 18 years. Ive worked for product companies, both consumer and enterprise. Ive been a consultant. Ive been a government contractor. Ive worked as part of a 3 person team at a startup, and a 100+ person distributed team at a large multi-national company. And it wasnt until 2012-16 years in-that I truly understood what a senior software engineer really is.

In most companies, senior typically refers to a rank within the company. A senior analyst outranks a junior analyst: they get to make more decisions and, at least on paper, have more control over the direction of the work being done.

In our field, senior usually means you have about three years of experience, or did a good job negotiating a title when applying for work. The result is that most developers at most companies have senior in their title. Ive had senior (or better) in my title for most of my career.

Programmers tend to be a merit-based bunch, and the product of our work - computer programs - are far more objective than what most other people produce at their jobs. Because of this, implicit leaders will emerge amongst a group of senior developers. Job titles rarely reflect who has the most respect, or who can be trusted with the most important tasks. What took me so long to learn was that that trust and respect isnt borne entirely of programming ability, but of a well-roundedness that can be difficult to quantify.

To be a trusted, respected developer, whos rightfully seen as a leader, requires more than just coding chops. It requires a higher-level view of the purpose and function of software engineering in most organizations, and a dedication to that purpose. The purpose, of course, is simple: deliver results with software.

In many organizations, someone else figures out what the company needs and then directs the developers to deliver something that should meet those needs. While this seems logical, the best developers I know dont entirely rely on this. They instead align themselves to the companys needs, rather than wait around for instructions on how to meet them.

These developers arent stuck in management, either. They code, and they usually work on the most important, most challenging, or most fun aspects of the systems they create. These developers, by making their organizations goals their goals, have control over their careers, and earn trust and respect, through simple demonstration of ability. Put simply, they get the best jobs.

This book will outline ten major areas of your career to cultivate. Primarily, each chapter is designed to express the importance of that area to you as a developer. Each chapter also contains specific information on how to develop your skills in these areas, often very prescriptive. These instructions arent the only way to develop your abilities, but they will serve you well if you find yourself overwhelmed by the task of, say, convincing your non-technical boss to use some new framework.

Each skill well discuss builds on the skills previous. As such, well start out where were comfortable: coding. Well outline a simple and effective personal process for fixing bugs that works in any environment before expanding on that process to include implementing major features in existing systems.

Next, well enter the realm of personal interaction. Well start by talking about technical debt and sloppy code, since these have the biggest effect on software thats visible to the non-technical outside world. Next, well talk about working effectively with all sorts of different people, which is so important, yet can be so difficult.

The second half of the book is a course toward being a true leader. We start with making technical decisions and arguments amidst a wash of conflicting priorities - a skill youll need later when we learn how to successfully bootstrap a new application. Successfully creating an app from nothing requires the ability to write effectively, and well discuss that as well.

The last three chapters are about building, being a responsive part of, and ultimately leading a team. Well learn how to conduct a technical interview, manage our time without getting lost in the code and finish the book with a whirlwind tour of a technical leads responsibilities throughout the lifecycle of an application, from starting it off, to delivering it, to leaving it behind.

For the second edition, Ive also included three new essays on being a senior software engineer. Engineer As Product Manager encourages you to take an active interest in the business youre a part of. Production is All That Matters discusses the importance of running software and how you should take a strong interest in how yours behaves. Responsible Refactoring expands on this to talk about how important it is to stop fiddling with working code, and how to know when a re-design is the right thing to do.

But first, we need to talk more about aligning your goals with those of your company. We need to shift our thinking from coding up features to a focus on delivering results in everything we do.

A senior software engineer is trusted and expected to do the most important work and to do it reliably. The way to accomplish that is to focus everything you do on the delivery of results.

At a previous job, I was responsible for the purchasing and refund logic of a large e-commerce website. One day, Mary (one of our customer service representatives) emailed me with a problem. Mary was attempting to refund a customer but the system wouldnt let her, instead giving her a cryptic error message.

I didnt immediately know what was wrong, so I was about to write her back with the message Ill look into it, but I stopped. What value would Mary get out of such an email? What purpose would it serve to send her a promise, but no real answer? I decided that she deserved exactly one response from me: an email with a definitive answer in it.

I did some research and realized that a constraint of our credit card processor was preventing the type of refund she was attempting. She would have to wait 24 hours from the time of purchase for the refund to go through.