Hacker News Reader

Comment by dunkelheit | Hacker News Reader

> What makes you do the bits of work that are neither fun nor strictly necessary to get paid is that other people need it done, and you don't want to fail them.

I have a bad habit of classifying coworkers into "tidy" and "sloppy" ones. Tidy people for example take time to arrange code neatly, they care about coding styles and other things that are strictly unnecessary (sometimes to the extent bordering on OCD). Sloppy people are result-oriented: if it works, it is done.

The majority of coworkers that I can depend on are tidy people - in addition to caring about code formatting they are also more likely to go through all corner cases to ensure that the program actually works. But do they do it because they don't want me to suffer or because they want the job done neatly? Or because they don't want others to think of them as sloppy? I dunno. I guess it is a little bit of everything.

View on HN

Pre-commit code reviews quickly hammer all those different kinds of people into the same kind of nail. It's one of the best aspects of code review as a practice, yet it doesn't get as much attention as code quality and correctness.

It is worth putting the time into refactoring things properly and looking over every line of the diff to make sure it belongs on my team. If you do this, your code can often pass review with only a few comments, even for a change that's hundreds of lines long. If you didn't send good code out for code review ... god help you. You're going to be buried in dozens of comments ("the beatings will continue until the code improves").

There's certainly an adjustment process when people join our team and our company. But ensuring consistency across our entire codebase is absolutely worth it. And I know that I have become a better developer by consistently being held to high standards, and doing the same of others.

There are issues on both sides of that divide. I can't stand the tidy programmers who try and clean up ugly code that handles lot's of real world edge cases they don't understand.

Sometimes you can find loops in the source code repository where multiple people make the same kinds of changes to the same function before reverting back to the original state when some bug shows up again even when there is a comment about that edge case. It's one of the few times I feel leaving commented out code is reasonable, no don't do this it's not going to work.

The real world is messy, at some point you have to represent that twisty logic or it's not going to work.

If removing edge case handling doesn't make some tests fail, then poor test coverage is the root problem. Refactoring a code base without tests is always touching the third rail, neat or tidy, no?

You say that as if people don't remove tests while 'refactoring'. Better coverage = people ignore tests as they always fail. Worse coverage and they ignore tests because the tests must be outdated.

I did not want to imply that tidy people are somehow "better". Of course they can screw up too. In addition to your example, wasting time on inconsequential things is a major sin.

My point is that in my experience dependability often comes loaded with these traits and I doubt that "love of thy coworkers" is the sole source of them.

I write a lot of code that only I will work on in the future.

I keep it tidy because I don't hate myself.

I tend toward the tidy side on things like this. I don't "have a reason", per se. In that regard, it's almost like an OCD, it's just something that needs to be done. (I don't have OCD at all, but this is just to illustrate.. you don't flip the light switch 100 times in hopes of some kind of reward, you do it because you're wired to do it).

Not sure how typical this is, but I suspect people who "just were going to do that anyway" will be drawn to roles where they have to or it's good practice. I'm pretty annoyed when deadlines or other stuff means I can't do that, and it's not about technical debt or anything else. I just feel like I'm forced to leave something half-finished, and it's annoying.

I like to think of myself as belonging to the tidy category, I value craftmanship, beautiful elegant code, what Torvalds would call good taste. I respect coding conventions. But sometimes, the manager comes in and says that the deadline was just tightened, and we need to release the thing earlier, so no more unit tests, some corner cutting ensues.

What's more, as my backlog keeps increasing, I can't build each component to the same level of quality without falling behind.

So I would say that it's not a black and white matter.

Reply on news.ycombinator.com