The danger of Slack

Slack is a wonderful communication tool, I love how easy it is to get in touch with my co-workers, but it is also a huge time suck which I have become slightly addicted to.  It is way to easy to start browsing through a channel, start checking on the pinned items (#living-vicariously, I’m looking at you), and then look up and realize that you have lost a hour of the prime working hours. When I first started my current position, I was so excited to have Slack.  It was absolutely verboden at my previous workplace, and my one experience was using it at a hackathon just for about 24 hours. It was so shiny, and packed to the brim with emoji’s, gifs and fun times.  Share your screen! Message! Share! For a while, I even had my laptop screen open with just Slack on that screen.  You only have so much attention and concentration to spread around, and my brain power was getting sucked into Slack channels.  I even had a couple weird Slack related dreams, and that is when you know you are spending waaaaaay to much time on it. It even felt a bit Circle to me at times, I related to a lot of parts of that book.

Now my getting down to business routine involves fully closing slack, muting other notifications, closing all unneeded chrome taps, and then putting in the headphones.  How do you focus? Is Slack a time suck for others or is it just me. Might just be my fear of missing out (FOMO) coming into play here too ¯\_(ツ)_/¯

Taking a step back from tactical to focus on strategy

We just got through a full company retreat.  Thinking back over my career, this might be the first company that I worked at that actually did one of those.  I have down team things before, and had all company meetings, but not a full on retreat. It was great to see the entire company come together to work on a common theme, and stop our day to day work to take a step back and look at our upcoming focus from a higher level.  Sometimes you get stuck in the weeds and focus on getting stuff done, you don’t think about the why.

There were some great talks by my fellow employees (the employees were in charge of the programming for one of the days), and one that stuck with me, discussed effective vs. efficient and how one should work first on the effective and then try for it to be efficient. I see this all the time pop up with processes that occur around requesting code changes, deployment strategies or how the business works with IT.  It also made me think back to my first software engineer position, I was an associate at a transaction processing software company. For my first code review I actually printed off my code. Literally onto paper, handed out copies to my product group and they made suggestions, in pen, for the code.  Was it efficient? Not on your life, but for some reason that was how it was done and that was how I was supposed to do it. This might have been somewhat effective, as a learning experience and sharing what people were working on, but was not at all efficient.

When you just focus on your day to day, and getting work done these type of problems just seem to pop up.  They usually start because it was the easiest or quickest way of fixing something. If we don’t take a step back and look at the why, and our long term goals, it is easy to get bogged down in the weeds.