I wholeheartedly agree with you that code can be art but I was never able to express myself on that level at my corporate jobs. I was always limited to writing code that aligned with the company’s rigid style guide, and never allowed to implement new design patterns that would’ve improved things but deviated from the way things were done in the existing codebase.
Thus, I’m not too miffed about being forced to use coding agents at work because writing corporate-sanitary code already felt like a robotic process before LLMs existed. Personal hobby projects and open source contributions are where we can express ourselves freely and create our art the way we want to. They’ll never be able to take that from us.
You worked places with style guides? Did… Did you have a real testing environment that wasn’t prod too?
I got taken off a project recently for being too direct about how the rest of the team was just spray and praying entirely AI generated code with no standards or review whatsoever, and they were charging ahead like it was a race to implement features we hadn’t even discussed if we wanted/needed.
If you can’t tell me how it works, you can’t confirm that we actually need it, you can’t tell me the upstream and downstream effects (or confirm they don’t exist), and you can’t even confirm that we even want it to do the thing it only supposedly does, then we have better things to do than go on a wild goose chase trying to debug it when there’s a looming deadline for things that legitimately do not work that we need. Stop vibe coding and actually review the existing shit for fucks sake. If the requirements have never been clear, solve that instead of generating more slop. Maybe update some of the existing documentation instead of having AI wholesale hallucinate entirely new not quite right ones over and over.
Anyway, please tell me more happy development bedtime stories. I need to chase away the nightmares.
You worked places with style guides? Did… Did you have a real testing environment that wasn’t prod too?
Yes, and the style guides reached far beyond things like “use camel case”. I’m talking guidelines for how whole blocks of code should be formatted. Also weren’t allowed to throw exceptions at all even though we were using up-to-date modern C++. Some guidelines had good intentions and others were just put in by OCD control freaks that no one felt like opposing.
And yes, we had a testing environment, although we mostly depended on manual QA rather than software tests. Medical devices can’t test in prod, fortunately
There are many C++ features that make the language worse. Exceptions is one of them. It’s not strange to have them banned.
Critical systems often only allow you to use a subset of the language. Dynamic (heap) allocations, recursive functions, exceptions are features that are often banned. In medical devices, safety is critical, so it makes sense. Otherwise you could get a Therac-like scenario due to an unhandled exception.
Most of my career I was allowed to write code how I wanted. I made it beautiful and nice to read. It was genuinely fun to find the best way to implement each feature.
My final job, I was forced to add semicolons on new lines for each ifelse statement, even for early returns, remove hyphens from my comments because they were “improper grammar”, put a useless giant copy pasted comment at the start of each file so you can’t even see any code without scrolling, one separate file for each class even if it’s an internal helper class used nowhere else, and use interfaces and MVVM for literally everything, even when it was severely over-engineering (or should I say overengineering). It just felt soul crushing to make this ugly ass code that took forever to write, just because the style guide said so.
Then A.I. happened and I quit being a software engineer completely. Telling an A.I. to do my work for me is just depressing. What’s even the point anymore? I still code for fun but I’m done with the industry.
These days it’s very common to write whatever code you want, and a formatter automatically rewrites it to conform to the projects rules during precommit.
Which is great because it allows you to focus on intent instead of format, and completely avoids any team disagreements or change rejections for trivial bullshit.
And then somebody changes the auto-formatter settings and all of a sudden every single file changed and committe appears as having most lines changes and you loose the ability find the real code changes between a version before that and the current version.
Guess how I found this out …
Standardizing code format via that path only works well if you start it really early in the project and never change it after that.
(Also, it doesn’t solve the problem of different software design styles)
I hear you, but these are solve-able human problems, not code problems:
Manager: Jose revert your commit, thanks.
Jose: okay, it’s been reverted, I won’t do that again, thanks for explaining to me why exactly what I did was the wrong thing to do.
I’ve had this exact conversation about this topic at least a half dozen times over the last decade.
When it comes to legacy code, almost all auto formatting tools I’ve used allow you to ignore whole directories and files, which can be very handy for legacy areas of the codebase not yet ready for this transition.
As for scenarios where large rewrites are necessary, it’s best to separate from any actual work, so the blast radius is focused, and that commit can be marked properly using .git-blame-ignore-revs which completes fixes the history issues that are common amongst those who don’t know what they are doing.
Definitely a painful process it can be, but it’s better to fight this battle than it is to try and get 1,000 humans to agree on something as vague as “style”
Ah yes, some random intern suddenly has ‘credit’ for almost all the codebase because they ran a linter with different settings than previous linter settings…
My favourite part is when your style or the auto formatter changes over time and you have to decide between:
running the auto formatter on 200,000 12 year old code files
doing them one by one
formatting them when you have to change that file
or ignoring all the warnings forever (it’s this one, this is what you do)
Plus it doesn’t fix the problem of auto formatters writing ugly code. You can’t easily tell the auto formatter that early returns can be bracketless for brevity, but nothing else can be. Unless you add a comment like \\ ignore-rule-2753674 which makes me want to throw up
Unemployed / disability lol. But if I could still move around I’d probably get into something outdoorsy. Park ranger or the like. Keeping a candle lit though, in case one day I miraculously recover or medical science advances or something.
Edit: actually it’s the reason I did software engineering in the first place. But actually this industry is now hostile to people with disability. Can I work from home because leaving the house is hard? No, everyone must be in office chained to your desk 9/9/6. Can I be neurodivergent? No, everyone must have constant in person meetings and work in open plan offices.
I wish I could work somewhere like your first paragraph. My career has been your second paragraph, probably because I’ve only worked on medical devices and we gotta have higher standards than a lot of developers. It also got taken a bit too much to the extreme tho
Believe it or not my first paragraph was working on medical software lol. It was good though, I liked the feeling of helping doctors help people, making the world a better place.
I wholeheartedly agree with you that code can be art but I was never able to express myself on that level at my corporate jobs. I was always limited to writing code that aligned with the company’s rigid style guide, and never allowed to implement new design patterns that would’ve improved things but deviated from the way things were done in the existing codebase.
Thus, I’m not too miffed about being forced to use coding agents at work because writing corporate-sanitary code already felt like a robotic process before LLMs existed. Personal hobby projects and open source contributions are where we can express ourselves freely and create our art the way we want to. They’ll never be able to take that from us.
You worked places with style guides? Did… Did you have a real testing environment that wasn’t prod too?
I got taken off a project recently for being too direct about how the rest of the team was just spray and praying entirely AI generated code with no standards or review whatsoever, and they were charging ahead like it was a race to implement features we hadn’t even discussed if we wanted/needed.
If you can’t tell me how it works, you can’t confirm that we actually need it, you can’t tell me the upstream and downstream effects (or confirm they don’t exist), and you can’t even confirm that we even want it to do the thing it only supposedly does, then we have better things to do than go on a wild goose chase trying to debug it when there’s a looming deadline for things that legitimately do not work that we need. Stop vibe coding and actually review the existing shit for fucks sake. If the requirements have never been clear, solve that instead of generating more slop. Maybe update some of the existing documentation instead of having AI wholesale hallucinate entirely new not quite right ones over and over.
Anyway, please tell me more happy development bedtime stories. I need to chase away the nightmares.
I feel seen. I’m trying to sort out how to socialise the idea that we should be working with a broader context in mind. Hard to break habits.
Yes, and the style guides reached far beyond things like “use camel case”. I’m talking guidelines for how whole blocks of code should be formatted. Also weren’t allowed to throw exceptions at all even though we were using up-to-date modern C++. Some guidelines had good intentions and others were just put in by OCD control freaks that no one felt like opposing.
And yes, we had a testing environment, although we mostly depended on manual QA rather than software tests. Medical devices can’t test in prod, fortunately
There are many C++ features that make the language worse. Exceptions is one of them. It’s not strange to have them banned.
Critical systems often only allow you to use a subset of the language. Dynamic (heap) allocations, recursive functions, exceptions are features that are often banned. In medical devices, safety is critical, so it makes sense. Otherwise you could get a Therac-like scenario due to an unhandled exception.
That’s a great story. https://ethicsunwrapped.utexas.edu/case-study/therac-25
Most of my career I was allowed to write code how I wanted. I made it beautiful and nice to read. It was genuinely fun to find the best way to implement each feature.
My final job, I was forced to add semicolons on new lines for each
if elsestatement, even for early returns, remove hyphens from my comments because they were “improper grammar”, put a useless giant copy pasted comment at the start of each file so you can’t even see any code without scrolling, one separate file for each class even if it’s an internal helper class used nowhere else, and use interfaces and MVVM for literally everything, even when it was severely over-engineering (or should I say overengineering). It just felt soul crushing to make this ugly ass code that took forever to write, just because the style guide said so.Then A.I. happened and I quit being a software engineer completely. Telling an A.I. to do my work for me is just depressing. What’s even the point anymore? I still code for fun but I’m done with the industry.
These days it’s very common to write whatever code you want, and a formatter automatically rewrites it to conform to the projects rules during precommit.
Which is great because it allows you to focus on intent instead of format, and completely avoids any team disagreements or change rejections for trivial bullshit.
And then somebody changes the auto-formatter settings and all of a sudden every single file changed and committe appears as having most lines changes and you loose the ability find the real code changes between a version before that and the current version.
Guess how I found this out …
Standardizing code format via that path only works well if you start it really early in the project and never change it after that.
(Also, it doesn’t solve the problem of different software design styles)
I hear you, but these are solve-able human problems, not code problems:
Manager: Jose revert your commit, thanks. Jose: okay, it’s been reverted, I won’t do that again, thanks for explaining to me why exactly what I did was the wrong thing to do.
I’ve had this exact conversation about this topic at least a half dozen times over the last decade.
When it comes to legacy code, almost all auto formatting tools I’ve used allow you to ignore whole directories and files, which can be very handy for legacy areas of the codebase not yet ready for this transition.
As for scenarios where large rewrites are necessary, it’s best to separate from any actual work, so the blast radius is focused, and that commit can be marked properly using .git-blame-ignore-revs which completes fixes the history issues that are common amongst those who don’t know what they are doing.
Definitely a painful process it can be, but it’s better to fight this battle than it is to try and get 1,000 humans to agree on something as vague as “style”
Ah yes, some random intern suddenly has ‘credit’ for almost all the codebase because they ran a linter with different settings than previous linter settings…
My favourite part is when your style or the auto formatter changes over time and you have to decide between:
Plus it doesn’t fix the problem of auto formatters writing ugly code. You can’t easily tell the auto formatter that early returns can be bracketless for brevity, but nothing else can be. Unless you add a comment like
\\ ignore-rule-2753674which makes me want to throw upIf you don’t mind me asking, to which career did you switch to?
Unemployed / disability lol. But if I could still move around I’d probably get into something outdoorsy. Park ranger or the like. Keeping a candle lit though, in case one day I miraculously recover or medical science advances or something.
Edit: actually it’s the reason I did software engineering in the first place. But actually this industry is now hostile to people with disability. Can I work from home because leaving the house is hard? No, everyone must be in office chained to your desk 9/9/6. Can I be neurodivergent? No, everyone must have constant in person meetings and work in open plan offices.
I wish I could work somewhere like your first paragraph. My career has been your second paragraph, probably because I’ve only worked on medical devices and we gotta have higher standards than a lot of developers. It also got taken a bit too much to the extreme tho
Believe it or not my first paragraph was working on medical software lol. It was good though, I liked the feeling of helping doctors help people, making the world a better place.