Transmuting Low-Value Programmer Cred into High-Value Status Illegibility

Not long ago, I wrote a post about that one, “top” software engineer role that companies don’t hire directly into.  I’m going to pick up where I left off there.

For a quick recap, recall the diagram I made (and my wife kindly GIF-ified for me).  In red, you have the positions that a company will hire into, and in white, you have that one position that they won’t.  It’s usually “Principal Engineer” or something like that.

A Recap of The Surface Narrative and the Real Motivation for This

In the last post, I talked about the surface explanation for this, accepted by idealists and pragmatists.

This role represents the most valuable software developers in the group to the company.  These developers combine technical skill with a certain je ne sais quoi that combines experience, domain knowledge, inside company baseball, and embodying the company’s values and training.

But I also talked about how that doesn’t stand up to scrutiny.  I talked about how if you picked the brains of leadership, you’d probably hear something like this.  (Assuming you also gave them truth serum.)

It seems like a win for everyone.  It rewards people for staying, makes us seem more prestigious, and it’s a non-monetary reward.  They love it, and it doesn’t cost the company anything to do.

Significantly, that top role that requires hanging around the company for years, serves a very pragmatic purpose.  It creates a position whose salary can creep up, unbounded, without dragging up the salary for the rest of the group.

In other words, create a bucket, put your lifers in that bucket, and give them 2% increases a year forever.  Without that bucket, you’d either (1) have to stop giving them increases or (2) potentially have to pay new hires a lot more.

So you create this policy to keep labor costs down.  And then you stand aside while the pragmatists and idealists manufacture and believe a merit-driven narrative.  Easy-peasy.

Read More

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