Things they didn’t teach you about software engineering

Depending on what you mean by "code" I disagree.

It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity.

Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes. For example:

* Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.

* Producing documentation and commenting code. Don't need it now. 10 years later everyone that worked on the code has left, nobody can understand it and you have to start from scratch.

* Investing in tooling.

* Using Bazel. It's so complicated! We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours, even for fixing a typo in the docs (these numbers are not made up).

Does those things produces no business value in the short term. But it definitely does in the long term.

Maybe that's not what you meant.

I learned this at some point while working in manufacturing. No one responsible for how much you get paid really cares how clever your idea is unless it makes the company more money.

For me, the game theory gets pretty advanced at this level.

My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is what our leadership wanted all along.

Trying to get my rush experimenting with new ideas under the current employer is really only shooting myself in the foot with regard to this long term plan. Any experimentation is reserved for side projects and weekends. At this point, I only bring "code" ideas to the team if I think they will legitimately improve the business in some eventual way that a non-wizard can understand.

I sleep around 7h per night, sometimes 8h.

I do 1 to 3 runs per week, between 45m and 1h15 each.

I have a guitar teacher coming 2h/week, the rest of my practice is random: could be from 0 to 6h per week.

Since I basically WFH 100%, I have no commute time, which helps a lot.

> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity.

I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it.

"build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).

> Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.

Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.

Performance is a real consideration but the better way to approach it is to make sure you understand the bottlenecks in your architecture and have a reasonable plan for replacing code when you need to. I’ve seen more failed apps in fast languages because the developers took so much longer to build things that they never found what users wanted or the performance problems they actually had weren’t what they expected so their Go code being 10% faster mattered less than taking months longer to reach feature parity.

There are situations where performance is critical on day one, of course, so part of your value as a senior engineer should be recognizing which situation you’re in and balancing those needs with your staffing levels, too. Your Bazel/make example is similar: if you’re seeing that kind of performance hit either something’s gone badly astray or you have grown to the point where you can afford to have someone dedicated to setting up more advanced tooling because they’re supporting hundreds of developers.