Career Philosophy: Stack Chasers vs. Evergreens

One way of pursuing a career in software development is to perennially jump from technology to technology, or you may say, tool to tool. The idea is to keep a close watch on the emerging trends and invest serially in the trends that seem most promising early enough that you can command a nice salary (or contract rate) for the short period of time where the demand is cresting and the supply of developers is lagging.

I flirted with this path for a time in my own career, until I realized that it was not sustainable for my temperament. I had to admit to myself that the only way I could sustain a career this way was if I genuinely enjoyed jumping on new tech continually. Because so few trendy tools ever sustain a high demand for more than maybe a couple years, this process must continually repeat, jumping again to yet another trendy tool until its 15 minutes of fame again subsides. I came to terms with the fact that I’m not actually the kind of person who cares about technology for its own sake, instead preferring to focus on solving real business challenges with proven, reliable tools, using software as a means to an end.

I’ll borrow some terminology I witnessed on a Hacker News discussion today, and refer to this career dichotomy as the Stack Chasers vs. the Evergreens. Hopefully it’s clear by now that I have sided with the Evergreen camp.

Eduards Sizovs, whose post started the Hacker News discussion, reminded me of the Lindy effect, which I had never thought about as being career advice, but I like it…

The Lindy effect is a concept that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.

In Eduards’ case, he decided to spend 80% of his learning efforts on evergreen principles of software development and 20% learning a Lindy-approved boring technology: the Spring Framework, a 16-year-old application framework for Java:

The longer a technology is on the market, the safer investment it is.

Don’t rush to learn new technology – it has a high probability of dying.

Time will show which technology is worth investing. Time is your best advisor.

Amen from the Evergreens.

The Enterprise Archaeologist

The Programmer-Archaeologist churns through this maddening nest of ancient languages and hidden/forgotten tools to repair existing programs or to find odd things that can be turned to unanticipated uses.

- Programmer Archaeologists

One of the aspects of working as a developer in an “enterprise” is that you often find yourself knee-deep in ancient piles of software, developed by some long-dead civilization, who left behind only ambiguous scratchings on stone tablets as documentation.

I will say that there’s a certain element of adventure to these things. You’ll discover tantalizing clues that you’ll piece together to divine the intentions behind the creators of these strange, crumbling structures.

And just as “maintenance” programming is some of the most difficult programming I’ve ever had to do, enterprise archaeology has been some of the most interesting.

The past needs you!

Risky Business

I’ve often thought about how to explain the differences between working for small/medium businesses and an “Enterprise”. Well, Ian Miell breaks it down better than I could in his article Why Are Enterprises So Slow?

I would sum it up thusly:

The priority of the Enterprise is risk avoidance. They have a huge, successful business and don't want to screw it up. A startup is the opposite. They have a tiny, fledgling business and must take risks constantly to be successful.

A huge, old company has seen just about every way someone can screw something up, and they’ve written a rule that applies to everyone that intends to prevent it from ever happening again.

It’s very important to the Enterprise that when something goes wrong there’s “One Throat to Choke.” As Ian explains..

From ownership comes responsibility. A lot of the political footwork in an enterprise revolves around trying to not own technologies. Who wants to be responsible for Java usage across a technology function of dozens of thousands of staff, any of whom might be doing crazy stuff? You first, mate.

The ability to always have some specific person within the organization to blame for something leads to the laborious “Change Management” in the Enterprise. As Ian explains..

In order to ensure that changes to systems can be attributed to responsible individuals, there is usually some kind of system that tracks and audits changes. One person will raise a ‘change record’, which will usually involve filling out an enormous form, and then this change must be ‘signed off’ by one or more other person to ensure that changes don’t happen without due oversight.

There’s absolutely nothing wrong with preferring working for an Enterprise over a smaller company…in fact there are many advantages depending on one’s point of view.

Just realize that the Enterprise is above all else risk-averse, and hence, slow.

Read the whole of Ian’s article for more wisdom:

Why Are Enterprises So Slow?

Opportunistic Agile

I recently came across Martin Fowler’s article on “Opportunistic Refactoring”:

If you don't spend time on taking your opportunities to refactor, then the code base gradually degrades and you're faced with slower progress and difficult conversations with sponsors about refactoring iterations.
…
From the beginning I've always seen refactoring as something you do continuously, as regular and indivisible a part of programming as typing if statements.

This made me think back on all the times I’ve blogged about this spirit of doing things opportunistically in the process of developing software.

From Opportunistic Programming, to the Boy Scout Rule, and If You Can Lean You Can Clean, I see a common thread.

The “just-in-time” spirit of Agile is opportunistic. Doing things when they’re needed, not before, not after. And capitalizing on the bits of value that are in front of you right now.

Some Thoughts on QA

A recent comment on Hacker News got me thinking about the role of QA people in software projects…

To quote Dodge (via Deming), "You cannot inspect quality into a product."

…

It doesn't matter how great your QA team is, if the quality isn't in the system the QA team can't put it there.

I’ve seen time and time again where managers become concerned about the low quality of the software their organization is producing, and deduce that the answer to their problem is to assign more QA people to the project, as if the lack of QA people is the reason for the low quality.

There seem to be some misconceptions about QA that I wanted to write a few notes about:

1. Testing of software should be at least 90% automated. The manual part is “exploratory” testing.
2. A corollary to #1 is that people who want to do QA as a full-time career need to be able to code.
3. The best QA people I’ve worked with in my career became more akin to business analysts (BAs) on the team, who were suggesting improvements to the user experience based on their knowledge of the business processes.
4. A corollary to #1, #2, and #3 is that QA can add value by:
• Being better at test automation than the developers.
• Knowing the business better than the developers.
5. Jobs that involve a large portion of repetitive, mechanistic work are begging to be automated away. Even slow-moving companies catch on eventually. Be the automator.

Conway’s Law & Remote Teams

Conway’s Law states:

organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.

In my last post, I wrote about how remote work tends to shine a light on areas where a software organization has been taking shortcuts and avoiding good design practices—things that are easier to workaround when everyone is within shouting distance.

If you subscribe to Conway’s Law, then it makes sense that the modularity of software designs would reflect the physical distribution of a software organization. It’s especially important that the work of remote developers can fit together across well-defined interfaces.

How much more important is self-documenting code when ad-hoc explanations are more laborious or time-shifted?

It’s fascinating to think of all the parallels that Conway’s Law implies between software design and a distributed workforce.

Even the trend of microservices…

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.

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.

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.

• Viasat
• Apple (One Infinite Loop)
• Microsoft (Most of Redmond)
• Skyscanner (London)
• Pixar
• Fog Creek
• Trello
• CMG
• Stack Exchange
• ExtraHop
• Epic
• MITRE
• NetApp (Sunnyvale)
• Cisco (Norway)
• IBM Research
• FastMail
• Red Hat (Westford, MA)
• Kensho
• SAS
• PARC

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.

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?

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.

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.”