5 Things I’ve Learned in 20 Years of Programming

This year, I’ve become increasingly acquainted with the DEV platform.  It’s a refreshingly positive oasis in the large sea of angry Reddit commenters and “well actually” connoisseurs that is the broader software world.

One interesting facet of this community is that it seems pretty beginner-heavy.  I regularly see posts written by and for industry newbies.  And by newbies, I mean folks that are aspiring programmers, in bootcamps, looking for entry level work or in roles with the unfortunate “junior” qualifier.

I find this enjoyable.  Relative newbies are generally enthusiastic and excited about the industry.  And that excitement is infectious.

But it also makes me feel my industry greybeard status.

I think of what I remember Bob Martin saying on a podcast or in a talk or something.

The demand for programmers has grown so dramatically over the last 4-5 decades that the number of programmers is always doubling every five years.  As a result, a programmer with 5 years of experienced has more industry tenure than half of the entire industry.

Old Man Status

I’m now pushing 20 years in the industry.  I spent about 10 of those in roles where my primary function was to write code.  The other 10 have involved managing programmers, coaching them, consulting with organizations about how to manage them, running a codebase assessment practice and these days, well, actually content marketing.

But in all of these roles I’ve written code to varying degrees.

By my calculations of geometric programmer growth, this makes me more grizzled than 94% of the industry.

So we have a bit of a juxtaposition.  I’m a programming lifer hanging around with a bunch of programming newbies.

This made me wonder to myself, “if I could summarize this experience into succinct bits of advice, and assuming that anyone actually cared, what would I tell these folks?”

And that’s the premise for this post.  The following are the things I consider to be the most important lessons and takeaways from a 20 year programming career.

Read More

Let’s Put Some Dignity Back into Finding Software Work

Hiring in software is broken, the internet reminds us on an hourly basis.  Here’s an article, updated a few days ago, on the subject.  It quotes a tweet from a month ago:

Technical Hiring is broken. We are hiring for a developer on my team and I have a chance to make this process better. Please let me know what and how you have made it better on your teams, I would love to learn from your experiences.

— Jinsy Oommen (@thegoodoommen) August 19, 2019

I found that with precisely 3 seconds of hard-hitting, investigative googling.

Of course, I’m hardly a neutral bystander in this conversation, having weighed in with my own “hiring is broken” post.  And, I take it further than most, holding the opinion that the job interview itself is a highly questionable institution. (If you’re more interested in my rationale, check out this video segment).

But today I’d like to not only lay out the problem, but spend some serious time laying out my own stab at a grassroots solution.  To do that, I’ll walk through what I perceive to be the core, underlying problem with the hiring process, and talk about what we’re doing differently, and how we can scale that out to more of the software industry.

You’re an Incompetent Liar

Let’s take off the gloves and be completely honest about the undertones of a job interview.

Come on in and sit down, please, candidate.  Now, as you’re obviously aware, the majority of people who come through that door are incompetent liars, looking to trick us into hiring them so that they can goldbrick indefinitely.

Luckily, we’ve developed a series of riddles, questions, homework assignments, and snap judgments that will allow you the generous opportunity to prove that you aren’t human garbage, like the rest of the people in the lobby.  Can I get you a bottled water or a coffee before we get started, %&$#er?

At its core, the job interview assumes some combination of incompetence and deceit.

Don’t believe me?

Ask yourself why, then, so much interview question wisdom involves self-congratulatory rhetorical chess games.  Ask if they have any questions for you because, GOTCHA, the REAL purpose is not to answer their questions, but to see if they’ve prepared!  Or, maybe ask them about their basic math skills.  Not because you want to know, but because you want to trip them up and see if they’ll admit error.

This is, at its core, not really a dignified process.  It doesn’t treat the company and candidate as two professional adults assessing mutual fit.  Instead, it casts them as patient teacher and problem child, respectively.

So, let’s fix that, shall we?

Read More

Don’t Let Anyone Tell You that You’re Not a ‘Real’ Programmer

Apologies for my absence last week from the tech pundit-o-sphere.  I was, well, what I mostly am these days: busy.  But today, I’m back with a premise that sounds suspiciously motivational-speakery.

