- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I'm not sure if this just lack of knowledge/ experience, or a sign of things to come, a character trait, so to speak.
Admin
Ah, code reviews - mostly undervalued and when done, often done wrong.
Addendum 2024-09-03 03:53: BTW transparency is never throwing someone under the bus. Every critique is fine as long it's not a personal attack. And if it isn't then there's a serious issue with the work culture in the team/company that needs fixing; often by cutting those out of the loop that don't empower the developers.
Admin
I had done a 3 month consulting gig for a very large financial firm. They programmatically tracked coverage and reported the high percentage to upper management. But over 90% of their tests didn't have an assert statement. Looking back, if I hadn't complained I might have been there longer. :-)
Admin
He should have opted for the long-term version of "be a bro", which seeks to help the offender to become a better developer...
Admin
As I mentioned above, this is a work culture issue. Those numbers should never end up with line managers because they simply don't have a clue what they mean. It just ends up in a toxic dynamic where devs play the system instead of doing their job of delivering quality.
Admin
"Every critique is fine as long it's not a personal attack." is the logical conclusion of "You are not your code.", which is among the very first things to learn and to understand, and to finally work and live by, in order to prevent a toxic work environment. (Yes, this is a very old-fashioned opinion.)
Admin
Even the most senior can make a bone head decision [been cranking code for over 50 years].... I WANT full visibility. I want review....
side note if A junior cant understand the results of the work done by even the most experienced guru - then the issue is with the guru, not the junior.
Admin
been there, done that, got the t-shirt. that's why tests are useless (at least unit tests), you can have up to 100% coverage without any meaningful test
Admin
Not pointing out other people's errors can actually harm their growth. And not letting managers know about issues that occur may prevent them from doing their job, which includes training people under them to do their jobs better, and making sure the right processes are in place so that the issues are either caught and dealt with, or don't occur in the first place.
Admin
@my name
I would not say "tests are useless".
Instead I'd say that "tests can be gamed, and gamed tests are useless". Which is why the measure of merit of testing is both coverage that a computer can easily analyze, and test quality that only human code review performed within a quality-first / ego-last culture can do.
As always, you can't fix a social / org behavior problem with a technological solution. If the culture sucks, everything within it will suck. Including the product it produces. Be that software, TPS reports, or spaceships.
Admin
That's not a problem. Nobody knows what the code is expected to do anyway, but the bosses are annoyed when they see error messages. /s
Sadly, most of our current test set is like that: Just checking if the simulation crashes.
Admin
I'll throw in my BTC3.4e-7 on the subject of "Every critique is fine as long it's not a personal attack." I was in my second job out of college and a co-worker was on vacation and there was a bug in something he wrote that I had to fix while he was gone. He practically exploded on me that I fixed it. It was "his" code. Apparently he felt his ego was more important than getting the job done. It was then I learned that some people treat critiques of their code as a personal attack. I vowed never to be that guy.
Admin
While that may be literally true, companies tend to measure devs by their code. So criticizing someone's code is (indirectly) affecting their evaluation. And people may be sensitive to that.
Admin
Some people have great difficulty understanding that not everyone reciprocates good will.
Admin
Campbell's law: The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.
If you do nothing but put in place a require to achieve 100% test coverage, then you will get 100% test coverage. However, you will likely not get the benefit you hoped to get from the test coverage - such as meaningfully tested software.
Management is supposed to be a continuous process and you are supposed to manage to your own needs. If a manager simply implements metrics based on someone else's "best practices" and never looks at the affect it has on the team (either positive or negative), then they will almost certainly get negative outcomes. This is not surprising and says nothing about the usefulness of unit testing.
For successful teams, test coverage is simply one component of test measurement. It only conveys the quantity of tests relative to the quantity of code under test. If you have no quality metric (or at least a process and/or culture that promotes quality), then you'll get a ton of poor quality tests. Heck, most development teams can even write down a list of attributes that distinguish a good quality test from a poor quality test, let alone understand the quality of any of their code (test code or production code).
Admin
If management measures code quality in such a way that devs can bully their way into seemingly better evaluations, then they are encouraging the bullying. If you find yourself at one of these places, start looking for a new job today.
Admin
I like the idea that a senior developer is a developer that coaches junior developers to become seniors honestly. And yes, I 100% agree with you, experience doesn't matter - in fact if you get more experience, you also get tunnel vision, so the healthiest and most productive ways I saw code reviews done was always between developers with a largest skill/experience range (youngest team member - oldest team member, inexperienced team member - experience team member, newest team member - longest lasting team member etc.).
Admin
I disagree, I have experienced that great test discipline can greatly elevate development team not only on a technical level but also on a social level (bugs create interpersonal conflicts, interpersonal conflicts create bugs - I think you have experienced that as well). But keep in mind, I didn't say philosophy, dogma, process (sorry for using the p-word) or doctrine.
Firstly I personally have found that writing a test for every meaningful bug you produce as a developer even doing development is actually creating over time the most useful way to approach automated testing. It has the benefits that you don't repeat the same mistake or someone else will fall into the same mind trap as you did. This saves so much frustrations down the road when applied with discipline, it's magically.
Secondly writing a unit test of a complex or non-intuitive business process or algorithmic challenge is the best way to document your code when done well. It solves the "developer is on vacation, what is going on there" issue nicely and is IMO the only real example where test-first makes sense. This saves so much frustrations down the road when applied with discipline, it's magically.
As you can see, I haven't mention a number there, I didn't say you should always do it for every single little piece of code, automated testing done right is itself a complex mental decision to be made and very contextual. And it should be seen as a team building tool instead of focusing on it as a pure quality tool.
Admin
I'll point out (without rancor) that @MaxiTB was responding to @my name but the bit he quoted was by me @WTFGuy (also in response to @my name).
Maxi's point is clear nevertheless and is one with which fully I agree.
Admin
Oh, that's weird, I think I failed copy&pasting there. You are 100% correct:
Admin
Agreed, though you need the right junior — someone who wants to learn from the experienced guru, and will question anything they don't understand. The last thing I want is someone who assumes that any lack of understanding is their own failing, and that they should just sign off on it without asking questions that might reveal their ignorance. I want a reviewer, not a doormat...
Admin
Or as I like to say. A good engineer has no ego. A bad one has nothing but.