A few months ago I ran into a post: Psychologists Have Uncovered a Troubling Feature of People Who Seem Nice All the Time. And even EARLIER in the year I read the Business Insider article, Why So Many Tech Founders Who Are Jerks Become Insanely Rich and Successful.
Which got my brain thinking about what does it actually mean to be a successful likable person, and if it’s bad to have opinion that goes against the grain. I think back to my earlier years of my career when I was learning as I went – I sure had an opinion on everything. “Oh this is crap code” would fly off the tip of my tongue. And I believed it. When I go back now and look at what I used to say was “the best code you can buy” I cringe. It’s crap. Why did I think I knew what I was doing?
I was arrogant. Reportedly that most sought after trait of an entrepreneur was just the thing I was giving off so readily. This worked for a couple years until I started running into developers who were actually better than me. Suddenly my arrogance was met with science and experience and my world was rocked. I dedicated the next several years of my life to having a students mind. Everything I did I tried to learn from, take my learnings, apply them elsewhere. I kept my confidence and grew my knowledge.
But something happened along the way. I started to learn how much I didn’t know. Through being a constant student I not only gained knowledge but I gained understanding as well. I started to understand that maybe “Crap code” didn’t always start out that way. Maybe that crap code served a very specific purpose and I shouldn’t mess with it. And does it really matter? At the end of the day most software only serves one purpose: make money.
Does pretty code make more money than ugly code? You can argue either way… better code is easier to maintain, it’s better tested, easily shared with other developers. But what if you business isn’t burdened with long test cycles? Or there’s no future developers in sight? Maintenance, while unpleasant, is not hampered by how ugly the code is? Then investing the cost of making the code pretty may not make business sense.
Now don’t get me wrong – I think those things are important. Especially at an enterprise level. But part of me started to understand that not every project will be the picture perfect case study for Unit Tests. That my job wasn’t to make this set of classes look pretty, uniformed and optimized their structure. My job was to fix a bug, commit and get it to prod. So you see I started to understand that “crap code” is crap only when it stops working.
Back to my original point though. Has this made me too timid? Too agreeable? Perhaps. But when I look back now, years removed, I know that I can leverage these learnings for the better. I believe we have to make choices as leaders to either be confident in our decisions and know why, but also be bold and strike out when we have our gut feeling tells us to. We need to know when it’s correct to be agreeable, and when it’s correct to stand out against the social norm.