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.
> 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).
- Don’t rewrite the architecture with microservices when the monolith is working fine
- Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so.
- Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple.
This is just a guess though – if you have some examples from your own experience it would be great to hear about some!
Can't disagree with any of those really. I guess it's really hard to draw out general conclusions about these sort of things when the specifics really make a difference. You can pretty much say "spend your time wisely" which is not very actionable.
For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc.
I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.
Premature optimization is much more useful as a deterrent for stuff like building complex data structures and processes to speed up looping through like 100 items.
"But it might be a million items later!"
Yeah, or the company might pivot before we ever go live with this feature. Just slap a for-loop in there and get on with your day.
You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way.
There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career.
When you hit that 1/10 product, you will experience some pain. But you now have enough information to justify dumping the resources (including political capital) into a proper long term solution.
> When you hit that 1/10 product, you will experience some pain.
There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes.
Spinning hypothetical tales of doom in order to be granted permission to build something shiny is probably the #1 thing that slowed me down in my career.
> It's amazing how many road blocks an executive trying to save their reputation can clear for you.
Precisely. The grandmaster software engineer learns to manipulate organizational inertia, fear and egos in order to achieve their goals. Simply detecting when someone has their heels dug in on something will take you about 80% of the way there.
Showing up to the 5 alarm fire with a perfect solution that can be deployed within 48 hours will make you look infinitely better than if you engage a months-long headbutt session with your managers about potential fires. Prepare your magic in secret and reserve your hope. If you are right, it will pay out. Be patient.
> 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.
> 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.
Honestly I have yet to use a significant (like >10k line) Python app that wasn't really slow. It definitely doesn't require YouTube scale.
"Just optimise the bottlenecks" is generally a myth in my experience. Most programs are all bottleneck.
And sadly those aren't problems or concerns for many/most folks. It's only an issue for those that haven't moved on after 2-5 years. Sad but true. Short term thinking is our present reality and way of conducting "business".
> "just get it done quickly" vs "take your time and do it right"
There is no such thing as "do it right". There's your flawed and biased perception of what's right, which doesn't take unknown unknowns into account.
> Oops three years later you're locking into Python and your app is slow as hell
Been using Python more than a decade, never had this problem. App slow as hell is always an eng culture problem. Shitty engineers will write slow code in any language. Don't do HFT in Python, don't write web apps in C.
> Producing documentation and commenting code. Don't need it now. 10 years later ...
The need for documentation doesn't skyrocket from 0 to 100 overnight.
Don't need it now? Don't write it.
Starting to feel the need? Start writing a little bit.
The problem is not the decision to not write documentation. The problem is not re-evaluating this decision in 10 years.
(another problem, based on your take, is treating documentation as binary: we either don't do it, or we're going all in)
> We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours
Do you think every team that uses Make has this problem? Again, sounds like it's a team problem, not tool problem.
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.