It stopped being fun to code around that point. Too many i's to dot to make management happy.
However, this has to be substantive code review by technical peers who actually care.
Unit tests also need the be valued as integral to the implementation task. The author writes the unit tests. It helps to guide the thought process. You should not offload unit tests to an intern as "scutwork".
If your code is sloppy, a stylistic mess, and unreviewed, then I am going to put it behind an interface as best I can, refer to it as "legacy", rely on you for bugfixes (I'm not touching that stinking pile), and will probably try to rally people behind a replacement.
And frankly, giving ownership to code ("it's yours") has, also in my experience, been an excellent way to give an engineer "pride of ownership". No one wants to have that "stinking pile".
In my experience unit tests have been simply a questionable yardstick management uses to feel at ease shipping code.
"98% code coverage with unit tests? Sounds good. It must be 98% bug-free — ship it."
Not that anyone ever exactly said that but that's essentially what is going on.
Code reviews seem to bring out the code-nazi types. Code reviews then break any goodwill between team members.
I preferred when I would go to a co-workers office and talk through an issue, come up with a plan to solve the problem. We trusted the other to execute.
When code reviews became a requirement it seemed to suck the joy out of being a team.
Too frequently a code review would turn into "here's how I would have implemented it therefore you're wrong, rewrite it this way, code does not pass."
Was that a shitty code reviewer? Maybe. But that's just human nature — the kind of behaviors that code "gate keeping" invites.
It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code.
My $0.02 from the other side of the manager/programmer fence.
That's exactly right. After said process, it comes down to trusting your coworkers to execute capably. And if you don't think coworker is capable, say so (or if they're junior, more prudently hand them the simpler tasks — perhaps code review behind their back and let it go if the code is "valid" — even if it is not the Best Way™ in your opinion.)
I usually give up, stop arguing why it is actually better than the way the gatekeepers suggest and redo my code, less time wasted.
Coverage results don't mean much. Takes some experience to know how easy it is to introduce a major bug with 100% test coverage.
Tests are supposed to tell you if a piece of code works as it should. But I have found no good way of judging how well a test suite actually works. You somehow need tests for tests and to version the test suite.
A overemphasis on testing also makes the code very brittle and a pain to work with. Simple refactorings and text changes need dozens of tests to be fixed. library changes break things in weird ways.
Unless I know the system being tested, I take no interest in tests.
There's clever hacky ways to test systems that will never pass the "100% coverage" requirement and are a joy to work with. But they're the exception.
it's synonymous with LOC. don't bring it up anywhere.
However, usually no one really cares about testing at all. Also many projects are internal, not critical, etc.
Make fast, break things, deliver crappy software.
Tests that are written to comply with a policy that requires that all components must have a unit test, and that test must be green, could be good. Often, they are just more bullshit from the bullshit factory that is piling up and drowning the product, the workers, the management, and anyone else who comes too close.
I feel that it’s still correct to call both of these things tests, because in isolation, they do the same thing. It’s the structure they’re embedded in that is different.
This codebase was quick to deploy at Microsoft. We'd rollout every week. Compared to other projects that took months to rollout with a tangling release pipeline
Anyways I left for a startup & most of this fast moving team dissolved, so the Ruby codebase has been cast aside in favor of projects with tangling release pipelines
https://techcommunity.microsoft.com/blog/adforpostgresql/how...
In a decade and a half, we had very few issues, all easy to handle, and ie app has its own clustering via Hazelcast so its pretty robust with minimal resources. Simply nothing business could point a finger to and complain about. Since it was mostly just me, a pretty low cost solution that could be bent to literally any requirement pretty quickly.
Come 2025, now its part of agile team and efforts, all runs on openshift which adds nothing good but a lot of limitations, we waste maybe 0.5-1md each week just on various agile meetings which add 0 velocity or efficiency, in fact we are much slower (not only due to agile, technology landacape became more and more hostile to literally any change, friction for anything is maasive compared to a decade ago and there is nothing I can do with that).
I understand being risk averse against new unknown stuff, but something that proved its worth over 15 years?
Well it aint my money being spend needlessly, I dont care and find life fulfillment completely outside of work (the only healthy approach for devs in places like banking megacorps). But smart or effective it ain't.
It's really frustrating; I'm all for some bit of code not needing a test, but it should be because the code doesn't need to be unit tested. Breaking unit testing, not knowing how to fix it, and removing all testing is not a good reason.
Yes, of course, some rockets may explode (almost 10 soon), or some people may have accident, but that's ok from their perspective.
Unfortunately, management often dictates this for all engineers.
As an employee at a company with a similar attitude, I cannot agree more with this.
A burning need to dominate in a misguided attempt to fill the gaping void inside
Broken and hurting people spreading their pain as they flail blindly for relief
Our world creaks, cracks splintering out like spider thread
The foundations tremble