An engineer walks into a bar and orders 1.0E20 root beers.

Bartender: “That’s a root beer float.”

Engineer: “Make it a double.”

[HT: Scott Hanselman]

Victor Szalvay: Technical Debt for PMs

I learned something interesting about the HTML5 date tag. Look at this calendar dropdown:

Here is the sum total of code needed to make that happen in a Chrome browser:

HTML4

< view plain text >

1. <input type="date" />

That’s it! No Javascript, no CSS. Programmers these days have it easy.

Because of the huge productivity differences between good programmers and bad programmers — 10x? 28x? More? — my biggest leverage point as a development manager is my ability to hire people.

At my last job, we had an HR Director named Lucy. In every one of our annual Employee Satisfaction Surveys, Lucy’s group had the lowest scores in the entire organization. Nobody liked or respected her.

She was, however, close with the CEO, which made that irrelevant.

Lucy’s friend Kathy Slauson runs the Slauson and Slauson recruiting agency, so that’s where we got our programming candidates, who were mostly terrible.

The Slauson agency doesn’t specialize in IT candidates, although they do have a “technical recruiter,” who unfortunately knows nothing about technology.

They don’t bring candidates in for in-person interviews. They take whatever candidates give them in the form of a résumé and they pass the résumés along to clients like me in hopes of being paid a fee.

1. Candidates send résumés to Slauson.
2. Slauson sends them to me.

What value does this add over candidates sending résumés directly to me? None.

Slauson doesn’t qualify candidates. They don’t map abilities and skills against the requirements of a position. They add no value to the process, and I had to screen all the résumés myself, the same as if I’d just bought them from a job board.

When I saw that Slauson was just going to throw résumés at me, I asked them to please add a short write-up, indicating why they thought each candidate was a good fit for the job.

What I got was write-ups like “Candidate is good with Technology X,” where Technology X is something I indicated as a job requirement.

When I asked “How did you assess that the candidate is good with Technology X?” they would tell me “We asked him.” Or “It’s on his résumé.”

In other words, “Candidate is good with Technology X” meant “Candidate states that he’s good with Technology X. Unverified.”

(If you’re wondering at this point why an HR department would funnel good money to a recruiting agency for doing nothing, go back and reread the part where I mention that Kathy Slauson is a personal friend of Lucy the HR Director.)

I said earlier that Slauson has a “technical recruiter.” She was in the office one afternoon and handed me a résumé.

“He doesn’t look like an ASP.NET programmer,” I said after looking it over, “which is what we’re looking for. For example, I don’t see any C# experience.”

“It’s right here,” she said, pointing at the résumé where it said this: C++.

If you’re not a programmer, you might say, well, easy mistake to make. C# (pronounced C-sharp, like a musical note) and C++ (pronounced C-plus-plus) are both programming languages containing the letter C followed by one or more symbols.

But whereas C# is the primary programming language for web development on the Microsoft platform, C++ is a lower-level language used for system development. Nobody does web development in C++.

Not surprisingly, a high percentage of Slauson’s candidates bit the dust in the initial phone screen with me, because the phone screen was their first encounter with someone whose programming knowledge was non-zero and could possibly tell a good programmer from a bad programmer.

According to Kathy Slauson, that was totally unacceptable. She thought that because she had an in with the HR department, we should be hiring every candidate she sent over, qualified or not, and paying her for the privilege, which is the way it worked before I arrived on the scene and screwed up the process.

She was always very polite to me in person, assuring me that she was doing her best to improve the quality of candidates, but behind the scenes, she was telling Lucy the HR Director that I shouldn’t be allowed to interview candidates anymore.

(That information was never supposed to reach me but it did.)

Think about that: we had a recruiter telling our HR Director that a manager shouldn’t be allowed to interview their candidates. (The fact that I no longer work there tells you which side of the issue Lucy came down on.)

Kathy also told Lucy that the candidates I was rejecting were perfectly good candidates because after I turned them down, they were being hired at other companies.

Imagine that!

Of course they were being hired at other companies. They were being hired by companies with lower hiring standards for programmers. The best thing that could happen with some of those candidates is for them to be hired by competing organizations.

Do you think Amazon or Google worry that candidates they turn down get hired somewhere else?

(No, I wasn’t trying to match hiring standards with Amazon or Google. I’m just saying that it wasn’t my goal to be the employer of last resort, or to be able to say, “If we don’t hire ‘em, nobody’s gonna hire ‘em!”)

