The programmers in my head

Whenever I sit down to start working on a new piece of code, inevitably the people in my head start talking to me.  Now, I know that might sound a bit crazy… but what does that say about you for reading my blog?!  In talking with some other senior developers I find myself very not alone in having multiple minds about things.  In fact, this conversation is a bit of a play off of another one with my friend who told me about how he would fight with me about his ideas before we even had a chance to discuss them.

Problem Solving Mind

In the book pragmatic thinking and learning, Andy Hunt makes reference to Jerry Wienberg’s Fieldstones “just write” method.  This is modeled after a process of how to build a stone wall using natural stones.  Not all of them are going to fit, so trying to make them do so right up front is a big waste of time.  Instead, the idea here is to walk around and notice the ones that could be of value and put them off in a pile.  When you start to actually build the wall, you have a nice place to go look for the stones you want.

My first mind is focused on actually solving little problems.  If I am writing a new piece of code that contains technical challenges… I try to get experience with it and make it pieces of it work.  This is when I shut the door to my office at home, hang the do-not-disturb sign, or stay late at work so I can think / write.  When I am doing this, I am not thinking about the wall to build.  I am  instead thinking about & making all of the little rocks I need.

Refactoring Mind

My second mind processes start to take place almost immediately after I have made my little rocks.  I start to ask “Is it important to make this generic and if so how?”.  If the answer is no, I refactor the code for readability and use.  I also verify that basic abstraction is met (where should the methods go, what are the relationships, etc..).

If the answer is yes, I start down a long conversation with myself and Joe (an old co-worker).  I start to think about all of the patterns the code feels like and what it’s ultimate goal is to accomplish.  I want to make sure that I am not solving THIS problem, but I am solving THE problem.

During this time I draw my current process on a white board.  I let it stew and see if I like it.  I think about how I am going to maintain, where the expansion points are, and I even like to flip the problem itself upside down.  That is, invert the relationship and see if it makes better sense.

My first set of conclusions are usually all wrong.  But none the less, you gotta start somewhere.  If you ever saw me and Joe (the real person) discuss software architecture… this is pretty much exactly what goes on in my head.

Professional mind

My last mind asks about how people will use my code and how the code communicates.  Code communication has to be appropriate to the consumer audience.  If I work with a group of people who are comfortable with anonymous delegates, generic functions, function mapping, abstract virtually typed observers… then, because it’s where I play, I mostly done.  However, if I work with a group of people who might not be, I usually start going down the API / framework route.  How do I expose my genius in such a way that it’s easily used?  My first resource in doing this is the MS Framework Guidelines book by Brad Abrams.  There are some incredibly insightful practices there on how to communicate your intent for usage. I try to look at coding tools to make sure that I am communicating usage; accessors, exceptions, and attributes can be VERY are meaningful, and in some cases I prevent people from abuse.

There is a great book called “About Face v.3” by Alan Cooper.  In his book he talks about usability design.  While his intent was for external consumers of products, I deeply believe that other developers should be bundled into that group.  To write code, I have to consume code.  In the book, Alan’s recommendation was to design for the middle.  Not everyone is a senior developer, nor is everyone a beginner.  Most folks are somewhere in the middle.

A good litmus test is to grab a junior developer (not from my head) and have him walk through your code and see how he fares.  If he has road blocks, I try to verbally communicate the intent… then I ask my self why I had to.

It’s pretty safe to say that people who have worked in only a singular technology in .net (or otherwise) have a predisposition to only a collection of patterns.  Showing someone a MVC example in java might be cake, but until recently there wasn’t an explicit pattern usage of that in .net (though I would argue one could always do it).  If a person is predisposed to the patterns you are using, it’s usually easier to communicate with them.  If they aren’t, accept that you are going to have to connect the dots.  Some of that needs to happen verbally, but you would be surprised how much you can elude to in your code.

Try to keep the people you have worked with in your head.  When ideas comes up, grab your friend and take the idea to the mat.  Don’t think “no one will care”, instead think… if I was to show this code to x person, what would he say?  Just because others you work with today might not notice doesn’t mean that its okay.  This is an incredibly powerful tool in keeping yourself honest.


Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: