Habit 3: Complexity Demonstrates Intelligence

Smart people naturally create…chaos?  Today’s habit is about the value of parsimony in your work.  Previous habits linked here:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Demonstrate Your Intelligence With Complexity

Ow, my head hurts...

Project complexity creeps in from two paths.  First, there’s accidental complexity.  As developers we love solving ALL kinds of problems–that’s usually why we choose this field.  Often times we start solving the problem before thinking about it first.  The result is stream-of-consciousness code, where even YOU won’t understand it in six months.  With comments.  As Mr. T would say, “I pity the fool”.

How about the developer that actively accidentally obfuscates their code by using counter intuitive algorithms, poorly named variables, or seven levels of indirection.  This intentional complexity is even more insane.  I’m not sure if this comes from some Napoleon complex in software, lack of training/experience or just a naive repertoire of coding tools.  Either way, it sucks for everyone else down the line from your code.

Simple code is easy to read, easy to maintain, and a joy to work on.  Sometimes, simple code will naturally evolve from complex code during the course of code reviews or pair programming efforts.  The best programmers I’ve ever worked with have one thing in common:  making complex things simpler.  And despite what I read about this Python library experience, simplicity pays for itself down the road.  Being afraid that a simple solution makes you appear less smart is crazy.  Want to prove how smart you are?  Try teaching some training class to your peers instead.

There are some easy ways to help fight both kinds of complexity:

  • Google the problem before you attempt solve it.  See if a solution already exists.  Understand that solution first.
  • If you only understand one solution to a problem, ask someone else for a different perspective, especially if you struggled with that answer.
  • Refactor if you don’t like it the first time.
  • Actively seek to reuse existing libraries.

Endeavor to make things easier for yourself and others.  The sanity you save may be your own.