There’s so much awesome stuff to consume, it’s easy to forget to make stuff.
Making stuff puts you out there, too. Which makes you vulnerable to criticism. It’s easy to be afraid to make stuff.
It’s also easy to make stupid stuff like lazy Twitter jokes, and get immediate positive feedback in the form of likes and retweets from your friends. It’s easy to do that instead of making the harder stuff that takes more time and thought.
A team that’s doing everything wrong is an opportunity to deliver a lot of value, if you can help them. But helping them is a people problem, and people problems are much harder (for me, at least) than technical problems.
A team that’s doing everything right looks like a pleasure to work with, but your potential value to them is lower. You won’t be able to help them as much, because they don’t have as far to go. But you’re probably more likely to succeed, as a team, in solving the technical problems in front of you.
If you practice doing something the wrong way, you’ll get better at doing it the wrong way.
“Practice makes perfect” isn’t bad advice, there’s just more to the story. You still need to practice to get better. But practicing alone isn’t going to do it. You have to pay attention to your results, keep your goal in mind and make sure you’re moving toward it.
The term “agile” is over- and mis-used in modern software development, to the point that it can more or less be considered meaningless. Just about everyone seems to say they’re agile now, whether they share the values in the agile manifesto or not.
So, fine: The word is meaningless. Is that such a big deal? Let’s not be discouraged by the abuse of a single umbrella term. Let’s keep our focus on the mindset and the values.
Some of these questions hone in on whether the organization really does have a healthy mindset for modern software development, the ideas we used to group together and call “agile”.
A young college student was working hard in an upper-level math course, for fear that he would be unable to pass. On the night before the final, he studied so long that he overslept the morning of the test.
When he ran into the classroom several minutes late, he found three equations written on the blackboard. The first two went rather easily, but the third one seemed impossible. He worked frantically on it until — just ten minutes short of the deadline — he found a method that worked, and he finished the problems just as time was called.
The student turned in his test paper and left. That evening he received a phone call from his professor. “Do you realize what you did on the test today?” he shouted at the student.
“Oh, no,” thought the student. I must not have gotten the problems right after all.
“You were only supposed to do the first two problems,” the professor explained. “That last one was an example of an equation that mathematicians since Einstein have been trying to solve without success. I discussed it with the class before starting the test. And you just solved it!”
It’s nice to be able to point to Snopes.com to assert that this is a true story. This really happened. George Dantzig was the student. And of course the story shows up in pop culture — the movies Good Will Hunting and Rushmore might be familiar examples.
Writ small, though, this has happened to you. When you don’t think something’s hard, you’re more likely to try it. When you aren’t burdened with a lot of assumptions, it’s easier to be creative.
This is a Beginner’s Mind.
Thing B doesn’t need to be a superior alternative to thing A to be worth learning about. It just needs to be useful. Even potentially useful.
F# doesn’t need to be “better” than C# for it to be worth my while to learn. Maybe it’ll be a better way to solve a particular problem. Or maybe it’ll just bend my perspective in some interesting new ways, which might make me a little better at understanding and solving problems in general.
Functional patterns don’t need to be “better” than OO patterns to be worth my while to learn.
Kanban doesn’t need to be “better” than Scrum to be worth my while to learn.
React doesn’t need to be “better” than Angular to be worth my while to learn.
And so on.
Individualism says we should value self-reliance and independence. I find myself pulled in this direction because I deeply believe in focusing on what I can control, that the only thing we truly control is our own actions.
Collectivism says we should value community and interdependence. I find myself pulled in this direction because I deeply believe that serving others is fundamental to happiness and fulfillment.
Can both be good things? Strong proponents of each seem to act like these ideas are mutually exclusive. I’m not so sure that’s true.
Folks who win the lottery tend to be much happier for a short period, but then fall back to somewhere near their pre-winning level of happiness.
Folks who lose a limb tend to be much less happy for a short period, but then adjust back to somewhere near there pre-amputation level of happiness.
This effect is called “hedonic adaptation” or “the hedonic treadmill”. Our level of happiness adapts to something resembling a thermometer’s set point, regardless of external events. It sounds both bogus and sad, but there’s a ton of evidence for it.
Maybe you’ve experienced it. Maybe you’ve gotten a raise or promotion and then three months later you no longer appreciate it, you’ve accepted it as the new status quo. Maybe you lost your wedding ring and were devastated for days, but then the next week you accepted there was nothing you could do about it, went out with your spouse to buy a new one, and now six months later you barely think about it.
We tend to overestimate the long term impact of events, good or bad. A single fortunate event won’t make you happy for the rest of your life. Or even for very long. So stop waiting for something like that. There’s no silver bullet.
So what should we do about this? My plan: Aim for small-but-frequent bits of happy over daydreaming about big ones that I’ll quickly take for granted anyway.
Tim Ferriss, an author I respect, has said that he had great success writing his first book by drinking a glass or two of wine and then imagining he’s writing an email to two friends.
I was struck by this. It seems to me to be a great way to hone in on a tone that’s accessible, and to focus on what excites you about whatever you’re trying to write about.
I try to imagine writing these posts to friends. I imagine one friend who’s a little more knowledgeable about the topic than me. I keep another friend in mind who’s just a few steps behind me.
There’s no wine involved, but coffee helps.
Sometimes you try a new thing and can’t imagine going back to the old thing.
This is how I feel about automated tests. Once you experience the confidence you get from being able to make a change and verify that you haven’t broken any of your tests, it seems unfathomably painful to go back to the old thing.
This is how I feel about git. Branching and merging, in every previous version control system I used, were so unpleasant that I would do my best to avoid doing them at all. Git makes branching cheap, which supports workflows that can make merging painless. Now I dread the day I sign up for a project that uses a different VCS.
This is how I feel about iterative and incremental development. It’s foolish to think that you know what you need to build when you start a project. Short feedback loops, especially when they can involve user feedback, lead to good outcomes. Long feedback loops are quixotic, and projects with them tend to be epic wastes of everyone’s time.
I could go on. The list isn’t long, but it isn’t short.
What’s been a game changer for you?