wandercoding.com

I was reading an article on nightmare bosses when my mind started drifting towards days gone by.  I was working for a large software company, but in a small division.  At one point I worked for a couple of tough bosses in a row.  The first was tough, but the second one was incompetent.  As I thought about my own performance and behavior during that time, I remembered my lack of motivation.  Then my thoughts travelled farther back in time to when I was a manager.

At one point, I was the development manager for a product group.  I was managing eleven people and we had successfully worked together to produce one product and were working on a second one.  Being a former developer and peer, I was pretty easy to work with and for.  I understood software development and developers and knew to give them a lot of rope for creativity and self-guidance.  On the other hand, I had two employees in particular who were slowing things down on a very tight schedule.  My feet were being held to the fire and I tried to insulate my developers from the pressure as much as possible.

I should have been a little tougher.  Not a nightmare boss, but a boss.  There are many degrees of management and these can apply differently to the different people that you have responsibility for.  Unfortunately, applying the same style to every developer is a mistake that I’ve come to realize only many years later.  Maybe this advice will help you avoid the same mistake.

There are common and different things that make developers work well.  Common items usually include positive feedback, a feeling of appreciation for their work, comfortable and quiet work environment, freedom to choose work-hours, lack of interruptions, good equipment, etc.  These are generalizations, but most people respond well to the above.  Developers respond differently, however, to the amount of supervision, freedom to choose projects, and tightness of specifications.  For example, some developers work very well when unsupervised and with a very loose set of requirements.  Others perform horribly under the same circumstances.  Others still can be easily distracted or have other things going on in their lives that either distract them or that they choose to work on during work hours.

For people who fall into the latter category, a certain amount of babysitting (pardon the use of the word) is in order.  This can be done respectfully, however, and if you’re good, it can be well disguised.  One developer, I discovered later, simply wasn’t doing much work at work.  He needed closer supervision and to understand the importance of what he was (or more accurately wasn’t) doing.  This should have started with a frank discussion of the nature of the situation:

• We needed his code.
• It wasn’t just what he was or wasn’t doing, but what would happen to the group if he wasn’t focused.
• It wasn’t just his reputation, but mine as well.

Then, I should have worked out a plan to cope with him.

• Get a good understanding of his areas of responsibility and what others were expecting from his code.
• Formulate a design of the code and a plan and schedule to complete it.
• Checking in with him every day, going over a goal for the day and progress made.
• If there was any doubt, sit with him for an hour or two each day to ensure progress.  This could be done under the guise of wanting to understand this area of the system better.

You may be asking yourself, why there wasn’t already a schedule and a design, and in fact there was.  However, these things change over time and if someone is already off track, then it’s time to evaluate things in detail, even if you simply discover that initial designs are still good.

If you’re the manager of a group, remember that as the manager, it’s your job to see that everyone is doing their job to the best of their ability.  This doesn’t need to be a micromanagement activity, but it may need to be for some of your employees.  The best way to find out what’s going on with every member of your group is to visit with them often.  A bi-weekly one-on-one meeting for half an hour is often insufficient for this.  Stopping at everyone’s desk for five minutes every day to two will help you understand what everyone is up to, what roadblocks they may be facing, and what interconnections you can make between team members, who may be duplicating efforts.  Customizing your management style for each developer is simply providing the same kind of flexibility you like to have over the software that you use.  The equivalent of each developer having their own options menu on how they should be managed.  The end result is a smoother way to work.

My most recent project is working on a small IDE (integrated development environment) for generating micro-C Linux kernels.  It’s an updated version of Fusion.  One thing in particular that it does is present a UI of choices for configuring the kernel to your hardware.  Specifically, we want the end user to be able to add their own hardware without us needing to do the work and releasing an updated version of the software or a patch to it.  This called for some truly customizable UI.

Since the original software was written in VB, I thought C# would be a good platform for the application.  It would allow me to reuse some of the components, like ScintillaNET, and have equivalent operating system calls and components to the original application.  Also, having a built-in MDI (multiple document interface) framework was an added bonus.

The interesting part has really been the customizable UI.  How can we let the user add their hardware to our configuration dialog?  The answer was simple: use WPF (Windows Presentation Foundation).  If you’re not familiar with WPF, it’s Microsoft’s XML-like, declarative UI language (XAML).  It turns out that this is really easy to load at runtime.  By the way, for help in generating the XAML code, I found Kaxaml very helpful.  Then came the other end of the problem.  How does this same end user modify the C header file that this UI generates to add his own hardware needs?

Well, of course, you’d think about putting information into a user-accessible file that you could load at runtime.  You could parse it for “commands” that would retrieve information from the UI and log the information for output to the header files.  This would generally work fine, but some operations can be a little complicated and I had no desire to build a true lexical parser to handle operations that C# or some other scripting language already had built in.  After a quick search, I found out that C# can compile code at runtime.  Another search took me to Westwind, where I found a nice package built around the numerous commands that C# makes you execute to accomplish the task.  The Westwind code builds a class and takes constructor arguments.  I added a callback class to the arguments, so my end-users can add C# code and calls to my specific class to generate the header files.

I hope this gives you some ideas on how to increase the level of customization in your application or how to add some user-level customization.

I was reading Scott Hanselman’s blog yesterday (computerzen.com) and read a good post about coding basics. I left a comment about the process of coding and making your code better. I thought that one thing in particular was worth writing about here on my site.

There has long been debate about the value of commenting your code. I grew up with code commenting and have continued to do so through my career. The main arguments against commenting code seem to be that a) the code itself is or should be self-documenting and b) comments are often wrong, so why bother.

My answer to these is:

a) I’ve read so much code in my life that is incomprehensible that I wished the person who wrote it had written a comment (or many) about what the code was trying to do – especially because it’s rare to find non-buggy code. Sooner or later, someone’s going to have to go back to that code and fix something.

b) If the comment is wrong, even that’s not so bad. Out of date comments are a place to start. For some reason, when you see a comment and try to evaluate the code, it’s not that hard to figure out that they’re out of sync. There’s clearly some mental process that gets invoked that helps you understand what the code is trying to do. Plus, if the comment is actually correct, you’ve just clued the person into what’s really going on (or is supposed to be going on).

Clearly, I’m in the “keep the comments” camp. One thing I started doing a while ago is functional design by comments. Before writing a function or object-oriented method, I write a comment for what the function will do. Then, I outline the code by writing comments. Writing code this way forces you to think about what you’re going to code and not just jump in. Once you do this, you start thinking about ways to structure the code most efficiently and maintainably. One more benefit: if your comment on the whole function is huge, chances are that you’ll need to break down the actual contents into multiple sub-functions, allowing you to refactor at the conceptual level sooner, rather than at the coding level later.

Try this simple method for writing code for a little while and you’ll probably get hooked on it too. If one of your colleagues comes over to your desk some day and complements you on a well designed and documented class or function you’ve written, or you simply find your own code easier to maintain, you’ll know you’ve earned your next donut.