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

What Do I think of “Full Stack” Development and the DevOps Movement?

Once again, I’m doing reader question Monday on a Tuesday.  I have no good excuses this time, either.  We arrived last week in San Diego, which is beautiful.  So, I’ll just flat out admit that I spent the weekend strolling beaches, eating lobster tacos, drinking craft beers, looking up at the stars and just generally enjoying life in a way that involved no writing of blog posts.  I regret nothing.

So let’s to reader question Monday on a Tuesday.  This is actually a question that just came in today as I was gearing up to write about TDD and remote teams.  It caught my attention, so I’ll give about the fastest turnaround time I’ve ever done on a question.

I recently stumbled upon this article: https://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/

Which seems to lump Full-Stack dev in with DevOps, and discards DevOps, on the premise that the full-stack dev is good-for-the-org-bad-for-the-dev. I know you’ve weighed in against the full-stack dev with preference for specialization. I wonder if you believe this also means DevOps is DOE, or if there’s still room for DevOps in your mind (or perhaps more broadly speaking, for startup-like, feature-teams so often found in Agile/Scrum orgs)?

If you don’t like DevOps, what do you recommend instead to manage the entire release automation process, and everything else it entails?

Alright.  There’s a lot for me to work through here, so let’s break things up a little.

DevOps (And Full Stack) is Killing “The Developer?”

First, let me recap briefly the article’s thesis.  And I’m really going to try to be gentle here and non-objectionable.  I trade in blog posts for a living these days, and slugging it out with random people on the internet has worn as thin as it can possibly wear to me.  I’d really rather not argue with this Jeff Knupp, and I can certainly empathize with waging a vigorous campaign to make your own job more fun.

The article’s thesis is, essentially, this, from the perspective of a salaried employee in the enterprise.

I hate the DevOps (and full stack) movements because I like writing code and they result in me writing less code.

The author might object to this thesis, but that’s really the message.  It asserts the superiority of the software developer as compared to other individual contributor roles, and then argues that DevOps and full stack (and forced skill diversification in general) are good for the employer, but bad for the employee.  (Although he then curiously argues that it’s also bad for the employer, since they’re “overpaying” for non-development labor.)

Read More

A Career Guide for the Recovering Software Generalist

Since I’m kind of an old man, in college, they taught me C and its shiny new cousin, C++.  This was a CS program, so they didn’t ultimately focus on the language.  Instead, they went on to focus on the theory of things: algorithms, data structures, reasoning, and, well, computer science.  But they had to teach us just enough language for us to make sense of and apply those concepts.

So C/C++ it was.

My first full time programming job was a dream come true for the software generalist.  They had C and C++ both for me to work on.  But they had plenty of other language besides, and not a ton of manpower to spare.  So I learned Visual Basic.  And also PHP.  Oh, and Java.  (There were actually a few other things besides, but I think you get the point).

By the time I was about 4 years into the workforce, I’d switched my focus as the world moved toward web apps.  I’d gone from working on Linux kernel programming in C to Java web apps with Spring and Ant.  Fast forward several years, and I’d switched it up heavily again.  Java web apps?  Pff, that was so 2006.  I went to work for a completely different company, making a completely different product, and became a C#/WPF developer of desktop applications.

I was the consummate software generalist.

The Software Generalist Source of Pride

I was proud of this, too.  If you’d asked me what I specialized in, I’d have said something like this.

My specialty is that I’m a generalist.  I live and breathe code.  Don’t care about your domain or your particulars and I don’t care about your language or stack.  I’ll be good anywhere, as long as it’s code.

If you’d pressed me on the specialty point, I might have conceded a little.

Well, I guess my specialty is object oriented programming.  Yep, if you need inheritance, encapsulation or polymorphism, I’m your man!

These days, assuming you read this blog with any regularity, you probably know how ruefully I tell this story.  I’ve written how free agents can stop generalizing and about the idea of niching down.  I’ve given advice for free agents to specialize.  But today I’d like to double down on this advice by offering it to salaried folks and not just freelancers.  You should specialize.

Read More

Resume Skills for the Job Seeker with Upward Ambition

It strikes me that, lately, I write a lot about how to make it in a free agent world (or how to get there).  So today, I’d like to switch up it a little and give a nod to those of you in the salaried world, and perfectly happy there to boot.  But don’t expect me to talk about a resume skills section or what have you without at least a little realpolitik and a little cynicism.

The resume-interview one-two punch is a stupid way for employers to find employees.  Full stop.  But it’s also the prohibitive incumbent and the system that you’re going to have to navigate.

