The Harsh Light of Remote Work

I came across the Remote Only manifesto recently, and while reading the points was struck by a common theme.

One of the major hurdles to remote work adoption is that it involves doing hard work in areas that people find tedious and hugely prefer to skip if they can get away with it.

Documenting things, standardizing things, careful and thorough written communication, having to examine carefully the work someone has produced to judge their performance, etc.

There are all sorts of ways to fudge these things when you all commute to the same building every day. You can see when someone is physically present in the building or not. You can get around poorly documented processes by tapping someone on the shoulder. The problem is, these things are all ephemeral and poor substitutes for actual value added.

harsh light

Effective remote work arrangements kind of force you to get your shit together as a working group and do the stuff you really should have been doing all along.

It's like when organizations get excited about open-sourcing a cool piece of their internally developed software. Suddenly when you're about to expose it to the light for general consumption, you realize all the design flaws that have left it tightly coupled to what should be isolated systems and how you don't have a reliable build process but have relied on Jerry who "sets you up" when you join the company so you can compile the damn thing. In short, it exposes all the places where you took shortcuts instead of sticking to good software design practices.

Remote work can shine a harsh light on the flaws of an organization. Walk into the light.

The private office is dead, long live the private office!

As someone who has been a vocal critic of open plan offices over the last several years, while also gleefully taking in the rise of remote work, I'm starting to wonder if it's time to give up the fight.

I find the sister phenomenon of the coworking space illuminating. An intentional open plan community for those fortunate souls privileged enough to look the quiet and privacy of a home office dead in the eye, turn their back, and instead pay a monthly fee for its near opposite.

coworking space

It's almost like the open plan and the home office represent the yin-yang of working environments.

Companies with large distributed workforces often have hot-desking arrangements in their facilities with a pleasing symmetry of a progressive work-from-home policy.

I may be giving up on the idea of employers going back to the days of private offices, and calling the whole discussion moot. Really, what are we more likely to see in the future: more companies building out private offices for their employees, or more companies unleashing their employees upon their own home offices? The answer is so obvious, that I'm not sure it's worth typing.

The private office is dead. Long live the private (home) office!

Humane Offices: The HN List (April 2018)

An Ask HN post hit the front page of Hacker News this month asking people to submit information about companies that specifically do not use open plan offices. I decided to comb through the comments and produce a clean listing of just the company names, with links to their websites, and, where applicable, the specific office location mentioned.

The Know-not-all Developer

In the Hacker News discussion of a recent post by a programmer who had publicly quit Google, I ran across a comment that I wished I could have sent back in time to the younger, angrier version of myself who was constantly frustrated with the goings-on at his early developer jobs.

People were debating how to win the “political game” that seems to determine one’s success in a larger organization. In discussions like this, I’ve noticed (and participated in) a common cynicism about “politics” amongst developers—that one’s technical merit is chronically underappreciated and that you must scheme your way to the top.

Hacker News comment

It took me years to come to the difficult realization that maybe the people who were placed in positions of authority were there because they had a better grasp of the needs of the business by which we were employed. Maybe they had strived to understand a broader context for their work and how it impacts the profitability of the company.

Are there boneheads in management? Of course! Just like there are at any level of an organization. But I personally found it better for my mental health and career satisfaction to develop some humility about my relationship to the broader organization.

My advice for a younger me would be this: Listen to the folks in your management chain that you have regular exposure to and try to develop a sense for the kinds of problems they tend to think are important, and then focus yourself on those areas. Also, you don’t know everything.

The Professional Buzzkill

I’ve joked occasionally that every software project needs a dedicated “Buzzkill”—someone who balances out the pie-in-the-sky thinking that often hurts these projects.

I do believe that optimism is one of the greatest dangers to most software projects—people being unrealistic about the complexity of things and how long things take to do well. But no project ever gets off the ground without optimism, right? Would any non-technical person ever sponsor a software project if they really took in the full complexity and likelihood of failure that their project (or any project) faces?

Broken toy

So let’s accept the necessity of the optimist. Instead of damning optimism, let’s promote context. Maybe every team needs the “Contextualizer”—the person who places new ideas in context and then encourages discussion in that light.

One of the great triumphs of Scrum is that the product backlog acts as a context for features to land in. Force the product owner to think about all the other stuff they’ve asked the team to do, every single time they have a new request.

I pledge not to shoot your idea down, but I will give it some context!

Ownership

One of my favorite Twitter accounts in the software industry is Esther Derby’s. I’m constantly nodding along. This one got me thinking about the concept of “ownership” on software teams.

Esther tweet

It’s a common refrain from software project managers that they want developers to take ownership of the features they build, as in, accept accountability for what they’ve built and its quality—to care about it.

As someone whose career responsibilities have occasionally involved diving into another team’s codebase to figure out what went wrong, I’m guilty of thinking to myself, “How could these devs have shipped this crap? Don’t they care about the quality of their work?

Later on, I get a glimpse into the management of the team, and witness how the developers are pressured constantly to deliver more features, forget the bugs, and “commit” to delivering requirements they had no hand in writing and no say in the timetable for delivery.

It is damn near impossible to get developers to really take ownership of their code when all the circumstances of the project are implying: “Shit it and ship it!

Development teams must have veto power over scope and estimates, which I’m sure scares a large contingent of managers out there, but without that there is no hope for “ownership.”

Software Development Methodologies as Collective Fictions

The failure of methodologies to accurately model reality is a common source of cynicism amongst boots-on-the-ground developers. I can recall many conversations with teammates where we’d end a meeting and then chuckle in hushed tones with each other about how “wrong” we were doing Scrum and how clueless our managers were.

In his article My 20-Year Experience of Software Development Methodologies, Ian Miell makes the point that methodologies are necessary as “collective fictions”—a thought I personally find comforting.

As an industry, we tend to look back on Waterfall as hilariously naive and antiquated, but to Ian…

…the waterfall process was a ‘collective fiction’ that gave us enough stability and coherence to collaborate, get something out of the door, and get paid.

He goes on to discuss his experience with Rapid Application Development at a startup:

We were small enough not to need a collective fiction we had to name. Relationships and facts could be kept in our heads, and if you needed help, you literally called out to the room.

We got slightly bigger, and customers started asking us what our software methodology was. We guessed it wasn’t acceptable to say ‘we just write the code’.

Turns out there was this thing called ‘Rapid Application Development’ that emphasized prototyping. We told customers we did RAD, and they seemed happy, as it was A Thing. It sounded to me like ‘hacking’, but to be honest I’m not sure anyone among us really properly understood it or read up on it.
As a collective fiction it worked, because it kept customers off our backs while we wrote the software.

Ian then experienced Agile, with all its foibles:

The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.
As a collective fiction it worked, because it kept customers and project managers off our backs while we wrote the software.

As someone who’s been making software professionally for over a decade now (not as long as Ian!), I have arrived at much the same conclusion, that software development methodologies have value regardless of their literal reality. Organizing principles and shared terminology alone are worth adopting something...anything.

Sure.

Accepting the inevitability of these collective fictions is like taking a weight off of one’s shoulders. It just saves so much angst.

Bosses like to give politically-correct names to things that their people are already doing, and that’s fine. The software industry’s current fixation on Agile concepts is a reflection of the way that a distributed workforce would inevitably do things. Ian explains:

If software methodologies didn’t exist we’d have to invent them, because how else would we work together effectively? You need these fictions in order to function at scale. It’s no coincidence that the Agile paradigm has such a quasi-religious hold over a workforce that is immensely fluid and mobile.

We’ll always be working under some “methodology” and that’s okay. Just keep making good software, and don’t worry about what people are calling it.