Author Archive: The Programmer

Learn to Code

24 Jan 2017 /

I’m a programmer . . .

Job searches for me go like this: I’m old, I have to compete with people half my age, but I’ve worked in Orange County since forever so I know some people, and I can write good code in interviews, which the majority of programmers who show up for interviews can’t.

I was out of work on January 5. It’s now January 24. I have three job offers and picked the one I like best.

Moral of the story: Learn to code, kids . . .

Thus spoke The Programmer.

Accoutrements at the New Office

9 Dec 2015 /
3-star ball

The new office comes with a chef, who seems to see himself like one of those celebrity chefs with the quirky personalities.

Not to put a damper on the fun but I like my chefs to be unobstrusive. I just want a bite to eat. I don’t want to manage a new interaction with an eccentric reality show wannabe.

Just dish up the grub, man.


We also have a ping-pong table now, which triggers a lengthy discussion of the intricacies of table tennis equipment, conducted for some reason in the midst of a group of people trying to get some work done.

Three-star balls? I got your three-star balls right here . . .

Thus spoke The Programmer.

What Can Be Done About Gender Diversity in Computing?

6 Oct 2015 /

That is the question posed in, among other places, the October 2015 issue of Communications of the ACM.

Since gender is no longer a biological imperative connected to one’s physical anatomy, there’s now a simple answer to this. Men (and women, but that’s not relevant to this question) can identify as either gender, independent of reproductive organs and chromosomes, and a thoughtful consideration of the uniqueness and validity of every person’s experiences of self requires a societal stamp of approval.

Google or Facebook or any organization that wants to improve its gender diversity metrics can offer some modest incentive (could be financial, could be you use the women’s locker room at the company gym … use your imagination!) for workers to identify as female. Have a 50 percent female workforce by Friday!

Now that I’ve written this down I’m thinking that maybe I should be starting up a diversity consulting firm rather than giving the idea away for nothing. Room for expansion: Racial identity is fluid now as well (see here and here).

Thus spoke The Programmer.

My Name is Fido

3 Oct 2015 /

From an actual email:


My name is Fido and I’m an IT recruiter at TechDigital Corporation. We are currently hiring a .Net Developer/Software Engineer preferrably [sic] with experience in the Financial domain for a W2 or C2C Contract for one of our direct clients in Green Bay, WI.

Fido Xavier

  1. I live in California. Are there no software engineers in Wisconsin or anywhere between California and Wisconsin?
  2. On the Internet, no one knows you’re a dog.

Thus spoke The Programmer.

Profiles in Management: The Jackass Whisperer

11 Sep 2015 /

Nothing good comes from two people talking about a third person who isn’t there. If your boss is allowing people to talk to him or her about team members who are not present, you have a problem. If you are the boss and you’re doing this, knock it off.

Who is worse: the person who wants to talk about you behind your back or the person who encourages them to do it?

The good boss is loyal. You can count on him going to bat for you, even if he privately disagrees with your view and even if defending you is not necessarily the best thing for him. He is never two-faced.

The bad boss, perhaps while boasting of his uncompromising integrity, thinks only about what’s best for himself. Watch your back.

Thus spoke The Programmer.


The Ceiling Seems Very Low

10 Sep 2015 /

I don’t know if this is good news or bad news. It would help to know what “trains” means but I read the article and it doesn’t say. Reporters need to be more inquisitive.

Can someone with no knowledge of computer science or programming be “trained” to teach computer science or programming? What would that entail? How long would it take?

Can someone who’s never played an instrument or listened to a piece of music be “trained” to teach a music class?

Can someone who’s never picked up a drawing pencil or visited a museum be “trained” to teach an art class?

Can someone who doesn’t speak Spanish be “trained” to teach a Spanish class?

The ceiling on any of these approaches seems very low compared to hiring actual programmers, musicians, artists and Spanish speakers . . .

Thus spoke The Programmer.

I Think We Are Kidding Ourselves

7 Sep 2015 /

More people have ascended bodily into heaven than shipped great software on time.Jim McCarthy


On the other hand, the number of people on LinkedIn claiming to have a demonstrated ability to lead software projects to successful completion, on time and on budget, as well as the number of companies seeking to hire such people, is infinite.

Thus spoke The Programmer.

This Kid Made an App That Exposes Sellout Politicians

8 Jul 2014 /


Yes, the algorithm is

