Author: josh

“Composition” means putting things together.

I compose when I write. I’ll write a sentence. I’ll write a second sentence. I’ll maybe add a third. Soon, I have a paragraph.

I make choices when I compose. A new sentence might belong in a new paragraph.

Maybe a sentence demands its own paragraph.

(Maybe a thought isn’t that important but I can’t help but include it. I might wrap such a thought in parentheses.)

I’ll compose sentences into paragraphs, and then the paragraphs often get composed into something, too. A blog post, maybe. An essay or an article. An email. A cover letter. Perhaps a chapter — one of many that get composed themselves, into a book.

I compose when I write code, too. I’ll write a line of code. I’ll write another line. Maybe I’ll add a third. Soon, I might start thinking about taking a few lines and extracting them into a function.

So I make choices when I compose code. New functionality might belong in a new function, a new class, a new module.

I’ll compose functions into classes and/or modules, then compose modules into libraries and/or applications.

If you have to lose in order for me to win, and I have to lose in order for you to win, somebody’s gonna be having some feels. Probably both of us.

Fear: We’re both afraid of losing. If it looks like you’re losing, you fear the consequences. If it looks like you’re winning, you might start to feel that you have more to lose and your fear might grow because of that.

Anger: When we lose, we get angry. Especially if we see unfairness. And losing might make us see unfairness that isn’t actually there.

Aggression: Your efforts to win might harm your opponent, and vice versa.

Envy: When you lose and I win, you might have envy for me.

Guilt: When you win and see I’ve lost, you might feel guilty about our different consequences.

In a win-lose situation, even when you win the game, there can be things you lose in the greater game.

My last post suggested that it’s difficult to sell oneself as a fox in the software development sphere. People want hedgehogs.

So what’s a fox to do?

My ultimate answer is that I don’t know. I’ll let you know when/if I figure out a foolproof master plan for it. Don’t hold your breath.

But for now, I do have some speculative thoughts on the matter. I have a possibly-naïve answer in three steps.

1. Hedge.
2. Build foxy relationships.
3. Expose yourself.

Hedge

Be a hedgehog. Do hedgehog work. This doesn’t mean you shouldn’t also be a fox. It means you should be T-shaped. Be a specialist and a generalist.

Find hedgehog work you’ll enjoy, so if you fail at foxhood, you will still have spent your time well.

Build Foxy Relationships

“The best way to get clients is to have clients.” – Gerald Weinberg

Can’t get clients? Make some. When smart people hire you as a hedgehog, gently be a fox, too: listen, learn, ask good questions, offer insights, repeat. Show those people your foxy goodness, find more smart people, repeat.

(Notice I say “smart people”. Let’s define “smart” as “appreciative of the free services of a fox”. Not everyone hiring you for hedgehog work will be so appreciative.)

Building those foxy relationships grows your reputation and your network. Get recommendations from that network, for your foxy work in particular. Social proof that you’re valued as a fox is the closest you’ll get to the hedgehog analog of a technical skill on a résumé.

Expose Yourself

Get exposure. Invest a serious amount of time in getting your name and your abilities out where potential clients can see them. The way you go about this should vary by what you’re good at, what you’re comfortable with, and what works. So experiment.

As a bonus, just about any way you try to gain exposure will inevitably lead to improvement of your fox skillset. A software engineer who also knows about writing, podcasting, screencast/video production, public speaking, or running an OSS project or a conference or a business… that’s someone who “knows many things”. Very foxy.

In the software engineering market, it’s far easier to sell yourself as a hedgehog than as a fox.

Recall:

“The fox knows many things, but the hedgehog knows one big thing.” – Archilochus

Some folks simply want to hire hedgehogs for labor: Say I have a spec and I want a .NET developer to implement it. I need someone who knows one big thing, how to do a certain kind of work.

Some folks want to hire hedgehogs for expertise, often specialized technical experience. Let’s say I’m worried about security of my software product. I might bring in someone with deep knowledge of security to advise me on that topic in particular. Again, someone who knows one big thing.

Some folks want to hire foxes for …let’s say “consultation”. Maybe “general advice”. Or “a different perspective”. After all, “the fox knows many things”. In a bad situation, when I can’t see a solution (or when I can’t see the problem), I might bring in a fox to help me. A fox might challenge my thinking. A fox might help me question my assumptions or priorities. A fox might remind me to look at the bigger picture.

Here’s the problem with being a fox, though: Nobody knows you’re a fox.

You can easily put hedgehog qualifications on a resume. When you put “10 years JavaScript development experience” on your CV, that’s a hedgehog thing. “One big thing.” As a technical skill, it’s much more verifiable, much more concrete, and much more sellable. The market for it is large and visible.

