Category Archives: Coding

Ownership and Leadership

In Design, Code, Test, Repeat (which you’ve probably already read and if you haven’t, you should), a major theme in building a software career is “ownership and leadership”.  I’ve worked with many programmers over these many years and the one thing that seems to differentiate the excellent from the very good are these two qualities.

Let’s break them down as they’re different. Here’s a scenario: you get a new job.  You have a diverse range of technological skills and write code well, but even with that, you still have a new product or environment to learn.  It may take a while to get your footing in this environment and that’s okay.  But, after a while, you should have done a few projects and have some code in the system that you wrote.  If you haven’t, sign up for a project that will put you in this position.  Having code in the system that’s yours makes you the go-to person for that area of work.  It makes you an integral part of the organization.  Nothing can make you irreplaceable, but you still want to be recognized as a contributor – someone who can be given a project, complete it, and be willing to maintain it.  Once you’ve got an area that’s yours, go get another one.  Don’t become just a niche programmer, expand your knowledge and ownership.  Caution: you’re not doing this to be come a code hog or king of your own fiefdom, it’s because it will give you a higher-level perspective on the way everything works together.  It leads to leadership. It also looks better on a resume for your next position or when you want to make a case for a raise to say, “I designed and developed this feature or product” instead of “I worked on a, b, and c”.

It’s difficult when starting a new job to be a leader and even in a job where you’ve been for a while, there may be several leaders. Both situations are fine and normal. As I said earlier, you don’t want to become king of the fiefdom, you want to be a team player, but you want to be a top team player; a valuable one. Part of this comes from ownership. The more you know, the more you understand, and the more you see. At this point, you start seeing the bigger picture. Then comes the tough part: talking about it. I’ve worked in many places where the structure looked like a whack-a-mole game. Stand up to speak out, even when asked, and the next guy up the ladder would look at you like, “how dare you speak up”. This does nothing but keep your ship heading for the icebergs. If you work here, you might start sending out some feelers for a new place to work. I’m not known for my ability to keep quiet, however, so when I see things that I think need to be fixed or evasive maneuvers that need to be taken, I say something.  If there’s something I can do about it, I’ll offer to do it. Don’t be a pain in the butt about it, but I think that if you don’t say something, you’re just complicit in the disaster that you’re about to become a part of. In the end, sometimes these disasters can cost everyone their jobs (I’ve detailed a couple of these situations in the book, too).

Doing good work needs to involve trust. If you own something, and are willing to change it, maintain it, and speak up when you think you’re being asked to screw it up, you’ll become a trusted member of your team. You’ll have the chance to move up in the organization or move around. It’s a little more pressure than just being a code monkey, but it’s way more interesting, and probably way more lucrative.

Who’s Your Data?

I’ve worked on a lot of different projects and products over the years.  Most of these have been PC-based, file-based storage, applications.  The latest project I’ve been working on has been similar, except that its data is stored in a database.  My colleague, Steve, and I were talking about global data recently, and it got me to thinking about the some of the more horribly structured projects I’ve worked on in the past.

Now, envision that you’re new to a project that’s been in the works for a few years.  There have been a couple of revisions released to the public.  The code has patches scattered around it, copied and pasted code, sparse comments, and data and operation code are intermixed.  In order to write new code, you not only need to understand the data, but the hierarchy of objects that contain the data.  Storing this in files is a recursive process that filters through object after object.  Touch something and something else breaks.  Sounds like most code you’ve worked on, doesn’t it?

Again, envision this code, but with the data stored separate from the operations on the data.  Sounds a bit like Model-View-Control doesn’t it?  Well, even if you aren’t working on something that’s well laid out in a nice, interface-based, MVC pattern, or you want to build something that’s quick and less painful, or you want to migrate some of your code to something similar, a global data area might solve your problem.

I’m not talking about a wad of global variable strewn all over the place (that’s a mess).  I am talking about an in-memory database, with structured information.  In other words, the information that you need to save could be stored in a set of arrays, classes, or structures, that do nothing but hold the information.  All of the other work would be done by other classes.  Think how easily you could write new code to operate on the data without interfering with the other classes that operate on it.  Think how easy it would be to find data.  Think how easily you can implement persistence (save and load).  This could be a simple step in cleaning up some of the spaghetti that’s already in your code-base.

Interface Magic

I’ve been a fan of interfaces (the programming kind) ever since I started using them as part of COM programming, sometime in 1995.  At times, I went overboard, creating an interface or maybe two for every class I wrote.  In the COM days, you really needed to worry about this, because it was the way to communicate between dlls and exes without worrying about nasty linkage and header file issues (i.e. basic C++ programming B.S.).

Now that I’ve been writing more of my own code as a lone programmer, I’ve gotten a bit mellower about interfaces.  I’ve been writing smaller projects and I don’t have to worry about other people using my code.  However, the other day, I found that creating an interface was just the quick fix I needed to save myself from copying and pasting a bunch of code three times.

I had already created three different classes that were just data holders with unique data.  I only needed these three, so doing some code duplication didn’t bother me (we all have a tolerance and I hadn’t reached it just yet).  But, then I needed an output routine that would have to traverse the data for each instance of all three classes and I realized that creating one simple data access interface would let me write just one routine.  Also, later, I could use the same interface to clean up the original code and make it more concise, if I felt so inclined.

On a previous project, I had designed a set of interfaces to cover the functionality of some very different classes that needed to be selected and manipulated on the screen.  When a colleague stopped by and wanted to write a new uber-manipulation tool, I thought for a moment and told him to implement the common Control interface that I used for my other objects and he’d be halfway done with his job.  It also meant that I didn’t have to suffer through someone else hacking away at my already working, but somewhat complicated selection code.

One other thing that I (and my coworkers) did at a previous job was to give every class a public and a private interface.  All communication with the classes was done through the interfaces and not through a class directly.  Remember that the other benefit of interfaces is the clear indirection between the communication layer (how you interact with the class) and the implementation layer (how the class responds).  It’s very easy to get lazy with public and private tags to access data, but many times we get a little lazy and let other code see our internal structure.  Then, when we find out it’s too slow or needs slightly different functionality, we have to change the calling code to change our internals.

For me, one of the great benefits of interfaces is the ability to reuse code that calls the interface, allowing me to worry about the new functionality without having to rework the old (i.e. I don’t need to accomodate a new class in the old code because I’m calling interfaces instead).  Interfaces can allow my classes to masquerade as several different kinds of objects without the need for complicated inheritance trees.  I often find that creating a new base class to handle a particular interface can be just the ticket, too.  One of the best things about software is its malleability.  It often pays to rework a few things and add some interfaces, even after the fact, to make the code easier to understand, use, and reuse.


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.

Truly Customizable User Interfaces

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.

Comment on Comments

I was reading Scott Hanselman’s blog yesterday ( 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.