Byte-Sized Book Review: Developer Hegemony

Kyle Walsh — Thu, 30 Apr 2020 17:47:59 +0000

Intro Stuff

I'm favoring speed over form with this new series, as I've read a lot of software books over the years and mostly want to give people the impetus (or not) to read a book from the perspective of someone who's been in the industry a while and had many ups and downs. I've wanted to do something like this for a while, but hadn't had that quake book-like effect that's knocked me out of my doldrums to actually start the reviewing process until Developer Hegemony: The Future of Labor by Erik Dietrich. It is such a thought-provoking, insightful, and I think inspirational book that I want to give it a bump on this forum and thank Erik implicitly by writing this positive review :)

My Hot Take Review

It's rare that I get a software-related book that I not only love, but want to read as fast as possible and not skim at all. This book was literally a page-turner for me, and I read it over a three-day weekend recently.

If you've ever worked in a corporate programming setting, especially for one of the larger software companies, and had certain aspects of that feel unsavory to you, then much of this book will resonate strongly with you.

Additionally, if you've ever felt like your personality is just a bit askew of the "classic" software engineer stereotype (only loves code, meritocracy, high social anxiety, wants the world to boil down to binary), this book will resonate as the liberated "efficiencer" archetype will synthesize what you may have been hoping for in a "dream job/fit" situation for your personality...the catch being you have to make that job for yourself.

Along the way, Dietrich describes how the corporate pyramid functions, its roots in the Industrial Revolution, the archetypes of people who work in this pyramid, and why he believes it's a failure and how you can succeed within that structure - if you so choose. All very cogent points and, though arguably cynical, very true to life. People who strongly identify with their perceived elevated status as software engineers, who may (knowingly or not) look down upon other forms of corporate "line-level" work, may be in for a rude awakening as he rips the veil off just how pedestrian software engineers really are relative to other vocations also judged by their output alone. Corporations may know to do some ego stroking along the way, but in the end you are what you output and you are a means to an end. A translation unit of business logic to code resulting in money.

Just as his take is seeming most dire, he promotes the idea of breaking free from this, and embracing your ability to solve problems, understand business, and bring efficiency to whatever domain you're working in by going it alone (or with a pack of like-minded individuals) as what he calls an "efficiencer". This part is the most empowering, and if you've ever had the spark or inkling to "start your own thing", it'll get those juices flowing yet again.

Verdict

Read this book! I'd say, if you're a "big picture" developer like me, you would even enjoy reading it cover to cover versus a topical skim. So many things that have bothered me over the years, or that frustrated me, were captured and put to words very effectively, that reading it was almost cathartic. At the same time, the latter quarter of the book outlining a hopeful way to move the industry forward was a positive way to end the journey. Interviews in the appendix make for some helpful application of going the "efficiencer" route he details. I can't recommend it enough!

My System For Ramping Up With "No Free Time"

Kyle Walsh — Tue, 09 Jul 2019 15:45:04 +0000

Introduction

Learning new things, and then making effective use of that new knowledge, is key to our work as technologists! I used to haphazardly learn new things: either what was demanded of me from work, or just digging in on stuff I found interesting. Then I became a parent, and my free time went out the window! No longer could I just stay late at work, bail on friends, or pull an all-nighter to catch up. So, I married a few concepts from some really great books on reading, learning, problem solving, and habits. None of this is ground breaking, but sometimes hearing things in someone else's package and then going from there is what people need to make progress. It worked for me, maybe it can work for you!

Reading

How To Read A Book is probably my favorite non-fiction book. It's written with such a clarity and directness that I truly appreciate (probably a product of coming out of the 1940s), and really goes deep on a matter that many of us take for granted. Some of you may be thinking: How To Read a Book? Uhh, just read! Seriously, give it some consideration.

The author details four levels of reading (each step leverages/consumes the previous step as part of its approach):

Basic Reading - What we all already mostly do, start to finish, plodding along.
Inspectional Reading - Scan the structure of the book - table of contents, index, references, etc- and skim the points of interest in a targeted fashion. Start thinking of what questions you'd ask the author if it were a live conversation.
Analytical Reading - Now you're fully in conversation mode with the author. Writing detailed notes as you go of each section, answering your questions. Fully dissecting the book to its core. This is an active activity, not a spectator sport. Really consider the author, their biases and background, and whether you agree or disagree.
Syntopical Reading - The final stage of reading. This is where you are effectively applying a bit of a Breadth-First Search to your personal research. This method means selecting multiple sources/books on the topic and comparing/contrasting their approaches, usually storing your combined and synthesized notes in a master notebook or commonplace book. Sometimes we need multiple takes on a topic before it cements. A modern-day interpretation of this would be reading a book's chapter on something, next a blog post, and then cross-referencing those with WikiPedia, YouTube, or Khan Academy.

Some steps in this may be "common sense" for you, but the deliberate and formalized approach will yield you more consistent results than if you do some steps of this inherently.

A final note on reading and books: don't fall victim to the cost aversion of not reading an entire book cover-to-cover that you buy. A book is like taking a calculated bet on your life. You could read one thing in one chapter that changes your life or opens your mind in a way that is way more fruitful than the 10-20 bucks you spent on it. I've noticed that myself, and many peers in computing over the years, will give blog posts more leeway than books. Treat each chapter in book (or even subsection) as a more formalized, more rigidly constructed blog post, and take what you need.

Learning

Ok, cool. You extracted a bunch of data from a source, or sources, that spoke to you. Now you have to make it stick! Spaced repetition is the key here. Regularly test your knowledge via recall. Make sure you can explain it to someone else, ala the Feynman Technique (if you can't explain it to someone in basic terms, you don't know it well enough yet).

A Mind For Numbers, or it's companion course on Coursera, Learning To Learn are great at cementing this approach. As you continually test and recall, the concepts will cement themselves.

For applications to programming, this is where you want to write your test applications or clone applications mimicking the features you've learnt. Next-level would be a side project you're passionate about that leverages the newly-discovered concepts. For things that a little more esoteric, you can setup an Anki/Flash card deck to drill the high level concepts while also writing the code for a practical implementation.

Problem Solving

The best book on this, IMO, is G. Polya's How To Solve It. It's another classic, and it's the template for how to approach a problem in a very structured manner. It's very similar to applying the Scientific Method to problem solving.

The basic gist of the Polya approach is:

Understand the Problem - know it fully and deeply. Restate it to others. Drill down until you have zero ambiguity in what you're trying to accomplish.
Devise a Plan - Polya suggests many different ways to distill a problem down to a simpler problem, consider special cases, draw diagrams, etc. There's also an encyclopedia of problem solving strategies that follow after the problem solving template is detailed in the beginning of the book.
Follow the Plan - pretty straight-forward, stick to your plan, and be deliberate
Reflect on the plan - look back at what you did and note what worked and what didn't. If the problem still isn't solved, consider if you fully understood it or if you need to devise a new plan.

Habits

One of the quotes in Refactoring that I really liked was "I'm not trying to be a great programmer. I'm trying to be a good programmer with great habits".

It's hard to be consistently great...and the reality is that many of us aren't going to be naturally great with little effort...but if we can build our habits such that doing things well becomes second nature, then the compounding effect of your habits over time will mean you're a solid, reliable, and effective software engineer wherever you work. A great book on habits that I geeked out over big-time was Atomic Habits. The author does a fantastic job of distilling the little changes you can make in your life and approach to thinks that are easy to implement and really start to compound. I can't recommend it enough!

Conclusion

So, maybe many of you already do some (or all) of the things I mentioned automatically as part of your implicit process. If you do, that's great! For me, I really had to formalize explicitly a way to execute learning new stuff as quickly as I could due to my outside responsibilities growing so much as a new parent. This template/approach should work for anyone who wants to get the most out of their time and get back to writing code and solving cool problems. Hope it helps!

DEV Community: Kyle Walsh