Being told "how" instead of "what". Use this API to access that database to do this process. Don't tell me how to do something. Tell me what you want. Let me figure out how. That's my job.
Being told "what" instead of "why". So you need a 4 GB csv download of the entire database every day at noon? Why? Oh, in that case, why don't you just use <somethingElse> which has been right at your fingertips all along. If you don't understand the system, ask and I'll be glad to help. But don't make up unnecessary work for me.
Being asked for data to put into your Excel spreadsheet which you will screw up 8 minutes later. Then you want me to fix it. Forget it. If you have a business problem, tell me about it. We will find a solution together. Lone rangers don't get help. I'm not Tonto.
Calling me every 42 minutes for 3 days asking, "Is it done yet?" No, it's not. I'll let you know when it is and if there's a problem, I'll let you know about that, too.
Not calling me for 3 weeks after a release. Either it's working perfectly or no one's using it. It would be nice to know which.
Criticizing my work in a meeting in front of others without talking to me first. Big mistake. You don't want to piss off your waiter and you don't want to piss off your programmer.
Meetings when a phone call would have sufficed.
Phone calls when an email would have sufficed.
Status meetings. Pointless. I'll email status. Any questions, click "Reply".
Code walkthroughs that are more concerned with syntax than function.
SQL SELECTs inside of iterations. Please go work at McDonald's.
Sarbanes-Oxley (SOX).
Web filters that screen out Hacker News. Grounds for divorce.
I don't mind fixing other peoples problems. I will even stay late to do so if asked but if you do so and then fuck off out of the office at 5:00pm you can better believe I'll be doing the same. If your problem isn't an emergency for you then it isn't one for me either.
Calling my work shit without providing any constructive feedback, problem details, or patches will tend to make your future requests for help go straight to the bottom of my priority list.
Blaming me or my work for a problem you are experiencing without performing any investigation into what actually the problem is also will make any future requests for help go straight to the bottom of my priority list. Not quite as far down as the category above though.
I don't want to sound like a prima-donna but I don't like creating unnecessary work for others because most people have better things to do, I just wish this was reciprocated more often.
1. Employee self-assessment forms - We don't need HR to make to my manager make me tell him what I think I do well/poorly. Business jargon is no substitute for 2-way honest conversation.
2. Managers that try to shoehorn every problem into one solution.
3. Being restricted to technology choices that your manager knows.
4. Being the single go-to guy for everything in your department because no one else is interested enough to learn things on their own - Want me to setup your enterprise Java portal while fixing IE CSS/Javascript bugs that our web developers couldn't figure out while debugging a WordPress plugin for another department? Sure, you want fries with that order, sir?
If you list 'how' instead of 'what' and then continue to list 'what' instead of 'why', you could save yourself one aggravation in between by being merely upset at 'how' instead of 'why' ;)
Funny that #10, 'Comments that explain the “how” but not the “why”', quotes from an article by Jeff Atwood to show how the comment should have been written. But in the original article, Jeff actually says that that commenting style is also not as good as refactoring the code:
"That must be what I was getting at, right? Some sort of pleasant, middle-of-the-road compromise between the two polar extremes of no comments whatsoever and carefully formatted epic poems every second line of code?
Not exactly. Rather than add a comment, I'd refactor to this:
private double SquareRootApproximation(n) {
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
return r;
}
System.out.println( "r = " + SquareRootApproximation(r) ); "
I'd consider that new code a step backwards since it removes the vital words "Newton-Raphson". If I didn't recognize the algorithm I might have a very hard time working out exactly how and why that lump of code approximates a square root. With the words Newton-Raphson included somewhere I could easily look it up and find out everything I need to know about not only how and why it works but also its strength and weaknesses. Personally whenever I use some non-trivial algorithm I haven't made up I tend to include a comment pointing to the book or paper I got it from so that others can get the canonical description of what the algorithm does.
Ideally I'd even like to see a brief comment on why Newton-Raphson was chosen as well. Is there a good reason why I shouldn't replace that code with some other square root approximation technique or was it chosen because it was the only algorithm the author knew?
I agree that the algorithm name should appear somewhere.
I would probably refactor the code as Jeff says, but add a comment that describes the function, probably with details about why it's implemented the way it is.
IMHO #11 could be added as "unindented code". I was going to a guy's code yesterday and I felt very _irritated_ to read it, that i ended up spending 15min indenting it myself. I'm sure a lot of people don't like unindented code.
and I totally agree with #1, it's very true for me. And especially when I've used some framework and the framework has been updated to a newer version with lots of goodies, i feel lazy to maintain code that been written in older version of the framework. (and even more lazier to update it to the new framework if it requires lots of changes). I just leave it working fine in it's current state. Seems like thats what results in legacy software. So I now follow my new rule-- working on beta versions of frameworks so that i can leave it unmaintained for longer time and spend the time on new ideas.
I'll do you one better. Something I found in a legacy codebase: reverse camel case code. Imagine rEADING tHIS aLLdAY. I felt like I was being partially yelled at all day while debugging.
Do you not have an editor/IDE that can automatically format code for you? Both Visual Studio and Eclipse can do this, and editors like Vim or Emacs can too.
I have someone on my team who uses SlickEdit, and it messes up all the indentations when I look at the same code in Eclipse. I have to spend a few minutes reformatting it every time he makes changes to the code, and it's a real pain.
I knew a physicist who only programmed C++ in notepad. He was having some problem with some multiple-body simulation he was working on, and I took one look at his code and told him to paste it into Gedit or Notepad++ or something (since he was a die-hard anti-Emacs/Vim zealot.) He refused, couldn't figure it out, did an "exact transliteration" of his code into Python and suddenly it worked.
Also, some editors have their own rule for how many spaces a tab makes - some use 3 and some use 4 - or if you're like my designer co-worker, you manually use the space bar arbitrary. Gave me a big headache when looking for matching css selectors.
When I first started interning at this company, I always wondered why people were doing stupid things in code and I would fix it to be cleaner and the program would break. Then I would realize there's a reason it was done in this stupid roundabout way. People that don't comment their reasons for doing stuff out of the ordinary annoy me.
Vague bug reports and scope creep are definitely up there.
One of my least favorite situations is dealing with other people's minor plugins or libraries...
If it's in Python, usually it's good as-is.
If it's in PHP, usually the structure is so disturbing that if we have to use it, I simply try not to look. The code ranges from naive to over-engineered, the latter of which is especially pointless in PHP.
For other people's JavaScript, usually I'm horrified by all of the 'for' and 'if' blocks that are lacking braces. Argh! Half the time I end up rewriting and removing portions of various plug-ins, and I often feel the compulsion to go fix all of the lazy bracing at the same time.
I found number 1 to be slightly inaccurate. I think it would be better as "What moron wrote this garbage?! That's it! I'm gonna go find out who wrote this and give th... Oh. That was me. Crap."
Meetings can be exceedingly fruitful when done well. The other day I found myself chasing a solution for a good hour or so. Realizing the inanity of this, I called together the interested parties, explained my issue, and together we worked out a feasible solution and corrected some of my misunderstandings. Total time commitment of the meeting? Thirty minutes.
The next time you find yourself in a fruitless meeting, consider the things you could do to ensure future meetings are more valuable in the future, and work with management to get your ideas in motion. Hopefully you'll improve your situation, and you'll show initiative that'll look great when your next review comes up.
Meeting quality is mostly a function of the thinking quality of the person controlling the meeting. If the purpose of the meeting is to impress the exec in the room that Joe is "doing something" the rest of the attendees of the meeting will probably find Joe's meeting a waste of time.
Being told "how" instead of "what". Use this API to access that database to do this process. Don't tell me how to do something. Tell me what you want. Let me figure out how. That's my job.
Being told "what" instead of "why". So you need a 4 GB csv download of the entire database every day at noon? Why? Oh, in that case, why don't you just use <somethingElse> which has been right at your fingertips all along. If you don't understand the system, ask and I'll be glad to help. But don't make up unnecessary work for me.
Being asked for data to put into your Excel spreadsheet which you will screw up 8 minutes later. Then you want me to fix it. Forget it. If you have a business problem, tell me about it. We will find a solution together. Lone rangers don't get help. I'm not Tonto.
Calling me every 42 minutes for 3 days asking, "Is it done yet?" No, it's not. I'll let you know when it is and if there's a problem, I'll let you know about that, too.
Not calling me for 3 weeks after a release. Either it's working perfectly or no one's using it. It would be nice to know which.
Criticizing my work in a meeting in front of others without talking to me first. Big mistake. You don't want to piss off your waiter and you don't want to piss off your programmer.
Meetings when a phone call would have sufficed.
Phone calls when an email would have sufficed.
Status meetings. Pointless. I'll email status. Any questions, click "Reply".
Code walkthroughs that are more concerned with syntax than function.
SQL SELECTs inside of iterations. Please go work at McDonald's.
Sarbanes-Oxley (SOX).
Web filters that screen out Hacker News. Grounds for divorce.