Things I Learnt from a Senior Software Engineer

I have an admittedly crazy thing I do occasionally. I do 5 minute pomodoros. So it's 5 minutes of writing code followed by 1 minute of reflection. In that one minute, I'll write down what I did in the last 5 minutes (it takes about 10 seconds to write since it isn't much ;-). I'll also add a few TODOs that I'm hoping to do, or break down ones I've already got.

Now, 5 minutes seems an impossibly small amount of time, and admittedly this is a difficult technique. It's also very tiring (I can't do it day after day), but once you get good at it, it's surprising what you can get done in 5 minutes. You don't necessarily need to have written code -- just made some progress towards understanding something, etc.

Later, I'll go over my notes. I've got everything annotated every 5 minutes which means that it's ripe for thinking about how I can improve. Did I make a wrong turn somewhere that wasted me time? Was there a way I could have detected that? Did I decide not to do something test first when it would have been better to do so? Etc, etc.

I should point out that while I have a timer, I only use it as a suggestion -- I don't have any notifications for instance. It's just that if I glance down and notice my timer has gone (or is close), then I wrap up what I'm doing to get to the reflection stage. Similarly, if I'm writing TODOs and it's being productive, I don't mind doing it for 5 minutes or so. Finally, if I run into something really puzzling, then I just turn off the timer. Some problems need thinking time (though I have found that having only a few minutes to make progress often forces me to try something in order to get more information and that will crack the nut -- indeed, far more often than I would have ever suspected).

It's the only tool I've found that really helps me improve my technique. The other pretty cool thing about it is that I've found that this log helps me get in and out of the zone extremely quickly. Even if I've put it down overnight, I'm right back into it within a minute or so.

I am measurably much more productive with this method (like 2 or 3 times more productive), which surprised me initially (I thought I would be much less productive). The real downside is that it's draining. I can't keep it up for more than a couple of days at a time.

Anyway, very dissimilar to what you were talking about, but I highly recommend it for those interested understanding what they are doing and how to improve.

The trick here (and in someone else’s “Thrilla in Mozilla”) is that you don’t need to understand the humor or reference to understand the code. It’s just a nice little bonus, since threader is already a perfectly reasonable[0] name.

This is different from insisting that helper functions in brains.c be of type pinkyfunc_t.

[0] I was tempted to undercut my own point and write cromulent there instead.

I've had burnout a few times in my career. I think it happens to anyone who really enjoys their job. It's like being placed in front of a pile of candy -- just one more piece!

But burnout is an awful feeling. You aren't able to work. For me, I would stare at the screen for hours on end without being able to get started.

I found that 2 things helped me the most. First the pomodoro system. You are probably familiar with it, but just in case: you have a 25 minute session, where you devote yourself to nothing but concentrating on work. For me, it's unbelievably important to get my first pomodoro in as early in the day as possible. I also found that it is just as important that this pomodoro is coding: not reading mail. Not doing a status update. Not having a standup meeting. Not investigating some bug. I've got to write code as soon as I can in the day. That flips a switch for me. Very important, especially if you are burned out: show up for work significantly before your fist meeting of the day -- the meeting will suck the life out of you and you need some life to suck.

The next thing, strangely, is a TODO/log of what I'm doing. Being burned out means that everything is a barrier. Usually the barrier is too high, so you are stuck staring at it with no idea how to get over it (because normally you would just step over it).

When I first start a pomodoro, I write a TODO of what I'm going to do for the next 25 minutes. I find it's best to spend as little time as possible doing it. Just write down the first thing that comes to your mind about what you need to do. Write 3-4 items at least. Then start tackling the first one. Inevitably, you will find that your TODO was not good -- because you didn't spend time thinking about it. As soon as you realise what you need to do, update your TODO and then do it.

It's tempting to write the code and then write down what you did. I find that it works best to do it the other way around even though it breaks the flow. When you are burned out, flow is quite hard to maintain and any distraction is going to grab you hard. By focussing on making sure your TODOs are correct, it means that you can easily jump back in.

The biggest thing to realise is that you will often be punted out of the zone and will be staring at your screen. What you need to do is to say to yourself, "Just one more" -- which means, making an easy TODO for yourself and writing the code to fullfil it. Then "Just one more". Eventually you will get distracted. When you finish being distracted, turn on the pomodoro timer and say, "Just one more".

At first you may find it hard to do more than 4 pomodoros in a whole day. Don't worry about it. Just try to do as many as you can. Then the next day try to do more than the previous day. I have found that I can claw my way out of burnout pretty quickly like this. It doesn't take long before I'm enjoying my work again. After that, the productivity starts coming back and things start to feel easy again.

Hope this helps.

100% with you on this. I find the replies to your comment here remarkable.

Namings should be descriptive not idiosyncratic.

It might be just like the guy I spoke to last month that said he just makes everything public when writing Java. Some people can have opinions that differ from best practice, it doesn't justify them, however.

Express your personality when you speak to people face to face, tell a joke, make witty observations at lunch, or in a code review meeting, don't express your personality in manifest idiosyncracies in your comments and code.

Yeah, I work for a CDN with tens of thousands of machines, and I still miss wac052.mad when we decommmed that POP 5 years ago.