Month: April 2021

This is a post that I wrote quite some time ago. I’ve got several posts like this that could be considered inflammatory or controversial. Generally, rather than posting them as soon as I’ve written them, I let them sit in draft from–generally for years.

Only after significant time and distance has passed from the incident or situation that caused them to be written, do I go ahead and publish them.

I have things that I’ve been learning lately that are more technical in nature, but the most pressing thing that I can think to share relates to something that read recently from Suzy Welch. She quoted Warren Buffet as saying: “You cannot make a good deal with a bad person.”

She then went on to indicate that the same principle is true when it comes to your career, that “You cannot build a good career with bad people.”

This echos something that I heard so many years ago that I can’t be 100% sure where I heard it, but which I believe came from the lawyer who runs “The Passive Voice” blog. In essence, the takeaway from the quote as I remember it was that “no contract, however well written will be good enough to protect you from doing business with someone who is untrustworthy. That when you think that you’re entering into a contract with someone who will try to cheat you, rather than trying to beef up the language in the contract, you’d be better served by simply walking away from the deal.”

Suzy Welch’s article (which you can find here: https://www.cnbc.com/2019/01/18/warren-buffetts-career-advice-could-change-how-you-approach-your-job.html) crystalized some things for me.

It’s very easy to rationalize staying in a job where you’re dealing with bad people. Oftentimes, there are good people in even the worst company. You may think that you just need to accomplish X or Y before you can change jobs, or that it’s too soon to move on once you realize that you’re working in a ‘bad’ company, but my advice is to begin looking for another position immediately and to move on as soon as you can.

There is a lot more that I could say about all of this–a lot more that I want to say about it, but that risks straying into dangerous territory. If you find that there are bad people at the top of your company, or your department, get out as quickly as you can, and don’t let yourself forget that anyone who stays working for a bad person for long enough will naturally begin to adopt their values, justifications and behaviors.

If you find a company that has good people at the top, that should weigh in your decisions to leave or stay much more than I realized 20 years ago when I first started my career.

My blog posts have historically meant to serve a few purposes.

1. Serve as a positive signal for prospective employers.
2. Document things I’ve learned so that I have the for future reference.
3. Serve as an outlet through which I could explore and solidify my views on things.
4. Serve as a positive signal for prospective consulting clients.

Given that I’ve recently accepted a position with an organization where I can see myself staying for years potentially, item #1 has become much less pressing.

Additionally, for various reasons, I’m not actively looking for another consulting engagement, so item #4 is less in play that it has been previously.

Given all of that, it makes sense to cut back a bit on the frequency of my posts. I’ll aim for every other week roughly on average until something changes. That should be more than sufficient to cover points #2 & #3 for now.

“In computer programming, orthogonality means that operations change just one thing without affecting others.”
— “Compactness and Orthogonality”. www.catb.org

Maybe you’re familiar with the concept of orthogonality. Maybe you’re not. Either, way I find that an example is often just the thing for me when it comes to solidifying a concept.

I was recently working on a fairly challenging Agile story, and as part of that, I built a function that took in an optional ‘options’ object. I was finding that under certain circumstances I wanted to log information to the user, and other times I didn’t want to log that information from that function.

So, I created the options object and had the function check for the log property on options. If it was true I went ahead and changed the database and logged the change to the user. If it wasn’t true, I didn’t change the database and didn’t log anything to the user.

Simple right? Except I violated the rule of orthogonality, and didn’t even realize that I’d violated it until a few days later as I was in the middle of debugging my function.

My initial assumption was that if I logged, I also needed to update the database. If I didn’t log, I didn’t need to update the database.

Unfortunately, I promptly found myself in a situation where I needed to update the database without logging, and then proceeded to tie myself in knots trying to satisfy that need without changing my underlying assumption.

Ultimately, I did what I should have done from the start. I started checking for two properties on my options object. Log and update. Like magic, my problems went away.

Imagine that. 🙂