Some dude at code_poet:
"Untested Equals Broken"Ever work with a software dev this mindbogglingly arrogant? Yes, we all have. I haven't lately, because guys like this tend not to get hired at the last several places I've worked, and my current gig is no exception. Maybe he hides this nonsense in his interviews. Even if so, he wouldn't last long on any team I've been on recently.
Let's review the sins:
1.
Unilaterally removing the work of someone else. The time to question this sort of thing is either in a code review or in a cleanup iteration (sprint or whatever you call it). Our "hero" is also probably one of those guys who constantly pressures people to keep their current work checked in so in case a new priority comes up or someone gets sick work doesn't get lost.
Therefore, what probably happened here is that the other dev was working on something in stages and got called away to another emergency, which often happens. He checked in his partial implementation and shifted gears. In the meantime, our "hero" zorched his work for some pointless aesthetic reason. NOT COOL. Unless your goal is to find yourself marginalized. I have to wonder about that in the case of our hero.
Better solution: Check the logs to see who added this code and, I don't know,
send them an e-mail asking them what the hell this was about. If this half-implemented code still bugs you, then maybe you can negotiate a solution. Maybe you could just get over your bad self. If you have to, then add something like
// TODO: 7/OCT/2009 Half-implemented. Complete implementation or remove next cleanup sprint.Or if you need to refactor it for some other reason, well, alerting your team to this plan of yours is probably a great idea so they can go, "er, I'm about to use some of that, be careful." Maybe they could negotiate a solution in this case, as well. Maybe you can
gasp write some unit tests yourself, as testing is a shared responsibility and not necessarily the duty of the person offering the functionality.
It's also helpful to use a source-code system that supports shelving so half-implemented stuff stays out of the codebase and gently encouraging people to shelve if they get interrupted.
But, whatever you do, don't go unilaterally stomping on other people's work and then throwing 'tude when questioned.
2.
Aphorisms. Methodology fetishists like our hero here love to do this. Aphorisms like "untested code is broken code" are used as substitutes for critical thinking, probably because the users of these aphorisms are too busy feeling elite to think critically about anything. Or they may not even know how--programmers tend to be superlative pattern matchers, which is great for doing their jobs, but not very good for confronting things that actually need disciplined thinking.
Seriously, dude, are you going to tell me we need a unit test for code like this?
public String getName() {
return name;
}
public String toString() {
return String.format("%d: %s", getId(), getName());
}If you say, "yes," you are guilty of aphorism-induced brain addling. Perhaps you've also fallen victim to the "we have 100% unit-test coverage therefore our code is great" meme.
There are many ways to test code. VISUAL INSPECTION IS ONE OF THEM. Unfortunately, it is often a lost art among those who have drunk the Agile/XP Kool-Aid. If code is obvious, it doesn't need a test. If you have doubts, then sure, write a test. If you have doubts about someone else's code, then do them a solid and write the damn test yourself instead of complaining about how non-elite they are.
Not to mention that unit tests are often the wrong thing anyway, because most things go wrong when units talk to each other, and therefore most effort should be put into the integration tests. This is such a contentious and difficult issue that I will discuss it at some other point.
3.
Being proud of humiliating your charges. The best way to make friends with and influence junior devs is to identify yourself with their shortcomings and reminisce about how you have screwed up just as much as (or even more than) they have. This will tend to reassure them that software engineering is indeed a hard thing to learn, and even your "leet" self has tons of battle scars. You will buy a lot of cred with your future suggestions if you apply humility and empathy to the situation.
If you revel in humiliating them and displaying smug self-superiority, then they will tend not to come for you for future help. You will suffer because you will no longer be viewed as a mentor, and they will suffer because they will have one fewer avenue for self-improvement. And your team suffers for obvious reasons.
Hat tip: A former co-worker of our hero who would probably nut-punch me if I mentioned her name, but she knows who she is.
