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.
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.
The New Year came and went without much of a fuss. I read about the [2016 Maker Challenge] 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.
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], and we know very little about its origin. It’s an interesting word, and interesting is good.
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.
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.
A friend asked me what my design philosophy was and how it had changed over the years. He was asking about the design and flow of applications and websites. Actually, he actually asked about visual design specifically, which I found interesting in itself. I paused for a moment when he asked, which is unusual for me as […]