Junior Developer: The Title You Should (Almost) Never Accept

I’ve had sort of a hate-hate relationship throughout my career with the title of junior developer.  Wait, that’s too nuanced.  Remove the “sort of” — I’ve just had a hate-hate relationship with the term.

This isn’t a job title you should accept, unless you have your back against the wall.  A prospective employer might say to you, “congratulations, we’re offering you a junior developer position!”  Treat this equivalently to “congratulations, we’re offering you a position at $10,000 below market value!” or “congratulations, you’re on your own for health insurance!”

If you’re hard-up, take it.  But keep your job search going full throttle, and keep your current “junior developer” role off your resume.  If you don’t have mouths to feed and rent to pay, take a pass.

Why?  Well, I’ll get to that.

Junior Developer Title on My Mind

Last week, unprovoked, I tweeted out my opinion of this title.  I don’t need to rehash that tweet here, since I’ve already explained my stance here.  But I got a thoughtful and reasonable question in response.

Can I ask what your reasoning is? In the past we’ve taken on people with no development experience & called them “junior”, & the day they get to drop that word from their title seemed to me to be a positive celebration of their progress in learning. But open to new perspectives.

— Russell Dunphy (@rsslldnphy) April 1, 2018

I didn’t respond to this because I’m terrible at Twitter.  In fact, I didn’t actually notice it for days and then I got busy.  I thought to respond at that point, but then I realized that I’m enough of a blabbermouth that I’d adjudicate myself much better in a blog post of 1,000+ words than I would in a tweet of 280 characters or fewer.

Then, coincidentally enough, someone mentioned me in another tweet (that I also didn’t notice for a while).

Got some responses. Need more! RT for reach. #DevDiscuss

CC: @raelyard @saltnburnem @ThePracticalDev @pavsaund @ReidNEvans @pryelluw @jonhider @rick_pack2 @daedtech @tednewardhttps://t.co/CSOivuE0oB

— Jose Gonzalez (@JoseGonz321) April 4, 2018

“How do you reward junior devs that are kicking ass?”

My initial, off-the-cuff thought?  Stop calling them “junior devs,” for God’s sake.  But I didn’t get the sense that was appropriate for the conversation.

Instead, I think it’s appropriate here, in a post telling you not to accept this title.

Read More

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

Amid 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

That’s true.  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