Tales from the Interview

I enjoy reading about interviews. Especially the bad ones.  Luckily The Daily WTF keeps me stocked with stories that would chill your bones:



A Doomed Interview (from John) 
Times have been tough, so I’ve been looking just about evernwhere for work. Buried in the last page of the local newspaper, I found a tiny job ad seeking a candidate with several technologies I had experience with. Against my better judgment, I called the number and, after a few minutes of small talk, was invited to an interview. Not the next day, not the next week, but right then and there. Within hours, I found myself on a backwater industrial parkway, standing in front of a non-descript building.

Stepping through the front door was like entering a DooM level: dark as hell, a creepy bad atmosphere, and a slight fear that a giant spider was lurking around the corner. As my eyes adjusted to the gloom, it took all of three seconds to realize that I didn’t want to work there. Against my better judgment, I headed in and up a dimly lit staircase.


The office was decrepit, devoid of people, and looked like a dingy basement with clutter, files, and junk strewn everywhere.What kind of a person would work here, I asked myself. Against my better judgment, I tapped on the door and called out “Hello?”. 

You’ll just have to visit The Daily WTF to see how it ends, for my part; I’ve only had one really weird interviewing experience:

The year was 2007, the bubble was bursting but no one in the banking industry realized it yet; especially not the two floor trading specialists that needed a software developer who could troubleshoot application problems on the ‘trading floor’. I sent in my resume and was called for an interview.  At the time Wachovia was building a skyscraper in Charlotte; it was the topic of conversation by every recruiter or interviewer I talked to that day.  Except for one fateful conversation.

Two of the members of the application development team started taking me through the interview process, and let me know that they were going to stress me out while requiring me to solve brain teasers on a whiteboard. Somewhat confused, I replied, “You know I was in the Army, right?”  I guess that didn’t meet their definition of stress. They continued to ask me rather hurried questions about various programming ideas while wondering why I hadn’t solved their problem about the snail going up the well wall. 

Fast forward six months, and their division was cut (due to the recession), and my job would have undergone a cut as well. Their skyscraper is now owned by Duke, and they were bought out by Wells Fargo. I went on to a contract as a Web Application Developer using Perl.


The Ties that Bind

Same Shiny Boots

In the Army, I spent hours shining my boots. On days where I wore my dress uniform (very few), every part of my uniform looked amazing. If I didn’t have the time to shine my boots, I took them to a retired Sergeant Major that made a living shining other peoples’ boots.

My obsessive behavior over my uniform is the only thing that differentiated me from other soldiers.  We were all the same; same haircut, same uniform, same shiny boots. 

Many soldiers complained about shining boots or having to prepare their uniforms, but we all understood the reason behind it. If you didn’t have the discipline in your daily life, you wouldn’t have that discipline when other people depended on you in combat.

Behold, the Tie

When I left the Army, I worked at a variety of places; some with a flip-flop and T-shirt dress code, and others that required ‘Business Casual’. None of them ever broached the line that required developers to wear a tie.

Ties are a long standing symbol of professionalism in the civilian world. If you are wearing ‘Business Professional’ attire, people take you more seriously and think you know what you’re doing (newsflash: All of Wall street wears ties).  They’re more likely to trust you, and if you’re especially smart about your attire, it can be the difference in choosing who to promote. There’s even an unwritten rule: Dress for the position you want, not the one you have. 

None of which applies to software development.

Shaken, not Stirred

It’s because software development is 1 part common sense, 1 part counter-culture, and 1 part fledgling industry. 

If you aren’t interacting with a client, wearing a Tie doesn’t make sense. It is doubly so when your job depends so much on getting into a mental groove; a groove that’s much harder to attain if you’re constantly thinking about the lack of blood flow to your brain.  There’s also the time aspect. If I’m spending an hour a night worrying about my attire for the next day (I’m colorblind, give me a break), then that’s an hour I’m not spending researching Windows Communication Foundation, playing with Ruby, or helping out on Stack Overflow. All of these make me more valuable to my employer. Wearing a tie does not. 

There’s also the talent cost. If you have a great developer that can choose his company, all else being equal, he will choose the company without the tie. 

Third, our industry is young, and its roots are predicated on rebellion against the status-quo

