It’s Not About the Code

Since Lance Armstrong’s first autobiography, It’s Not About the Bike, which explored his journey as a promising young rider, through cancer and on to a Tour de France win, cyclists have bandied about the phrase and its opposite, “It is about the bike.”  When not about the bike, it might be about the journey, with the bike as a means to an end; when about the bike, it may be about the elegant beauty and simplicity of the machine, or still too, the bike may serve as a symbol of the freedom and athleticism of cycling.  In either case, they’re both right.

As software engineers, it’s often all about the code.  The code is usually what lured us into the profession.  It’s what we zealously protect in source code repositories; what we review for correctness; what we refactor for simplicity and even elegance.  We love new, and sometimes old, programming languages.  We love to talk about code, and we love to write code.

But, is it really all about the code?  Should we spend every moment of our working day coding, and only coding?  If so, we run the risk of being nothing more than a commodity coder, or “just a programmer,” and viewed, quite rightly, as simply a necessary evil to our employers.  With the commodity view of coding, it’s easy for an organization to outsource its software development.  When an organization wants only low-wage commodity coders, it’s also easy to proclaim a shortage of “qualified” candidates and lobby for H-1B reform

Except at the most junior levels, what does a software engineer or developer typically do?  Code, yes, but also analyze, design, architect, estimate, test, debug, mentor, write, teach, schedule, document, learn, coach, plan, prioritize, coordinate, evaluate, review, hire, … the list goes on.  Are these activities trivial and incidental to the purity of our calling, or an integral part of the art and science of software engineering?

Fortunately, many organizations do recognize the skills, both broad and deep, that are expected of their software engineers.  We engineers, in turn, need to ensure we’re more than simply coders.


Shock Jocks

The other week I read this:  Software Developers Are Terrified Of What Happens When They Hit 30.  The latest breaking news from CNN?  A supermarket tabloid alongside Shocking Proof that Obama is a Muslim!? No, this from the supposedly respectable Business Insider.  Has the dystopian world of Logan’s Run finally arrived, or is serious journalism on a holiday?

The author mostly cites a thread on Hacker News, which to my reading did not contain hordes of frightened 20-somethings agonizing over their imminent departures from relevancy in the tech world.  Instead, the thread contains many thoughtful comments from software engineers of varying ages and experience, mostly all saying they love what they do and the key to career longevity is to keep learning.

A more insightful article appeared in the New Republic a few weeks later, The Brutal Ageism of Tech.  This too focused on a fetishism with youthfulness – in the Silicon Valley – to the point of visiting a plastic surgeon to appear young and therefore relevant.

Articles such as these aren’t new, but why the steady drumbeat to spread fear, uncertainty and doubt?  Ageism certainly exists, but outside of the dorm room VR bubble of Silicon Valley it should not be sparking terror.  Young adults can bring energy and enthusiasm to a team, but despite what Mark Zuckerberg thinks they aren’t by definition smarter, yet the media is all too happy to accept this arrogant naiveté as fact.

Certainly 30 is usually a watershed year in one’s life, as the realization finally comes that You Are No Longer a Kid, as Mr. Zuckerberg may learn when he turns 30 next month.  Unless you’re a professional athlete, or a prodigy, most 30 year olds, regardless of profession, will just be hitting their stride both personally and professionally.  Why would this be true for a doctor or lawyer, but not for a software engineer?

On a related note, I’ve been listening to some of Shawn Wildermuth’s Hello World podcasts with various tech professionals, all of whom do seem to be older than 30.  They must not yet have encountered the terrifying and brutal truth.

Santayana Says

Some years ago I worked on a project that was not exactly a success.  Maybe not an outright failure, but more like a small-scale for its era.  At the time, I joked about writing an opus titled “Anatomy of a Failed Project” to record all the disastrous actions along the way.  I never did write it, and over the years lost my pithy observations to time.

Since I have much fresher memories regarding the challenges of a sputtering startup I thought I’d record a few thoughts now, rather than face the doom of repeating the past.  Rather than carp about the negative, I’ll offer a few positive prescriptions.

Do know your limitations.  Just because you are smart and good at some one thing does not mean you are good at everything.  Really.

Do hire quality.  Don’t assume that you can hire good people once your business is successful.  You likely won’t ever be successful without a quality team.

Do mind your business.  You can spend endless hours debating the latest Facebook news, but unless you are learning from their actions you might as well spend your time sorting nuts for all the value it provides. Apply the same attention and intellectual rigor to managing your company.

Do communicate honestly and frequently with your employees.  Your employees joined on because they believe in the vision.  Treat them with respect.

Do communicate honestly and frequently with your customers.  Your customers have made a bet on you.  Maybe they’ve paid for your product, maybe they’ve trained their employees, maybe they’ve effectively gone “all in” – whatever their level of commitment, they are counting on you.

Do treat your partners with respect.  If you’ve partnered with other companies, apply the golden rule and treat them as you’d like to be treated.

Do have a plan and execute it.  Don’t assume good things will just happen, that prospective customers will spontaneously flock to your product or that buyers will materialize from thin air.  Work it.

Do build a culture of respect, honesty and integrity.  A company’s founders will set the tone going forward.  Realize it, and build something you can be proud of.

There are of course many more “do’s” for a startup, but I’m already starting to forget them….

Hello, World!

I’ve looked almost everywhere, but can’t find the round tuit I’d pinned to my office wall back in another century. Oh well, it looked just like this:


There are other styles of tuit, but this one brings back a lot of memories and I’ll be sure to guard it more carefully.