The Senior Software Engineer
Yesterday, my former colleague Dave Copeland published his second book: "The Senior Software Engineer". Dave gave me an advance copy to review, so I'm fortunate to have already read it. I'm biased from working with Dave and seeing the quality and consistency of his work. That disclaimer aside, I think the book is great. Go buy it.
The premise of the book is that software isn't valuable in and of itself but creates value through what it does. The responsibility of a senior engineer is to figure out how best to consistently create value.
The book is a distillation of the skills and techniques you need to progress from a job where you implement pre-defined specifications to someone who takes vague problem statements and creates demonstrable value.
You can guess which of those job descriptions I find more fun, interesting, and lucrative.
Who the book is for
Dave's target audience are junior engineers looking to advance to positions of greater freedom and responsibility. The book is invaluable for that group. I wish someone had given me a copy of this book ten years ago. The relentless focus on results over "progress" is something it took me some time to learn.
That said, I think the book will also prove immensely valuable to senior developers, particularly those who are leading teams. I found several sections of the book clearly stated some of my strongly held but poorly articulated beliefs. In the future, I will definitely steal some of Dave's examples when I'm coaching junior developers.
A word of caution
I am mildly concerned that certain sections of the book will come across as more dogmatic than I think Dave intended. Having worked with Dave I know that he is anything but dogmatic.
In one chapter Dave describes his process for implementing a minor feature. When written out, it may come across as somewhat ceremonious and rigid. However, I think that is just the result of committing a simple, lightweight process to paper. When written out in detailed form even making a peanut butter sandwich can look complicated.
He proposes you should internalize a simple process for fixing bugs or creating features that ensures you understand the problem, fix it quickly, and leave the code in a maintainable state. What he describes is a formalization of the steps most successful developers I know already follow implicitly.
As you read through the book, keep the central value of the book in mind: producing results is what matters. The internal processes Dave documents are tools for accomplishing that, not religious doctrine to be followed blindly.
Dave had written a previous book (Building Awesome Command Line Applications in Ruby) published via the Pragmatic Programmers. This time he's self publishing.
There is a buzzword from the bubble in the 90's that I still find interesting: disintermediation. This is the process where the internet removes middlemen. So instead of going to a travel agent to book your flights you can go directly to Southwest.com.
The same thing has been happening in publishing. To their credit, the Pragmatic Programmers are a radically different type of publisher. They by all accounts have a better tooling for writing a book than other technical publishers, they pay fair royalties, and they have helped many engineers become authors.
Still, you're now seeing people like Dave and Jesse Storimer from Shopify cutting out that even lighter middleman. In a world where you can build a medium-sized niche audience via blogging and twitter I'm not sure publishers are necessary.
A publisher does provide help with editing, type-setting, and distribution. But—particularly after going through the process once—you can hire editors, learn how to reasonably typeset a book, put up a website and take advantage of lightweight distribution mechanisms like digitaldeliveryapp.
Given the larger, built-in audience of the Pragmatic Programmers I imagine Dave would have sold some more copies of his book. But would he have sold twice as many copies? I'm not sure, and that is what he would need to do to cover PragProg's very reasonable 50% commission (other technical publishers supposedly take 80-90%)
I'm intrigued to see how the self-publishing experiment works out for Dave. My completely uneducated guess is that self-publishing will prove more profitable. Although, this is still a technical book so I don't think Stichfix is going to be in danger of losing Dave to a full-time writing career any time soon.
More Articles on Software & Product Development
- Agile With a Lowercase “a”
- ”Agile“ is an adjective. It is not a noun. It isn’t something you do, it is something you are.
- How Do You End Up With A Great Product A Year From Now?
- Nail the next two weeks. 26 times in a row.
- Build it Twice
- Resist the urge to abstract until you've learned what is general to a class of problems and what is specific to each problem.