Okay, that’s a bit grandiose, I admit. But I often see tweets or posts about how people don’t “get” capital-A Agile. Tweets like this and this point out common faults. Everything they say is technically correct but not especially useful. Pointing out all of the not-get-its in the wild won’t make people “get it” better, […]
I just returned from traveling and wanted to highlight some good design I saw: the mobile ticket display for Chicago’s Metra (suburb commuter) trains.
Every project eventually hits a point where a big change needs to be made, and it’s going to break everything. And you’re going to be the one stuck putting it back together. Whether it’s a language or tool change that causes your application to no longer compile, a third-party SaaS service change that breaks features […]
Some error messages, like C++ template errors, are inscrutable, and some, like the venerable favorite “segmentation fault,” are uselessly vague. But the merely unhelpful messages aren’t the worst. It’s the misleading error messages that take the prize.
Over a recent weekend, I installed a new faucet in a bathroom. Aren’t I handy? Well, not especially—I heard the same joke from the employees at three separate hardware stores: “Well, it’s not a real house project until you’ve gone back to the store at least twice.”
The Pragmatic Programmers advise us to “use a single editor well,” letting it “…be an extension of your hand.” If you’ve ever watched an experienced developer, it can be quite dispiriting to see just how effectively and quickly they can work. IDEs both old and new have such a dizzying array of facilities that it […]
A coworker recently found an “interesting” problem: A database starts to have errors once a table reaches more than 500 columns. Well, duh. I mean, what kind of idiot designs a schema that way? Let’s do some “Git blame”…oh.
Debugging a recent project has been surprisingly challenging. It’s a complicated product with multiple components, but that’s nothing new. The customer’s QA department has done great work, but it still feels like this is harder than it should be.
I’ve always felt that code should be absolute, with concrete yes or no answers. It is like that on the small scale: An “if” statement runs one branch or the other. But on the larger scale, it’s very hard to treat our code that way.
To have a successful project, you need to trust your team, and they need to trust you. This is obvious on some levels. Your team must trust that they’re going to get paid, and you must trust that they’re not going to copy your whole database and sell it to your competitors. But trusting your […]