if (isPolitician(x)) {
    x.sellout = true;

Thus spoke The Programmer.

Antipattern: Daily Standup is Too Long

19 Jun 2014 /

Scrum recommends timeboxing daily standup meetings at 15 minutes. If you can’t finish in 15 minutes, there may be something wrong with your format.

Are you actually standing up? What are you talking about? Each person should answer three questions:

  1. What have you accomplished since the last meeting?
  2. What do you plan to accomplish between now and the next meeting?
  3. What, if anything, is impeding your progress?

Focus on accomplishments, not just assigned tasks, i.e., don’t say “I’m working on A and I’m planning to work on B.” Don’t have discussions. Anything coming out at the meeting that needs to be discussed can be discussed after the meeting. Try saying this more often: Let’s talk about that after the meeting. Immediately after the meeting if necessary, without even leaving the room, but not during the meeting.

Anyone in the meeting who is not responsible for accomplishing things during the sprint should not be talking.

Are you clicking through a project management tool to review what each team member is working on? Don’t do that. Anyone who wants or needs that information can click through the project management tool on their own time. Talk about accomplishments and blockers.

Why is this important? Well, you can meet or you can work, but you can’t meet and work at the same time. I recently observed a daily standup with 20 attendees (including remote workers) that was running 30 minutes a day, i.e., 15 minutes too long. They were losing 300 minutes per day (15 minutes x 20 people), 25 hours a week, and 100 hours per 4-week sprint.

Do the math on your own standups and decide if it’s important to you.

Thus spoke The Programmer.

Hard Deadlines

7 Jun 2014 /
Alarm Clock 3

Does saying “This task has to be done by Friday” increase the chances that the task will be done by Friday?

No, but it increases the chance that it won’t be done before Friday.

Better question: Why isn’t it done now?

Thus spoke The Programmer.

Fast Work

17 Nov 2013 /

A junior high school math teacher posted this on Facebook:


That makes perfect sense to me. Work gets done a lot faster if the results don’t have to be correct.

Thus spoke The Programmer.

Minimizing Retention

4 Aug 2013 /

From an actual job description for a Software Development Manager:

  • Worth with management and directs to put together a solid SW Development career development plan in alignment with Organization Solutions all-up to grow hi-potential employees and minimize retention.

If you’re writing job descriptions and learning English at the same time, there’s no shame in having a native speaker review your work.

The job description goes on like that for 10 or 12 more bullet points. I singled that one out because I like the phrase “minimize retention.” I can recommend a couple of people for that.

I assume it’s a language problem in this case — that the author meant to say “maximize retention” or “minimize turnover” — but it might be a kick to have a job where your actual charter is to minimize retention.

You would not be an easy person to work for. You would take all the credit. Your subordinates would get all of the blame.

Picture having the names of all staff members written on a whiteboard in your office and removing them one by one with a triumphant swipe of your eraser at the end of their (hopefully brief) tenure.

Maybe your boss would stop by every now and again to tap on a name and ask, “Why is that guy still here?”

Of course, if some clinging vine is screwing up your retention rate by refusing to quit (maybe he really needs the job?), you can just call him in and fire him. Or her.

Good times! If only all job objectives were this easy to meet.

Thus spoke The Programmer.

Every New Feature is a New Failure Point

14 Apr 2013 /

The TPMS warning light on my car dashboard is lit up, which, according to the owner’s manual, indicates a malfunction in the Tire Pressure Monitoring System, a system designed to alert me, via a different warning light, when the tire pressure gets too low.

It’s a completely unnecessary system to begin with because I can monitor the tire pressure myself, as drivers have done since the invention of the automobile.

Let’s add a completely unnecessary new system so when it breaks, the owner will have to pay to fix it.

Can I just ignore the warning light? I don’t know. The worst-case scenario is that the TPMS not only breaks but creates a domino effect that knocks out a critical system that I actually need.

Toilers in software development can draw their own analogies . . .

Thus spoke The Programmer.

Generalists Are Better Than Specialists

9 Mar 2013 /
Halo Reach, Forklift.

People ask me what is my “specialty” in software development. My specialty, if I have one, is in not having a specialty. I feel like I can contribute on any task.

That answer throws people off. They repeat the question, explaining that everyone is best at something. Managers especially like the idea of specialists because it simplifies the assignment of work: UI tasks go to the UI guys (or gals), SQL tasks go to the SQL guys, middle-tier tasks go to the middle-tier guys, and so on.

Before launching my illustrious career in software development, I worked on a union construction site. Everyone’s job was defined in excruciating detail — what each union member could and couldn’t do.

For example, if we needed to move a pallet from here to there, we had to find a teamster to drive the forklift. There were a few exceptions to that rule, depending on what was sitting on the pallet. In the exceptional cases, we had to find an operator to drive the forklift.

If we couldn’t find a teamster or an operator, the pallet had to sit where it was. We couldn’t move it. It didn’t matter how many other guys were standing around who knew how to drive a forklift.

Since then, I haven’t been a fan of specialization on work teams. It leads to some people having more work than they can possibly do while other people are standing around idle.

I’d make an exception if work demand could be guaranteed to match the available allocation of specialists (i.e., never), but if not, then give me a team of generalists every time.

Thus spoke The Programmer.

There is a Difference

17 Feb 2013 /

There’s a difference between being persistent and floundering.

Thus spoke The Programmer.

How to Lose Your Job : A Fictional Memoir (Part I)

4 Sep 2012 /

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.)

Money to burn

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.

Money and whiskey

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 . . .

Ruby on Rails for Rubes

28 Apr 2012 /
Ruby Tuesday

(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.

Which is More Valuable: Collaboration or Competence?

29 Jan 2012 /
Pablo Picasso, Three Musicians (1921), Museum ...

Pablo Picasso, Three Musicians (1921), Museum of Modern Art

The title of this post makes a good interview question. Usually, the candidate will say something to the effect of “they’re both valuable” to avoid the possibility of slipping up and choosing the one that the interviewer believes is less valuable.

Let’s say we need to get a picture painted. We could say, “Picasso — you’re our best guy in this area. We’d like you to paint the picture for us.”

Or we could say, “Picasso — work with the steering committee to get that picture painted.”

You could make a case for either approach, but you can’t do both. So which is more valuable?

Personally, I think collaboration is overrated. It leads to the knowledge of experts and novices being given equal weight.

There’s a reason why pilots don’t invite passengers into the cockpit to get their opinions on how to fly the plane . . .

Thus spoke The Programmer.

I’m Addressing the Shortage of Women in Technology

22 Jan 2012 /

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.

Basically Done

9 Dec 2011 /

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.

Next Page »