Everyone I hired was an order of magnitude improvement over the people they replaced.

I like to work with talented people. I’m not trying to get rich and I don’t have a career path. I’m trying to learn and get better and contribute to my profession.

If you give me a job where I’m responsible for hiring people, I’m going to hire the best people available, and decline to be force-fed unqualified candidates by a friend of the HR Director.

To be continued . . .

I recently concluded a 3-month job search. As part of my networking, I met a number of unemployed people in other fields who were having trouble not only getting jobs, but even getting interviews.

I talked to a lot of people and averaged about an interview a day, including phone interviews, mostly for development manager jobs. For every development manager job, there are multiple development jobs, so if you’re a developer, your situation is even better than mine was.

I live in Southern California, but the demand is not just local. I had multiple contacts from companies outside the SoCal area that can’t find qualified candidates.

I’ve been working again for over two months, I no longer have an active résumé on job boards, and I still get emails and calls every day from recruiters all over the country.

Agile and Scrum are in demand

The situation with Agile and Scrum right now seems to be that a lot of people are putting it on their résumé but most of them are bluffing.

One hiring manager told me that he’d talked to three dozen candidates who claimed to know Scrum and only one (me) who actually knew it.

Another hiring manager asked me to describe the Scrum process, beginning with a product owner with an idea through the end of the first sprint. It’s a basic question, and when I finished, he thanked me for my answer. “You’d be surprised how many people I ask that question and the answer is a yard sale.”

Actually, you’d be surprised how little I’d be surprised by that.

One recruiter contacted me about a 3-month Scrum Master contract in Toledo, Ohio. A glance at my résumé will tell you that I’ve never worked outside Southern California, so on a list of people likely to take a 3-month contract in Toledo, Ohio, my name would be far, far from the top, but the difficulty of finding a qualified candidate to fill that job is such that the recruiter contacted me anyway.

If you really know Agile and/or Scrum right now, it’s a seller’s market.

Don’t kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%.

Most likely, that means going from 0% to 1%. And that’s the biggest improvement of all.

— 8 ways to be a better programmer in 6 minutes

My boy is playing NBA 2K12 and points out that my Where’s Waldo shirt looks like the Washington Wizards (nee Bullets) throwback uniforms.

“Where’s John Wall-do?” he says.

Ha ha. I get my comeback opportunity a few minutes later when his game player passes to a teammate, who scores, but his player doesn’t get credit for an ssist.

“HOW CAN THAT BE ANYTHING BUT AN ASSIST FOR ME?!” he shouts in disbelief. “That’s bad programming.”

“Oh I doubt that,” I say. “The people who program video games are a lot smarter than the people who play them.”

When I was working at the Boeing Company in the mid-1980s, one project with about 80 programmers was at risk of missing a critical deadline. The project was critical to Boeing, and so they moved most of the 80 people off that project and brought in one guy who finished all the coding and delivered the software on time. I didn’t work on that project, and I didn’t know the guy, but I heard the story from someone I trusted, and it struck me as credible.

— Steve McConnell, Making Software: What Really Works, and Why We Believe It

(Photo credit: matt hutchinson)

The biggest headache in software development is that most programmers can’t program and don’t want to learn anything.

I recently finished up a MOOC called Software Engineering for SaaS, offered by UC Berkeley through Coursera. For a modest investment of a few hours a week for five weeks, I learned some Ruby on Rails — a well-designed platform and a lot of fun to work with — as well as tools like GitHub, Cucumber, RSpec, SimpleCov and Heroku.

Over 50,000 students from 150 countries signed up for the class. According to a final email from the professors, about 10,000 students attempted at least one assignment or quiz. Or to look at another way, 80 percent of the students gave up without even trying.

Approximately 2,000 students, or 4 percent, completed all four of the assignments and the three quizzes.

One of the enrollees who gave up without trying is a former colleague of mine, an ASP.NET programmer, who threw in the towel when he realized he wasn’t going to be allowed to do the programming assignments in C#.

Evidently he read under Prerequisites: “Programming proficiency in an object-oriented programming language such as Java, C#, C++, Python, or Ruby” and missed the course description at the top of the page: “This course teaches the engineering fundamentals for long-lived software using the highly-productive Agile development method for Software as a Service (SaaS) using Ruby on Rails.”

