warpedvisions.org — Stuff to make you think

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.

Tips for Avoiding Technical Debt and Regret August 15, 2016

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?

💰 Being Honest About “Technical Debt” July 17, 2016

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.

Do just one more thing March 28, 2012

I have a suggestion. Do just one more thing. If it’s not rude, do another. And another.

Rediscovering the interestingness in my Twitter feed March 18, 2017

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.

Reasons I hate TODO list and task tools December 30, 2016

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 […]

🦄 Unicorns and the Shifting Landscape of Computing April 3, 2016

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.

42 Things I will make in 2016 March 10, 2016

The New Year came and went without much of a fuss. I read about the [2016 Maker Challenge][1] shortly after the holiday, in the flood of annual self-help and 2016 resolution articles. The challenge was something I was keenly interested in, then promptly forgot about in the chaos of startup and family life.

The fight for clarity and beauty in writing December 2, 2015

I’m not old yet, but I’m becoming a curmudgeon. In fact, I love the word *curmudgeon*, it’s a word that sounds like its meaning, with a spelling that is all pissy and annoyed. It’s a word of [mystery][1], and we know very little about its origin. It’s an interesting word, and interesting is good.

Things that make your podcast much less annoying to listen to December 1, 2015

I have tried to love podcasts for a few years now. There are several that I like, but I find it difficult to listen to any of them consistently. I’ll binge listen for a few weeks, but for whatever reason I get stuck and move on to the next show.

Thinking in diagrams; a developer’s guide to learning to love drawing design March 14, 2015

I think about software design by diagramming and writing. The act itself improves the result. It forces me to decompose and organize the problem, and attempt to explain it back to myself. I have always been able to think about software through this process of sketching, refining, and describing diagrams, even when I didn’t know anything about what was standard or what should be done. I started by doing what made sense to me.