When working on internal tools, I often find ourselves talking about quality as a value in itself (an intrinsic value, if you will); both when considering plans, and when communicating with our users (developers, in this case).

Last week I came across a (taxi|cab) sporting a tagline along the lines of "committed to quality". What I realized is that I have no idea what it means for a cab or cab company to be of high quality. What I care about is getting from A to B in reasonable time, for a reasonable price, without anything bad happening (like, say, an accident, or the driver being rude, which is arguably even worse than an accident).

I don't care one bit about the size of the engine, tire pressure, or the color of the toe-nails of the driver. All I care about is having a pleasant experience while getting the results I expect.

So here's a thought: the same applies to developer tools, even internal developer tools. Quality, as in code quality, is only interesting in that it allows us to implement new features and fix bugs faster. What matters in the end is the experience developers have while using our tool - that they get the result they want, that they have a good experience on the way (the tool is "delightful"), and that nothing bad happens.

This of course leads to a more generic and stronger point: developer tools are products. Especially internal tools: they need to create very real value, otherwise it doesn't make sense to work on them as opposed to working directly on the product of the company. Since companies usually have very limited resources for working on internal tools, the trade-off between spending time on refactoring code and spending time on fixing bad UX is extremely pronounced.

In short: internal tools are a product with scarce resources; plan accordingly.

Last Thursday Carol S. Dweck spoke to a packed room about growth mindset in Budapest at an event organized by HVG Extra. (You know someone’s serious when they have their own Wikipedia article). These are my notes from the talk.

A.k.a. a terrible, terrible hack. There are hints around this solution on the internets, but I couldn't find a good explanation of what's going on, so here you go.

A few days ago Soft Skills: The software developer's life manual reminded me that blogging is a Good Thing ™, so I cloned the old repository. First things first, let's upgrade Octopress! Since I last looked, Octopress received a major version upgrade from version 2 to 3. That's good, the post detailing the release is really promising. It didn't, on the other hand, receive a migration guide. That's less good. After looking around the interwebz and finding several articles about moving from Octopress to Jekyll, I also decided to take the leap. Here are some learnings not covered or not detailed in those articles.

In Mindset: Your Dev Environment Is Software I showed several small examples for how you can optimize parts of your development workflow, just by realizing that the stuff you're using to develop is also software. (Yes, this is trivial, but stating it explicitly leads to interesting results.)

Today I'd like to give a detailed explanation of how a biggish refactor of your workflow might look like. Case in point: SSHing to nodes by ip, by hostname, by EC2 instance id, by Chef role, as different users. Fast.