Just Say No

I remember when I first started out as a software engineer in 2006 I had to “earn my stripes.”  I did as I was told, learned from my elders, and tried to make suggestions here and there.  If my ideas weren’t good I was told why and would either go back to the drawing board or move on.

Something has changed with the paradigm of management and engineers.  It seems management is afraid to offend or bother engineers.  Nobody wants to say “no” to an engineer anymore.

We allow engineers (generally junior ones) to

  • Design overly complex systems
  • Use random languages or frameworks
  • Go against team agreements
  • Merge code without reviews
  • Be rude to their fellow employees
  • Make inappropriate and sexist jokes
  • Become “brilliant jerks”

Why are we afraid to stand up?  I guess engineering talent is at such a premium that we don’t want to lose engineers.  But guess what?  A bad seed will make other engineers leave.  Not only that, the bad seed will probably leave at some point anyway and someone will be left with the mess.

Be logical.  Sometimes you will agree, sometimes you will disagree.  Sometimes your opinion will be swayed by a good argument.  But don’t be afraid to say no.  You’re running a team, organization, or company and not a hippy commune.

Good Luck,

Navigating The Gym In January

A good chunk of America stuffs their face from Thanksgiving until the end of December.  Some large percent of these chubbers decide to make a New Years resolution to go to the gym more, lose weight, get into better shape, etc…  This yearly ritual makes January the busiest and most annoying time at the gym.  Here is some advice for the resolutioners to be less annoying to everyone and possibly be more successful.

  1. Plan a routine and schedule.  Go to the gym for an hour for three days, then take a day off, then repeat.  Go at the same time each day.  It will become a habbit
  2. Use weights and do cardio.  Whatever your goal is, both weights and cardio will help you be healthier.
  3. Start simple.  Blogs, message boards, and your idiot cross fit friends will tell you how you have to squat and jerk and clean and back flip.  While those lifts are great, you are just starting out.  Do simple stuff that you recognize.  Use machines at first and slowly work in some free weights.
  4. Don’t hog anything.  A gym only has so many free weights, so many treadmills, and so many benches.  Do your exercise and move on.
  5. BENCHES ARE FOR BODIES.  Don’t be that guy or gal that leaves a cell phone on a bench just to stand next to it.  I don’t care if you are exercising next to the bench, unless your body needs the bench for an exercise let someone else use it
  6. Fancy outfits don’t help.  Maybe get a good pair of sneakers.  Your $500 lululime pants won’t make you run better or give you more strength.  It will just make you look like snobby.  Just get something you can sweat into.
  7. Toe shoes are useless
  8. Don’t do weird stuff.  Yes the treadmill goes to 10 mph.  Yes you can tie a weight to your waist while you do exercises.  Yes you can add a free weight to a machine rack.  Yes you can hang from the chin-up bar and do crunches.  But WHY WOULD YOU?  STOP BEING WEIRD. YOU WILL HURT YOURSELF
  9. Stop staring in the mirror.  Yes, right after you lift your muscles look bigger.  You own a mirror at home.  Nobody wants to see your belly no matter how ripped you are.
  10. Eat better.  Diet plays a large factor in gaining muscle and losing weight.
  11. Keep at it.  Just keep going to the gym.  Things get easier and feel more natural.

Good luck and stay away from my boxing bags

Stop Using JavaScript For Everything

Sorry if this is a rant.

JavaScript is the ubiquitous client side scripting language and has been for a while.  Then a few years back NodeJS was created allowing for JavaScript to be used on the server side.  It’s actually a great completely event driven platform that can power many high scale systems.

But then it got weird.  I suppose UI engineers have been locked into client side work for too long and found Node to be their escape into other worlds.  People started using it to solve every technical problem – load balancing, code deployment, crontabs, system scripts, build tools, etc…

JavaScript and Node are NOT the best tool to solved every problem.  I feel like engineers fall into this hole for two major reasons:

  1. UI engineers are too lazy to learn another language.  There i said it.  I know you say your “expertise” is in JavaScript, but I’d bet that a majority of people who claim to be experts in any language are just average or slightly better than average.  Each language has its pros, cons, and best uses.  Pick up a book and learn another language.  Python is great of systems scripting.  Java / Scala is awesome for long running processes, etc…  Stop using the butt of your drill to hammer a nail into the wall.
  2. Node makes things too easy.  There are a load of libraries easily accessed via NPM.  The event driven model makes the concurrency problem abstracted from the developer so they can develop “scalable” applications without thinking too much.

