Friday, October 11, 2013


I used to work for a company that had a very strong engineering ethic and process. I was part of a large project that was based on a high level of development excellence. For example the unit test coverage minimum was 98%. For the most part, we were always above 99%, but occasionally fell below when new people/dev groups would join the project and were not familiar with our standards.

Enter CRAP
I think everyone would agree, keeping 98% code coverage is challenging. What if we could eliminate the need to write tests except where it really counted. CRAP (Change Risk Analysis and Prediction - now there is an acronym looking for a definition!), tries to help by identifying more complex code,  or code that would be more at risk to change.

We used crap to eliminate unneeded unit tests and to gauge the amount of unit test coverage required for any particular function. It actually works pretty well. Getters, Setters, and 2-3 line functions (with little logic), also have no requirement for unit testing. That's how we defined it anyway.

We lowered our unit test coverage requirement to 90% and used CRAP to ensure complex functions were covered. Great right?

CRAP Thinking
In our case, the spirit of these changes was to eliminate trivial test requirements and focus on more relevant tasks. Unfortunately, some took this as a rule to be bent and broken.

One curious engineer figured out that if you keep all your functions to very simple 2-3 lines you won't have to write any unit tests. So they went about re-factoring their code in such a way so that there just weren't any functions longer than 3 lines.

How do you do that? You create functional binary handlers to combine the logic of other handlers and build up a kind of domain level syntax that you can use to formulate high level logic.

It's kind of brilliant really, if it hadn't been so insidiously underhanded. I mean, if they had published their technique as an open source project, they probably would get a following of similarly curious developers.

But that's not what was wanted in this environment. The code was (properly) rejected and the engineer had to abandon the technique.

Thursday, May 9, 2013

Loop de Loop

Some time ago, an unnamed engineer applied to the unnamed company I was working at for a Sr Web Engineering role. I was in the chain of onsite interviews. Actually I was the final interviewer. My role was to challenge the person to the depth of their technical expertise. I really like that role. I found that when I compared notes with other engineers at the same company, most would ask pointless and non-revealing questions that didn't provide the applicant a chance to show what they know and how they think.

Anyway, this applicant had passed the phone screen. The notes were positive and suggested a high quality candidate.

I started the interview with my usual array of general technical questions, exploring the depths of their experience. I was not interested so much in what they knew as what they could do, so my questions followed a practical path of how would you do this, why would you do it that way, etc.

So the practical exercise was also a standard approach for me. Generalized, it was a task to collect all the DOM elements on a page that had the same classname. Now that task is easily provided by jQuery selectors, getElementsByClassName, querySelectorAll, and other more primitive functions combined with some javascript.

My requirement was that they use none of these, but write the function manually. This requires basic knowledge of the DOM, knowing where to start and how the DOM nodes relate to each other. Its a very straightforward tree navigation task.

That said, very few of my applicants ever wrote a clean version of this task. As a matter of fact, only one ever did it right without any coaching.

Now solving this problem was not the bar they needed to jump. No, it was much simpler. First show you understand the kind of problem it is. Say the words "the DOM is a tree". "I will have to iterate the tree starting at the root node (document.body) and collect any elements who's classname has the desired pattern". "And then return the array of elements".

If you could say that without help, and write a 'non-pathetic' solution you were hired.

I would offer help to the candidate in the form of lightening the load when they failed to understand the tree aspect of the problem. I would dumb the problem down a bit and say: ok, the task is to simply filter a set of nodes passed in as an array. Could you write that task out? Doing that well might get you hired. Most Web Engineers can do that. Not all. What a pitiful situation. You cant iterate a linear array and collect a bunch of nodes. What did you do before you got here? Pick your nose all day?

Anyway, this guy took the cake. he was unable to iterate a simple nodelist. I dumbed the task down ever more: Write a loop that adds up the numbers 1 to 10 and returns the sum.

C'mon, my dead grandmother could do this. But he couldn't. I looked at his resume again. He was a Sr Web Engineer, 10+ years experience. What galaxy am I in? How did this person get in here?

I knew no one would believe me so I took the giant pad we had setup in the interview room back to my desk and stashed the page in one of my drawers. I might need some real evidence of this guys truth. And sure enough I did. The other three interviewers gave a thumbs up. I vetoed vehemently and offered proof for anyone needing convincing.

Now maybe the guy just had a brain freeze. Ok that's fine. He can apply somewhere else. And he did. He applied to a consulting firm, got hired and 3 months later was working in my office as a contract employee. The world is a fucked up place.

Wednesday, April 10, 2013

Developer Resume Translation Guide

Senior or Lead Developer
I was the only one around, so I guess I'm the lead

Developed Custom Implementation Of ....
I had know idea how it was supposed to work, so I did it any way I could.

Managed Architecture
I cobbled together a website using WordPress.

Mentored Jr Developers
There was some poor schmuck lower than me, so I tormented and abused him regularly.

Interfaced with all levels of management
The owner of the 4 person company where I worked would occasionally talk to me.

Actively Keep up with Technology
I surf a lot of porn

Familiar with Word and Excel
I'm a loser