Comment by varjag | Hacker News Reader

Comment by varjag | Hacker News Reader

I think it's a common pattern, only perhaps the magnitude is worse in your case. I observed it on myself as well on other programmers back when doing a project management stint.

What helps me personally is having a notepad where I jolt down TODO items, to the most atomic level if possible. To give an idea what's on it here now:

  - probe for activity on the I2C bus
  - find the SIGCHLD problem
  - remove rectangle in the logo on web interface
  - follow up to a customer on his RFI

I.e. tiny bits of work that do not present much challenge separately, yet are actual, necessary things to be done. No deadlines, priorities, long descriptions, etc. No grand items like "add feature X" or "do complete test coverage". They are easy enough that I can complete at least one (but usually a bunch) in the day, and strike it out. Each time you do that, there is a modest tingle of gratification, so it helps to maintain working mood. Also, looking back at the list of completed items is reassuring.

That's exactly my approach. I spent a month on a project not really getting anywhere, putting things off and moving things 2/3 pixels in CSS code doing "work". I then bought a whiteboard, itemised in root-level terms the tasks I needed to get done, how I would achieve them, and then crossed them off when done.

I not only felt accountable to myself, but as I work alone, friends or family visiting me would ensure my checklist was being ticked off and ask questions on specific points ("why haven't you done that?" "because XYZ is taking longer than expected" etc...)

The list makes you answer questions about how you'll tackle the problem, it also allows you to think without staring at a screen which is beneficial.

I've had a lot of success with the pomodoro technique. You start with a todo list for the day and then do work in 25 minute chunks with 5 minutes off in between each chunk. I've found that giving myself those 5 minutes of time to deliberately not work makes it much easier to actually focus for the 25 minutes when I am working. It also forces you to look at what you're doing every 25 minutes so you don't head of down rabbit holes.

When you know you need to "add feature X", what do you do? Write "itemize feature X" on your list, and then, when you come to it, sit there and think of a list of things to replace it with?

When you get to that point, you need to get input from the people that you are coding the feature for in the first place. Have a productive meeting with your manager to discuss what they want for feature X, for example. Then the more atomic parts of the todo list should become clear-er.

No, I don't do any meta stuff in the notebook, that would be silly. It's not a progress report, development plan or a Gantt chart. You don't show it to your peers or supervisors, you don't need to decieve anyone with it. The main purpose is self-accountability and keeping (loose) track of the things you need to approach. Micro-managing myself, so to say.

If I need to add a feature, I just come up with first obvious things that have to be done, and expand it as the problem works out or new circumstances arise. E.g. I had to add a protocol support (Modbus TCP & UDP) to the product, the list ended up like this (editorializing a bit):

  - get green light from the manager
  - read the spec for minimal conforming implementation
  - implement conforming request parsing
  - implement register read command
  - add application-specific bit X to a register
  - add application-specific bit Y to a register
  - implement UDP recv/send loop
  - test UDP part
  - implement TCP listener
  - test TCP part
  - fix zombie issue with TCP handler
  - test TCP part
  - build of product with the new feature
  - test the build
  - test the build vs real PLC

Perhaps everyone has at least some ideas what you should do when you begin on chunk of work X, so you just write them down, no matter how trivial.

Itemize feature X is often very difficult. Instead of itemizing all of feature X in one go, just figure out what the next item is that needs to be done to move towards feature X and write only that single item on the to do list.

That's programming. Recursively specifying problems until they're defined unambiguously in terms of solved problems. When you've reached the level of the features of your language and tools... that's your program.

Thinking in terms of "add feature X" is not breaking it down enough. No feature is an atomic piece of code...if it was, "add feature X" would be enough to implement it and you would be done. The trick is to keep breaking down "add feature X" until you have a list of todo items that are close enough to code that they are then trivial to implement.

Its organized, efficient, and it works. And its masking the problem. You don't really want to do any of that - you want to be doing something meaningful and important.

So yes you can train yourself to be a wonderful cog in somebody else's machine. But consider the other advice here: find a better project. You have never actually been in charge of your career until you took a job that paid Less, because the project was better.

Reply on news.ycombinator.com