Seconding this. I used to really care about code maintainability, cleanliness, and other topics super important to us engineers.
4 years in The Valley have quickly dissuaded me of such foolish naive notions. Your code (outside some common sense basics) is completely irrelevant. Whatever you can stick together with duct tape and chewing gum is almost always the best solution. All the business wants is speed. By the time "bugs" is the highest reason for churn ... well you're likely going to be on your 5th employer by the time your first employer reaches that point.
Absolutely nobody in the real world cares about the quality of your code. They just want to do their job with as little interaction with your software as possible and move on.
It's kinda sad really how much time we waste talking about the best way to hold a hammer, the best hammer you can use, the best nails etc. when all our customers want is the picture to be up on the wall already.
Edit: One important addition -> If you're senior and you see juniors writing "bad code" on your team, your job isn't to teach them why it's bad. Your job is to create systems that make good code easier and more obvious to write than bad code. Be the force multiplier.
The vast majority of software is not written with that amount of churn.
The end user doesn't care about the quality of the code, but you can be damn sure they care about the quality of your software.
Also, talking about hammers is overly reductive. Software is far more complex than hitting something with a hammer. Builders might not talk about the best way to hold a hammer, but they constantly talk about the best way to build a house.
> The vast majority of software is not written with that amount of churn.
My current employer has code that is 6 years old. I had coffee with a former colleague and they are still running code from when I was there, and I left 5 years ago.
6 years is still young for code. My current employer has code that's 13 years old. My last had code that was nearing 20.
And there's nothing wrong with that. Old code isn't "bad". In fact, it's almost certainly better than new code, because it's been battle hardened. It's got that fix in it for that weird edge case.
The last company I worked for was just trying to move off of a PowerBuilder+Sql Server 2008 system that was written by contractors in 1999 and maintained by two developers who had been there for 20 and 14 years.
What was wrong with it:
- neither the version of PowerBuilder or Sql server was supported by their respective companies.
- they were dependent on the two developers not getting hit by the lottery bus. Good luck trying to hire someone who knew PowerBuilder and/or was willing to learn it.
- the only way to access the program by the remote offices were Citrix Terminals.
I was originally brought in to lead the effort to modernize the system [1] but they had a change of plans when I got there and I ended up leading a completely separate effort.
[1] the plan I proposed was to upgrade to a newer version of PowerBuilder that could expose the system as COM objects, write a C# WebAPI around it. Write automated integration tests calling the Web service and slowly migrating the PowerBuilder code to C# and calling the underlying stored procs directly from C#.
This seems related to the problem of how we have no idea how to hire people. I don't want to hire or work with people who are on to their fifth job by the time their crappy work starts causing major problems for the company that paid them to make it. But asking little whiteboard coding questions gives me zero signal to determine that.
It has null to do with "The Valley". A young startup should probably take velocity and "just ship" over any other consideration. But new startups are not a very big or important part of the IT industry.
Have you ever worked on the same project for more than a year?
That's the sort of timescale where you notice quick hacky solutions come back to haunt you later. Sure you will deliver things quickly at first, but when you do have to modify things, or fix your own bugs it becomes a nightmare.
Yeah, been maintaining the same software for 4 years now. Honestly the elegantly designed beautiful parts of the systems have been the hardest to maintain. They end up too specialized to a single use-case and you have to keep rebuilding them from scratch.
Meanwhile the hacky code keeps chugging along happily and dealing easily-ish with any new requirement you throw at it.
What a terrible attitude! You're happy to write shit code because it'll be someone else's problem to deal with by that point?!
I can understand not being dogmatic about SOLID, design patterns and the like, but doing any old shit because you can get away with it is pretty disgraceful IMO. That kind of behaviour certainly wouldn't fly outside of "The Valley".
4 years in The Valley have quickly dissuaded me of such foolish naive notions. Your code (outside some common sense basics) is completely irrelevant. Whatever you can stick together with duct tape and chewing gum is almost always the best solution. All the business wants is speed. By the time "bugs" is the highest reason for churn ... well you're likely going to be on your 5th employer by the time your first employer reaches that point.
Absolutely nobody in the real world cares about the quality of your code. They just want to do their job with as little interaction with your software as possible and move on.
It's kinda sad really how much time we waste talking about the best way to hold a hammer, the best hammer you can use, the best nails etc. when all our customers want is the picture to be up on the wall already.
Edit: One important addition -> If you're senior and you see juniors writing "bad code" on your team, your job isn't to teach them why it's bad. Your job is to create systems that make good code easier and more obvious to write than bad code. Be the force multiplier.