wandercoding.com

The time of year has rolled around once more where gift-giving is the order of the day.  Sure, this is a shameless plug (have I ever claimed to be shameful?), but I can’t think of a better gift for your friend, spouse, colleague, or manager than my book – Design, Code, Test, Repeat.  It’s probably the funniest book about software you’ll read, but it’s also informative.  I introduce you to my friends’ and my best and worst experiences in over 20 years of software development and management.

Here’s just a sampling of the topics in the book:

• Interviewing – How to suck and how not to suck at it.  In these times of job-hunting and layoffs, avoiding mistakes and steering interviews are invaluable skills.
• Handling yourself professionally on the job and dealing with process, projects, and people.
• Best practices for your projects.
• Best practices for your career.

Not only is there a wealth of information, but to keep things fun, it’s filled with small cartoons and drawings.  For your perusal, I’m including another small excerpt.  Here’s a story about a friend, Bob, who was interviewing a guy for a software position.

The Philosopher

Bob was interviewing people for a position on his team and found a guy named Ivan who was about to graduate with a Ph.D. in computer science from a nearby university. In the past, they had had some very good luck hiring smart people who were lacking in some software experience and teaching them how to write software. If you have an engineering background, you’ve probably done a bit of programming in school anyway and the problem-solving skills are useful in both fields. This guy even had a background in computer science, so while his practical experience seemed to be lacking, he seemed promising.

They had Ivan come in for a half day of interviewing. He was polite and likeable, but clearly lacking in experience – pretty much what we expected. The problem was that for a guy who had very little practical experience, he had a philosophy about everything. He’d say things like, “My philosophy on starting a new coding project is to sit down and do some rough design work before starting a prototype.” It sounds reasonable enough doesn’t it? But since he’d never had a real job, it was a bit questionable. Additionally, his answers to most of the other questions were just vague philosophies as well. Now this guy had been a teaching assistant for a Java class, so he should have been able to come out with something concrete based on his work on a Ph.D. in computer science, right?

Unfortunately, they didn’t do a great job that day of really testing his Java coding skills. Instead, even though they had doubts, they hired him under the assumption that like our other people fresh from school that the equations:

Education = Brain

Brain + Mentoring = Future Valuable and Productive Employee

would hold true. It didn’t. The guy couldn’t code his way out of a paper bag. They tried to get his feet wet by having him check some code out of our source code repository, copy and paste some changes into the files, compile and test them, then check them back in. Believe it or not, he needed help with the copying and pasting part. Not how to use copy and paste tools, but finding the same code in the other files and putting the right code in there. After giving him several mentors, having him audit another Java course, and giving him 9 months (much too generous) to get up to speed, they had to give up and let him go. He went back into academia and is a Professor somewhere now. He was indeed a smart guy, but just wasn’t made for the kind of work they were doing.

In the end, if you have doubts, you’re better off passing on a candidate or perhaps having a short trial period, if that’s possible, to truly assess whether you have a winner on your hands. Better yet, try some of the suggestions below to remove the doubts and clarify the candidate’s true potential.

Have a great holiday.

Don’t forget to buy Design, Code, Test, Repeat.  It’s a fun, funny, and helpful read.

Some authors are releasing books based on blog entries.  Well, I’m going to go the other way around.  I’m going to publish a few blog entries based on my book,  Design, Code, Test, Repeat.  Here are a couple of sections from Chapter 15:  It Doesn’t Get Any Better Than This – Best Practices.

Dominance and Submission
One of the things a couple of companies did was to use sub-mission documents. When you checked in your code, you filled in a simple form with information about what the code was for, what files and versions were involved, and what bugs you (may have) fixed. This document was checked into the source control system and emailed to your colleagues. Although writing these was somewhat tedious, they were very helpful in seeing what files went together as a bug fix or new code submission. If the build broke or a new bug crept into the system, you might be able to spot what happened by reading through some of these documents. They were also very helpful in tracking who was doing what. Several people would read these after returning from vacation to see what had been going on while they were away. Another benefit was that simply reviewing your sub-mission documents for the week made it easy to write your weekly status report.
These documents were referenced in the bug tracking database and the comments for the files that were checked in. This allowed for easy cross-referencing. If you knew the bug, the file(s), or the submission document, you could trace any desired information from there.

Put Down the Keyboard and Step Away From the Code!
As your release date gets closer, you’ll likely be pushing to fix all of the bugs in the system. If you’re not using a bug tracking system – and you should be – then you’ll probably be using a common spreadsheet or some other method. All of the bugs in your system should be rated according to their severity and desirability to be fixed before release.
It’s unfortunate, but your software is probably going to ship with some known bugs in it, simply because it needs to get out the door on time. However, just because you have a bug doesn’t mean it should be fixed. First of all, bug fixing time shouldn’t just be a free-for-all. Developers are more likely to spend time fixing the “low-hanging fruit.” These are the easy bugs to fix or the ones in the developer’s own code that they find most embarrassing. You may wish to let them have some time to do that, but then you should really concentrate on the most important bugs – the ones that crash the system and block functionality from working. Towards the very end of the release, only specific bugs should even be permitted to have fixes. This will prevent the “fix one bug, create two more” syndrome from keeping your release from shipping.
Managing this time well gives you the opportunity to truly control the quality of the software you send out and when it gets sent.