Recently I was reminded of that old saying, and why it matters.
For quite a while now, the common social skills have been devalued in programming. It's become almost our version of machismo, this blunt commentary about others' work.
Frankly, it's stupid. Nobody is immune to the discomfort of having their work denigrated or dismissed. I mean, why are we not promoting at least a modicum of civility? How hard is it to rephrase from "This code sucks" to "This code needs some cleanup" ?
Some will no doubt claim that it's meaningless fluff; a waste of precious time to consider feelings. But it's not - there is no truly egoless programming - if there were, we could not be as good as we wish to be, because only through the personal pride of doing a job well can we have good code, and even if we fail, we are not helped by someone else being rude in their discussion of the code.
This is not to say we should not mention failings in code we review - but we should be mindful of the impact of our words. If you are rude to a coworker, you risk s/he will not hear your comment for the tone - they will get angry at your tone or wording, and resist the discussion because they will perceive you as hostile, instead of helpful.
Sunday, July 03, 2011
Thursday, June 16, 2011
The Truth, The Whole Truth, And Nothing But The Truth
It's been a demotivating few months at The Job lately, what with the Google rejection, and sundry other depressing events of the new cow-orker variety.
But today I got a snootful of it. One senior colleague explained today in a meeting that the feature that I was supposed to pull into my server 2 years ago, that would solve all my performance problems, in fact will not solve them as it is currently written, but requires more work to do what it was promised to do 2 years ago.
In the meantime, every time the performance issue was discussed in conversations where this colleague was around, this feature was touted, and my lack of action was wondered at. Nevermind that changes to the core handling of a major process is not taken lightly; nor is it attempted when customers are getting bi-weekly update releases that cannot fail to work. I was an idiot for not pulling this feature into my code immediately.
So the tip for developers is this - never lie to your colleagues about what you code can do for them. If it is not complete, or plain wrong, shut up about it.
But today I got a snootful of it. One senior colleague explained today in a meeting that the feature that I was supposed to pull into my server 2 years ago, that would solve all my performance problems, in fact will not solve them as it is currently written, but requires more work to do what it was promised to do 2 years ago.
In the meantime, every time the performance issue was discussed in conversations where this colleague was around, this feature was touted, and my lack of action was wondered at. Nevermind that changes to the core handling of a major process is not taken lightly; nor is it attempted when customers are getting bi-weekly update releases that cannot fail to work. I was an idiot for not pulling this feature into my code immediately.
So the tip for developers is this - never lie to your colleagues about what you code can do for them. If it is not complete, or plain wrong, shut up about it.
Monday, June 06, 2011
Close Encounters of the Search Kind
A few weeks ago, I was driving home after dark, and while stopped at an intersection, a bright light shone down on my car and I levitated out of my car.
When I awoke, I was in Mountain View California, and I was being questioned by strange beings.
Not really - but I did get asked to interview with Google.
tl;dr version - I didn't get hired
The detailed version -
I was cold-called (emailed, actually), by one of Google's recruitment specialists, and got my resume to him - I don't know how my name was initially brought to his attention; I was told that someone at Google recommended me, but I don't know anyone at Google currently, so it may have been from an old resume submitted years ago. I passed the resume screen, and shortly after was scheduled for a phone interview.
I spent the next week and a half cramming algorithms, data structures, and logic puzzles. Everything I found online about interviewing at Google put me in fear for not knowing esoterica like red-black trees, how to implement a heap, and how to determine how many ping-pong alls would fit in a 747.
The phone interview turned out to be a single coding problem, and I managed to take 50 minutes to solve, and missed an obvious part of the solution.
After two weeks had passed, I pinged the interview scheduler for an update, and was pleasantly surprised to hear that I was getting a second phone interview! So it was back to the cramming.
The second phone interview was somewhat better, in that I managed to not fall flat in solving the problem - again, a straightforward programming problem - and managed to do it quickly enough to field a few more questions.
Another two weeks passed, and my ping at that point resulted in a request to schedule an on-site interview! I was elated, and spent a day grinning to myself.
Shortly after, I was winging my way out to the mothership for a whirlwind 36 hours in Mountain View.
The on-site interview was intense - 4 separate interviews with Googlers, covering a number of topics; fortunately, none of the questions were trick questions - nary a manhole cover or gas station in sight. I was taken to lunch at one of the cafeterias, which had an interesting variety of food, and was quite busy.
Two weeks later, after no response, I pinged the interview coordinator and got the bad news - I was not moving forward.
I was dropped as low as I had been lifted. It really sucked to hear that news. Even though I knew that Google was willing to reject qualified people, it still hurt terribly.
So now I join the ranks of the many who have not passed muster in the Mothership, and I bide my time until next year, when I will try again, assuming they are still looking.
When I awoke, I was in Mountain View California, and I was being questioned by strange beings.
Not really - but I did get asked to interview with Google.
tl;dr version - I didn't get hired
The detailed version -
I was cold-called (emailed, actually), by one of Google's recruitment specialists, and got my resume to him - I don't know how my name was initially brought to his attention; I was told that someone at Google recommended me, but I don't know anyone at Google currently, so it may have been from an old resume submitted years ago. I passed the resume screen, and shortly after was scheduled for a phone interview.
I spent the next week and a half cramming algorithms, data structures, and logic puzzles. Everything I found online about interviewing at Google put me in fear for not knowing esoterica like red-black trees, how to implement a heap, and how to determine how many ping-pong alls would fit in a 747.
The phone interview turned out to be a single coding problem, and I managed to take 50 minutes to solve, and missed an obvious part of the solution.
After two weeks had passed, I pinged the interview scheduler for an update, and was pleasantly surprised to hear that I was getting a second phone interview! So it was back to the cramming.
The second phone interview was somewhat better, in that I managed to not fall flat in solving the problem - again, a straightforward programming problem - and managed to do it quickly enough to field a few more questions.
Another two weeks passed, and my ping at that point resulted in a request to schedule an on-site interview! I was elated, and spent a day grinning to myself.
Shortly after, I was winging my way out to the mothership for a whirlwind 36 hours in Mountain View.
The on-site interview was intense - 4 separate interviews with Googlers, covering a number of topics; fortunately, none of the questions were trick questions - nary a manhole cover or gas station in sight. I was taken to lunch at one of the cafeterias, which had an interesting variety of food, and was quite busy.
Two weeks later, after no response, I pinged the interview coordinator and got the bad news - I was not moving forward.
I was dropped as low as I had been lifted. It really sucked to hear that news. Even though I knew that Google was willing to reject qualified people, it still hurt terribly.
So now I join the ranks of the many who have not passed muster in the Mothership, and I bide my time until next year, when I will try again, assuming they are still looking.
Saturday, October 16, 2010
No Comment
It seems that only a rant-worthy topic can stir me to blog these days, for which I apologize.
However, I just had an experience with a practice that I cannot fathom, and I had to rant about it.
I was looking over some code for another part of The Job's product, in preparation for implementing a similar thing in code I am responsible for. The initial set of changes were relatively clear, and had been done by a local colleague. Then it appears that there was a second set of changes made by another programmer that were less clear. The second set was a bit more sweeping, and were done by a supposedly mid-senior developer. There were no comments in the code that had been changed. Wait, I was wrong - there were comments - every if/then and while block had the closing brace commented with "// end if" or "// end while" - EVEN THOSE IN FUNCTIONS ONLY 5 LINES LONG!!!!!
I remember when I was in college taking a FORTRAN class, we were told to comment heavily, and the ends of sections were required to have such comments, but we also had to have block comments before every major section of code. How did this get mutated into commenting only the ends of blocks? No comments about the intent of the block, the actions in the block, nothing. Just the little end markers for the blocks, cluttering up the diff report.
The part that scares me is that this was also allegedly reviewed by the offshore manager, and passed without comment (or any comment was ignored). What the hell is being taught as programming practices these days?!
I'd have preferred no comments at all to those useless bookends.
However, I just had an experience with a practice that I cannot fathom, and I had to rant about it.
I was looking over some code for another part of The Job's product, in preparation for implementing a similar thing in code I am responsible for. The initial set of changes were relatively clear, and had been done by a local colleague. Then it appears that there was a second set of changes made by another programmer that were less clear. The second set was a bit more sweeping, and were done by a supposedly mid-senior developer. There were no comments in the code that had been changed. Wait, I was wrong - there were comments - every if/then and while block had the closing brace commented with "// end if" or "// end while" - EVEN THOSE IN FUNCTIONS ONLY 5 LINES LONG!!!!!
I remember when I was in college taking a FORTRAN class, we were told to comment heavily, and the ends of sections were required to have such comments, but we also had to have block comments before every major section of code. How did this get mutated into commenting only the ends of blocks? No comments about the intent of the block, the actions in the block, nothing. Just the little end markers for the blocks, cluttering up the diff report.
The part that scares me is that this was also allegedly reviewed by the offshore manager, and passed without comment (or any comment was ignored). What the hell is being taught as programming practices these days?!
I'd have preferred no comments at all to those useless bookends.
Tuesday, September 07, 2010
Old Age and Treachery....
...beats Youth and Skill any day....
So goes an old saying that I like to repeat when one of the young guns at The Job starts ragging on us older programmers.
The key thing is that there is a great deal of accumulated knowledge that good programmers can use that just can't be taught. There are patterns in bug behavior that you learn to recognize, weird interactions that only happen once every decade (or longer), and paradigms that cycle around with Halley's Comet to crash systems - and it's damned hard to teach such things, both in what to look for, and how to generalize them.
That's not to say that young programmers are bad - they've got energy, enthusiasm, and just as much a chance to be truly smart as us codgers. And the lack of experience can lead to pushing an idea hard enough to make it a success (Twitter, anyone?) But most times reinventing the wheel is just wasted effort.
So as I scan the Web for interesting things to blog about, I run across three articles about the cultural differences in two other countries (vis-a-vis the USA): India and Japan
First, India: This one notes that in India, there is very much a belief that programming is the lowest rung of the corporate ladder, and that one's career will advance away from programming. This other one notes that there is also a very strong cultural pressure to rise in a company to achieve "success" within 5 years of starting formal work, in order to marry well.
Similarly, this article notes that Japan has a similar, if somewhat less severe problem, forcing its programmers into management after 13 years, although it hints that there is enough of a vein of monastic dedication that may give the truly determined programmers a chance to excel, at the cost of renumeration.
Now all this makes me look askance at outsourcing to such places - if the developers you get in India are, for the most part, novices, how are they going to learn the experiential things? They aren't experienced enough themselves, and there are no experienced programmers in their companies to teach them, should they be aware of the need. And if your outsourcing company is fortunate enough to be able to keep individuals on staff long-term (instead of them going elsewhere for better salaries), you still will lose them as a developer in five years!
I can't speak for anyone else, but I know that I've learned a great deal in the years since I hit 27 - I'm better at finding abstractions, much better at determining the cause of a bug, and much more likely to put logic in the data instead of the code. I know that my code will need to be refactored, but also that I'll need tests to be sure I don't miss a detail in the rewrite. I also know that any code that has been in production for years probably has dozens of special cases that make it hard to use the obvious abstractions, so I'd better look at it from the bottom-up as well as top-down.
So goes an old saying that I like to repeat when one of the young guns at The Job starts ragging on us older programmers.
The key thing is that there is a great deal of accumulated knowledge that good programmers can use that just can't be taught. There are patterns in bug behavior that you learn to recognize, weird interactions that only happen once every decade (or longer), and paradigms that cycle around with Halley's Comet to crash systems - and it's damned hard to teach such things, both in what to look for, and how to generalize them.
That's not to say that young programmers are bad - they've got energy, enthusiasm, and just as much a chance to be truly smart as us codgers. And the lack of experience can lead to pushing an idea hard enough to make it a success (Twitter, anyone?) But most times reinventing the wheel is just wasted effort.
So as I scan the Web for interesting things to blog about, I run across three articles about the cultural differences in two other countries (vis-a-vis the USA): India and Japan
First, India: This one notes that in India, there is very much a belief that programming is the lowest rung of the corporate ladder, and that one's career will advance away from programming. This other one notes that there is also a very strong cultural pressure to rise in a company to achieve "success" within 5 years of starting formal work, in order to marry well.
Similarly, this article notes that Japan has a similar, if somewhat less severe problem, forcing its programmers into management after 13 years, although it hints that there is enough of a vein of monastic dedication that may give the truly determined programmers a chance to excel, at the cost of renumeration.
Now all this makes me look askance at outsourcing to such places - if the developers you get in India are, for the most part, novices, how are they going to learn the experiential things? They aren't experienced enough themselves, and there are no experienced programmers in their companies to teach them, should they be aware of the need. And if your outsourcing company is fortunate enough to be able to keep individuals on staff long-term (instead of them going elsewhere for better salaries), you still will lose them as a developer in five years!
I can't speak for anyone else, but I know that I've learned a great deal in the years since I hit 27 - I'm better at finding abstractions, much better at determining the cause of a bug, and much more likely to put logic in the data instead of the code. I know that my code will need to be refactored, but also that I'll need tests to be sure I don't miss a detail in the rewrite. I also know that any code that has been in production for years probably has dozens of special cases that make it hard to use the obvious abstractions, so I'd better look at it from the bottom-up as well as top-down.
Monday, August 23, 2010
Explaining Technical Debt to Managers
I've written about technical debt already, but this is a good take on how to explain why it's necessary to clean up code to your managers.
The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time. So they don't see the roadblocks to adding new features very well.
And program/project managers are even further out of the loop on this - all they see is a UI and a list of features. They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?
So anything that makes it easier to explain why working code needs to be changed is a good thing. The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.
The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time. So they don't see the roadblocks to adding new features very well.
And program/project managers are even further out of the loop on this - all they see is a UI and a list of features. They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?
So anything that makes it easier to explain why working code needs to be changed is a good thing. The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.
Thursday, July 08, 2010
More on Estimation (+/- 10%)
The first thing to do when asked for an estimate is to recognize it. Sometimes your boss comes to you with a question that carries a hidden agenda. Spotting these leading questions is usually not hard, because they tend to be asked by your boss when s/he appears at your door unannounced, with a nervous smile, and asks something that seems curiously specific.
The second thing to do is make sure that once you know why they are asking, that you know how big the thing is. This may entail some time educating the questioner about all the real details so you can give an estimate that at least is about the thing they think they want.
Next, you need to break down the job into smaller tasks. From experience, I think that nothing is smaller than a day, and you cannot accurately estimate anything longer than 5 days. So start breaking the task down into discrete sub-tasks until everything is in the 1-5 day range.
Now, you may be objecting that there are some things that take almost no time to do, and you could do 5, 10, maybe 15 of them in one day, cutting your estimate significantly. Perhaps you can do a number of the things in the same day, but there are always unforeseen complications in any workplace that will make things drag out, so the 3 tasks that were going to take one day end up taking 2 because you had to add a new accessor method to a library class and add the tests for it, and the build process did not pull in the correct version, or you had to merge someone else's changes in before you added your stuff, etc. Leave that padding in.
Now that you have a detailed, 1-5 day breakdown of the task, spend a little time looking at the amount of time you think this will take, and consider the other things going on across that time. Does it fall across Christmas, when nearly everyone will be taking time off at the same time, so you won't be able to get in touch with anyone if you're in the office working? How about summer vacation, where someone important might be totally unreachable for 2 weeks? Or does it straddle the big release of the current product, which will result in a lot of field issues? Use this info to estimate how much of your day will be spent a) dealing with these other issues, and b) being interrupted. Having to spend 2 weeks digging through a month's worth of log files looking for a root cause will cut your progress to a snail's pace, as will having to attend twice-daily status updates. Remember, it can take up to 15 minutes to regain mental context after an interruption.
Finally, take the number you have, adjusted for expected interruptions, and add a fudge factor of 30% (initially). This will give you a reasonable starting point, with some room for pulling things in (as all bosses are wont to do), but without the congenital optimism we developers seem to have.
(And another suggestion from www.codesqueeze.com might be useful, if you boss doesn't have the hearing difficulty that cuts off the upper bound of a range)
Of course, there is always the method I read about early in my career - take your initial estimate, multiply by 2, add 5, then convert to the next highest time unit)
Subscribe to:
Posts (Atom)