Personable Doesn't Equate to Good

by Nick Tuesday, August 15, 2006 11:53 AM

This applies to more than just computer geeks.  You see this in any specialized profession, especially ones that require great technical prowess or accomplishment.  That's right, even doctors and lawyers can be like this.  In some cases it's being known as a team player, or just personable, or having good bedside manner.  Often times, this is how people unfamiliar with your profession measure your ability.  If you have good bedside manner, then you must be a skilled surgeon.  If you can relate well to a client, then you must be able to write wonderful briefs.  If you're not a cubicle recluse, you write great code.  Of course this is entirely false.  In fact, often times it's the exact opposite.  People who are the most introverted are often times the most skilled at their profession.  But because they come off as shy, or maybe even rude, it's assumed they must not be good at what they do.

In my experience, some of the most clever, most skilled programmers have been very introverted, and very reclusive.  They're the type of person who sits in their cube, and won't interact with you unless they have to.  But the code which they produce is very high quality, and they have a very deep knowledge of software.  Having spent part of my career hanging out in hospitals, I don't know how many times I've heard from nurses about about a doctor with terrible bedside manner, who was the best surgeon they knew of.  Often times I think serious professionals tend to sacrifice the development of their interpersonal skills in order to concentrate on the technical aspect of their job.

I write this for two reasons.  First, it's important to recognize this about yourself if you know you are this type of professional.  People will judge you, fair or not, based on your ability to communicate well with others, even if it is not the most important part of your job.  Of course, the ability to work well with others, and communicate effectively with patients or clients ought to be a highly desirable skill anyway, and so if you should recognize that it is a reflection on you, and try to improve.

I also write this to make others aware of this.  Don't judge someone purely based on their interpersonal skills.  While it may be important, it's often times not the most important skill to have for a position, and you may be passing up on someone who would do an incredible job for you.  Moreover, someone who can talk a good game my not have the chops when it comes down to actually doing the job you hired them to do.  Don't use one as your only measuring stick for the other.

The Development Process Explained

by Nick Tuesday, August 01, 2006 10:44 AM

One of my coworkers forwarded me this link, which has a great pictorial analysis of how the software development process works.  It's priceless... and something to always keep in mind when you start a long running project.

I Didn't Write That Code

by Nick Tuesday, August 01, 2006 10:40 AM

I review a lot of code during the week... it's one of the more interesting parts of my job.  It's amazing how certain patterns just sink into you brain after you review enough code.  Recently a coworker was in my cube asking about what a particular section of code was supposed to do.  We were looking at my monitor when the following conversation took place:

Coworker:  What does this do?
Me: Well you wrote it, why don't you tell me.
Coworker:  I didn't write that code.
Me:  Yeah, you did.
Coworker:  I never change anything in that project.  You're the only one who works in there.
Me:  Trust me.  I didn't write that code.  I would never write an If statement like that, and that's not how I write comments.  That looks like one of your If statements to me.
Coworker:  What?
Me:  Here, let's take a look at the Source Safe history log.

Sure enough... after just a few minutes in Source Safe, it was revealed that he added the code in question.  It's funny how easy it really is to pick out one person's code versus someone else's.  I can differentiate code written by pretty much everyone on my team just by looking at a few lines.  People have different commenting styles, and different spacing conventions that they like to use.  People leave fingerprints in their code that they don't even realize.

So then we sat around for a few minutes and I showed him his fingerprints.  I showed him how his If statements were subtly different from mine, and how he comments differently.  I didn't do this to correct any flaws... because there weren't any.  It was simply a matter of coding style.  It is important to at least be able to recognize your own code though.

Project Management Tip of the Day

by Nick Monday, July 31, 2006 10:01 AM

Make your TODO's TODONE!

I'm not actually a project manager, but I do share in some of those responsibilities on my current project, in so far as I'm considered the lead developer and architect.  One of things that I've learned over the years, and I try to push for before every major release to production, is to have all the developers on the team go through their code and clean up TODO's.  Today was a perfect example why.

Right now we're working on a 2.0 release, which involves a lot of rewrite since the 1.x branch.  However, we still have to support the 1.x branch which is in productions until we release 2.0.  Friday we got a call for a production problem, and we were able to narrow down the problem this morning.  When I found the offending code, there was a TODO which described the fix that needed to be made.  The defect was actually rather obscure, and I'm surprised it came up... but nonetheless... someone at some point in time anticipated this happening, and stuck a TODO in there which perfectly described what needed to be done to fix the defect.

Had that TODO been turned into a TODONE... this problem would never have occurred.  At some point in time prior to a release, you should always go through your code and try to get to a 0 TODO count.  Granted, this rarely happens in real life, but you should at least evaluate every TODO in your code to see if its really still an issue.  TODO's that are in code too long should also be noted in defect logs as well, so that they begin to elevate the chain of importance, and can be evaluated with other code changes that have to be made.

Finally, all TODO's should have initials next to them.  A one line TODO can often times be very vague, and so its helpful to be able to go back to the original offender and get more context from them as to why they put in the TODO.  Sadly, this particular TODO was nameless, although it was fairly descriptive.