Tie it up

If you don’t have face-to-face time with a customer, you shouldn’t be scruffy looking, but a tie isn’t necessary either. If you’re a business owner, your programmers will be more productive, happier, and more likely to stay around if you relax your dress code.  Think about it, it’s cheaper than a raise.

Think Before You Measure

I like Target. That probably has as much to do with a lack of alternatives as it does their appeal. Normally I’d go to Wal-mart. However, there are no Wal-mart stores in Northern Virginia. I think there’s one, but it’s rather sketchy. Coming from the south where Walmart is a local hangout, it’s strange not to see one for miles. Not that I’d ever ‘hang out’ in one. But it happens, or so I’m told.

It is, as they say, what it is. I’m not really sure *what* it is though.

Back to the matter at hand.

Target uses a system of measurement to ensure that the cashier is speedily checking customers through the line.  This measuring device uses one criteria to measure a cashier’s worth: How long it takes them to check a person out. From red-bar-of-doom to red-bar-of-doom.  there are two options “R” (for “Red” i guess), and “G” (which probably means “Green”, which is a good thing. I think.) it looks like this:


What this says is that the employee has received ‘88%’ green scores for his shift, and in the past ten transactions, has had two ‘R’ (Red, or “Bad”) transactions. 

It says nothing about the accuracy of his work.

My fiancee and I were shopping at Target one evening and a cashier inadvertently gave us an item without ringing it up. It could have been because I was chatting with the cashier or it could have been because he was tired and just ready to go home and spend an hour figuring out Lost. Who knows. 

What good did Target’s (probably expensive) measuring system do them? None.

That’s the problem with measuring in general.  If you measure something, you incentivise it. Target measured the speed at which customers are checked out. That causes the cashiers to pay attention to how quickly it takes them to check customers out, which means they go faster. Pretty soon Target is starting to miss a non-trivial amount of merchandise that is neither caused by internal loss or by shoplifting. 

You’re reading this post right now, and at least one of you is saying, “That’s great, but I can’t change that. I’m just a programmer.” Bull. You aren’t just a programmer, you create substance out of thin air.

 Business people know business — but they don’t have a monopoly on common sense. We deal with common sense every minute of the day (or lack thereof, depending upon our neighbor’s code).  That’s part of our value as programmers. Without that, we’re just glorified code monkeys.


The Perils of Football Pads

I’ve always wondered why rugby players seem to get injured less than Football players. It doesn’t make sense to me. Football players have pads, Rugby players do not. One is protected, the other is not. One gets injured, the other does not. QED. 

So why in the name of Chuck Norris do Football players have more frequent and more extreme injuries than Rugby players?

The answer is in the pads:

[UMKC physics professor Robbert] Riggs believes there would be fewer serious injuries if players didn’t wear pads or helmets.

“As a retired Marine officer,” Riggs said, “I know that when you’re wearing body armor, sometimes you feel invincible and I think there’s some of that. They put on all those pads and they feel invincible.” (emphasis mine)

Sound familiar? (warning, PDF)

The developer does not need to explicitly free memory assigned to an object, which goes a long way toward reducing the amount of time spent debugging memory leaks. (10) There can be no memory leaks in 100% managed code.

Not only is this statement downright false, it’s also dangerous.  

Google currently has 103,000 hits for “Memory Leak C#”, and they all contain a similar tale of woe, programmers telling other programmers how not to make the same mistake they did. Each example boils down to one of three things:

1. Not de-referencing an event handler:

MyType object2 = new MyType();

// …
object1.SomeEvent += object2.myEventHandler;
// …

// Should call this
// object1.SomeEvent -= object2.myEventHandler;


My most recent encounter with a memory leak was much like this: There was a class that dealt with dynamically wiring up events for other objects (as if they couldn’t do it themselves?) and although these references went out of scope, the event handlers were still hanging around, subscribing to references that were now gone. Anything that was being used as a reference couldn’t be garbage-collected, resulting in hundreds of megabytes of memory being retained over the course of an application’s life.

2. Creating global references to objects:

I don’t care what Greenpeace tells you: Think locally, not globally. Objects that don’t have external references are much easier to keep track of than those that do. 

3. Disposing of Forms

If you’re a Winforms or Webforms developer, this one is for you. ASP.NET MVC guys get a pass because they wised up. If you’re using something that isn’t yours, Dispose of it. Period. Database Handles, Filehandles, Controls, Forms, Whatever. Dispose of it. 

Bad decisions have a half-life that rivals uranium. Don’t make bad decisions: Know your code.

On The Subject Of Chewy Cookies

From Roboppy's Flickr Photo Stream

I love cookies. I especially love Chocolate chip cookies. Chewy ones. You know how hard it is to get people who are used to crunchy cookies to make you chewy ones? It’s a religious war. Crunchy cookies are easy. You put them in the oven, you wait for the allotted time, make sure they look brown and take them out.

Chewy cookies? Those are a little tougher. You have to put the cookies in, make sure they stay in just long enough to be cooked, but not long enough to be hard, and you have to take them out at the exact right moment.  This is not something you do distracted.

Building a blog engine is quite a bit like that.  It’s easy to follow the directions everyone else has followed, it’s easier to use the platform everyone else has used, but it just isn’t as good.

Here are some blog engines that out there, by platform:

Name Platform
WordPress PHP
Subtext ASP.NET
Slash Perl
Blog Engine.NET ASP.NET
dasBlog ASP.NET

Notice that none of the ASP.NET blog engines are written in ASP.NET MVC. Phil Haack (the PM for ASP.NET MVC) is currently working on porting subText to MVC, but he’s the only one.

There is nothing wrong with these blog engines — they’re all good blog engines. But they do too much. I’m writing this in Blog Engine.NET, but I find myself constantly working against my editor to get anything done. I’ve talked about this before.  If you split the world into Microsoft stack blogs and everyone else, the Microsoft stack looks pretty bad. ASP.NET (forgive me) is not exactly ‘web 2.0’. Have you seen the junk it produces behind the scenes?

  <input type=”hiddenname=”__VIEWSTATEid=”__VIEWSTATEvalue=”/wEPDwUJMjg0ODM3NzE0ZGSoESYSPiXqs94xPK36e2sP1eds+w==” />

And that’s just one line. It gets worse.  .NET developers have to either choose ASP.NET or PHP. Crunchy cookies or Macadamia Nut Cookies? Chewy Chocolate chip? Not an option.

It’s time to make some chewy chocolate chip cookies.

Testing Regexes

Recently I had to implement a Regular Expression (Regex) to validate that a property was a certain length. The validation rule was:

String should be  3-4 characters in length, first 3 must be numeric, third must be greater than 0. and fourth (if provided) must be alphabetical.

Since I rarely write Regexes, I generally catch up with the .NET Cheatsheat, or reference my copy of Mastering Regular Expressions. There is even a free tool online (created using Adobe Flex), that allows you to test and create Regular Expressions in real time.



[Author’s Note: This was actually written on 2/25/2010. I went looking for it to find the link to the Adobe flex tool and realized that I’d never published it. I’m publishing it now, especially because I goofed on the original requirements and have to refine my regex.]

Past Prologue

When I was younger, my 9th Grade English teacher, a gentleman by the name of Mr. Hurd, told my english class an anecdote I’ve never forgotten:

There was a child about the age of 13, his friends were astonished to see the advent of television. He was not. They would go on and on about Cowboys, Indians, Cops and Robbers, and he would quietly read his books.  They asked him one day, “Why don’t you watch Television? The shows are amazing!”.  His answer: Everything that had been done for television has been done before for books. There is no need to watch Television, I know how it ends.”

I remembered that anecdote as I read Joel Spolsky’s latest Blog post:

Philip Greenspun and Dave Winer (with DaveNet, even before Scripting News) pioneered the Internet Pundit style of essay writing which has served so well for fifteen years. They started as lone voices in a new medium, but the genre spread like wildfire. It was perfectly prognosticated in the 1990 Christian Slater movie Pump Up The Volume. If you’ve already forgotten it, here’s what happens (not a spoiler): Slater plays a kid with a low-power radio station in his bedroom, broadcasting in the middle of the night to the other isolated, angsty kids in his high school. Interesting drama ensues. 102 minutes later, by the time the credits roll, high school kids everywhere are spouting their opinions on their own pirate radio stations. And that’s exactly what happened with blogging, until we got where we are today, with millions of people expressing themselves and using the exact same narrative techniques and stories and styles that the first bloggers pioneered. (emphasis mine)