The breadth offered by a fox is much harder to get across. I don’t know if you’re a fox until I see you acting like a fox. “10 years strategic thinking experience” is not a thing. Nor is “command of a variety of mental models and tools for thinking”.

Here’s another problem with being a fox: Most of the time, people don’t think they need a fox. Even when a fox is exactly what they need. You can’t help people if they don’t want your help. And those people certainly aren’t going to pay you or go looking for you.

A good fox can be very valuable, but it’s difficult for that value to be realized.

(BTW: Check out Erik Dietrich’s post A Taxonomy of Software Consultants for further discussion of the three hiring situations I mentioned, minus the fox/hedgehog analogy, and plus some thoughts on the unfortunate use of the term “consultant” for all three roles.)

Here’s an interesting frame: When solving a problem, you might approach the situation as either a fox or a hedgehog.

“The fox knows many things, but the hedgehog knows one big thing.” – Archilochus

The hedgehog has depth. She can help you with the one big thing. She can answer questions about that one thing. She can help you with known unknowns, in other words.

The fox has breadth. She can look at your situation and cross-reference the details against her broad knowledge. She might just ask you some really good questions you wouldn’t even have considered. In other words, she can help you suss out unknown unknowns.

Everyone’s capable of acting like a fox or a hedgehog. You might have a strong inclination one way or the other. It might vary by situation, too. You can probably think of scenarios where you tend to act like one or the other.

Each approach can be a useful tool. Add both to your toolbox. Use them when they might help. (Like a fox.)

An abstraction is useful because it allows you to ignore the details inside it.

A function is an abstraction. You give a name to a few lines of code and instead of executing those lines of code, you execute the function.

You can create abstractions using other abstractions. This can lead your code in some amazing directions in terms of expressiveness and thus maintainability.

But each abstraction you create is a thing you have to design and maintain. It’s a thing another programmer might have to learn, too.

The notion that software is grown and not just written rings true. There’s not a straight line from recognizing that software can help us to arriving at a solution. We iterate: We build something we think will be helpful, evaluate it, improve it, evaluate it, improve it, and so on.

The notion that teams are grown rings true, too! You don’t just put people together, say “poof, you’re a team”, and expect them to start working together effectively. Teams need to iterate: we form with the idea that we can do some valuable work, evaluate how we work together, improve it, evaluate, improve.

In both cases, we’re never “done”. Requirements change, people come and go from the team, and we have to evolve and adapt.

1. Do I value this person’s opinion?
2. Have they thought about what they’re criticizing? Have they considered the nuances and context involved? Or are they shooting from the hip?
3. Do I agree with the criticism myself?

If you have a high tolerance for messiness, you’ll drive people with a low tolerance crazy.

If you have a high tolerance for awkwardness, you’ll drive people with a low tolerance crazy.

If you have a high tolerance for ambiguity, you’ll drive people with a low tolerance crazy.

If you have a high tolerance for risk, you’ll drive people with a low tolerance crazy.

If you have a high tolerance for redundancy, you’ll drive people with a low tolerance crazy.

Dave Rael’s Developer On Fire podcast has quickly become a favorite.

Dave gives a great interview and he’s getting some astonishingly good guests. So many technologists I’ve long admired keep showing up here. It’s impressive.

I could recommend dozens of episodes as a good first taste. Esther Derby, Scott Hanselman, Chad Fowler, Dave Thomas, Andy Hunt, etc, etc. But I’ve tried to narrow my list of favorites down and write about three shows in particular, to pique your interest but not overwhelm you:

Jessica Kerr

This is the episode that drew my attention to Developer On Fire to begin with. Jessica is one of my favorite technical speakers and public technologists in general. Her enthusiasm for learning and teaching about technology and her deep humility and bravery were inspirational to me long before I listened to this episode, but they come across in it, too. Check her out on Ruby Rogues (which is about way more than Ruby) and on Twitter, too.

Gerald Weinberg

Jerry’s book Becoming A Technical Leader changed the way I think about my work at a fundamental level. Then his Secrets of Consulting and More Secrets of Consulting did that again. His work has been huge for me. It’s some of the first stuff I’d recommend to a developer looking for professional growth resources. So I was extremely excited to see he was on the show. And he did not disappoint. He tells some great stories in this episode, and you get the sense that he has countless more, all illustrative of hard-won wisdom. I would subscribe in a heartbeat to a podcast where Weinberg just tells stories about his decades and decades in the software business.

Michael Feathers

Michael wrote one of my all-time favorite technical talks, The Deep Synergy Between Testability and Good Design. He also wrote the book on dealing with legacy code. This episode and the blog posts he mentions in it have me excited: He’s been thinking and writing about not only better ways to build software, but about how to improve the systems around the construction of software: how software helps organizations, and how organizations can adjust themselves to really capitalize on the value software can provide them.