Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> When there's a bug in their code, point it out, but don't tell them how to fix it.

It's funny, I've learned the opposite lesson the hard way.

I used to just point out bugs, like I was a tutor hoping they'd realize the problem on their own and fix it correctly.

Unless it was an obvious brain-o (i.e. the developer knew what they were doing and just flubbed), this resulted unerringly in a "fix" that (a) didn't solve the problem, and (b) created another. I would end up coming off as a nitpicking asshole trying to guide the developer into writing correct code.

So now I just reply, in detail, with exactly what fix to apply, often including code verbatim. Call me jaded, but it works, and I've realized it's not my job to get people to learn to think for themselves. Those that want to already know how.

Related: never post example code you wouldn't want to see copy+pasted verbatim into the codebase. I can't count the number of times I've said "fix it using code like this" only to get a complaint a week later that the fix doesn't work, and seeing my pseudocode complete with foos, bars, and made up meta syntax copy+pasted verbatim.



The problem with this is:

a) it doesn't scale

(you are now doing the other devs' job)

b) it only works if you are infallible

(if there's a bug in your fix the other dev is going to say "colanderman told me to do it this way")

I know that it is tempting to just tell people what to do, but it's not a long term solution.


> it doesn't scale

It's strictly better than repeatedly pointing out the same, but slightly different, bug, in a series of incorrect fixes, before being forced to spell out the solution upon realization that the dev isn't going to get it on their own. Just skip to the end.

> if there's a bug in your fix the other dev is going to say "colanderman told me to do it this way"

So?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: