Your co-workers are not an excuse to suck

One of the difficult aspects of programming is dealing with paradoxes that come up over time.  This is exemplified by writing ‘flexible’ code which “does everything for everyone” but cannot be touched or everything breaks.  I would hardly call that flexible.  Sometimes different things are the same, and other times same things are different.

One such paradox came up today.  I made a statement and then found myself back peddling a bit later in the same conversation.  The statement was something like, “You shouldn’t write code in a manner that makes your team unsuccessful.  If a piece of code I write can’t be maintained or used by others… I should really question the value of the code itself.”  Although this is an overall good statement, the problem lies in the using others as an excuse not to innovate.  The anti-pattern is castrating innovation because others are not in a place to maintain it.

For the record, I believe I work with a good team.  But just like any other team, we are all in different places professionally.  This does not mean that I should withhold ideas because others might find them difficult.  Instead it means I need to build up my team, train them on what they need, document my code properly, and follow standards.  In short, I need to write professional software and be a professional developer.

This is not a post about co-workers at all.  Instead this is more a post about encapsulation.  OOP does a great job in dividing responsibilities in a way that allows developers to be successful.  The work place shouldn’t be much different.  In this case, we need to consider dividing responsibilities from two angles.  Those who must consume the code and those who will maintain it.

From a consumption standpoint the code should be well documented, easy to use, clear in it’s intent, and meet the needs of the consumer.  From a maintainability standpoint the code should be well documented, clear in it’s intent, and extensible.  The only significant difference in the two pieces of code is HOW you meet your audience.  If I am writing a paper for academics, it’s going to be a very academic paper.  If I write an email to my wife I highly doubt she wants an outline, definition of terms, executive summary and then my proposal.  The same is true for writing a complicated body of code.  Those who want to consume it are invested in it for different reasons then those who may need to maintain it.  You have an equal responsibility to both.

You have to meet people where they are at.  And if where they are at is very low, you have to REACH very low to meet them, and then lift them up.  You don’t need to set the bar lower, you just have to uplift your juniors.  If you are packing the tools to do it you should.  If for not any other reason but because someone wasted their time showing you how to grow up.

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: