What future are we building, given that we play a role in such an important process?
On the role designers play, what they do as careers progress, and how design can positively enhance the world.
Reminder: if you tilt your head just so, developers do a lot of design activities too.
A channel, a sewer, Alabama, and a sunset walk into a bar:
What’s intriguing you, dear reader?
Things I’ve quit doing at my desk:
Many writers maintain a private writing hut. The hut has one purpose: it’s the place they go to write. They don’t do anything else there. Once they can’t write any more, they go do something else. I think we need to think of our desks in the same way: these are places where we get work done.
I like my desk, but I know the hours I can sit at it and get work done before fatigue sets in are finite. I try to mix in standing at our bar-height dining table, sitting on the couch (most recently, with three dogs), working from coffee shops and occasionally sitting on the front or back porch.
The big idea from that article, burning a hole in my head, is that we should step away from our desks when we’re not working (for me, telling computers to do things). Thinking can happen on a walk, standing outside, or in the shower. Socializing can happen from the couch or mobile device. Procrastinating by reading, surfing, social networking, etc. can happen anywhere.
Once I freed my mind from the idea that I’m only working the moments my butt is in a chair at a desk in front of a computer, my work improved and my life got better. Quit your desk and find out for yourself.
Math: humans mostly have a love/hate relationship with it. And yet, even if you’re challenged by the continuous maths like myself, it’s hard to argue that there isn’t something magical to seeing the commonplace of our world in mathematical terms.
Facing risk by instrumenting the hell out of it:
Software development is a complex system existing as it does at the intersection of people, systems, good intentions, confused and changing goals, and overly literal state machines. Past behavior isn’t always an indication of future behavior, and humans are terrible at reasoning about complex systems. As such we’re unlikely to know or have good visibility into whether we’ve reached a steady state and our hypotheses are likely to be wrong. In this uncertain and complex environment we initiate change only when the cost of not making a change overcomes the fear of making it.
First in a series on how Etsy writes, deploys, and operates changing software without The Fear. Thanks for writing this stuff down, Kellan!
Problems, puzzles, startups as dynamic mazes:
just running to the entrance of (say) the “movies/music/filesharing/P2P” maze or the “photosharing” maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies that are likely to move walls and change assumptions
I love this idea about thinking of solving systems as though they were an ever-changing maze, with history (fallen players) embedded within the system. Doubly so when you extend the metaphor to solutions that route around one problem to brazenly take on another problem. If this had a further extension to football playcalling, it would be perfect.
Practice Responsible Refactoring:
When cleaning up the code enables you to work faster for a task you aren’t dreaming up but actually have at hand, refactoring is the way to go.
Dave Copeland makes the point that refactoring without a value-added change (feature, improvement, bug fix, optimization, etc.) is a losing proposition. By the numbers, he’s absolutely right. Further, I’ve found that probably half of the refactorings I’m convinced are necessary aren’t as simple or useful as I thought once I get an hour into them. Despite all that, keep doing therapeutic refactorings for practice and to keep your spirits up.
Overtime is Morphine, Ernie Miller:
A developer who is truly concerned about the health of his or her company also must be careful to ensure the “patient” isn’t developing an unhealthy dependency on their heroics, allowing the company to limp along without experiencing the pain that should accompany unwise choices. Pain is how we learn to avoid repeating mistakes.
I’ve seen too many developers put in a heroic effort, only to repeat it the next day, sometimes without sleeping in. That’s “killing the patient”, to extend Ernie’s metaphor. It’s not the natural state of a business to notice the human cost it might have. The people inside the business have to assess that cost and do something about controlling it.
If your business, or the one you work at, requires regular heroics, consider that it is a broken system. Luckily, software developers are well equipped with mental routines for diagnosing and patching broken systems. Time to hack the organization.
Lessons from Premature Abstractions Illustrated. I’ve run afoul of all three of these:
Make sure you have someone on the team or externally available that will keep the critical, outside look at the project, ready to scream and shout if things turn bad.
Don’t let your technical solution influence your design decisions. It’s the tool that needs to fit the job, not the other way round.
Don’t build abstractions as long as you have no proven idea on how the levels below that abstraction will look like.
I could have used an outside, trusted voice to gently reel me in if when I went off into the unproductive weeds. Someone to ask “how will this help the team in two weeks?”, someone to point out ideas that might be great but have only achieved greatness in my head. A person who is asking questions because they want me to succeed, not because they’re trying to take me down a notch.
I have rushed into implementing the first idea in my head. Sometimes I’ve convinced myself that my first idea is the best, despite knowing I need to review it from more angles. I’ve jumped into projects with a shiny new tool and a bunch of optimism, only to cut myself on a sharp edge later on.
I’ve built systems that look fine on their own, but don’t fit into the puzzle around them. I’ve isolated myself building up that system, afraid to figure out how to fit my system into the puzzle in a useful way. I’ve used mocks and stubs to unintentionally isolate myself from the real system.
Basically, these are all really good ways to paint yourself into a corner. It seems like being in a corner with a shiny new system/tool/abstraction would be nice. Unfortunately, my experience is that once you have to make sense of that abstraction in a team, things get dicey.
It’s dangerous to run a software project on your own! Take a friend.
The rap game doesn’t have to be all posturing and diss tracks. We need more smiling rappers.