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

Obviously difficult to work with and unprofessional. Utilized programming side effects which obscured the intent of the code to such an extent that he unintentionally reversed the logic of the test he was supposed to implement.


Abuse of side effects to save code is just a reality of working in limited or embedded systems once you have run into their limits. On one of my current projects, the target has only 8K of program memory. I had to do some things I'm not proud of to get the required functionality to fit because the alternative was to say "It can't be done, scrap everything." The target is an embedded hard-realtime processor core, so there's no way to add more memory to it. It's a component integrated into a larger system so I can't demand a larger or more capable device without incurring significant redesign costs. Quite frankly, I won't be considered worth those costs. Nobody's doing to take on the expense and effort simply because I can't hack it. I'd have a hard time blaming someone for doing the painful to keep a project alive, considering I'm doing exactly that. We can always agitate for better conditions next time around, but this time we must go to war with the army we have, and sometimes that necessitates fighting dirty.

The rest of the stuff is entirely valid though. A programmer that cannot be managed is worthless, and someone who is unwilling to accept correction is a liability. I wouldn't refuse to work with him because unless I'm his superior I don't get to make that call, but I would probably go out of my way to avoid interaction. (And if I were his superior, unless he's got political juice or something, I'd have him shown to the door if he won't work with the team instead of against it.)




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

Search: