The Curious Case of Not Hiring Directly into Software Engineer V (Or Whatever)

“What about the principal consultant role?”

“Oh, we don’t hire into that position.”

This exchange occurred over 6 years ago.  At the time, I was interviewing for a role with a consulting agency (or something calling itself that, anyway).  They had four salary bands for their developer/consultants, and shooting for the top wasn’t out of bounds with my experience level.  So I asked.  And then they told me about this policy by way of dismissing the question.

I’m not exactly sure why this instance stands out so much in my mind.  Perhaps because it occurred so explicitly.  But when I think about it, I think every salaried gig I ever had featured some kind of unique role like this at the top of the individual contributor set of software people.  In other words, at every job I ever had, there was always exactly one titular band — Senior Software Engineer II or Principal Developer or whatever — reserved only for the company’s dues-payers.

Not having been a wage worker for a long time, I hadn’t thought about this for years.  But I heard someone mention a corporate policy like this in passing the other day, and it got me thinking.

I dunno.  Call it nostalgia or whatever, but given my recent opting for whimsy with the blog, I figured I’d riff on this.

The Curious Case of “We Don’t Hire for X”

Stop for a moment, at this point, and think about how deeply weird this little corporate quirk is.  I mean, you’re probably used to it, so it might be a little hard to do this mental exercise.  Like the job interview, fundamentally nonsensical practices can create a sort of Stockholm Syndrome in corporate denizens.

So let’s blast away the cobwebs with a helpful graphic.  Below is the skeleton of what some org chart might look like.  As the GIF flashes, you’ll see color coordination.  In red, you have the positions that the company will staff from the outside.  Remaining clear, you’ll see all of the positions that the company has a policy to staff only via promotion.

Interesting, eh?  Trickling down from CEO to C-suite to VPs to directors to managers, you have positions that a company will staff from outside, if need be.  Sure, sometimes they may want to promote from within, and often they’ll do exactly that.  But companies will bring in outsiders for leadership roles.

They’ll also typically look for outsiders to fill any of the roles at the individual contributor level, from Software Engineer I through Software Engineer XVI, or whatever, depending on the richness and thickness of the HR matrix.

But then you’ve got that one… it’s always an impressive sounding title, and it’s always where individual contributors go to max out, collecting COLAs and generally demurring against nudges to management.

Strange, huh?

Read More

How to Write Emails People Won’t Respond To: Give Them Homework

From time to time in your life, you probably need to reach out to someone.  This might be someone you barely know or used to know.  It might be a complete stranger.

But if you’re reaching out to them, it’s probably because you want something or need something.  And if they don’t know you very well, you’re on thin ice from the get-go with this outreach.  This is easy to get wrong.

Today I’d like to address one of the biggest thematic ways that we all tend to get this wrong.  We mess this up by giving people homework assignments.

No Finger Pointing Here.  We All Do This, Me Included.

Before I go any further, let me confess to sending long emails.  I mean, to be fair, I go overboard with everything in text.  I tend to epitomize Blaine Pascal’s sentiment, “I would have written a shorter letter, but I did not have the time.”

In blog posts (or books), that can be a virtue when properly harnessed.  In emails, usually not.  How often do you receive a wall of text in an email and think, “oh, sweet, let’s dig into this?”

And yet, that’s what I tend to do, unless I fight myself.  So understand that nothing I’m saying here is intended as drive-by judgment of others.

Rather, it’s an examination of how we can fight the impulse to send self-serving communications — ones that inadvertently create homework for the recipient.

Empathize with Your Email Recipient

I own, as a partner or sole owner, 3 businesses.  One of those has dozens of people doing work for us, and another has me partnered with 2 folks in close proximity.  With these two business, I have something like 20 regular client companies with different people working for them, and I don’t know how many prospects.

This puts the number of people I potentially need to be responsive to at over 100, whether responding directly or delegating.  If all of them needed a lot of things in a week, I would work well over 40 hours just responding to them.

On top of this, I also have public-facing concerns.  I have social media (though these increasingly broadcast only), a blog, blog comments, books, and more Slacks than I can keep track of.  I’m a panelist on a podcast.  Oh, and I also have friends and family.

I say none of this to ask for sympathy or to humble brag (complain brag).  I love the businesses, the friends, the family, and the venues for public outreach.  And I also really do make a concerted effort to respond to everyone that reaches out to me.  (Ask my wife, who often asks “why are you still up” when I’m interfacing in these venues.)

