Author: josh

Independence Day! It’s a celebration of freedom, liberty, etc. It’s also a celebration of a revolution. That’s worth dwelling on. Revolution: change, hard and fast.

Prosperity tends to make us afraid of change. Having things means having things to lose. The potential downside that could come from change starts to look bigger than the potential upside. Revolution-style change is a terrifying prospect today. For me, at least.

But change doesn’t have to come via revolution. When it comes that way, it’s usually because we’ve resisted it too long. Something eventually had to give, and it gave. But change can come in small pieces: a little change, a little pain, a little bit of the unknown, early and often. I’ll keep beating this drum: Embrace change, avoid revolution.

(You could also resist prosperity, living beneath your means. But I think that’s a harder sell.)

When you learn the lingo, you get better at communicating with those who know it, but worse at communicating with those who don’t. (You become more adapted, less adaptable.)

Give a talk at a functional programming conference, and you’ll be expected to use fancy terminology. Give a talk on functional programming to a broader conference, an audience new to the ideas, and you’ll need to explain your terms. If you use the terms, you may look out and see glazed-over eyes, because people won’t know what you’re talking about.

To fit in, you learn how things are done. In learning how things are done, you lay some tracks in your brain. Then when you need to do things, you’re inclined to follow those tracks. They coalesce into a path. And the more that happens, the less inclined you are to stray from the path.

We all have handling and we have horsepower.

Horsepower is our ability to do the technical work. Maybe a high IQ, or the ability to think or remember things quickly. Our familiarity with technologies and systems comes into play here, too.

Handling is our people skills. What it’s like to do the work with us. Not so much about IQ, more about emotional intelligence, social intelligence, empathy, leadership, etc.

Obviously, you’d like to have great handling and high horsepower. And you’d probably like everyone you work with to have the same. But, of course, most of us tend to be geared toward one or the other. Some of us are particularly lacking with regard to one or the other.

I’ve worked with folks all over this spectrum: high-horsepower-terrible-handling, great-handling-awful-horsepower, and all over in between. I’ve found that that diminishing returns kick in pretty quickly as you shift toward the higher-horsepower-lower-handling side.

That high-horsepower brilliance so often feeds into ego, which feeds into disregard for other people’s opinions and feelings.

To do great technical work at scale, you need good handling, too. You need to be able to work with a team. That might mean taking your foot off the gas a little. Slow down, listen, learn. Learn not just facts and specs and keyboard shortcuts. Learn about your teammates. Let go of your desire to make things work the way you already know they should work. Get there with the team. Humbly try to grow them and stay open to being grown by them.

Sprints set a floor. When we do three-week sprints, we force ourselves to stop at least every three weeks to evaluate what we’re doing — whether it’s valuable, what our next chunk of work should be, etc.

A lot of the time, we let sprints set a ceiling, too. We only stop and evaluate what we’re doing on the seams of those three-week intervals.

That’s maybe okay for an organization’s initial transition into agility. But once you get it, you’ll probably want to tighten the loop. You might want shorter sprints. Or you might want to throw sprints out the window.

You’re uniquely suited to tell us about the world from your perspective.

In order to decide to do it, though, there might be some fears to overcome:

• We’ll think you’re weird.
• We’ll think you’re dumb. You’re doing it wrong.
• We’ll think you’re boring.
• We don’t care about your perspective to begin with.

I have all those fears every time I publish something. But when any of those fears is realized, it’s a path toward something.

• “Weird” is interesting. “Weird” is new. New things are weird, by definition.
• “Dumb” means you get to learn something. You get to get better. Or try, at least.
• “Boring” tends to mean either “too obvious” or “too complicated”. You’re either entering a topic at the ground level, and there’s a lot you get to learn; or you’re way ahead of the rest of us, and there’s a lot you get to teach us when you figure out how to bridge that gap.
• When we don’t care about your perspective to begin with, those other fears don’t matter so much. People are wrapped up in their own heads, their own shit, and your perspective on whatever is way down on their list. That’s true until their attention gets drawn to whatever you’ve written about. Then you might get their attention. But in the meantime you get to work your own shit out in obscurity.

“I don’t have anything to write about.”

Just write about the few true things you know. Do us that favor.

A pet peeve of mine: The free food in the technology world seems to often be the worst possible food for you. User groups invariably have pizza, soda and beer. Food people bring into the office is invariably bagels, donuts, or some other kind of baked good.

Sure, these things are all delicious. They’re also all terrible for you. And they hurt productivity: That donut you ate at 9am is why you can’t concentrate at 10:30. Have some more coffee and defer your crash until after lunch. Great.

This bothers me on another level, too: Cheap junk food culture sits right alongside cheap junk code culture. If we can’t muster long term thought about our own food, we’re not likely to do it with respect to our code or our businesses, either.

(PS: Should I not complain about the food, because it’s free? Perhaps. But the free aspect of it is beside the point from my perspective. The appeal of this food for me is usually the convenience — that I won’t have to think about feeding myself for the evening as part of deciding whether I can go to a user group meeting.)

Okay, maybe not. But bear with me. I want to invite you to stop thinking about what you’re doing as “code reuse” and start thinking about it as “design”.

The reuse mindset put blinders on you. It pulls you in the direction of eliminating redundancy in existing code. I.e., I have several functions with the same shape and I create a new thing with that shape and have my existing things refer to (and thus depend on) the new thing.

Reuse is often a good thing, but it’s not the only thing.

How might your thinking differ when your task is “design” instead? Design mindset is a more top-down way of thinking, more holistic. When I think about design, I think about what the right building blocks are for the problem at hand, and consider how they ought to fit together. Some of the tactics are similar, but the strategy driving your choice of tactics is likely to be different.

“Divide and conquer.” That’s what the professor who taught me recursion called it.

By “it”, I don’t mean recursion. I mean breaking a complex problem down into a set of simple problems. This was handy when learning to write recursive functions, though. We could separate (divide) them into the base case and the recursive case(s), then solve (conquer) each case independently.

Reduction is more broadly applicable, though, of course.

When you use a model, you reduce a complex domain to a simpler one to help you focus on a particular problem.

When you ask clarifying questions (and don’t fear asking stupid ones), you reduce the set of stuff you don’t know about a domain. This has a similar effect: It helps you solve a problem by narrowing the set of things you have to think about.

When you construct things from small pieces (oh, hey, pure functions make great building blocks), for each of those pieces, you reduce the scope of a complex problem into a set of simpler ones. Divide and conquer.

Dear Future Me,

Come back and read this stuff.

You wrote it to help yourself remember it, right? That was one of the reasons, at least.

Coming back and reading it from time to time will help, too. Don’t forget.

Consider human brains as systems to integrate with.

What do you need to do to integrate with another system? Generally, you need a contract. You need to agree on the terms of your communication — protocols, primitives, messages, endpoints.

It’s kind of the same with people. In order to work together we need to be able to communicate and coordinate. We need common language and we need to agree on process.

In both cases, it takes work. And you might not get the design right on the first try.