Looking back some odd years, my job description has had quite a bit of scope creep. I started off as a humble backend developer, maintaining an API and maybe writing some SQL migrations. Then came the automated testing, which seemed like a natural extension of the role. Our team at the time still had a dedicated QA person for testing, but we took on some of that load. After that, the push was for full stack engineers, consuming APIs as well as building them. Ideally, taking mockups of designs somebody much more talented than myself could dream up, and building them in code. So I learned whatever UI framework was popular at the time and grappled with CSS. Some projects would not have a designer, and the stories became simple text describing what things should look like, the PR reviews of padding or color changes would be common. Eventually, the teams who managed the deployments started to dry up as well. So I would read up on Dockerfile implementations or minikube or mesos container hosting, making sure volumes and ports were managed properly just another line item in the job description. Around that time the QA folks started to disappear entirely, replaced by automated end-to-end tests. Taking old test cases and implementing them in playwright never felt great.

All of these new items took time to learn, and each area had a depth of knowledge to them. Database query plan views, managing test accounts in a shared environment, learning how to center the damn div, I still struggle to get the github action YAML file correct on the fifth attempt. This all is just what I have seen from a professional standpoint, on the side I still like to keep up with some trends. Toss in a study of some machine learning, neural networks, and a new language or 2. My bookshelves are a healthy mix of mystery novels, Sci-fi, and text books, and I'm ok with this. A long time ago, I accepted that I would have to constantly have a backlog of topics to cover to stay relevant in this industry. I enjoy learning, it feels like progress to me.

Recently, I have seen some argue that developers' knowledge needs to expand outside of the technical realm, that learning a different industry would be the next logical step. If you are building an accounting system, it would be better to spend time learning not just about double entry bookkeeping, but how to handle edge cases as well. To become your own subject-matter expert in an industry and marry that with any technical knowledge you would carry with you.

Honestly, I have been tempted by something like this. The idea of going back to school and learning something completely different. Re-entering the working world with years of experience in software paired with a degree in whatever. For myself, these thoughts have spawned from watching the tech job market. I have recently seen others make the case for this scope creep based on AI and code generation tools.

For fun, let's consider a hypothetical team structure. If we take these ideas to the extreme, what would things look like? If the scope of a role continues to grow, to the point where it would consume every other role's responsibilities, a team of 1. A single person becomes responsible for an entire product, design, development, sales, marketing, the lot. Let's assume the tools are able to parse whatever input this person gives into fine level details and correctly implement the requested changes.

I thought I wanted something similar to this for a while. I left my cozy big tech role to go ship my own software with the idea of becoming my own boss. After finishing V1 of the product, shipping it, and watching the download counter not move. It quickly became apparent that marketing the app was going to be the next big thing, and honestly, I couldn't be bothered. I figured if I had some adoption, the next step would be attempting some sort of monetization, but again, I wanted to focus on V2 features. So the application has gone nowhere, and without adoption, I debate if I want to put more time into feature work.

I would prefer to lean on the skills and knowledge of others for things outside my area of experience, and I'm comfortable working to be an expert in "Tech". Yes some of the skills I have in this area are rusty, and some areas I have never touched, but I will when I can, or I have to, and that's fine. If I could find a team of people working towards something where they needed my experience, trusted me to implement good solutions to the problems we have. I could in turn trust them to flex their skills in whatever area they were experts in. That would be ideal in my mind.

At the end of the day, I'll move in whatever direction the industry decides to shift. If I had a chance to provide my 2 cents, I would make a case for acknowledging the passion for technology of the majority of software devs. I think there is something special about that, we want to be here, we want to keep building and pushing tech forward. Any time spent pushing people outside of where they want to be might be better spent trying to identify how better to work together.

I get it, this feels very "Teamwork Rah, Rah! Let's all be one big family!", and I have sat in enough all hands watching leaders try to push that point with happy hours or pot lucks, I'm just as tired of it as the next person. But I do think the ideas behind the message are sound and can lead to a very productive and satisfying environment. I would push that we need to spend more time trying to identify how to implement that sort of culture. Maybe I'm starting to creep into the leadership domain. Let me get back to trying to understand the chain rule and the backpropagation process.