Let Brad Code

I'll never forget M.

M was my mentor, and we didn't always get along.  I chose him as a mentor because we didn't get along.  I needed someone who had different perspectives than I did.

Anyway, one of our early meetings, I talked about people at work I admired.  I expressed that I admired a guy we'll call Brad.

Brad was a guy I'd worked with many times.  He was part of senior leadership, and he still found time to write code, on the evenings and weekends if necessary.  At the time, his architecture team was embroiled in doing the scut work of rolling-out "Agile Development" to a hardware-development organization.  (Another really long post for another day....)

....but M wasn't so happy about it.  M was a Principal Engineer (there's another name for it there, but let's just call it 'Principle') and he took a dim view of people that wrote code at that level.

"Do you really think Brad should be writing so much code?" he asked.

"Umm.....yes."  I was slightly dumbstruck.

* * *

I'm not so naive that I didn't get M's point.  He was thinking opportunity cost.   Brad was paid 10-20x what developers in our offshore developer offices pulled down every year.  From a total cost perspective, it made more sense to have him lead 20, 40, or 100 developers and optimize their stuff and the overall systems architecture, versus him mashing a keyboard 8 hours a day pounding out embedded C code.

I get that.  It makes sense, logically, but there are several fallacies there.

Outsourcing

Almost from the beginning, this blog has been about the massive outsourcing in the United States in the late 1990's.  Companies viewed their IT departments and programmers as a cost center, and so they sought to outsource to consulting firms like IBM Global Services, or they spun up their own development centers worldwide and outsourced to their.  My former employer did the latter, spinning up shops in Kolkata, India, and Cebu City, Philippines.

Charitably, results were mixed.  In two clauses, India got expensive and insubordinate (not that I blame them!), and Cebu had to sustain 40% turnover year to year.  Neither was entirely tenable.  

On a spreadsheet, it certainly seems better to have 100 developers instead of 10, or pay 1/10th the price for the same widget.  It just never quite works out that way, you need either.  "Making outsourcing work" with a Business Analyst / Remote Dev team model is possible, with enough detailed specs.  However, this adds years to your product cycles and eventually you lose.  Your competitor with a colocated development arm will destroy you.

"Growing Beyond Coding"

We've all met this guy.  We've interviewed him occasionally:  "Oh, yeah, I'm certainly good enough at the tech stuff, but what I really want to do is get into Management and Architecture, the place where the real decisions are made." 

Go vomit.  I'll wait.

IMO, anyone you want anywhere near your product will never espouse that attitude.  We get into this business because we love solving problems, and we generally like the thrill of making computers do our bidding in the most efficient and AWESOMESAUCE way possible.  I don't think you grow out of that.

Counterpoint:  Another (unofficial) mentor of mine, A, once told me, "You know who the real architects are?  They're guys like Bill, and Seth, and Brandon....guys who make 100 decisions a day about how to do stuff in the system.  They're the people implementing things.  That's real architecture."

If you can't tell, I agree with A very much.

* * *

The New  Model (Developer) Army

What's really changed since the Architect / Business Analyst / Peon Programmer model arose in the 1960's is the tooling.  We now have high-level programming languages, IDEs, and test/integration tools that allow one developer to do the work of 20 from 1990 and perhaps 5 from 2000 when I started.  It's entirely practical for a two-pizza-box team to deliver significant function, and that's the model most startups follow today.

In sum, don't take your 'Brad' developers and take them away from the code.  They need it, and you need them to stay in it.  Consider how you might rearrange things so they're still influencers across the organization and they're still making daily commits.  

I believe you'll like the results.