So let’s focus on resume skills today and give you a fighting chance at navigating the process.  In fact, let’s go beyond just navigating it and look at how to maximize how it works for you.  This has two essential components.

• Filter the riff-raff employers out of your search as quickly as possible.
• Impress the ones you care about.

Let’s look at how you can tune the resume skills section to help with both.

The Anatomy and Purpose of a Resume

First of all, let’s consider the purpose of a resume.  Lansing Community College, winner of the SEO sweepstakes for “what’s the purpose of a resume” has the following to say.

The purpose of a resume is to provide a summary of your skills, abilities and accomplishments. It is a quick advertisement of who you are. It is a “snapshot” of you with the intent of capturing and emphasizing interests and secure you an interview.

Who am I to argue with an institution of higher education?  That all sounds exactly like the ostensible purpose of a resume and a very sunny assessment besides.  It’s your own tiny commercial in print, and, done right, it gets you interviews.

But let’s be a little more blunt about the way things work.

You put together a resume, trying to stuff as many self-aggrandizing tidbits as you can in there while looking plausibly humble.  Then you fire it off for the viewing displeasure of an extremely bored person whose main mission is to find reasons not to call you.  This resume filtration will feature two passes, usually.  These include an automated or semi-automated pass to disqualify anyone without the magic acronyms and a second one to disqualify anyone that seems fishy somehow.  To navigate this minefield, you put together a resume with the following sections.

• Basic contact information.
• Employment history, including job titles, job descriptions, and accomplishments.
• Education.
• The resume skills section.
• Some people include an “objective” which should probably be “straight cash, Homie.”  (Just kidding — no one appreciates honesty here, so I’d just omit this altogether)

What do Resume Skills Look Like?

In this particular post, though, I’m going to focus on the resume skills, so let’s not worry about the other sections too much.  The standard advice there is usually good, particularly the part about trying to quantify the accomplishments at your various jobs as much as possible.

It’s the resume skills section that features the great tragedy among the broader, lesser tragedy that is this whole process.  I’m talking about this, lifted from a hypothetical resume for one Amy Jones, “midlevel software engineer,” on Monster.com (they’re still truckin’, apparently!).

Read More

Side Hustle Ideas for Software Developers

I was originally going to write the next corporate realpolitik explained post, this time about the software architect.  And, while I can and will still do that (tweet at me or something if you’d like to speed it along), I’m just not feeling cynical these days.  I have a nice winter of drifting through the US south planned, running a lifestyle business and generally enjoying myself.  So why not write about something instructional and uplifting?  Like side hustle ideas.

What’s a side hustle?

It’s not so complicated.  If your full time work is your full time hustle, then your side hustle is work you do on the side.  You could think of it as a hobby that makes you some money.  For some, that’s all it is and all it stays.  Others might look to it as an eventual job replacement.

If you work 40 or more hours per week, this might seem daunting.  And, it can be.  Instead of spending your recuperation time reading, watching TV, or appreciating your family, you’re carving off a slice to do even more work stuff.  For that reason, you should be sure to find something you like doing.  And also for that reason, I’m going to emphasize more manageable and iteratively achievable side hustle ideas.

This post is mainly aimed at salaried software developers that have never made money outside of a salaried context.  Anyone is, of course, welcome to read along — it’s not like side hustle ideas are exclusive in any way.  But understand who I’m talking to with this advice.  I’m talking to folks with full time jobs that don’t want to risk running afoul of employers (say, by moonlighting) and don’t want to spend all of their waking hours on the side hustle.

Don’t Build Software as a Side Hustle

First up, let me recommend a few hustles not to pursue, particularly for those of you that are first timers at this.  It’s not that there’s anything wrong with these things.  They’re just not where you want to start.

First of all, don’t make a mobile app or build a SaaS.  Yes, you heard me correctly.  You’re a software developer and I’m steering you away from software development.

Why?  Here’s the thing.  You spend all day, every day writing software for a living already.  You know software — you live it and you breathe it.  So if you go home and start a side hustle building software, all you’re going to do is build software.  You’re going to build it, then build it some more, and finally, after that, when it’s finally time to ship, you won’t ship so that you can spend another year building it.

I’m exaggerating, but not a ton.  Bias toward familiarity makes for great procrastination.  Why do you think software developers contemplating a blog spend weeks agonizing about what platform to use or whether to hand code it.  Because you know software and you don’t know writing.  So you dither over unimportant software decisions.

Side hustles are about earning some extra money, sure.  But they’re also about teaching yourself business, which I heartily endorse since continuing to improve as a generalist programmer starts to yield diminishing returns after a while.  So lay down the IDE and dive fully into the business world.

Read More