Yesterday I migrated a bunch of microservices from the baseline Node 6 Docker image to an Alpine Linux version that I custom-built to be as small as possible. Average image size went from 800MB to 80MB across the 6 services, for a total savings of over 4GB per deployment.
Not a bad way to spend a day.
Any engineer worth her salt must learn to prioritize well. The next couple weeks are crunch time at the office, so my posts here will be spotty at best. My hope is that once things settle down I can dive into some meatier topics. But for now, superficiality rules.
In 2007 I spent most of the summer in the desert flight testing a sensor system in the back of a C-130 (incidentally, our test aircraft was used a few years later in the filming of the opening scene of The Dark Knight Rises). During my off-hours there wasn’t much to do in town, so I listened to quite a bit of music, including this particular album:
The message of this song is one I believe applies to many areas of life, software development not the least. As I said yesterday, in any situation where a mistake is made, no matter who committed the error, it’s a worthwhile effort for everyone involved to consider what they could have done differently. The way I figure, to admit absolutely no responsibility is to relinquish the one bit of control I do have over a situation, namely myself. And that’s a power I’m unwilling to give up.
It can be scary to live in a state of constant self-evaluation, but I find it freeing. It’s the mark of deep-seeded insecurity when one is unable to admit his own faults.
It happens to every developer at some point. You spend a bunch of time trying to determine the source of an urgent bug, only to find out the problem was caused by action or inaction of the user. It’s easy in that moment to be frustrated, but may I suggest a more circumspect path? It behooves a thoughtful developer in these moments to consider if the source of the user error was caused by poor design. Perhaps the button wasn’t in an obvious place, or the side effects of the command were not obvious, or the name of the feature didn’t describe the outcome. In many (even most) cases, user error is preventable with good design.
Yes it’s difficult, and perhaps impossible in some situations. But it is the high calling of the software engineer to design products in a way that a user almost subconsciously knows how to operate without error. Viewing design with this attitude saves a lot of frustration.
It might seem this is a counter argument to Not Even Mostly, but actually they go hand in hand. A user must be carefully listened to and considered, but sometimes they must also be guided into the features they really need, versus what they say they want. Do that hard work up front, and you’re more likely to have a system that minimizes the potential for mistakes.
Also, go read The Design Of Everyday Things.