Things they didn’t teach you about software engineering

Product/feature value usually spans a larger range of values than time to build it, so you don't need to estimate value as accurately for it to be a useful guide. It's also often easier to estimate because you wouldn't consider building it unless you have potential customers lined up.

And then if the PO says "building this feature would earn us back 2 developer-months in the first year alone" it's usually very easy for a developer to judge if building it fits into that profit window or not.

----

Of course, nobody does this in practise because people suck at decision-making. The next time someone asks you "how much will it cost?" try asking them "how much is it worth our organisation? What are we willing to pay?" and it will be clear they have done zero analysis on cost/benefit.

People don't know how to analyse -- or are uncomfortable with analysing -- these things so they are looking to be guided by their emotional response to information.

You can look up "software engineer vs programmer".

I know this is kind of an unpopular opinion, but I think an important reason we end up with this kind of work environment is that we have no formal division of labor into separate professions.

Compare e.g. with healthcare: I sometimes jokingly explain the situation to friends by saying imagine if there was only a single profession called “Healthcare Worker”, and every hospital had to self organize “Hunger Games”-style. Everybody is hired as a “[Junior/Medior/Senior] Healthcare Worker” and then they battle it out to decide who gets to sit in the corner office, who gets to be a doctor and who gets to clean the toilets. Often it turns out everybody does a bit of everything, otherwise it’s perceived as “unfair”.

When there is no rigid formal power structure people make up for it with “politics”. I think that’s to a large extent what’s happening, and it’s sort of consuming our lives…

To the points about time spent and business value coming first, I would defend them by saying first that companies of different sizes operate with different requirements for their staff. You were hired to code, but in my experience the code is only important when it's serving the end goal of value. It's up to you to make sure that you're providing value, so be fluid enough to know when not to say, 'not my job'.

As for the grueling time expectations, I feel a lot of commenters are reacting to environments like those you hear about game devs; of course that's not alright. But yes, if there's systems that you work on that no one else really knows about, you'll need to keep tabs on them pretty much all the time. It doesn't mean you need to check in all the time, it means you need to write code to tell you on weekends when your things need to be checked out.

The job I have now could probably be done by some ninja coder for less, but they pay me because I know how to deal with everyone who doesn't code while I write my code.