I’ve been rewriting this one in my mind for over a month now. At first, this was going to be just my thoughts on the Scheduling chapter of Algorithms to Live By, but I was not content with it. Actually, I was very disappointed with this chapter.
Algorithms to Live By?#
I hoped that chapter 5 would help me solve some of my longstanding scheduling/priority/focus problems, but there’s just nothing there that I could use. I’ve read better tips on random blogs and articles on the internet. It only briefly mentions techniques like pomodoro, treating them as nothing more than reductions in context switching. There is a lot more to it than that. How about flow? How about low and high energy states? I’ve been trying to figure this out for years. According to the book, it doesn’t really matter what order we do things in, because they’ll all take the same amount of time. Wrong!
It’s been driving me crazy. There’s more to it - so much more. The book seems to say that if we just act like computers, following the algorithms, we’ll be able to solve tasks optimally. But we’re not computers. We’re not machines. It’s vast over-simplification. Actually, this book should have been written the opposite way: How to program the computer algorithms based on how humans solve life problems! So… other than the idea of priority reversal, I found nothing useful in this whole chapter. Actually, I read up through chapter 9 already, and I can’t say that there’s much else worth reading. Maybe a bit in chapter 7 about overfitting, but most everything else is basically this: we found a great algorithm to solve this problem, and we did a study on humans to see how well they performed, and they did about as well as the algorithm, naturally. So, what’s the point of knowing the algorithms if you already naturally know how to solve these problems? Better to be just a book about algorithms alone and how to solve complex engineering problems with them.
On to the small bits of knowledge and experience I’ve gotten. I wanted to wait and compile this into a complete collection, but I’m still human, and I’m still learning and growing, and I think that this may never be complete. Writing bits of it is better than nothing, though.
I thought this was a cheap gimmick when I first heard about it. I only actually tried it when Nikola suggested it. Hey, it actually works. Giving myself 25 minutes (+-5) to work, then 5 minutes break throughout the day… it just works. I don’t know why it works. I made a little script to turn off all my instant messengers during pomodoro time, then turn them back on for break time. At Teltech, it’s usually acceptable to be away from Slack for 25-30 minutes at a time, so this actually works pretty well here. I get a decent amount of work done, and the breaks keep me from getting stuck on a problem too long. Doing about 8 pomodoros in a day (4 hours of straight work) is a pretty decent accomplishment, if you can manage it. A lot of other things don’t fit in pomodoros, like meetings (typically 15 or 60 minutes long), and ad-hoc slacks (hey, can you help me fix this thing real quick?). I just can’t see doing a pomodoro during a slack conversation or a server outage.
|Teltech has a very good engineering and work culture, in my humble opinion. We work hard to keep this culture, manage expectations, and reduce interruptions.
Now, pomodoro works, but I dislike it. I don’t fully know why. I’m happy with the amount of work I get done with it, but I don’t enjoy doing the work as much during pomodoro. It might be too much structure for me. It might be that I like to lose myself in my work, just deep coding for 3-5 hours straight sometimes. Or maybe I like having the extra space to breathe and think. But not doing it opens me up to notification distractions, slack and otherwise.
Maybe it’s best in moderation. Maybe do 4 pomodoros a day, and flex for the rest of the day? Or maybe use pomodoro for some tasks but not others. I’m also thinking maybe I should just ditch pomodoro and run my instant messenger kill script on a timer. Let it do a pomodoro-based thing for me. The main thing is I need a timer to turn slack back on, or I might just be missing-in-action for several hours straight by accident. I just won’t remember to start slack up again on my own…
Speaking of which: Slack needs improvement. It really needs improvement. I’m not talking about the high CPU usage or how much RAM it gobbles up. Yeah, it’s excessive, but it’s tolerable now on a high-end machine. What they really need to fix is the linux systray icon. It has 3 modes: plain, blue dot, and red dot. Plain mode means you’re caught up. Red dot means you got a direct message or a mention. Blue dot means you got a message that’s not a DM or mention. I hate the blue dot. Kill it with fire, Slack! I’ve asked for the option to disable it several times in the slack feedback. They just tell me that it’s not on their roadmap (Ugh!). I have such a hard time ignoring that stupid dot. Whenever my mind wanders a little bit, it’s like "Hey, a blue dot! I must know what somebody posted! It might be interesting! It might be a work-related question that I can answer!"
No, brain! Stop! It’s going to be a silly link in the random channel… Too late, I’m already distracted.
So uh… the workaround to this is to mute unimportant channels. So, I mute random, game discussions, and all the other watercooler-style chatrooms. But hey, now there’s a new problem: I can’t see when there are new messages in these, so I check them repeatedly by habit. It’s even worse! Solution: click the 3 dots next to "Channels", then "Show", then "Unread channels only". Now I can see which channels have unread messages (muted channels will appear when they have an unread).
It kind of works. It’s not as good as being able to disable the blue dot, though. Oh, and @mentions are a bit weird in muted channels. I think it disables the notifications for some reason, so now I won’t get notified for urgent things in important channels… so I can’t mute the important channels. But then I’m back to the blue dot for every message, regardless of urgency. Time to try out an alternative Slack client again… Weechat has a decent slack plugin, but it’s terminal-based, so the UX is tricky, and there are no link previews or inline images. bleh…
And then we have the @here announcements. For some reason, @here became an announcement mechanism. 90% of the time I see it used, it’s to say "hey, you should read this at some point". Many times the @here in general channels is to say "check your email". I guess email has become so polluted that many people never check it? I usually check it at least once or twice a day.
I tend to think @here is for urgent things, like anything between the servers are down and customer support calls are flooding in, or there’s a nasty bug in production. Each channel in Slack is different. The general rule I follow is to disable @here notifications the first time I get an @here that doesn’t require my immediate attention. Today, I realized that I’ve muted @here notifications in almost every channel. I get direct @mentions and DMs when something actually needs my attention, anyway.
I haven’t found anything written about this before, so I’m not sure how many others are like this. Essentially, when I’m feeling full of creative energy, I like to work on writing new products and features. After I spend enough time on that, my creative energy gets drained, and then I’m at low energy. I can try to write new features in this state, but it’s slow going. Instead, I work on fixing bugs, cleaning up code, writing documentation, and refactoring. I do this until I’m back in a high energy state again.
This does not work well with sprint/scrum structure. Even scheduling tech debt items doesn’t really work, because it’s hard to predict when I’ll be at high or low energy. I find that I don’t really work well with the sprint structure. That might just be me, though. Lots of published research and articles tend to say that scrum and sprints are the way, and we should all be doing them for maximum efficiency.
In my quest to increase my personal productivity - essentially, the amount of useful work I’m able to accomplish in a day/week/sprint/quarter - I read through all kinds of tips on how to optimize and maximize productivity over several years. Eventually, I found a blog that says this is wrong. It seems the blog is down now, though. Maybe I should have saved it to disk.
Anyway, it says that we should not be trying to squeeze every bit of productivity we can out of every minute. This is counter-productive. Having time to think and breathe is important. Especially as creative professionals, we need to let our brains rest and process things. Stop trying to maximize productivity; we’re not factory workers. Those who appear to be doing nothing are actually getting a lot done, mentally.
This one’s tricky. I’ve got a miniature boss-man in the back of my head, and he’s constantly active during work hours. He reminds me that I should be working constantly throughout the day. He causes me to feel like I’m rushed even when no one is pushing me or waiting for me. Sometimes, when I want to relax and solve a work problem, I do some programming after-hours. It feels nice to code without pressure. Maybe this is part of being a workaholic? I’m not sure. I’d disable the boss-man if I could. Maybe I should. It’s silly for me to push myself to "do something" or keep a constant stream of some sort of activity when that’s not my job. My job isn’t to look busy, it’s to get work done. Completely different. Gotta unlearn this habit, somehow.
Maybe it stems from working in a startup that had all the devs in a glass room with the CEO’s desk on the other side of the glass? But it feels like this goes deeper, somehow.
As of this week, I think I’m getting a bit better at this. When I feel a bit overwhelmed, I just go for a short walk or jog. I also keep a log of the things I do during the day so I can remind myself that I am getting things done. I tend to forget what I accomplish or work on because everything in my brain is compartmentalized. If the last thing I work on is code, I might forget that I spent an hours handling HackerOne reports, writing documentation, reviewing pull requests, helping with a tricky Go problem, etc. I just think "but I only got 10 lines of code written today". So, the log helps. It’s just a simple tab-delinated text file where I list out everything I worked on. Sometimes I write how long something took.
Like I said, I’m still figuring this stuff out =). I’ll probably write more as I learn it myself. Or maybe I can write a book about it? I wonder if I have the ability to write something that large.