I’m biased. As Mulder did, I want to believe. Except, I want to believe that being a generalist can work. And that’s what “Range” [affiliate link] by David Epstein, claims. It’s subtitle is, “How generalists triumph in a specialised world.”

It’s not a challenging read. There is a lot of anecdata, examples of people who took a broad path and still succeeded. In that sense, maybe it’s like “Quiet,” which is about introverts. It doesn’t tell you how to succeed, only that it’s possible and that you’re not alone. Maybe that’s enough?

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?¹

I recently shared a blog post entitled “The Most Successful Developers Share More Than They Take” with the comment:

I try to practice “public by default” though, because of my work, it’s often “on the internal wiki” rather than fully open.

Unfortunately the article spends a lot of time talking about blogging and podcasting which, perhaps, undermined the point I was trying to make. If you want to write blogs, speak on podcasts, and present at conferences, good luck to you¹. Not everyone will want to do those things, and that’s fine. I’m not advocating for that. I think most people can do what I meant.

Sometimes it’s only when you start writing about a subject that you truly understand your opinion. That’s the approach I’m taking to answering the question: are you going to leave Twitter?

A few people have asked me in the last couple of months and the only response I have is that I’m not jumping ship and closing my account immediately.

But as the weeks have progressed, as I’ve written this piece, my thinking has evolved. It’s not that I’m going to immediately close my account but I can see The End approaching. Indeed, my usage of Twitter has dropped considerably.

I’ve been working from home for five years. I started well before the pandemic and, like many who have tried it, would have a hard time going back to an office full time. However, I used to spend my commute reading. In those years I have not managed to consistently find time to just sit and read.

What I’m saying is that 2022, from a book reading perspective, has gone not got well, even worse than 2021! I have only completed four books. I enjoyed two of them, the other two were a bit meh. Not actually bad but I wouldn’t say that they justified their word count.

Every year I try to complete the Advent of Code. Every year I fail to finish. I get about halfway through, and the exercises start taking longer to complete than I have time.

Every year I think about Jon Bentley’s Programming Pearls¹ [affiliate link], because the same kinds of challenges you find in Advent of Code can be found in the book. The main difference being the quality of the answers. At least in my case². In the words of the preface: “Programming pearls whose origins lie beyond solid engineering, in the realm of insight and creativity.”

I’ll be honest: I wanted to like “Facts and Fallacies of Software Engineering” [affiliate link] by Robert L. Glass more than I did. I’m not sure if it’s dated badly — it’s from 2002 — or I was in the wrong frame of mind, or something else, but it just didn’t work for me.

The book is structured as a list of facts grouped around areas such as “Management” and “Requirements.” For each fact, there is a discussion, the controversy, and then the sources and references. The writing aims to be friendly, but I found it a bit grating¹.

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.