Ask HN: What to do as a software engineer that cares more about what to build?

I have worked with 3 types of PMs during my time as an engineer as well as a lead.

1. The one who tries to reinvent the product and you tend to end up questioning their design or product decisions because they seem flaky and makes no sense. Being a newly promoted lead with my own ideas I was often at loggerheads with them. For anyone who reads this and is in the same position, I would suggest to continue building what the PM asks you to do. Any opposition or pushback you create regarding their choices will just lead to chaos for your team and in the end you would have to go with it since their role is the one making such decisions.

2. The one whose requirement are empty shells waiting to be filled with the questions raising by the people they present it to. I would suggest to get away as far as possible since your requirements will never remain fixed as the PM will be open to suggestions and influences from all over the company and you would end up with a rube goldberg machine.

3. PMs who take time to do research, write down solid requirements, convince stakeholders and also have a iteration based release plan in mind. I worked with only 2-3 PMs like this and based on what I saw, they tend to burn out faster than you do and either quit or regress to type 1 or type 2 just to get the release out.

Having said all this, I would rather be happier working with solid requirements rather than making them. I have played the role of a PM temporarily and found that it is generally a thankless job, regardless of the effort you put in.

I do too. There is something about building your own idea that’s magic. Even partially magic is given the “we need an x” but deciding on the technical and visual design. Team work is probably more effective here: graphic designer. UX, product managers etc. at producing the polished results we expect in the 2020s but man … why are we drawn to side projects? The urge to build from the ground up is strong.

Hell yes. After 20 or more years doing this, you build a reasonable bullshit filter. A lot of the time, if the ask doesn’t pass that filter I find it very, very hard to commit. It’s hard enough being useful without that. Life is too short to be wasting it on building something you know is d destined for the bin.

I think the majority (80% I’d guess) prefer to have the requirements come from someone else. To be honest I’ve worked with many people who would always say there isn’t enough ‘design’, as if the classes and methods should be written out for them and do as little thinking as possible.

I love the idea of "hands on product management", where you are both the product manager and one of the developers. The difficulty is finding a balance between passion and financial wisdom.

I think all humans want to feel like they've had an impact and that their work is valuable.

I agree with this as well. Around 50 people (maybe even 40) companies are required to start operating in a more bureaucratic way, and more often than not this means there's a top-down approach where software developers are just doing what they're told rather than influencing what gets built.

Came here to say this. Go to a small product company in a domain you are interested in.

Consulting companies are ok, but there you pretty much build what clients want. If you can find one that focuses on an interesting domain, that can be a good fit.

At small companies you get to be part time product manager, project manager, customer support, QA, developer, doc writer, and more. Especially if you are relatively senior.

For some folks I know, this is a nightmare. I personally love it. Give it a go!

How can you find such small companies? I'd look in the "Who's hiring" threads and on sites like https://www.builtincolorado.com/ (if they exist for your area). Also, ask in your network.

Seconded. 50 people is a good round upper limit.

Thanks for the pointer to the article!

Yeah, that's a good point. The PM is sometimes pretty constrained by the business. Maybe it's just a grass is greener thing. Have you been anywhere where the eng team had some say in what they make?

Never that simple at a macro level. Business will claim more knowledge of the “market” and are probably right if they have got feedback from customers. “We need to build X as part of our strategy”

Sure you can choose to use nodejs instead of ruby or embed video instead of streaming it yourself or find a better confit system than admin pages but the entire product ideas are probably decided by the business well in advance of when the developer gets whiff of it.

Imagine you are about to purchase a car and the car dealer weirdly tries to convince you to take up cycling via “what’s the problem”. You’d probably walk to the next dealer as you’ve made up your mind you want a car.

Haha. Yes, I do that potentially a bit too much. It always feels like pulling teeth -- like the official process doesn't have room for that kind of back and forth. For example, in scrum, the product owner is meant to have that conversation, not the engineers.