Don't Outsmart Yourself


 

The great Richard Feynman had a saying.  "The first principle is that you must not fool yourself and you are the easiest person to fool."   

I believe there is a similar principle that can be applied to software engineering.  "Don't outsmart yourself."   

As a software engineer, it can be easy to:

  • Over-engineer a solution to a simple problem.
  • Strive for elegance over ease of understanding for others.
  • Use an obscure, or less popular approach to solve a problem.
  • Abstract away complexity pre-maturely.
  • Write a custom library when something that could have worked off the shelf would have sufficed but maybe wasn't a perfect fit.
It feels good to do these things.  It works parts of your brain that might be aching to do something interesting.   It can impress your peers.  

In time though, you will outsmart yourself. 

The smarter you are, the more prone you will be to outsmarting yourself.   The trick is to balance ego with prowess.  Yes, you could do it your super smart way, but it is just as effective half a dozen other ways.

Your elegant solution might not be as flexible as you thought, and new requirements may be harder to implement.

Your custom library might not keep up to date with industry trends, and soon those off the self solutions are miles ahead of where you are, and you don't have the time to add those new features.

That abstraction you created was hiding important features from the caller, and now others have made shortcuts and you have a leaky abstraction that serves no purpose.

That fancy new database you used has a custom query language, and a basic recursive query may have sufficed.  Now the new team that is maintaining your project must learn a new query language.

There is a time and place for elegant code, over-engineered solutions, and beautiful abstractions.  Your next work project is 95% likely to NOT be the time and place for them.   

Strive for understandable, well documented solutions.

Strive for maintainability when another team inherits your code.

Don't write code for your ego, write it for the next person.  You write it once, but it may get read hundreds of times by others.  Optimize for reads.  Don't outsmart yourself!

- Andy Glassman

Comments

Post a Comment

Popular posts from this blog

Write Admin Tools From Day One

Image
UPDATE:  I gave a talk expanding on this blog post at EMPEX NYC 2023 . The Problem Writing useful features for your users is key to a successful product.  It makes sense then that you should maximize your time writing features for those users.   This approach is very effective at the beginning of a product's life, but over time, you may find you are spending more time maintaining the product that developing it. Some of the biggest development time sucks can be: Tracking down the cause of unexpected behavior. Fixing data. Answering user, or team member questions. Running maintenance scripts, or other ad-hoc tasks. The "Oh #&@$" Solution These small support tasks start to add up, and there is no easy way to offload the work to product, or support.  You and your development team reach a breaking point where you must start prioritizing administrative tools. Unfortunately, you will slow down your new feature development even more in the short term.  It will take time for t
Read more

Phoenix LiveView: Async Assign Pattern

Image
UPDATE: LiveView has added a built in, more robust way of using this pattern.  Check it out here ! I've been using LiveView for about two years now. It's a great framework that makes snappy and responsive pages. One anti-pattern I see fairly often is loading a lot of data in the initial page render. For the un-initiated, the mount/3 function is called twice.  Once for the initial 'dead' render, and again after the socket is connected.   Many times, for the sake of simple straight forward code, not much is done differently between these two renders. I haven't found any references (I'm sure they exist) on a best practice for managing the following flow: Set sensible, lightweight default values on initial render. Kick off one or more async processes to make longer running function calls. Receive the values in the LiveView, and update the assigns. As always in Elixir, the tools are powerful, and theres many ways to accomplish this. Spawn a linked, or unlinked pro
Read more

Extremely Fake Cheapskates! Season One Recap

Image
If you've been browsing Netflix lately, you may have noticed a recent influx of trashy reality TV shows.  While I normally avoid these like the plague, there was one that recently piqued my interest.  I've been reading the Mr. Money Mustache blog lately so I just HAD to watch Extreme Cheapskates .   Have these extremists used any of MMM's penny pinching tactics? Maybe there would be some useful tricks I could impress my wife with! I was not disappointed.  This show was a gold mine of hilarity, but it was rather inconsistent.  On one hand there are characters such as Jeff, a man who may out stash Mr. Mustache himself.  On the other, we have people like Vickie, John, and Abdul, who's money saving methods seemed about as real as an episode of Keeping up with the Kardashians . Lets meet the cast of characters that Extreme Cheapskates has lined up and see if we can filter out the real eagle squeezers.  I'll rate each one on a scale of 1 (Gucci hidden under the bed) t
Read more