“I’m not going to learn Ruby on Rails,” he said, as though it was a silly, irrelevant thing to suggest to a professional programmer, like learning a yo-yo trick.

Thus spoke The Programmer.

I keep hearing that there aren’t enough women in technology, like this is a problem. The most obvious explanation is that women don’t want to work in technology. If they want to work in other fields, fine. If they want to raise their kids, even better.

I did some tutoring for a girl taking AP Computer Science. She’s a junior in high school and wants to be a veterinarian. Afterwards, she told her dad, “If I decide not to be a veterinarian, maybe I’ll be a programmer.”

Don’t let it be said that I’m not doing my part to address the shortage of women in technology, even though I think it’s baloney . . .

Thus spoke The Programmer.

One of our contract programmers tells me that his current project is “basically done.”

“It’s done or it’s basically done?” I ask.

“It’s done. Amanda is testing it.”

“How do you know it’s done if she’s still testing it?”

“All the tickets are closed except one, so it’s basically done.”

“I don’t mean to give you a hard time. I’m trying to figure out if there’s a difference between ‘basically done’ and ‘done.’ Because usually there is. I inherited a project here last year that when I got it, it was ‘basically done,’ except it needed some more testing. I put one of my best guys on it and he was still working on it a year later when it was finally cancelled. It took a year to go from ‘basically done’ to cancelled. Hence my lack of fondness for hearing projects described as ‘basically done.’”

Notes for next team meeting: Effective immediately, we’re not going to describe any task as being “basically done,” “pretty much done,” or my personal favorite, “done — it just needs a little more testing.” (Isn’t that what testing is for — to find out if it’s done?)

We’ll classify things as either Done or Not Done. If it’s not done, we should be able to say what has to happen in order for it to be done.

Thus spoke The Programmer.

Scott Hanselman: Brain, Bytes, Back, Buns – The Programmer’s Priorities

Dennis Ritchie was the inventor of the C programming language and a major contributor to the UNIX operating system. He died last week at the age of 70.

His brilliantly clear tutorial on C, written with Brian Kernighan, was affectionately known as “K & R” by those of us for whom it was an integral part of learning to be programmers.

R.I.P. Dennis Ritchie.

I did a phone interview today with a programming candidate. Of the first six questions I asked him — and I don’t start with the hard questions — he gave a halfway correct answer to one.

I tried to wrap things up with some easier questions so he could end on a positive note. I struggled to find a question he could answer. It was a sad interview.

I saw from his résumé that he’d recently ended a 10-year run in a corporate IT department. Corporate IT departments are usually not on the leading edge of anything, and I have to surmise that he didn’t put in the necessary time to keep up with things on his own.

I don’t know how good he was 10 years ago, but at this point, his skills are stale, and he’s going to have a tough time in the job market.

I’ve spent a lot of my own time over the years reading things and working things out on the computer, creating untold domestic conflict in the process. It’s a battle.

It’s easy to let your career slip away from you . . .

Thus spoke The Programmer.

Michael James posted this annotated job listing in the Scrum group on Yahoo . . .

[Redacted] is looking for a dedicated and experienced application developer [blah blah blah] to ensure delivery of high quality artifacts, to adhere and to follow [Redacted]‘s SDLC. This is an excellent opportunity [blah blah blah] well-known Fortune 50 company.

Tasks and responsibilities

[clip]

• Provide accurate and timely estimates (work breakdown schedules)
• Must have proven ability to provide project estimates and work-breakdown schedules

And you know these guys are getting great results from their precise WBS and SDLC because of these lines:

• Must be extremely responsive, able to work under pressure in crisis with a strong sense of urgency
• 24/7 on call responsibilities on a rotational basis

Contracting hordes of itinerant trainees to write important software, and guiding them from a distant point in time and space.

— Ron Jeffries

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship.

Read full article.

We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias . . .

Users don’t think like programmers. They don’t recognize the patterns and cues programmers use to work with, through, and around an interface . . .

— Ask “What Would the User Do?” (You Are Not the User)

Excerpts from Global Nerdy:

Bugfoot

A bug that isn’t reproducible and has been sighted by only one person.

Shrug Report

A bug report with no error message or “how to reproduce” steps and only a vague description of the problem. Usually contains the phrase “doesn’t work.”

Smug Report

A bug report submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.