Tuesday, January 21, 2014

Your Code is a Joke!

Programmers Aren't Renowned For Their Social Graces

When you first decided to get into the industry of programming you must have already met more than a few people who had obviously gotten into it because they were better interacting with machines than people.  So the unfortunate burden for the rest of us is we need to get along with "those people".  Yes, that's right "those people".  To be fair, we're all on "the spectrum" all the way from social oblivious programmers to social butterfly (much like the autism spectrum).

Does any of the following sound familiar?

  • I just rolled back your change-list.
  • Why did you bother submitting that [code I had been working on for weeks]?
  • I just reverted your code.
  • The performance of <insert the tech you own> is terrible/slow.


Now, for clarity - it is perfectly fine to revert/roll-back someone's work - but as a friendly gesture - give them a head's up before you do so.  In the best possible of worlds - you discuss the problem and that gives them an opportunity to address it (thus removing the need to revert it).  Failing the ideal scenario - as a courtesy you just give them a head's up that for some reason (business or technical) you'll need to undo the work they submitted.  And yes, this applies even if you own the system in question.  I realize what I'm about to suggest is common-sense - but just put yourself in their shoes - if you would be annoyed at someone who reverted your work without giving you a head's up first - why wouldn't they?

I've been unfortunate to be on the receiving end of all of the above.  I'd like to say I've never taken it personally, but truth be told - every time I hear or see those words - it bothers me.  As I've gotten older, I've started to take less "personal offense" when someone says (or does these things) - but there is always that initial gut/knee-jerk reaction of "what a so and so" - thankfully people aren't telepathic yet - so this is where you apply the social filter they haven't developed.


When is Being Right More Important Than Successfully Collaborating?

Depending on how deeply you read into this - the answer might not be obvious.  Computer science is one of those domains where there are "strictly better" solutions.  For example a O(n log(n)) is inferior to a linear-solution or O(log(n)).  However, like most domains of sufficient complexity (for example: medical science) - the more interesting the problem, the less obvious the solution.

On the surface, a problem can seem very simple, but more than once I've been surprised to learn of a much deeper problem.  On one occasion I recall updating a method that was exposed through our public API - only to find out from one of our customers that I had dramatically dropped the performance of the application they had built on top of our back-end system.  That was when I learned about the symbiotic relationship you can develop with customers.  The new features/functionality they're requesting are granted a higher priority and they are willing to take our pre-releases/beta's.

The point of all of this is just to say - just because you think you're right, does not make you right.  

Conclusion

When all is said and done - it doesn't matter how perfect and efficiently you've written your code.  More applications (stand-alone, web, database, middleware, etc) have been written than have been "used".  The most "successful"* applications are those that have required the efforts of many programmers working together towards a common end.


Parting Thought

No amount of experimentation can ever prove me right; a single experiment can prove me wrong.


*From my perspective the success of an application is based on how widely used it becomes and how useful it is to those that use it.

No comments:

Post a Comment