One of the hallmark characteristics of a nerd is the ability to enjoy a wide variety of things without worrying about how popular they might be. On that note, I listed to this song yesterday and unashamedly enjoyed every minute of it. Wish I’d been there.
One of my favorite truisms in software development is the following:
“When two things aren’t the same, then they’re different.”
I don’t care how hard you work to make development and production environments the same, I don’t care how portable you think your programming language is across operating systems, and I especially don’t care about claims made on a product’s marketing material. Case in point:
[Docker] makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.
No doubt the Docker team has worked incredibly hard to make the above statement true, but nothing in life is guaranteed with 100% certainty. Last week I discovered that the cron utility will not execute any crontab or script that has more than one hard link pointed at it (don’t ask me why not, it just doesn’t). And due to the way Docker’s overlay filesystem works, the operating system can report a regular file as having multiple links. At least it does when the container is running under Kubernetes. But not always! When running with docker-compose on my Mac the crontab only reported one hard link, and thus cron worked great.
Took me nearly a day of fiddling to determine why the container worked great locally but failed in Kubernetes. Argh.
Customers are a finicky bunch (they’re human, just like everyone else). That means they’re not always right, and any business practice that assumes they are is likely to fail in the long run.
Don’t hear me wrong, I’m not saying that software engineers shouldn’t listen to customers. Nor am I saying businesses shouldn’t careful consider their customers’ demands and in certain situations give in. I’m really speaking more to an attitude of continual acquiescence. That’s not helpful for a customer who may not have the skill to evaluate what he wants, and it’s not healthy for a developer when they see their professional opinions thrown to the wayside.
If a relationship isn’t a two-way street, it’s probably not worth having.
Everything takes time.
Plan accordingly (which also takes time).
I’m taking a day off from writing today. See you tomorrow!
(Yes, I understand the irony of this post)
It’s been nearly two years since I became an official “manager” of software engineers. While it comes with its share of challenges, I find it more fun than I’d initially expected (it doesn’t hurt that I still have time to write code).
Software development has a reputation for being the domain of anti-social nerds who work in isolation on esoteric technologies with scientific precision. But the truth is that human beings write software, and development is just as much an art as it is a science. Each engineer brings his or her own unique skills, personality, and craftsmanship to a product, and the result bears that image.
The best software projects are those that recognize this and use it to its full advantage instead of fighting against it with process and policies that seek to stamp out individuality at the altar of predictability. It’s a self-defeating approach, at least until the time when AI can write good code (and if that happens, we’re all doomed anyways).
Only tangentially related, but this is the best article on software development ever written. Until tomorrow?