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 →
EppsNet Archive: Programming
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 →
Aside
Scott Hanselman: Brain, Bytes, Back, Buns – The Programmer’s Priorities
Dennis Ritchie, 1941-2011
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. Read more →
Craftsmanship over Crap. — Uncle Bob
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 →
How’s That WBS Working for You?
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 Read more →
Outsourcing
Contracting hordes of itinerant trainees to write important software, and guiding them from a distant point in time and space. — Ron Jeffries Read more →
The Professional Programmer
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. Read more →
Ask “What Would the User Do?” (You Are Not the User)
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) Read more →
New Programming Jargon
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. 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 →
Twitter: 2009-07-20
RT @RonJeffries: I can waste time in so many ways. How can I monetize this skill? # You don't hear a lot of FORTRAN jokes from cats – RT @sockington: 10 MEOW 20 GOTO 10 # Showed this video at an IT team meeting this afternoon. Good discussion on teamwork ensued. http://bit.ly/EAA0 #kicklikeagirl # Read more →
Programmers Say the Darndest Things
It’s done but we’re still working on a few things. Then it’s not done, is it? It mostly works, but it still needs a lot of testing. How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works? I’m not making these up, by the way . . . Read more →
Microblog: 2009-04-02
prefuse gallery: http://prefuse.org/gallery/ # Processing gallery: http://processing.org/exhibition/index.html # Wordscapes: http://www.typotopo.com/wordscapes/ # RT @GLHoffman: NYC cabbie turns to passenger, after they both see huge crane fall off a building. “Fricking cranes.” # RT @Ben373: “Sh*t happens – when you’re around as*holes. ” Old truism from my dad. # Read more →
Teaching Coding to Kids
VSLP Overview View more presentations from llangit. (tags: studio visual) Read more →
Software Tips from Bjarne Stroustrup
Here are 38 tips from the designer of the C++ programming language. These in particular jumped out at me: [5] Don’t try technological fixes for sociological problems [8] Design processes to encourage feedback [9] Don’t confuse activity for progress [10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested [19] Use existing systems as models, as inspiration, and as starting points [22] Design for change, focusing on flexibility, extensibility, portability, and reuse [27] Keep it small. Don’t add features “just in case” [29] Repeatedly review and refine both the design and the implementation [31] Experiment, analyse, and test as early as possible and as often as possible Read more →
We Are Not (Just) Nerds
One thing that I resent about our computer culture is that they say we are nerds and that nerds don’t get along with people. I think that’s just insane. We are not just nerds — we are nerds, I mean, look at us! But we are not just nerds, we are like the priests or something in the Middle Ages, we are the Lords and Ladies of Logic. We are in charge of rationality for our era. We are bringing common sense and good practice and sound judgment and aggregated wisdom and glory to everyone. That’s our job. — Jim McCarthy I posted this quote on a blog at work and IT people were calling each other nerds all day. Good morning, nerd! How’s it going, nerd? Being a nerd felt like, like being a hero — just for one day. Read more →
You Have to Explain Something to a Computer
When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.” It’s so hard to do the design unless you’re faced… Read more →