checklist.txt 📋

Intro

A checklist is a useful tool emplyed by professionals in many industries - not so much by programmers tho. We mostly automate tasks yet we still do quite a bit manually relying on our memory and experience. One of those tasks is thinking.

As studies shown memorized checklist is as good as having none:

The use of memorized checklists was similar to not using any checklist at all; hence the use of written checklists should be encouraged, instead.

In an attempt to improve quality of my work I started this project which aims to gather things which we should not forget to think about while developing software. The list does not provide any instructions on how to complete any of it's tasks - as it's not a manual:

It differs from an instruction manual or operating manual in that it does not normally provide details on how to perform the steps, as it assumes that the operator is competent and familiar with each step.

There is also no particular order to the items - the numbers are just for ease of reference.

So here you go and good luck to you pal 🫡

Programmer's checklist

  1. Do we really need this?
  2. Can I remove this?
  3. Can I make it simpler?
  4. What will/can change?
  5. What is the min, max expected value?
  6. What is the most common expected value? Can it change?
  7. What will happen on boundary values (0 - 65535)
  8. What will happen if there is no value?
  9. What will happen if value is really big or really small?
  10. Can the equation overflow the type?
  11. What are the usage numbers?
  12. How many users we expect? Will we have more?
  13. Are these distributed uniformly? (in time and space)
  14. Can I batch the operations? Process many at once?
  15. What are the assumptions? Are there any hidden ones?
  16. Can I assert those in code?
  17. Can we change the assumptions to make the code simpler?
  18. How to test this? Will the test be actually useful?
  19. On what kind of hardware will it run? Which platforms?
  20. What are the priorities?
  21. Are there any low hanging fruits?
  22. Have I handled all possible errors? Is there one more?
  23. How can I limit errors in the first place? Maybe change assumptions?
  24. Design it with maintenance in mind.

    Time spend on implementation is always shorter than the lifetime of the code you wrote. So it's only logical to spend a little more time on better and simpler implementation which will help you with troubleshooting, modifications and have less bugs in general.

    This is not only smarter but also way cheaper in the long run.

more to come...