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.

The backlash has begun. Four months ago, everywhere was proclaiming that working from home was both the New Hotness and Here to Stay. In the last few weeks, those same venues have switched gears, documenting how people can’t wait to go back to the office. What changed?

Nothing. Simply the novelty wore off.

I get it. The last time I had a work-from-home job I didn’t really enjoy it. It was a decade ago and the technology wasn’t quite there. No Slack, an emphasis on phone calls rather than video-chats and much weaker collaboration tools like wikis. I was also one of only a few people working remotely. But, perhaps most significantly, I was at a different stage of my life.

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.

Since the whole world is now working from home (terms and conditions may apply), everybody else is writing their working from home tips. I didn’t want to feel left out.

The way I see it, there are two related aspects: first, how you deal with it; two, how your office culture deals with it.

If you’re asked to work from home, you need to make the most of it. But right out the gate, it’s important to note that it doesn’t suit everyone. It sounds good, but some people just find it hard to be productive when there are distractions, from housework to a Nintendo, and they find it hard to manage without the face-to-face social interactions. There are many reasons and there’s no shame in admitting it’s not for you.

If I took this book to heart, I should try to convince you to read it.

I’ll be honest, I wasn’t sure I’d like this book, and I mainly took it out of the library so I could make the joke in the first paragraph (and others like it). I mean, negotiation isn’t my job. I’m not, like the author, a hostage negotiator. I’m not even in sales. The key, of course, is that we all have to negotiate from time to time. While I may not often have to negotiate money in my day job, I do have to agree on the scope of work. This is a form of negotiation. We all have to buy stuff or hire someone to deal with jobs around the house.

The gist of “ReWork” is that anyone can be an entrepreneur but you don’t have to follow the Silicon Valley tradition of seeking venture funding and providing foosball tables. If you do things right — different — you can make a sustainable business in a more traditional, bootstrapped way, and you don’t have to continually grow to be considered a success.

Many of the “lessons,” however, apply to almost any knowledge work. They subscribe to a less-is-more philosophy, and the book follows that example by being a quick read. Like the less-is-more outlook, that doesn’t make it bad, only very targeted.