Don’t worry, though, realpolitik fans.  It’s not that.  Not exactly.

Sure, don’t let anyone tell you that you aren’t a ‘real’ programmer because (1) that’s a crappy thing to say and (2) because you’re awesome and all of that.  But I’ll leave those lines of argument to others.  Instead, I’m going to talk about why letting this nonsense into your head is bad for your career and your positioning.

The No True Scotsman Fallacy

First, though, let’s wander down to the anthropology dime store and categorize what we’re dealing with here.  When someone tells you, for whatever reason, that you’re not a ‘real’ programmer, they’re most likely indulging in something called the “no true Scotsman” fallacy.

The gist of this is to create a subjective, moving-goal-posts purity test for membership in some club.  And people generally do this as a direct follow-up to painting with too broad a brush and having  someone subsequently call them on it.  For instance, here’s the eponymous example, quoted from the Wiki article:

Person A: “No Scotsman puts sugar on his porridge.”
Person B: “But my uncle Angus is a Scotsman and he puts sugar on his porridge.”
Person A: “But no true Scotsman puts sugar on his porridge.”

In my personal experience with purveyors of this fallacy, I generally see two principle motivations, often intermixed:

1. Zealous, subjective belief in the purity test itself.
2. Having made a strident claim before really thinking it through, accompanied by a personal tendency never to back down afterward.  (Sound familiar?)

Now, take a dash of this part of human nature, mix it into a heaping bowl of the internet, bake it in the oven for 20 years, and get ready to enjoy a bottomless casserole of “why you’re never good enough.”

The Many Flavors of ‘Not-Real’ Programmers

By now, you might find yourself nodding along, imagining programming-oriented statements like this.  Maybe people have painted you with a brush like this, or maybe you’ve just seen them do it to others.

• No real programmer works heavily with CSS and markup.
• Real programmers use the command line — not user interfaces.
• In 2019 you’re not a real programmer if you’re using anything but git.
• No real programmers just use their IDE out of the box, without customizing it.  (Also, bonus for, “real programmers use VIM and not IDEs.”)

I imagine these statements sound quite familiar.  There sure are a lot of armchair arbiters of ‘real’ programming, aren’t there?

So, having defined what this is and given examples of how to recognize it, I’d like to spend the rest of the post talking about why this type of seemingly-minor bloviating is actually insidiously pernicious for those exposed to it.

Read More

To Find a Niche, Learn Why Your Company Pays Your Salary

My belief in picking a niche for yourself becomes obvious to anyone who reads more than a post or two here.  I’ve written too many posts about it to list, and I talk about it on my Youtube channel these days.

But today, I’d like to reference a couple of specific posts where I talk about this in order to flesh out a concept.  Here are those posts.

1. Just under 2 years ago, I wrote a post about how you could pick a specialty with the help of your resume.  My advice was to look at the “key accomplishments” sections and start brainstorming with those.
2. Earlier this year, I wrote a post about picking a niche.  And, in that post, I distinguished between generalizing, specializing, and niching.  Specializing involves looking at your own skill set, picking something you like, and hoping people want to pay for it.  Niching involves looking at needs that others have and filling those needs.

Here’s the gist of what I want to talk about today.  2 years ago, I gave advice that would indeed help you pick a specialty.

But, I actually think that it’s, at best, locally maximizing advice to help you pick a niche.  So I’d like to course correct a bit with my advice to the countless people that ask me for help finding a niche.

Read More

Celebrating Software as a Tactic, Not a Profession

As you may recall, a few weeks back, I offered the hypothesis that software is a business tactic, rather than a profession.  My main purpose in writing that post was to level set a bit with my desired direction for the blog, leaning toward an increase emphasis on reader questions.  And, you all immediately obliged, so thanks for that!

So, I’ll start by responding to people’s questions/reactions to that post, both in comments and through other media.  The follow-up questions/thoughts that I’ll address fall largely into 2 buckets:

1. How do you reconcile “software as a business tactic” with “software as an end,” particularly an aesthetic one, such as with video games?
2. Maybe software is a business tactic and isn’t currently a profession, but why shouldn’t it be?

Number (1) is easier and chronologically first, so let’s do that.

Read More