The Geek Hierarchy

by Nick Friday, July 28, 2006 4:12 PM

Via Samantha Burns comes a bunch of really good geeky links.  First there is the Geek Hierarchy Tree.  I've examined it, and it seems pretty close to me.  Then there are some great computer quotes for you to enjoy as well.  They're pretty good quotes, but nothing beats this collection of Computer Stupidities which I've had in my favorites list for a long time.

The Law of Additive Annoyances

by Nick Friday, July 28, 2006 2:10 PM

Everyone has little annoying things that they do which you probably could do without.  But we handle them because, we know we have them too.  But sometimes, there is a person who has so many, that suddenly everything they do drives you nuts.  Even just small things that they do, which normally wouldn't really bother you, start driving you insane!  I call this the Law of Additive Annoyances.  And God help you if the person who sits in the cube next to you fits into the category.

Warning to All My Feed Readers

by Nick Tuesday, July 25, 2006 12:39 PM

Just wanted to give you all a heads up that I'm going to start using FeedBurner to supply my RSS feeds.  Fortunately, dasBlog is so cool, that if you give it the location of your FeedBurner feed, it will automatically redirect people who use your existing feed to the new one.  So hopefully, you'll never know it happened.  But if for some strange reason you stop receiving my feed, you'll need to come back to my homepage and get the new feed address.

Actually... You Didn't

by Nick Friday, July 14, 2006 9:18 AM

I review a lot of code during the day.  Some people's code I review after they check-in to source code control, while one person in particular has to show me their changes before they're even allowed to check-in.  Whenever she comes to me with her code changes, she always says "I fixed the bug"... and after looking at her code I always have to respond, "Actually, you didn't."  This is quickly followed by, "Yes I did... that thing doesn't happen any more."  And while that's always true... her solution was to simply comment out the offending code, instead of fixing the offending code, which results in a new bug to replace the one she supposedly fixed.

It's as if the function she commented out was called InsertDefectWithoutDoingAnyRealWork(), when in reality it's called DoSomethingAlmostRightThatStillHasToBeDone().  And then after I tell how her that her solution will cause functioning code to not function any more, and that she needs to go back and really fix the bug... as she leaves, she always says, "OK, but this did work."

No it didn't!  Fixing a defect by causing 5 more is not fixing a defect at all!  Fixing a defect by commenting out code is not fixing a defect!  Every line of code was written for a reason.  It may not do exactly what was intended, but there was a purpose to it's being there.  So before you simply comment something out, you need to understand that purpose in order to make sure that by the time you're done, that functionality is either deemed to truly not be needed, or has been fixed.

That is when a defect is fixed.

Regular Expressions are Evil

by Nick Friday, June 23, 2006 10:49 AM

As I'm prone to do from time to time... here is another programming rant.  One of the books on my shelf at work is Mastering Regular Expressions from O'Reilly.  It's a very good book on the topic, and if you're interested in learning regular expressions, I highly recommend it.  Recently a coworker came into my cube, noticed the book and said "Wow, you have a regular expressions book.  I really want to learn about them, because they look so great!"  Her voice was filled with excitement.  I had to say it, but felt bad when I killed that excitement by saying, "They're not.  They're evil.  They should be used as little as possible."

Regular Expressions are very versatile, very powerful, and can do an amazing number of functions, and if I had my way, I'd never use them.  From my experience in industry, the programmer who generally likes regular expressions is also the type of programmer who never comments their code.  They're also the type of programmer who tries to combine as many operations as possible into one statement.  They like compact.  Compact looks cool... but compact can't be understood easily.

The reason why I think regular expressions are evil is because, unless you are a true regular expressions expert (and few really exist), you can't look at a regular expression and quickly say what it does.  It's this weird black box of strange characters strung together that's difficult to interpret.  It probably works, and it probably does the job very well.  But when you come back to that section of code in 3 months, will you be able to say what it does?  Will someone else who didn't write that expression be able to come in tomorrow and know what it does quickly?  Or will they have to spend an hour parsing through it in order to determine its purpose?

I do use regular expressions sparingly... but I comment the hell out of them.  I tend to use 3 times the number of comment lines when I embed regular expressions than normal code.  You have to if you want to know what you did a month later.  I say regular expressions are evil, because my goal is to always write code that someone can come in and look at, and know what it does without having to tear their hair out.

I don't always succeed in that goal, but at least I try.

Programming One Liner of the Day

by Nick Friday, June 23, 2006 9:38 AM

From a comment on Asymmetrical Information:

I'm a poor programmer whose solution to execution failures is type louder and more slowly.

I hear evidence of this in the cubes all around me sometimes.

About Me

Nick Schweitzer Nick Schweitzer
Wauwatosa, WI

Contact Me
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit. ... Full Bio

Community Involvement

Twitter

Archives

Flickr Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from Nick_Schweitzer. Make your own badge here.

Standard Disclaimers

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014 Nick Schweitzer