Hacker News Reader

Comment by derefr | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com