Adam.Kahtava.com / AdamDotCom

Robert C. Martin (affectionately known as “Uncle Bob” in the development community) has a number of great books demonstrating the benefits of OOD/OOP and good design principles. Those acquainted with his books will also be familiar with his generous use of conversation dialogs between developers.

A sample excerpt:

RCM: “Will you help me write a little application that calculated bowling scores?”
RSK: “… Sure, Bob, I’d be glad to help. … I used to be a pretty good bowler … “
RCM: “Let’s begin with scoring a single game …”
RSK: “OK, we’re going to need some test data. Let me sketch out a little picture of a scorecard …”
RSK: “Shall we start at the end of the dependency chain and work backward? …”
- A Programming Episode from Agile Principles, Patterns, and Practices

This dialog continues for some 40+ pages as we’re walked through a paired programming session demonstrating test driven development and refactoring techniques. Admittedly, while reading these dialogs, I initially thought they were a bit over-the-top (campy), but as I actively listen to the communication happening within my team I realize that these dialogs are happening all around me.

An excerpt from this past week:

Me: “Will you help me write a stored procedure to retrieve the customer’s cart items count and default lightbox items count?”
Dev: “Sure, Adam, I’d be glad to help.”
Me: “Cool! This will be more efficient than aggregating the data from multiple repositories …”

Pull yourself in, that’s right, a little closer to the campfire, now sing it with me, “We all live in a yellow submarine… errr… an Uncle Bob dialog, an Uncle Bob dialog.” :)

The business world is full of “professionals” who wear the uniform and try to seem perfect. In truth, they just come off as stiff and boring. No one can relate to people like that.
Don’t be afraid to show your flaws. Imperfections are real and people respond to real. … Don’t worry about how you’re supposed to act. Show the world what you’re really like, warts and all … talk like you really talk. Reveal things that others are unwilling to discuss. Be upfront about your shortcomings. … You might not seem as professional, but you will seem a lot more genuine. - Rework: Jason Fried, David Heinemeier Hansson

I’ve struggled with the personal vs professional tension for sometime. Back in 2002, I started this site with the intention of professional self promotion (image above is my site from 2003). The results were predictable: the tone boring, the topics dry and most visitors saw through the veil of self promotion. I’ve matured since then (well I hope I have). :) Over the years I’ve found that a personal, down-to-earth tone maintains a healthy level of transparency both on the web and in real life. As Gandhi once said:

Happiness is when what you think, what you say, and what you do are in harmony.

A couple non-traditional considerations when preparing for a software development interview.

Prepare for the Warren Harding Error, Thin Slicing, Snap Judgements, and rapid cognition.

The Warring Harding Error as described by Malcom Gladwell:

Many people who looked at Warren Harding saw how extraordinarily handsome and distinguished-looking he was and jumped to the immediate - and entirely unwarranted - conclusion that he was a man of courage and intelligence and integrity. They didn’t dig below the surface. The way he looked carried so many powerful connotations that it stopped the normal process of thinking dead in its tracks. The Warren Harding error is the dark side of rapid cognition. It is at the root of a good deal of prejudice and discrimination. It’s why picking the right candidate for a job is so difficult and why, on more occasions than we may care to admit, utter mediocrities sometimes end up in positions of enormous responsibility. - Blink: The Power of Thinking Without Thinking

As Developers (and Generation X / Yers) we tend to buy into the ideal that “on the internet no one knows your a dog”, an ideal that’s been seared into our minds by Sesame Street and the like. An ideal where sunny days, chase the clouds away, where knowledge, technical skill, and communication should outweigh appearance - a place where being a dog, human, or giant harry elephant should be irrelevant. Unfortunately that’s not reality. Clean up for your interviews, put away those circa Cobain sneakers, and pack in the facial jewelery. Warren Harding (considered one of the worst US presidents) may have been elected based on his appearance. First impressions matter.

Beware of the Interview Anti-Loop

The Interview Anti-Loop as described by Steve Yegge:

when I was at Amazon … We eventually concluded that every single employee E at Amazon has at least one “Interview Anti-Loop”: a set of other employees S who would not hire E. The root cause is important for you to understand when you’re going into interviews, so I’ll tell you a little about what I’ve found over the years.

First, you can’t tell interviewers what’s important … they believe they are a “good interviewer” and they don’t need to change their questions, their question styles, their interviewing style, or their feedback style, ever again. …

Second problem: every “experienced” interviewer has a set of pet subjects and possibly specific questions that he or she feels is an accurate gauge of a candidate’s abilities. The question sets for any two interviewers can be widely different and even entirely non-overlapping. …

The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. …

And then you should wait 6-12 months and re-apply. That’s pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. - Get that job at Google

Don’t Trash Former Employers and Employees

One final bit of advice that’s often overlooked. Avoid talking badly about past employers and coworkers. If you had an unfortunate string of bad career experiences, consider hiring a therapist, or telling your Mom about it. The job interview is not the place to retrace or reflect on past personal struggles, and it’s not the place for trashing former coworkers and employers.

This March marked my fifth year of working in the software realm and five years since graduating University, and this year (according to industry standards) I’m now considered a Senior Developer.

Funny enough. Today, I don’t consider myself a Senior Developer, but a couple years ago I would have told you to “Call me Senior”. Back in those days I may have been a Senior Developer within the monocultured context of the domain, language, and environment I was working with, but certainly not within the larger context of the software realm. I had surrounded myself with homogeneous tools, like minded colleagues, and had fallen into the trap of thinking I was an expert when I wasn’t - we all thought we were Senior Developers.

“When you are not very skilled in some area, you are more likely to think you’re actually pretty expert at it … The converse seems to be true as well; once you truly become an expert, you become painfully aware of just how little you know.” - Pragmatic Thinking and Learning: Refactor Your Wetware

Over the years I’ve observed that Experts and true Senior Developers are collectively regarded as such by their peers, not by corporate credentials, not by job titles, or duration of employment. Experts and Senior Developers are more preoccupied with getting things done, improving themselves, improving their environments, and helping others - not worrying about job titles and status.

“The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.” - Code Complete: A Practical Handbook of Software Construction

Please, don’t call me a Senior Developer, I’m Mr. Developer or Señor Developer.

remember from school other students preventing you from seeing their answers by placing their arm around their exercise book or exam paper.

It is the same [in the working world] …

The problem with hoarding is you end up living off your reserves. Eventually you’ll become stale.
If you give away everything you have, you are left with nothing. This forces you to look, to be aware, to replenish.

Somehow the more you give away the more comes back to you. - Paul Arden, It’s Not How Good You Are, Its How Good You Want to Be

I identify with Arden’s philosophy. The creative process is enjoyable. If I’ve had fun producing it, then why not share it? I think our tendencies to hoard, get hung up on copyright, and get picky about attribution stem from our fear of being taken advantage of and the fallacy of thinking we’re special (we’re not special). I think we should throw our code into the public, share our content, give away everything, and watch what comes back.

The painting above was created by Ron Krajewski, based on my photo (licensed under Creative Commons). Ron mailed me a copy of the painting - it’s also available for purchase at Pet Art.

About a year ago I purchased my first ever cellphone (an iPhone) - before the smart phones I’d grab any old freebie phone that came with a multi-year phone contract.

Getting an iPhone was simple enough, but the reactions to owning one have been surprising. Responses have swung from: “Right on! Welcome to the fold!” to “Oh, an iPhone, it’s just a status symbol.”

I will be the first to admit that I’m more likely to whip out my new phone, but did you see my old phone? It was a the size of an Oh Henry! bar, the buttons faded, the screen cracked, and the antenna was a lightning rod - yes that is a picture of my old phone. Sure, I could have been a hero, milked another 5 years out of the old phone, but… I could also give up my washing machine for a washboard, my bike for a horse, and start burning candles. :)

