todayispotato

While I see what you're saying, there is a reason why these articles keep popping up, and that's because this "product-minded engineer" IS an actual role that is essential to developing good products. However, it has no name we can agree on so it doesn't exist in an organization.

We have software engineers that are supposed to be craftsmen, but everyone who can code uses the function title without any requirement on education or skillset. And then there's a huge gap to project and product managers, who often have no or limited technical experience and skills. Bridging that gap is what all these articles are all about, because they observe either a skilled product manager with technical chops or a developer with soft skills filling it.

Regardless, the point is that nobody hires for this role. Someone picks up the slack if you're lucky, or your product crashes and burns. Now these articles do seem to portray this person as a Messiah, but that's because he/she kind of is; an extraordinary person who saves your product, while it wasn't even in the job description!

Well no shit Sherlock, if you open a restaurant but didn't hire a cook of course you'd deify the waiter who whips up a mean lasagna. But how about you just hire a damn cook instead.

Anyway, now I've started to rant. The point is that we should see these articles as a sign that we (collectively as the software industry) are missing a role in our teams and should hire for it. Sure it's nice if this person is a genius, but hard work can replace a lot of geniuses.

They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users.

They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.

Not OP, but I do all those things at a company with 4 engineers. I have only met a couple (as in 2 or 3) engineers that I estimate would be capable of doing most of those things, but it's not impossible.

And regarding 3: both, of course. But he'll probably care more about users in day to day work, as those are more directly relevant to his goals (making a good product).

Exactly. And then the trick becomes scoping and problem selection. You can't solve everything after all!

You might be right. I do like my title more than yours though, it's more catchy!

Regarding your point however, I think you might have missed my point by a little bit, so I'll try to clarify.

I'm not advocating for existing tech. I love new technologies, and they're often a better fit than what came before. What I'm advocating for is that instead of spending time and money on investigating new technologies and trying to find problems you could solve with them, you instead spend time on finding and identifying problems that your organization is running into, or developing a vision on where you want your company to be in 5+ years.

I believe that the best and most suitable technology is always already out there, as long as you know what you need to build.

The thing is of course that looking at new technologies is easy, and identifying worthwhile problems to solve is very, very hard. But that shouldn't stop us from considering that way of thinking.

Yes you're right. But next to making money, a lot of us are also doing our best to do something valuable and worthwhile. It's just an attempt to get people to think in a slightly different direction.

I should have really used the latter...

You might have a point. The article was written to be thought provocative, to make people consider what they are doing.

The actual underlying issue however is that finding and identifying problems to be solved is _hard_. It's much easier to focus on something concrete like a piece of technology.

An example is, well, your example. The problem "How do we build car free cities?" is already much better than "How do we avoid traffic jams". But it's simple to solve that problem, for example by banning all cars; that doesn't solve the actual problem though (and is a bit silly).

The actual problem (I think) is not that there are cars, the problem is that there are too many traffic movements necessary over a physically too limited space to get everyone's needs satisfied.

Rephrasing the problem like that allows you to consider the various aspects of the problem; how can we reduce traffic movements (public transport, carpooling)? How can we more optimally use our limited space (smaller cars, stimulate bike usage and bike lanes)? And what are the needs that are being solved by traffic movements, and could we satisfy those without them (working remotely, grocery deliveries)? And what would it be worth to us to reach these goals, compared to the problem we are solving?

Perhaps I'll write an article on this specific mode of thinking. If I can actually find a way to get it on paper of course.

I'm not arguing about creating valuation on the market for founders. There are plenty of ways, on a sliding moral scale, to create a high valuation. I don't care about that.

I argue for creating actual value for users, on the long term.

I'm afraid you then might have missed my point by a little bit. Let me try and clarify.

I think new technologies are awesome. But I think you shouldn't look at a technology and ask "which problems should I solve with this?", but rather at the problems you have and then consider "which technologies should I use to solve this problem?".

The last one does mean you have to become good at identifying problems in your company or product offering, which is much harder than finding technologies. But I think that is a very worthwhile goal.

In the ACE specification or the ACE program? In case of the specification, the language is designed to be easily verifiable, also through the generated test suite. This allows a domain expert to check it, as well as a programmer if required.

In case of the ACE program, it's a program so can indeed have bugs. But at least then we only have to verify the implementation of a single program, instead of all of them.