Humility and Better Programming, Part 4
As I discussed in part 3, getting feedback on code you wrote is an excellent way to learn to be a better programmer. Everybody needs to set aside their egos and look at code reviews as a learning opportunity…
You can also learn by looking at other peoples’ code. We put a lot of effort into the LabVIEW 2012 Templates and Sample Projects. I’d recommend fully understanding the simple state machine and queued message handler. The finite and continuous measurement sample projects are a great place to start, too.
In LabVIEW 2013, we’re making a concerted effort to improve the examples we include. Some of the examples in 2012 had been written years ago, and no longer represent good LabVIEW programming practices. You can also study how others have written various design patterns in LabVIEW.
Are you involved with your local LabVIEW user community? You have many LabVIEW peers in other companies, and they’re a great resource for learning new ideas and reviewing yours. Some cities have both beginner and advanced user group meetings. The most advanced user forums are the annual CLA Summits held each spring. You have to be a Certified LabVIEW Architect to attend, and more than one CLA said that access to the summit is the reason he became a CLA. We highly recommend finding some peers inside or outside your company who can help you learn.
Here’s a question I get a lot when I talk about code reviews with my customers…
What if you are the only programmer on your team?
I have to admit that I’m not familiar with this situation. I have been fortunate enough to be in a great organization with a bunch of software engineers always available to review code. But if I were the only programmer, here are some ideas…
- Find someone else in your company, even if they aren’t on your team. Take them to lunch, buy them beer—and absolutely offer to review their code in exchange. Create a virtual team where everybody can share their LabVIEW knowledge. Do you have an internal LabVIEW user group meeting? Reviewing code there is a great place to start.
- Teach someone LabVIEW. Do you have a hardware engineer or a mechanical engineer who doesn’t know LabVIEW? Or a software engineer who only knows one of those archaic text-based languages? Ask them if they’re willing to learn enough to review your code. Tell them you’ll explain it enough detail that they can figure it out. Yes, it’ll be painful at first, but maybe you’ll win a few LabVIEW converts along the way.
- Consider hiring an Alliance Partner as a LabVIEW Consultant for a few hours.
When I was telling Nancy about this blog post, she suggested that you could just create an invisible friend and explain the code to him. I think most of us can find someone real to help, but it did remind me of another anecdote from the book about a side effect that happens when you plan on having your code reviewed. This is about an individual who took part in a programming study…
… one of these subjects—they were all students on a special three-month course—happened to come from a group that practiced egoless programming. At a certain point, he came to me and said that he had reached the point in his work where he needed someone to look over what he had done. As the object of the experiments was not to study differences between group work and individual work, I was forced—against my own beliefs—to request that the subject try to proceed without outside assistance, which would only add to the variance of the experiment.
As a sidelight to this incident, it should be noted that this programmer’s work seemed to the evaluators to be better organized and better executed than the other four programmers working on the same problem. In discussing this question with him, he raised the point that he had worked throughout as he always did in his own group—always with an eye to making the program clear and understandable to the person or people who would ultimately have to read it. This insight indicates that all the advantages of egoless programming are not confined to the detection of errors.
In other words, if you write your code with the expectation that it’s going to be reviewed, you’ll write better code. And that leads to another important idea. Even if you don’t expect others to read your code, don’t forget that you are almost certainly going to read your own code at some point in the future. It may be tomorrow, when you pick up where you left off today, or it might be a year from now, when something goes wrong with your deployed application, and your end user needs a problem diagnosed and fixed ASAP! I have code inside of LabVIEW that I wrote years ago. Every now and then, I have to look at it. It sure helps to to be looking at clean, well-commented code when I’m learning it all over again.
Enough about reviewing code. What else can we do to be better programmers? More coming up in part 5.