I’ve gone through a number of RSS clients over the years. I used to be a big Google Reader user. I used Reeder on my iPad a lot, and now I use NetNewsWire. To ensure that my feeds are shared between devices, I’ve used Feedly. I’ve paid for it, as I use it a lot and I don’t want it to go away like Google Reader did.
But they keep adding stuff that I have no interest in, including jumping on the AI bandwagon. It has, however, been fast and reliable. I don’t have much to complain about.
I had a bias about engineers that worked for large corporations. I assumed that they weren’t as good as indies and engineers at small companies
I work for a small company and my clients are usually big companies, so I have some perspective here1.
From my experience, the difference between working for large and small companies is bureaucracy and focus. A tolerance or affinity for these things means that the people attracted to each are different. Normally when we talk about “bureaucracy,” it’s a pejorative, but that’s not what I mean here. Larger companies need more formal process to function. We can save the argument about good or bad process for another time.
A few years ago I had a job where every new recruit would go through a long process of shock and gradual acclimatisation to the main software product.
What it did doesn’t matter as much as how it was built: it was an application developed on top of a proprietary programming language and user interface designer. The reaction was always the same. Why? Why?! Why would you reinvent Visual Basic on Unix? Why would you inflict a programming language even worse than Basic on developers?1
The whole team got this email today. Okay, it wasn’t today and these are not the exact words, but it was something like this:
We have a serious regression in build 456. We have set the project back rather than taken it forward. We need the utmost focus and commitment on fixing it. We’ve broken it and we stay in the office until it’s fixed.
I’ve had a few of those messages over the years and while it’s intended to focus minds it often has the opposite effect. Let’s examine why.
With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.
Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.
Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.
As is common these days, I was complaining about something on Twitter.
https://twitter.com/sdarlington/status/1523588282986033152
It’s easy to complain about security practices which, if I’m honest, is why I do it. But there is an important point, one that I included in a follow-up tweet:
https://twitter.com/sdarlington/status/1523602044791115776?s=61&t=69wO28ER8NUpssCyeNkqJw
The security team in many companies models itself on the DUP. Say no to everything. But – and this is the key – offer no alternative.
The tweet above is about passwords but I see it everywhere. Another common one is transferring files. I understand why sharing files can be problematic. Confidential data can be exported, either deliberately or accidentally. Viruses can be imported. Security defects can be exploited.
Before you ask, yes, it is weird that I’m reading a bunch of “management” books.
You can watch Michael Lopp’s career by following his various books. Start with “Being Geek” [affiliate link], the software developer’s career handbook. The move into management resulted in “Managing Humans” [affiliate link]. And his promotion from manager to director and executive gets you “The Art of Leadership” [affiliate link] which is the book I recently finished.
A couple of years ago I did a conference talk called “On Cloud Nine: How to be happy migrating your in-memory computing platform to the cloud.” I wish I’d had “Cloud Without Compromise” back then. It covers much of the same ground but, as you’d expect in a book rather than a forty minute conference talk, in much greater depth. More importantly, it puts some concepts into context much more clearly that I did, either by explaining it better or by giving it a good name.
I’m still fascinated by the computers of the eighties. Without well known standards, every machine was different, not only from those of other manufacturers but also older machines from the same company. As as user it was terrible. Back the wrong horse and you’d be stuck with a working computer with no software and no one else to share your disappointment with.
But looking back, there’s a huge diversity of ideas all leaping onto the market in just a few years. Naturally, some of those ideas were terrible. Many machines were rushed and buggy, precisely because there was so much competition. Going on sale at the right time could make or break a machine.
After university, when I first started working, I jealously noticed people leaving their desks and attending meetings. I was left sitting at my desk, bashing out code. What was going on? What exciting things were being discussed without me? Sometimes they’d come back from the meeting and ask a random question. It was all very mysterious.
A while later I started getting invited to these meetings. I found what was being discussed. I discovered the mystery.