Over a million developers have joined DZone.

Growing the Ideas From the Developer Hegemony Book

DZone's Guide to

Growing the Ideas From the Developer Hegemony Book

Marketing funnels, learning valuable skills, teaching others - these are just some ways to get yourself out there and promote the Developer Hegemony ideas.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Happy reader question Friday, everyone. Today, I’ll field a question about the Developer Hegemony book. For any newer readers, I wrote this book over the last couple of years and published it to Amazon in early May. For a briefer synopsis of its purpose and message, you can check out this announcement post.

The question was a lot longer than this (and contained some much-appreciated, kind words). But I’ll leave out any personal details and the backstory and leave just the question (paraphrased).

Aside from joining the Facebook group on the “What Now” page and spreading the word via social media, is there anything else I could do to help you get these ideas to more developers?

For some quick housekeeping, here’s the page in question and the Facebook group, too (feel free to join!). I appreciate the question, and I also understand it. I mean, of course, I literally understand the English language. But I mean that I understand the necessity of the asking.

The book release coincided with my “retirement” from IT management consulting. I went home, published a book, and dedicated my time to three simultaneous pursuits: a dev tools content marketing business, a specialized codebase analysis practice, and selling my primary residence in favor of what I think of as “cosmopolitan homelessness” (and moving).  I offer this not as an excuse, but as an explanation. I’ve been distracted.

Me going cosmopolitan homeless following the release of the developer hegemony book.

Moving Away Developer Skill Fetishism

Developer Hegemony features extensive treatment of the role of journeyman idealists. These folks play an important role in the depression of developer wages and autonomy. And they do this by bending over backward to disguise the fact that programming skill level has serious diminishing marginal returns.

In other words, imagine a spectrum of programmer skill from 1 to 5. You’d think that compensation would follow a linear model from 1 to 5, but reality has different ideas. As a labor purchaser, I’d offer maybe $100 per hour for level 1, $120 per hour for level 2, and then about $140 per hour for 3-5. Why? Because I need you to write a Sharepoint plugin, not design a neural network from scratch. Sure, I’d prefer a 5, but not enough to pay extra for one. And that defines the overwhelming majority of the market.

If I’m being blunt, the journeyman idealist then plays the role of “useful idiot” for his company. The company values the labor externally as it really is, but creates a different internal structure. Internally, it pays $30, $40, $50, $60, and $70 per hour, respective to levels. In terms of their value to the organization, 3-5 should receive identical pay. But the organization extracts a little savings on 3s and 4s by telling them to wait until they graduate to 5s. But they don’t break this news directly — they gamify the whole thing by turning it into some illusory meritocratic game, and then they sit back while the journeyman idealists gleefully administer their own underpayment.

Spread the word by putting a stop to this nonsense.

De-Emphasizing Diminishing Returns on Skill

I’ll connect the dots, now, if you’re waiting for this to resolve to coherence. We need to clarify and re-establish the actual relationship between skill and market worth in developers’ minds. If up-skilling at JavaScript or Entity Framework or something can help you sell your labor for more money, it’s a good career move. Otherwise, it’s just a hobby. And if it’s just a hobby, you can make a more intelligent decision about pursuing it than you can when some journeyman idealist is telling you that you can have a raise when you’ve memorized at least 15 Gang of Four design patterns.

So do this. When you see developers blindly chasing language level-ups, start a conversation. Ask them if they’d take Stack Overflow points in lieu of salary or badges in lieu of benefits. When you see people opting into and practicing for stack ranking programming contests, ask them how much the practice and contests pay per hour. If they tout saw-sharpening activities and deliberate practice, ask them to estimate the ROI on the activity.

In all cases, this will be jarring and you will seem contrarian. But if you get a foot in the door and you get them to consider, you can start spreading the developer hegemony message. By all means, offer them a copy of the book, refer them to my blog, or introduce them to me. But if you feel comfortable articulating these ideas on your own, then go for it.

Journeyman idealist games are like social media — they live and die by the sword of the network effect. If enough people stop playing algorithm trivia games, the games just disappear.

Start Different Communities of Practice

Let’s switch gears a touch. I feel a bit bad for dumping heavily on the journeyman idealist, so I’ll offer a positive alternative to the journeyman idealist. I’ve always found it curious that, as developers, we organize communities around our tools rather than our goals.

For instance, I’ve attended a lot of .NET user group meetups over the years and some Java ones besides. Perhaps Ruby, Go, or Python meetups are more your speed. We go there to find peers with mutual interests and to share ideas with them for how we can all improve. I love this concept (obviously, or I wouldn’t have gone to so many of these meetings). But it disappoints at times. I’ll get an invite that says, “learn to <Do a Highly Technical Thing> with <Hot New Tech>.”  And if I’m not interested in Hot New Tech or if I’ve never heard of it, I risk feeling I’ve wasted time after the meeting.

What if we shifted this meeting pattern? What if instead of organizing by what languages/frameworks we used, we organized by goals? Monthly meetups for people who build websites for small businesses or people who help software dev shops tune and optimize their databases?

Do this, and everyone attending can always answer, “why should I bother to attend?” It’s easy — every meeting will help you deliver value to your customers and help you make more money. Sure, some of the meetings will cover cool new techs and toys, and that’s fun for everyone. But you’ll never be doing it just because the cool kids are.

And, if you want to build efficiencer firms, this seems like pretty fertile ground for forming them. So you could start a community like this to get the word out.

Start Side Hustles That Serve Efficiencers

The last thing I’ll mention involves something I talk about in the book, but more as a prediction. I think one of the things that move software developers out of the role of “corporate drone” will be more and more businesses catering to independent developers. For instance, I imagine that you’ll see legal and accounting practices that specialize in helping small software development firms.

But we can actually scratch that itch ourselves. And, in fact, that’s what opportunistic developers have really started to do in terms of taking control. If you look at John Sonmez’s site, SimpleProgrammer, you’ll see someone who moved from software development to making content for software developers. You see similar offerings for training, coaching, etc. A lot of software developers transitioning to efficiencers stay close to home, identifying software developers as their target market.

You can do this yourself. Go ahead and build info products and train developers in development techniques if you like. But you could also do things like:

  • Specialize in helping software developers escape non-compete agreements.
  • Write accounting/billing software specifically aimed at software development (efficiencer) firms.
  • Build a turnkey “start your business” offering that incorporates a freelance programmer, sets her up with basic contracts, and makes her a website.
  • Or, what I plan to do — build a content library/offering around consulting and going off on your own.

The common thread? You can get the word out by making it in your financial interest to do so. Start a service that helps developers go efficiencer and encourage them to use it. I recommend doing this as a side hustle because that lets you test the waters and makes it less daunting.

Hold Onto Some Mild Indignation

Everything I’ve said here is fairly tactical, and I think that was the thrust of the question. You can discourage participation in journeyman idealist games, start efficiencer communities, and start efficiencer-serving businesses. All of that will serve to increase the profile of the developer hegemony idea. And, of course, socializing it with interested folks in your network via shares or word of mouth.

But I’ll offer some more strategic, philosophical advice to wrap up. Hold onto some indignation about the programmer’s current plight, and let it seed your mind with ideas over the course of time.

In the legal profession, lawyers are the bosses. In your doctors’ office, doctors run the show. As a programmer, you have 8 different bosses, Bob. Why is that? And why do people think you’re crazy for asking why?

Software developers are currently among the least influential people in the software development industry. That should piss you off. Hold on to that indignation, talk about it, and let that drive your conversations until it no longer applies.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

career development ,agile ,career growth ,consulting

Published at DZone with permission of Erik Dietrich, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}