Jonathan's Blog

Jonathan's Blog

Mindful Leadership and Technology (Mostly Software)


Mindfulness Leadership Resiliency Work Accoutability Proactive Make Sandals

What It Means to Get Fired - Mindful Firing Part 1

Posted on .

I was fired from a job in 2002. I deserved it.

This isn't what the HR team or my boss at the time would have said. They would have said, "We let him go."

In fact, through the rest of these posts, I will use the same euphemisms because that's the world we live in.

But, since this one is about me specifically, I can tell it like it is or was.

I was not "let go." I was fired. And I'm not saying that about how it happened, or what someone else did to me.

I'm saying it because I deserved it. I had skill deficits. My attitude was not great. I wasn't making the company money. I didn't want to help with sales.

The company needed to make money, and they needed more adaptable employees with a better outlook. So they fired me. It's as simple as that.

I didn't see it that way right away of course. I was mad. Things had changed and it wasn't my fault. The new office didn't understand my value, blah, blah, blah.

All of it true up to a certain point, and all of it - all of it - ultimately beside the point.

Fortunately for me, I realized I had changes to make and I started to make those changes.

I started quickly, but I'm still not done. I never will be.

The world keeps going all the time. You can decide that you're done learning or pushing yourself if you want to, but that isn't going to help you stay competitive.

So we push ourselves, we learn new things, and we work to stay competitive. That was my choice in that moment and I'm glad I made it.

I wish that I could say that this was a mindful choice for me. I wish that I could say that I recognized the need to be proactive, stop blaming others, and move myself forward. That did come with time, and today I try to handle things that way. But the truth is that initially this was all driven by fear.

My skills weren't competitive, my attitude was problematic, and the labor market, even for developers, wasn't that great in 2002. I had to change and I had to change fast to stay competitive, so that's what I did.

Today I recognize this as a significant turning point that led me on to a lot of great opportunity I wouldn't have had without it. But it's hard to see it that way right away. Right away I was just fearful about my job prospects and started making changes that I felt would make me more competitive. And I took contract jobs at a significantly reduced rate to get some experience.

Today I can see it their way. But it took a long time. I understand that the best path to change and to managing these type of stressful, life-altering situations is with mindfulness and distance, though of course urgency remains important.

Fear can be a good source of urgency, but if you use fear to generate urgency you get all the stress and distrust that come along with it. Even if that stress and distrust are only pointed at yourself.

Looking back on it, I was fortunate to have had the upbringing I had. I think that is what made me react with a mostly 'can-do' attitude toward the challenges I had as a young person in my career. It wasn't mindfulness back then. It was Mom and Dad. Thanks Mom and Dad.

What does this tell us about letting someone go, if you are the person in the position of having to do that?

It tells you that it can be for the best. But almost no one will see it that way in the short-term.

It tells you that it isn't your place to tell anyone that. You absolutely are not in a position to tell someone "It's all for the best," because only they will be able to come to those realizations, and only on their own or with the help of good friends or family. And only in their own time. You can't rush that and you certainly aren't in a position to try.

And it tells you to be as kind as you can because inevitably this will be hard and scary for anyone impacted by your decision.


Bots Conversational UI Slack Software Development Accoutability

Bots Rising - Part 6

Posted on .

Our internal bot has been running for a while and getting some use.

We've gotten it so that it runs for 7 - 10 days without issue, but after that length of time it seems to quietly lose the connection and we previously weren't checking for that. I'm not sure if that is a feature of Slack itself or the library we're using. In any case, 7 - 10 days seems pretty good and we should probably add some code to recover if something happens.

To get to 7 - 10 days with a Slack bot, the key was to use the Ping/Pong functionality you can see here. It's part way down the page, just look for 'pong'.

We're currently pinging every 10 minutes. This is a lot less than I've seen recommended, but I believe those recommendations were based on building chat clients with the RTM API, not long-running bots with lots of downtime. I don't want to get in trouble with Slack for sending a million ping messages for no reason.

Instead of upping the number of pings we send (which may have helped) we've added some functionality to check as part of our ping/pong functionality to check for the health of the connection. This seems to be the more responsible way to run the health check and reconnect if the connection is offline.

We've tested our reconnect, which works well. Now we just need to wait 7-10 days to see the production failure occur and see if it recovers.


Software Development Technology Software Accoutability I hate the phrase 'spaghetti code'.

Coding and Accountability

Posted on .

If you are a developer what code are you accountable for?

Is it only your own? Is it your own plus that of a system that you've worked on for some period of time? Is it your team's? Is it every project ever worked on at your company?

I ask this because I've seen a lot of different answers and I will share with you my own approach to this and why that has been my approach.

When I approach a code base I did not create, my first question is to ask, "What can I learn from this code?". This question can and should consume you for some time. You won't know the answer right away, if you think you do, you probably aren't listening closely enough.

Once you know what you should be learning and have begun to learn you can ask how you can make it better. There are always ways to make improvements and to meld your learning with what you already know.

At no point during this process do I use the phrase 'spaghetti code', precisely because it places the source of misunderstandings outside the self onto an inanimate object: 'the code'.

Code is, at one level, a tool to communicate to a machine what you want it to do. It can't be 'spaghetti' if the machine understands it and does what the humans in the room wanted it to do.

On another level, code is a tool to communicate between one developer and another the intent to make a program and what that program was supposed to do. You may choose to blame the previous developer (who completed their assignment), but I don't see how that helps any business situation you happen to be in.

My approach was to be accountable for all code that I touched.

For code written, from scratch by me, I am accountable for all of it, no matter how long ago I wrote it.

As a boss or manager, I don't necessarily expect every person to have that level of accountability, but I expect them to be on a journey that moves in that direction.

And I hate, hate, hate the term 'spaghetti code' (if that wasn't already clear) because it is such a victim phrase. Are you the victim of code? I certainly never wanted to be. I wanted to win and make the code do what it was supposed to do.

Think of the great developers you know. Do they use that phrase? I've never heard one do it.

The 7 Habits of Highly Effective People is very instructive on this point in general. Stephen Covey was not a developer but the lessons are apt to all of us, at all times.

Become proactive. You'll be glad you did.