A New Way to Measure Software Careers

How do you measure the progress of software careers?  I don’t mean rhetorically — give it some thought.  As a software developer working your way through the workforce, subconsciously optimizing for AMP, how do you evaluate yourself?

I can think of some things that probably flash into your head:

• Salary (AMP notwithstanding).
• The modifier attached to the title, “software developer” (preferably “senior” or ideally “principal”).
• Languages learned or mastered.
• Maximum cachet of employer (perhaps culminating with an Enterprise Silicon Valley gig).
• Progress toward management.

Maybe you have others.  Weigh in below in the comments if so — I’m honestly interested to hear.

Anyway, today, I’m going to propose a different one.  At first blush, this measure seems kind of binary.  But I think there’s actually a subtle continuum, and this post will explore it.

So, how do I propose we measure progress in software developers’ careers?

Simple.  Your career is as mature as the degree to which you control the decision about whether or not to write software.

What Does It Mean to Decide Whether or Not to Build Software?

Before I get into the progress spectrum I mentioned, I should probably justify my assertion and elaborate a bit.

First of all, when I talk about the decision about whether or not to write software, I don’t mean it in some kind of granular, micro-sense.  I don’t mean that you have the autonomy to decide whether to roll your own logger or to use Log4j.  I don’t even mean that you’re an architect and you can push back on the business about technical feasibility in the short term.

No.  I mean that you make the business decision about whether or not to write software.

For instance, say you’re a free agent that specializes in helping mom and pop retailers establish an online sales channel.  When Mom’s Gourmet Macademia Nuts calls you and contracts you to help, you decide whether to build a custom web app, use Shopify, or send them to Etsy.  (Or whatever — this isn’t exactly my forte.)  Mom asks you for help, and you decide whether or not writing software should be part of that help.

Or take me and my content business, Hit Subscribe.  In order to earn my CTO designation on LinkedIn, I’m handling the business’s technical decisions, including whether to delegate tasks, automate them with off the shelf products, or build custom automation myself.

That’s what I mean about the build decision.

Read More

Whiteboard Interviews: How to Avoid Them and Improve Your Career

As I mentioned last Friday, I’ve lost track of the number of folks who have shared Michael Lynch’s piece about quitting Google with me.  I suppose I should expect that, since I often rail against hiring practices that people associate with Google and similar companies.

This includes the titular whiteboard interviews, of course.  And, for good measure, I’ve even written a book in which I suggest simply not agreeing to do this style of interview.

Interestingly enough, though, I don’t have anything in particular against Google at all.  Nor do I have anything against its contemporaries, all of whom I am coming to think of as Enterprise Silicon Valley, given their legacy of innovation combined with their increasing resemblance more to the IBMs and GMs of the world than the hottest new startups.

I wouldn’t agree to interview at these companies, but that doesn’t mean I don’t like them.  I mean, I like Chrome and Gmail and have an Android phone — keep pluggin’ away, guys.

I’ll even go so far as to say I don’t begrudge companies using whiteboard interviews nor do I think that it’s a bad idea for them to do so, in some cases. 

But I’ll come back to the nuance of that later, leaving a dangling question of my hypocrisy until I do.  In the meantime, I want to share a tweet and a story of my own failure to follow up on messaging.

A Twitter Conversation about Breaking into Software

Amidst my (now often overwhelming, sorry to anyone who tweets at me and I don’t see it) mentions on Twitter, I noticed this one from a few days ago:

Aw thanks @daedtech has a good section in his book Developer Hegemony about why you should refuse to do these interviews and how to do it pic.twitter.com/c4rCkdtMGT

— Melissa McEwen (@melissamcewen) March 5, 2018

Melissa channels my take absolutely correctly.

In the part of Developer Hegemony where I explain my take on the path to, well, developer hegemony, I offer that advice.

Simply refuse to do whiteboard interviews.

Define and manage your career in such a way that you don’t need to do them.

The book covers a lot of ground, so I don’t place a ton of detailed emphasis on that point.  But I think that I should have followed up with some content that did.

Zoom out and look at the conversation.

Melissa’s tweet comes in response to someone named Daniel asking about resources for breaking into the programming world.  He appears to be attempting to synthesize the advice of people in that world, concluding that, no matter what, breaking in requires knowledge of “data structures [and] algos.”

