Staying in Software Dev? Best be able to just do things!

I sat down recently and started reading through some articles. Of all the articles of the 20 or so I was reading, one that stood out from the bunch was something Geoffrey Huntley wrote. In the article “The future belongs to people who can just do things” he brings up some points that I – and I think a LOT of people out there like Geoffrey and I – have been thinking in the preceding months. Let’s delve into a few of those thoughts, paraphrased, and elaborated on.

• First and foremost, for those coders that have been making a living writing those artisanal, bespoke, hand crafted, single lines of thought out code – your time is nigh.
• Second, if you’re one of those coders that churns out code, but you don’t care or don’t think about the bigger picture of the product you’re working on, you’re also in for a rude awakening.
• Third, if you have your environment or your stack that you build with, and don’t explore much beyond that stack (i.e. you’re specialized in .NET or Java or iOS) and rarely touch anything outside of that singular stack, you’re running straight at a brick wall.
• Fourth, if you’re pedantic about every line of code, every single feature, in a way that doesn’t further progress product but you love to climb up on that hill to die arguing about the state of the code base, you’re going to be left up on the hill to starve to death.

Beyond the developers. If you’re a technical product manager and can’t implement, or coder and can’t product, if you don’t understand the overlap then I’d bet you’ll run into some very serious issues in the coming years. If you’re a manager get ready to mitigate all of the above, and above all get ready to deal with a lot of upheaval. If you still focus on hiring the above focused and inflexible engineers, you’re likely to be falling on that sword for your team. Needless to say, there are very rough waters ahead.

That paints the picture of where the industry is right now and who is at greatest risk. Cast out and unable to realign and move forward with the industry – nay – the world in the coming weeks, months, and years. I’m not even going to mention why, what for, or how we got here. That’s a whole other article. I’m just going to focus on the now and the future.

It appears, as one common aside points out, that the future is with the redefined purpose and role that a “Product Engineer” would be. I could immediately pick this apart and say it may be too specific. I could also rant about what “product” means and what “engineer” means and that it misleads in context to programming. So I’ll elaborate to help stave off the pedantic soul that can’t think in an elaborative and systemic way.

Product Engineer

What I mean when I write “Product Engineer” is a melding of many levels and scope that we currently have in modern software development. It’s the rolling together in a mutative and advancing way the positions of product, engineering, QA, SRE, design, user experience, architecture, and all sorts of peripheral jobs around creating software into one role. Those that can take this role and run with it will be the ones that are the most successful in the coming years.

As Geoffrey titled his post, “The future belongs to those who can just do things“.

For many, I’d sadly argue a larger majority of folks than most, those on the “not prepared” side of the equation far outweigh those on the side of the “prepared” side. I’m not saying that the “not prepared” folks are going to be out of a job tomorrow, but I am saying that they’re going to be left behind. They’re going to be the ones that are going to be the first to be let go when the next round of layoffs come around. They’re going to be the ones that are going to be the first to be passed over for promotions. They’re going to be the ones that are going to be the first to be left behind when the company they’re working for decides to pivot to a new technology or a new way of doing things.

So what to do? How to prepare? How to get ready for the future?

You need to be able to do things. You need to be able to take a problem, break it down, and solve it. You need to be able to take a project, break it down, and deliver it. You need to be able to take a product, break it down, and improve it. You need to be able to take a team, break it down, and lead it. You need to be able to take a company, break it down, and grow it.

One thing that immediately pops into mind is something that almost all veterans attain, the skills they teach every prospective soldier going through boot camp. You need to be able to adapt and overcome. These are the things you need to do before you even sit down and start studying about that next tool or tech stack to get things done with.

Once you feel like you’ve gotten pretty good at breaking down a problem, a project, product, team, or company, then you need to start learning how to do it most effectively through the tooling that is out there. Working toward getting better and better at its use every day. Understanding what it really is and what it’s doing, all while not falling prey to the marketecture talk of the magic brains in the sky clouds nonsense.

Things don’t end there however. You’ve got to go beyond just breaking down something and implementation, you also need to really dig into why you break things down and how and why you’re delivering it the way you are. Without, and much of the tooling and technologies being created today are going to leave you on the sidewalk with a cup in hand hoping that it’s all quarters being dropped in.

Retro

In retrospect, I’m not saying hustle (not necessary unless that’s your juice, then go on). I’m not saying work yourself to the bone here. What I’m saying is – if you want to stay in tech at this juncture in time and into the future. It is absolutely fundamental to think from a systemic perspective, and understand the larger scale strategic reasoning behind what you’re doing. The reason being, in the coming weeks, months, and years what you will be able to do with tech innovations is so far beyond what we have been doing that you’ll need to be responsible for vastly expanded aspects of the process. You’ll need to understand market, product, fit, design, engineering, and more because working silo’d at this point isn’t going to be an option. Companies that silo the departmental cross functions are going to get ripped asunder if they can’t re-integrate those groups into a cohesive functioning unit.

These thoughts dovetail the next post up that I’ve got on the enshittification of the tech industry and how all this will likely make it worse, but it’ll eventually get better. This era is providing a chance to stand out with what you create in a way so you don’t add to the enshittification of the world. It’ll likely be one of the key differentiators in the coming years.

Anyway, agree or disagree, hate what I’ve written here? Tell me I’m wrong, or maybe you agree? Leave a comment here there or wherever and let’s discuss. I’m game to change the shape of my opinion here but it’ll take your input.