Experts continue to warn of a looming shortage of North American scientists, engineers, developers, and IT workers in general. Efforts like the K-12 CS Model Curriculum attempt to introduce computer science concepts to children as they progress through grade / high school in hopes that they’ll fill this void, but there’s another issue in play. Developers don’t let their children grow up to be programmers.

My hunch is that, most engineers, developer, or related IT professional would rather see their children succeed them - becoming doctors and lawyers and such, not an IT professional.

Malcom Gladwell (in Outliers) presents an interesting account of career progressions within family trees:

In 1982, a sociology graduate student named Louise Farkas went to visit a number of nursing homes and residential hotels [she was looking for] the children of people [who had immigrated] at the turn of the last century. And for each of the people she interviewed, she constructed a family tree showing what a line of parents and children and grandchildren and, in some cases, great-grandchildren did for a living.

Here is her account of “subject #18″:

A Russian tailor artisan comes to America, takes to the needle trade, works in a sweat shop for a small salary. Later takes garments to finish at home with the help of his wife and older children. In order to increase his salary he works through the night. Later he makes a garment and sells it on New York streets. He accumulates some capital and goes into a business venture with his sons. They open a shop to create men’s garments. The Russian tailor and his sons become men’s suit manufacturers supplying several men’s stores The sons and the father become prosperous. The sons’ children become educated professionals.

Farkas’s … family trees go on for pages, each virtually identical to the one before

From my observations, many developers / IT workers are first generation middle class, first generation post secondary educated, immigrants, or all of the above (myself included). Being a developer or IT professional is a small step up the ladder in helping our successors succeed.

Strong opinions weakly held is a common conversational / debating approach within IT. Basically you defend your opinion until someone disproves it, at which time you adopt the more correct opinion. This approach works well in IT where allotted time for debates are limited and the cumulative knowledge of the team outweighs the individual. This approach doesn’t work as well in the real world. Using this technique with unsuspecting civilians (especially new acquaintances) can results in the victim thinking you’re a) high strung, b) psychotic, c) egotistical, d) possibly a jerk. Actually, this approach can get tiresome in the IT realm too.

I go for a walk every day (yeah-yeah, I’ll be a mall walker one day). My route takes me by a series of automated parking payment machines - the ones where you punch in your license plate along with a parking quadrant. Surprisingly enough, these machines provide endless comedic relief as people talk, grumble, and curse these inanimate objects - some people go as far as to physically assault them, jam their keys in them, give ‘em a good kick. It’s funny to watch a level headed business man break his cool as he uses a car key to fish around in the coin slot while cursing. My favorite responses are the talkers; grumbling about the price of parking or technology in general. I’m sure they know the machine can’t hear them, but yet they give that box of wires a piece of their mind.

If these talkers and grumblers were on the internet they’d most certainly be on Twitter or have a blog.

Algorithm Analysis (Asymptotic Complexity / Big O Notation) courses are the bane of computer science students everywhere. These courses were mandatory, dry, and lacked real world pragmatism for students who just wanted to get stuff done. Well, that’s what we told ourselves; that’s the theory we presented to our friends - we were convinced that framework vendors or the hoogie-boogie man would figure out the most efficient way to performance tune / compile our code. We looked to Sun, Microsoft, or IBM to figure out the details. In truth we were lazy-naive students and Algorithm Analysis was tougher than we’d like to admit - much harder than programming in 4th generation programming languages, more difficult than computer theory, or operating system theory.

As I brush up Algorithm Analysis I found these perspectives interesting:

to be a good programmer, you just program ever day for two years … to be a world-class programmer, you can program every day for ten years, or you can program every day for two years and take an algorithms class - Introduction - Analysis of Algorithms, Insertion Sort, Mergesort

Having a solid base of algorithmic knowledge and technique is one characteristic that separates the truly skilled programmers from the novices. With modern computing technology, you can accomplish some tasks without knowing much about algorithms, but with a good background in algorithms, you can do much, much more - Introduction to Algorithms, Second Edition

It’s unfortunate that our professors never mentioned that Algorithm Analysis would be an integral part of academic type interviews and a prerequisite for getting a job at Google, but then again who would have listened?