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 close to 30 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 need to be responsive to at something like 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

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