Learning To Stop

Experiencing the pandemic has been very interesting.

There are many disadvantages to working by yourself when you're a coder/writer with a passion for strategic technology management.  All systems of people are political. Technology is the same. Technology strategy and implementation, like the rest of it, is a group activity. There are trends, movements, and things one should do or say to stay with the alpha group.

Isolation is not all negative, though. Working alone avoids some of the negatives others face. There's a lot of follow-the-leader in tech. Joe worked at BIGCORP before it took off, he created their backbone, he spoke at many conferences, and he's a likeable, smart guy. It becomes very easy, almost second-nature, to point at whatever the latest thing he says and all critical thought ceases. We can get on with our "normal" job. Got problem X? Joe wrote/spoke about that last week! I'll send you a link to his latest essay/video.

I find it interesting to mentally poke at why we tend to skip over certain topics, usually without ever acknowledging them. When I find people using appeal-to-authority or other conversation-stoppers, I start looking for patterns.

This is one of the advantages to isolation, the ability to refactor underlying patterns in various conversations that otherwise would go unexamined. Many of ideas contained here are important, but they always come up as part of some larger context and never teased out. (Yes, nothing is new under the sun, and many of these ideas have books and such devoted to them, but never in proportion to how important they actually are)

Focus, for instance, continues to be a common theme in growing companies. There are so many cool things to do, smart people eager to work on tough problems, and opportunities to grow! Decades of reading and listening support the thesis, often hidden, that maintaining focus in a tech organization is a non-trivial exercise in the best of times.

Maintenance Difficulty also has been a recurring issue for decades. So many movements and technology are created all around fixing or mitigating the problem of technology maintenance. The list is tremendous: CI/CD, SOLID, blue-green deployment, the Simian Army, TDD, ATDD, monorepo strategies, and so forth. These are all great ideas, but at heart these are all great ideas that try to prevent or help with tech maintenance.

Feature/Version Creep is an issue related to both focus and maintenance difficulty, but it deserves its own mention because even with perfect focus and simple-to-maintain software, new versions and features in underlying systems creates both new work, new problems, and new opportunities. OO languages support functional concepts. Containerization allows unheard-of scaling. New AI techniques support greater market penetration.

These are all ideas that recur in almost every tech conversation we have. For many junior coders they may seem too generic to deal with in isolation. None of them are good or bad, but taken together they are examples of how tech creates a foundation of shifting sand underneath whatever we're trying to do. This shifting sand always gives us more to do.

We Have A Problem

Far too few students are learning how to solve a problem using technology and then walk-away in order solve other problems. We are not teaching our problem-solvers how to solve problems, i.e., how to stop.

What books have you read in the last few years that have attempted to demonstrate "This is how you use technology to solve X and finish the work". I haven't read any.

There are thousands of counter-examples, though. Every year, hundreds of books are released on new tech, new platforms, new libraries, new processes, new opportunities. I have no idea whether any of these are good or bad. Don't care. What I care about is that all of these books, videos, and conferences are open-ended: learn this thing. Pretty soon there'll be another thing coming along that you'll want to add to it. It's an endless buffet and we're all salivating over the wonderful food and not thinking of when we've eaten too much.

I know of dozens of corporate teams that are in some form of death march, feature mill, micro-management hell, or lost cause. I see job ads almost constantly where by looking a bit under the hood, you figure out that while management has a lot of complaints, and they're willing and able to hire people to fix their problems, they don't actually know how to stop.

You can solve a problem and walk away from it. This should be the default way of working in technology. It should also be far, far more important than any of the other things we teach in tech.

It can be shown to happen all over the place, but nobody's generalized the concept of "here's how to stop" enough to ingrain it inside of whatever other tech we're creating. Instead, each piece of tech is built and taught as if it will become a needed and valuable tool for all of our career. Each piece is the start of a long relationship with this type of tech. And so, we easily pick up pieces that morph and complexify over time. Every now and then we drop some pieces or swap them out for others, but mostly, like a snowball, we just keep accumulating more and more things that are more and more unstable (whether buggy or not). Is it any wonder that we then use these pieces to build tech that exhibits the same behavior?

When I started, I read a neat statistic: whatever you're doing in tech, in two years 80% of it will be outdated. At the time I took that as a challenge and a source of wonder. What sorts of super cool things will I be up to in 20, 30 years?

What I found out, though, was that most of this 80% was not related to the problems I was solving. The changes, not always but mostly, were much more about me as a technologist than they were about people and the problems they had. Instead of learning to solve problems better, I was learning to do more stuff that I liked doing.

I am not yet another old dude yelling at a cloud and saying you shouldn't learn new stuff. Yikes! On the contrary! You should constantly learn and try new things! What better way to do that, though, than to do it inside of a mental framework that allows you to know when to stop? The world is full of huge COBOL systems written by people who didn't know how to walk away. It's full of folks still working on immensely-complex projects that could have been simple and done. It's full of projects with folks doing stupid things that could be doing something much more productive with their lives. Don't be building the next one.

We need to learn how to stop.

Our Audio Podcast RSS