So why am I whining?  JavaScript has a lot of nastiness.  It was built for the client side.  Once you start building large back end applications, the funk of the language becomes more and more obvious.  I cannot count how often global scope or the lack of types has caused a production outage.  Or an indented mess of code with callback hell becomes impossible to maintain.  Or how developers do not understand what the event driven model actually means and the limitations (hint, not everything you program is magically non-blocking).  Or someone decided to reinvent something that works perfectly fine just because they now can write it in JavaScript.

Node and JavaScript have their uses.  Just think before you build.  Don’t let the MEAN stack be mean to you 😉

Good Luck,


Pendulum Swing

One of my favorite natural phenomenons is the pendulum swing.  You pull the pendulum back and let go.  It swings to the complete opposite direction and then back and forth slowly decreasing the distance until it settles in the middle.  The most amazing part is that so many of our decisions are modeled the same way.  We react to problems by going in the complete opposite direction.  I’ve experienced this time and time again in life, and I’m sure you have too.

Years ago typed languages were king.  Then it was seen to be too cumbersome, so we started using untyped languages like PHP.  Later we see those code bases as nasty so now we are moving back to typed languages that are inferred or duck typed.

Early on, companies would say engineers are too expensive and then outsource all engineering.  Then when that failed they moved most of the jobs back.  Now some jobs are outsourced and some aren’t.

Relational databases weren’t meeting the development and scaling needs  because they were too rigid and structured.  Many people jumped ship to NoSQL databases where there is no structure at all.  But then NoSQL databases had problems of their own so now people are looking at NewSQL databases, which is somewhere in the middle.

Monolithic applications are hard to maintain, develop on, and deploy in a large organization.  So now people push for micro services, which are many tiny applications.  But people are seeing very different problems with that architecture.

Think about a hard breakup you had.  The next person you dated was probably the polar opposite of your ex.  Chances are that wasn’t the perfect person either.

We tend to react to things not being perfect by going in the complete opposite direction.  It seems that a better reaction would be to slightly correct course and actually address the problem at hand.  Be “iterative” or whatever the kids call it these days.  The next time you are in a meeting about architectural changes or re-organizations think about whether or not the change is a pendulum swing.

Good Luck,

Technical Debt

Sometimes it feels like junior engineers and product folk don’t quite get what technical debt is.  Actually, they understand what the term literally means but not the impact.  Here is a little fun analogy to help.

Imagine you live with your spouse in a nice tidy apartment.  You receive a call about a job interview for a position that is double your current pay but you have to interview right away.  So you turn your closet inside out looking for your best interview outfit.  Shoes, clothes, etc.. strewn around your apartment.  You’re dressed to your best but your apartment is now a mess.  Since you are in a rush, you leave everything and head to the interview.  While you are at the interview, your spouse comes home and trips on a pair of shoes you left out spraining his or her ankle.

The best case scenario is you get the job, but now you have to take care of your spouse and clean up the apartment.  It’s more likely that you didn’t get the job, your spouse is livid, you and your spouse need to clean up the apartment, and you now have to take care of your spouse.

Technical debt is the mess you leave to hopefully make some extra money off of a product feature.  The mess you make is in code and not in your apartment.  It can lead to bugs and outages.  Messy code and systems can be hard to maintain and build off of.  Each subsequent product feature becomes harder to build.  Engineers get angry dealing with a mess so they leave.  The next set of engineers cannot navigate the mess so they are constantly angry.

The thing is, if you had texted your spouse to leave a warning about the mess and cleaned up right when you got home from the interview, everything would have been okay.  It’s the same with technical debt, sometimes you need to make a mess but if you actually plan for it and clean it up, you will be okay.

Try to avoid technical debt.  But we all live in the real world so if it is necessary, pay it down quickly.

Good Luck,


I got some interesting email feedback from this blog article.  The article was generally geared towards somewhat mature startups / tech companies.  Fledgling startups in the early phase need to sprint to the point where they have customers and technical debt is a necessary evil.  The prettiest code ever is useless if there is no one using the product.  As time goes on and customers come in, you need to start paying down debt.  It’s kind of similar to processes – at first you will be horrible with process but as your teams grow and the company becomes real you will need to keep improving until everything is seamless.  Just as a warning, some bad technical implementations can actually get exponentially worse if left alone for too long.