I say this because, as someone with products, influence, and jobs to offer, I’m representative of who you might request a favor.  And I’m going to frame the rest of this from my perspective, which is also likely the perspective of someone that you’re emailing.

Read More

Politeness or Bluntness in Code Review? Settling the Matter Once and for All

These days I make a living producing content (or, increasingly, running a content operation).  As a result, social media and blogs have become more of a broadcast operation for me than a source of information.  Still, I had occasion recently to meander out of my bubble and observe a debate about code review etiquette.

The Code Review Etiquette Conundrum

Here are the two sides of that debate, paraphrased in my best attempt to inject no subjective bias.

• Code reviews can tend toward depressing and demoralizing for the reviewee, so make sure to include some kind of positive feedback.
• Manufacturing compliments is patronizing, so just stick to the facts and action items.

For the remainder of the post, I’ll use the relatively value-neutral framing of “subtlety vs. directness” to refer to these relative positions, with the idea that a continuum of sorts exists between them.

This incarnation was just the most recent.  I’ve seen this debate a lot over the years, and I’ve certainly spoken about code reviews before:

• Getting an annoying reviewer off your back.
• Automate it as much as possible to minimize the subjective human element.
• How code review culture becomes toxic.

So, as you can probably infer, I would be more likely to come down on the first point in the debate: be polite.  That’s not only my natural preference (politeness or just not doing them), but the product of my personal background and culture.  That’s a strong statement, so let’s but a brief pin it and then unpack it in detail.

We Assume the Subtlety vs Directness Question is a Conscious Choice of Personal Style

Reading the premise of this post, you probably start forming inner monologue immediately.  “Would it really kill you to just be nice for once?”  Or perhaps, “why would we waste a bunch of time beating around the bush with insincere games?”

That monologue then turns into the right way of doing things.  “Being nasty and constantly negative causes corporate turnover and makes our industry toxic, so we should stop.”  Or, “all of these games waste time and dilute the review process, hurting our production code.”  So think pieces on the subject become like this one about “spare me the compliment sandwich.”  You naturally think that your style is the right one and then seek to argue that everyone else should adopt your correct approach.

Code Review Rendered Trivial: The Ethnic Theory of  Plane Crashes

This looks a lot like the way we reason and argue about coding style.  But subtlety vs. directness is not that at all.  It’s heavily cultural.

Years ago, I listened to an audio book called Outliers, by Malcom Gladwell.  It’s a fascinating book, but what’s relevant here is its seventh chapter (summarized in detail here).  And now, anytime I hear a debate like this about code review, I think of Gladwell’s book and about Colombian pilots.

The Colombian pilots landed intensely in the subtlety camp.  The air traffic controllers at JFK airport in New York were decidedly direct.  And a completely avoidable tragedy ensued because of the impedance mismatch, so to speak, between these interaction models.

The Colombian pilots told the air traffic controllers that they were running low on fuel, and that they needed to land.  But they didn’t say (or yell) that they had an emergency on their hands, when, in fact, they did.  So the air traffic controllers reasoned that there was, in fact, no emergency and continued to put them off from landing.  The plane ran out of fuel and crashed.

If this approach can’t find easy resolution in a life or death situation, what hope do we have around a Github pull request or an IDE projected on the conference room flat screen?

Read More

Contrary to No One’s Demands, I’ll Blog about Whatever I Please

Since switching the reader question responses to Tuesdays, I don’t blog on Mondays.  Today I’m going to make an exception to write sort of a meta-post.

Categorizing it as an “announcement” would be a little too grandiose.  Instead, it’s kind of an explanation for my regular readers and something that I may link back to in the future for reference.

I’m reconsidering how I think about the DaedTech blog.

I’m Not Doing Anything Drastic with the Blog

Having said that, let me pump the brakes on any speculation about a pivot.  There won’t be one.  I’m not going to suddenly start blogging about knitting or something.  I’m not going to monetize the blog in a different way (except that I did recently remove the paid ads from DaedTech).  And I’m definitely not going to stop blogging.  I honestly don’t think I’m capable of not writing.

I mean it when I say I’m reconsidering how I think about the blog.  I’m going to start approaching topics differently and writing somewhat differently.

In short, I’m going to back for writing this blog purely for the fun of it.

Read More

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