Brent Simmons:

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 here¹.

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.

Some of the clients I work with have a very collaborative culture. Decisions are always run past all interested parties and buy-in is required from everyone.

The people in charge set the general direction but not how to do it.

I prefer to work for (and with) companies that are like that because, well, my opinion counts! Having the people who know the work the best make the decisions makes the most sense. People appreciate the autonomy and the trust that management place in them.

In this piece, Seth Godin argues that understanding something is better than just memorising a process. Understanding is certainly key, but I think that misses something: there is value to in steps.

True, if you slavishly follow the steps, you can’t adapt. But if you don’t document the steps, it’s easy to miss one and get yourself into trouble. The challenge is knowing when to follow the steps and when to improvise.

It’s five years since the first UK lockdown.

Despite that distance, I wonder if there is anything original that can be said about 2020?

Unlikely. Knowing that removes some of the pressure. Instead, I really just want to write something to commemorate the strangest of years¹.

For the most part, personally, 2020 wasn’t a terrible year, just unusual. I’m fortunate in so many ways. I kept my job. I normally work from home anyway, so the challenge when the first lockdown hit was having to work while having two kids running around all day. Not easy, but, equally, churlish to complain when so many others were losing their jobs or having relationship issues.

In my day job as a consultant, I often joke that “it depends” is my default answer to any question, much as Ben Goldacre made a catchphrase out of “I think you’ll find it’s a bit more complicated than that.”

I’m here today to tell you that it’s both absolutely true, and not at all true.

The truth is that, given a complex problem, the correct answer almost always is “it depends.” Without knowing all the constraints, all the things that have been considered and rejected, and all the things that affect the solution, it’s vanishingly rare that there is one, objectively correct answer that you know from the top of your head.

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.

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.

Have you heard about the Maker Schedule? The idea resonated as it explained a lot about my productivity.

For the uninitiated, here are how the two types are defined.

The manager’s schedule is [where] each day [is] cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

The Maker’s schedule, on the other hand:

I greatly enjoyed Graham Lee’s series of posts about specialisation versus generalisation in software engineering¹, quite possibly because it’s me.

My background is a little different from Lee’s, though, so I thought it was worth sharing.

I have a two tier experience². With a few minor blips, Unix has been a constant technology underpinning since my first year at university. I started using Linux around the time 1.0 was released. I got a Mac when — or possibly before — OS X was ready for mainstream use because it was Unix with a nice UI. At work I’ve seen the change from big Solaris and HP-UX machines, to Linux, to containerised applications (which are normally based on minimal Linux distributions). Sure, the different Unix variants are not exactly the same, but most of them have something bash-like and ls does the same thing everywhere, even if the more esoteric options vary.