Coding Quality and Your University Courses

All programmers are self taught - or are they?

The basic point of that post is true, at least in my case - my courses did little to teach me the details of good coding style and practice.  Of course (ha!) I also learned 5 programming languages in undergrad, so there was not a lot of time to get beyond the basics.

However, the courses also noted the building blocks of the larger concepts - modularity was handled in the first class via the "Karel the Robot" exercises - writing programs to make a small robot trace shapes.  This covered the idea of wrapping repeated actions in functions/subroutines to allow later re-use.

Pascal covered the side-effect in procedures vs functions

But the big thing I think that the courses gave me was the space to realize that I knew the right thing to do.  I was able to see the correct way by being allowed to do it wrong.

Case in point - I was taking a course that was taught in Fortran, and was waiting to turn in my program printout when the guy ahead of me in line asked if I would look over his program to see if I could spot the error in his code that was messing him up.

He told me that he knew BASIC already, so he was writing the programs in BASIC to get the algorithm right, then translating into Fortran for the grade - an excellent idea.  Then I looked at his code.  It was bad.  The first thing that struck me was that he was jumping all over the place, instead of having blocks of code in reasonable places.  IF X THEN GOTO 130 ELSE GOTO 200, instead of having the ELSE be a fall-through.  And so on.

I worked through his code to offer advice, but I don't know if he got the big ideas out of it.

But my main point here is that  if you go into programming, you should have the mindset to see the good stuff on your own - university education is to teach the things that your can't see.

---

Yet Another Rant, on Client-Server Roles

I fear that I am only writing posts here when I am pissed off at something.

However, that's not going to stop me from venting. :)

Ok, the topic today is communications programs, and a severe lack of understanding of a basic communications concept.

A typical inter process communications paradigm is the Client-Server.  One process is up and running, with a well-known contact point; this is the server.  Other programs, the clients, which can be short-lived, will connect to the server at the well-known point, send messages in, and the server will send responses.  In many cases, the server is single purpose, like the Network Time Protocol servers run on many large networks, to provide a consistent time signal for all the other computers.  But there is nothing that says a server cannot do other things as well.

But I ran across a developer recently who was confused by a program we have at work that is an intermediary in a chain of processes that communicate with external devices.  Due to the need for handling many external devices, this program uses an asynchronous protocol, where the messages going out are not responded to directly by the device, but at some later time.  So we have a zippered pair of protocols, where this program acts as a client to send a message to a device, and a server to receive the response from a device.

This developer was confused about this, noting that it was confusing that the one process was both a server and a client, when most were just one or the other.

I find it rather hard to believe that any developer with more than 4 years of communications programming work has not seen many, many examples of processes that talk to two or more other processes and act as client to one and server to the other.

I mean, is it just me, or is the idea that Client and Server are just roles a process assumes when it is communicating with another process, defined solely by who is originating the message?

The mind boggles.

---

Do Clothes Make The Developer?

A short time ago Kelly Sutton wrote about developers clothing styles.  The tl;dr summary is that developers tend to dress like crap, and should dress better.

Why?

Why should the dress code for the new century be driven by the fashions of the one before the last?  Sure, there is no reason for developers to wear dirty, worn, or ill-fitting clothes, but why should we wear ties at work?  Or expensive dress shoes that are slippery on hard floors?

Kelly makes a nod that developers (usually) strive to improve their development skills, and sometimes their personal health, so why not fashion?

Because fashion is not a merit-based activity with intrinsic value - work skills are, and personal health has direct value to us.  But buying expensive clothes that often require toxic cleaning chemicals just to suit an externally-imposed standard?  Not a very useful action, in my opinion.

Now, there may be merit to dressing up to fit in at your employer and climb the career ladder, but that is not necessary in companies run by fellow geeks.

So my fellow nerds, revel in your freedom to dress in comfortable, inexpensive clothes, and thumb your noses at the fashionistas that scoff!

---

Family Matters

This piece about a programmer dad rings so true with me.  I was fortunate to have a job that supported flex-time when my son was born, and we kept his schedule later than typical until he started preschool, so I was able to spend evenings with him and my wife after work.  When my daughter was born, it was even more important to be home for them.

And now, years later, I still prefer to be home early enough to spend some time with them before homework and other teen activities fill up their evenings.

So if you plan on having kids and earn a living programming, start figuring out how you will make the time for them.

---

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.

---