More Grist for the Mill

I saw this today, pushing for more and better programming education for UK schoolkids.

I'm ambivalent about it - I like that it's for strengthening programming, but I feel that the globalization of software development makes it disingenuous to try and get more programmers in the developed nations when all the corporations are looking to ship the programming jobs out to less-developed nations where developers are cheaper.

The conspiracy theorist in me suspects that the CEOs who keep pushing this without bringing programming jobs back home are just looking to hedge their bets in case India and China become too expensive; having a lot of unemployed programmers at home will make it easy to offer lower pay.

---

Parasitic Effects

I have seen a few things on the web recently that deal with the weird ways that some parasites hijack a host to reproduce.

There is some fungus that makes caterpillars climb high into trees where the die and liquify, dripping fungal spores down onto more leaves for more caterpillars to ingest.

There is some other parasite that makes ants climb to the top of grass stalks so that they are eaten by sheep, the other host in the parasites life-cycle.

And there is Toxoplasma gondii.  It makes rats attracted to the smell of  cat urine, so that they frequent places their predators are.

All this then jumped in my mind to the studies of how onloine games like Zynga's Farmville are highly addictive, providing an endorphin hit every time the player clicks the mouse.

For the first time on Earth, we have a large group of beings actively searching out the quirks of human biology and psychology, looking for things that they can hijack to sell their goods.  This concerns me - how long before someone finds the perfect combination of sights, sounds and smells that will allow them to induce the desired behavior in another person?

Until now, the search was limited by the blind chance randomness of mutations - if a hack evolved, it would survive, but the parasites were not actively seeking weaknesses in the behavioral armor of their hosts.

---

You Catch More Flies With Honey....

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.

---

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.

---

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.

---

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.

---

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.

---