One of my favourite reads is Kottke.org, a blog by Jason Kottke. Calling it a blog is a bit of a slight: it’s more of a magazine, like a proto-New Yorker. It’s thoughtful and relevant, weaving current events, artsy things, various interesting edges of tech, and topics about general humanity. Kottke has been killing it […]
December 11, 2017
I’m an idea guy. It’s why I love designing software, both in terms of system design and user experience. I love designing and developing products too. It’s something that can get me fired up, keep me from sleeping, and keep me motivated through even the darkest, rainiest days.
My love-hate relationship with Sprints, Agile, and software development processes in general.
April 22, 2017
In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.
It’s easy to feel unqualified to measure technical decisions, especially if you’re not technical. You may be disconnected from the planning process or you may not understand the jargon and details of an approach. How can you ask intelligent questions about risk when you feel so separated from what’s happening? How can you make clear decisions about risks with incomplete technical knowledge?
At best, we treat software technical debt like consumer debt, where we blissfully ignore the commodity and the terms of our choices, focusing only on our immediate need. At worst, we label our poor technical decisions debt (especially our predecessor’s). It’s a lazy phrase, a cop-out, and is a costly way of doing business.
I have a suggestion. Do just one more thing. If it’s not rude, do another. And another.
Some of my most productive business tools are the simplest. Take the *triage board*. It’s a whiteboard that hangs over my desk that has a list of my current projects, with magnets marking what I’m working on next. Weekly I erase the board and re-prioritize my projects, and daily I scribble notes and move the magnets as I work.
Sometime over the last year I stopped paying attention to Twitter. Between the political cacophony of 2016 and a growing list of people I was following, the noise ratio was just too poor to hold my interest. Twitter had become like LinkedIn to me, a service I used to have a professional presence, but not one that inspired or taught me anything. I had given up.
There’s a lot to like about our beloved task management tools. But if we’re honest, there’s a lot they get wrong too. Here are a few ways TODO tools grind my gears: Every task and list looks exactly the same. Lists are organized with limited hierarchy and pre-requisites. Lists are organized with no real spacial […]
Now this is where it gets interesting. I’ve been interviewing and hiring for almost 20 years. I have accumulated a bunch of questions I ask people. And while the technologies I talk about have changed, I have always expected certain skills and behaviours from specific levels of software developers. In terms of soft skills this has been very successful, but recently I’ve noticed that the hard skills have dissipated.