Author Archive: The Programmer

This Kid Made an App That Exposes Sellout Politicians

8 Jul 2014 /

Via VICE:

http://www.vice.com/read/greenhouse-app-hannah-ewens-nick-rubin-201

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:

math-test

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.

Clowns

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.


A Sad Interview

28 Sep 2011 /
Bluebonnets on railroad track

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, he’s out of work, 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.


Things Which Matter Most

24 Sep 2011 /

Things which matter most must never be at the mercy of things which matter least.

— Goethe

You’ve got to keep your priorities in order . . .

We’re developing an on-site conference registration system . . . the topic generating the most email bandwidth yesterday was the ability to retry a declined credit card if the on-site Internet connection is down.

Declining a credit card when the Internet is down is an unusual scenario that may never occur. We’re not even far enough along in development to be able to say for sure that we can accept a credit card when the Internet is up, but by golly, we’ll be able to decline one when it’s down.

My head is spinning . . .

Thus spoke The Programmer.


Don’t Invite Me

13 Nov 2010 /

If you invite me to a meeting, you’ll get my opinion.

I’ll probably try to state it in a way that’s interesting and memorable — because I want you to remember it.

Don’t confuse that with being frivolous though. I’m not pulling this stuff out of the air. It’s based on decades of knowledge and experience.

If you’ve already decided what you want to do no matter what I say, don’t invite me to the meeting.

If you want me to agree that something is a good idea when I don’t think it is, don’t invite me to the meeting.

Thus spoke The Programmer.

Tags: ,

I Am a Programmer

17 Dec 2009 /

They were like spectators. You had a feeling they had just wandered in there themselves and somebody had handed them a wrench. There was no identification with the job. No saying, “I am a mechanic.” At 5 P.M. or whenever their eight hours were in, you knew they would cut it off and not have another thought about their work. They were already already trying not to have any thoughts about their work on the job.

 

We had a manager’s meeting today on the subject of employee recognition. The text we were given to read in preparation for the meeting was indistinguishable from a handbook on training your new puppy:

Behavior which is reinforced is usually repeated. . . . You risk extinguishing the positive behavior by not recognizing it. . . . Provide compliments in a timely fashion, as soon as possible after the event occurs.

That seems demeaning to me and it trivializes the work. I like to be recognized as a person who does good work but I also want to be recognized as someone who cares about his work. I know better than anyone when my work is good and when it isn’t. I’m not looking for pats on the head.

I said in the meeting that I’d rather try to motivate people by giving them the opportunity to do great work, to have some choices about what that work is, and to become the person they’ve always wanted to be.

I pointed out that we’re giving up our youth, our family — everything we hold dear — to come in to work every day, and if the work isn’t worth doing well for its own sake, then it’s a pretty poor exchange.

“We come to work to make money,” Manager A said, as though explaining something very obvious.

“We should sell off our lives one day at a time to the highest bidder?” I asked. “That seems like a good idea to you?”

“Do you really believe the things that come out of your mouth?” Manager B asked.

Manager C stated that in “the real world,” 99 percent of the people he knows are working their jobs for the money and, financial considerations aside, would rather be doing something else with their lives.

The highest-paying job I ever had — before or since — I quit after eight months. I didn’t have another job to go to; I just hated going in there in the morning and I couldn’t wait to go home in the afternoon. I never got a chance to do anything I enjoyed or anything I was good at.

I’m not doing this stuff to get rich. I am a programmer.

Thus spoke The Programmer.


Adventures in Agile: The Scrum Board

8 Dec 2009 /

For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done.

Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?”

Ummm, I could, but it wouldn’t contain any additional information than what’s on the board.

That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task.

It never occurred to me that if you record information on Post-Its and stick them on a wall, rather than recording the same information in an “official” format like Excel or Project, there will be people who assume that you’re just screwing around.

NB: It’s not their fault for not getting it; it’s a communication failure by me because I didn’t anticipate the situation.

Thus spoke The Programmer.


Occupational Intensity

29 Nov 2009 /
Large boy shaking fist at small boy

I saw a guy yesterday — let’s call him Jack — that I used to work with 20 years ago on my first programming job.

My most vivid memory of him is the day he offered to sock another programmer — let’s call him Sid — “right in your f^$&ing face, Sid” because Jack was unhappy with the quality of Sid’s work.

You rarely see that kind of passion and zest in the workplace anymore . . .

Thus spoke The Programmer.

Tags: ,

The V Model

9 Jun 2009 /
The V Model

The graphic on the right came up for discussion at the office today.

The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons.

  1. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad.

  2. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.


Next Page »