I’ll leave it as a reader exercise to consider whether entry level work banging out forms-over-data web apps requires theoretical computer science experience.

Read More

Salary Transparency as the Fault in Our Stars

A few years ago, Hollywood produced a movie that I didn’t see and still haven’t seen, entitled The Fault in Our Stars.  I assume this movie’s title riffs on a quote from Shakespeare’s Julius Caesar.  And it is that quote to which I refer as a segue to talking about salary transparency.

The fault, dear Brutus, is not in our stars,
But in ourselves, that we are underlings.

I read Julius Caesar in high school, but if I dust off my literary dilettante credentials, I kind of remember what this meant.  Cassius, the speaker, was telling Brutus, his eventual co-conspirator that fate/the divine wasn’t installing Caesar as a monarch.  Instead, they were, by acting as underlings.  Cassius was saying, “God isn’t doing this — we are, with our inaction.”

And, naturally, this relates to the idea of salary transparency.

Salary Transparency as a Radical Workplace Idea

If you’ve never heard of salary transparency, that’s understandable, particularly if you live in the US.  Ever gone out to dinner with friends and asked to compare salaries when arguing over the check?  No, of course not.  Telling other people what you earn is considered gauche.

If this is true in social situations, it’s doubly true in the workplace.  You don’t wander over to Doris’s cube plop yourself down and say, “so, whaddya make per year?”  This is really gauche, and you could get in trouble.  As I describe at length in my book, Developer Hegemony, pyramid-shaped companies have a natural and rational incentive to hide this information.  In fact, so strong is this policy that they’ll create company policy of questionable legality.

The reasoning here is simple enough.  When negotiating, the less information your opponent has, the better.  If, at salary negotiation time, you know that everyone else in your role earns at least $90K per year, you’re going to hold pretty firm at $90K.  If you have no idea, you might lose your nerve and accept a job for $80K instead.

Now, you might object to me categorizing your employer as your opponent.  But you shouldn’t.  Salary negotiation is, ipso facto, a zero sum game.

But what if your employer didn’t hide this information?  What if your employer made all salary information publicly available the way sports teams and non-profits do?

Read More

What Do I think of “Full Stack” Development and the DevOps Movement?

Once again, I’m doing reader question Monday on a Tuesday.  I have no good excuses this time, either.  We arrived last week in San Diego, which is beautiful.  So, I’ll just flat out admit that I spent the weekend strolling beaches, eating lobster tacos, drinking craft beers, looking up at the stars and just generally enjoying life in a way that involved no writing of blog posts.  I regret nothing.

So let’s to reader question Monday on a Tuesday.  This is actually a question that just came in today as I was gearing up to write about TDD and remote teams.  It caught my attention, so I’ll give about the fastest turnaround time I’ve ever done on a question.

I recently stumbled upon this article: https://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/

Which seems to lump Full-Stack dev in with DevOps, and discards DevOps, on the premise that the full-stack dev is good-for-the-org-bad-for-the-dev. I know you’ve weighed in against the full-stack dev with preference for specialization. I wonder if you believe this also means DevOps is DOE, or if there’s still room for DevOps in your mind (or perhaps more broadly speaking, for startup-like, feature-teams so often found in Agile/Scrum orgs)?

If you don’t like DevOps, what do you recommend instead to manage the entire release automation process, and everything else it entails?

Alright.  There’s a lot for me to work through here, so let’s break things up a little.

DevOps (And Full Stack) is Killing “The Developer?”

First, let me recap briefly the article’s thesis.  And I’m really going to try to be gentle here and non-objectionable.  I trade in blog posts for a living these days, and slugging it out with random people on the internet has worn as thin as it can possibly wear to me.  I’d really rather not argue with this Jeff Knupp, and I can certainly empathize with waging a vigorous campaign to make your own job more fun.

The article’s thesis is, essentially, this, from the perspective of a salaried employee in the enterprise.

I hate the DevOps (and full stack) movements because I like writing code and they result in me writing less code.

The author might object to this thesis, but that’s really the message.  It asserts the superiority of the software developer as compared to other individual contributor roles, and then argues that DevOps and full stack (and forced skill diversification in general) are good for the employer, but bad for the employee.  (Although he then curiously argues that it’s also bad for the employer, since they’re “overpaying” for non-development labor.)

Read More