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. Read more →
Author Archive: The Programmer
I Think We Are Kidding Ourselves
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. Read more →
This Kid Made an App That Exposes Sellout Politicians
Via VICE: Yes, the algorithm is if (isPolitician(x)) { x.sellout = true; } Thus spoke The Programmer. Read more →
Antipattern: Daily Standup is Too Long
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: What have you accomplished since the last meeting? What do you plan to accomplish between now and the next meeting? 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… Read more →
Hard Deadlines
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. Read more →
Fast Work
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. Read more →
Minimizing Retention
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… Read more →
Every New Feature is a New Failure Point
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. Read more →
Generalists Are Better Than Specialists
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… Read more →
There is a Difference
There’s a difference between being persistent and floundering. Thus spoke The Programmer. Read more →
How to Lose Your Job : A Fictional Memoir (Part I)
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… Read more →
Ruby on Rails for Rubes
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… Read more →
Which is More Valuable: Collaboration or Competence?
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. Read more →
I’m Addressing the Shortage of Women in Technology
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. Read more →
Basically Done
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… Read more →
A Sad Interview
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… Read more →
Things Which Matter Most
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. Read more →
Don’t Invite Me
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. Read more →
I Am a Programmer
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. — Robert Pirsig, Zen and the Art of Motorcycle Maintenance 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,… Read more →
Adventures in Agile: The Scrum Board
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… Read more →