It was at this point that I resisted the urge to yell KHHHHHAAAAAAAAAAAAANNNNNNNNNNNN!!!! at the top of my lungs, and that wasn’t even the coup de grâce:

We need something that reflects the best new ideas about what authorship means in 2010, not just electronic forms of 18th-century pamphlets. We need to stop rewriting the same things again and again (fail fast! NDAs are worthless! Execution matters, not ideas! Use the right tools for the job!). Instead we should start filling in the long tail of knowledge. (emphasis mine)

I passed out right around the bold part.  This very thing he is railing against  is exactly what I’ve been writing, the same thing that my English teacher had railed against over a decade earlier. 

Everything I have been doing is doing everything old over again. I’ve become trendy. This is not good

So the question becomes: Do I continue what I’m doing, regurgitating years old advice with my own little anecdotes attached, or do I do something else.

I don’t know.

I do know that I love to write, and I love software. I love chocolate cake too; but I’m not sure that’s relevant. Normally I’d write some sort of call to action or some sort of resolution, but here I have none: Just the idea that if I do continue to write for something that’s published publicly, I need to bring something unique to the table.

The Project Dashboard

Quick, where is your project at?

Now, does everyone on your team know that information?

Ah ha. Gotcha.

If you’re an agile shop, then you probably hold Daily Standups. If you aren’t, then you probably hold daily Sitdowns (see also: boring meeting).

As everyone talks about their status in those meetings, everyone else is busy breaking Company IT policies. Only Youtube gets a pass (it’s really hard to watch a video with sound in a meeting. People tend to stare). At the end of the meeting, everyone who is still awake heads back to their desk. The management types (of course) schedule another meeting, and the cycle repeats itself.

Break the cycle.

Don’t discuss status in the Standup, discuss particulars. Keep the status information on a status board.  

Enter the Project Dashboard:

At a glance, anyone on your team can tell the following:

  • Server Status
  • Completion percentage
  • What’s going in the next release
  • Anything you want

How long does it take to build one?

For one as good as the Panic Status board, a few weeks. I’m building one now, and because I’m building it using ASP.NET MVC, it took me all of about a day to get the entire thing up. There are still metrics I’m adding, but the basic functionality is there. For it to be polished and out the door? About two weeks.

Why doesn’t your project have one?

If Programming had a Narrator

On Automation

<Narrator voice=”Michael Westen“>When you’re a programmer,you think of everything around you as something that can be automated. If you need to get something done, your first thought is usually how to get someone else to do it for you. Usually that’s a computer. In the course of automating this task, you may find out that it’s harder than you realize. But a good programmer works through those odds, because he knows that at the end of the day, the only thing that matters to the people you deal with is whether or not you were able to do it.</Narrator>

On Talking to A Programmer

<Narrator voice=”Michael Westen”>Being a programmer requires a sharp mind and great concentration. Every interruption causes a programmer to lose focus and often requires them to start over at square one. It’s no surprise then that they normally shy away from contact at work. In order to talk to them, you need to include food and something geeky.  Star Wars is normally a safe topic unless they have Star Trek paraphernalia on their cubicle. Pizza is always a safe bet. </Narrator>

Make it Happen

I used to work on a team that was full of smart people. Chock full of them. They were approachable and funny. Probably the best team I’ve ever worked on. Even with all these smart people, there was never any change. Awful processes stayed awful, deadlines slipped, and everyone felt like they were on the Voyage of the Damned.

Much like the Titanic, that team sank. As teammates, we drifted apart because of a number of issues, but all related around a fundamental problem:

Nothing ever Changed. 

What we could have used was someone to take the initiative and wake us up from our slumber. Preferably with loud cymbals:

To that end, I’ve made a promise to myself. If I want to see anything added to a project, I’ll take the initiative and do it. No Automated Unit Tests? Add them. No build process? Make one. Manual status reporting? Automate it.  

As a Lieutenant Colonel used to say to me. If you want something to happen, you have to Make It Happen.