How to develop code optimally
Did you find yourself fail to meet the commitment you give to your superiors? I did, and I guess I’m not the only one. It is not a very pleasant feeling.
And I thought: “Dude, I feel there is another way”. “It doesn’t feel to do a lot with your technical skills, it something different” (sure, better technical skills usually leads to faster development, but not neccesarily to a higher rate of meeting commitment), and I found myself wondering about ways to improve the process of specs/requirements -> commitment -> develop
Gradually, and with the inspiration of the book “The Pragmatic programmer”, I started to realize that the phenomena of not meeting the commitment (deadline, buggy feature, etc…) is mainly about one thing: focus.
- “product focus” — in my perception, there are three main things you should always keep in mind when you are developing: the feature, the deadline for it, and a clean codebase. you might not meet all of them, but they should always be in mind so you can decide what are the trade-offs you want to take. and hence:
- “prioritization focus” —try to prioritize each task, subtask and spec in your development process, be ready to be flex/agile to be able to easily change your implementation planning
- “physical focus” — clean and organized physical environment and development environment (I, personally prefer the attitude that offered me by my former team leader Roi Ronn to try to keep maximum 4–5 tabs in the browser and in the IDE (most of the time 2–3 tabs are enough in the IDE), close all the unused windows, etc…). dedicated time for development without distractions (try to make a “micro-commits” to yourself that is a concrete destination to achieve in a range of about 30 minutes to 2 hours and try not to stand up from the chair/do another actions until you finish the micro-commit)
- “subtask completion focus” — breaking your task to smaller subtasks would probably give you a greater sense of control over the task. you will have a more detailed program of how to fill the task, you will have a more detailed schedule, you will have a more frequent better feeling and Dopamine secretion each time you complete a subtask, that will motivate you to continue the development.
Now I would like to offer a proposal for the developing process methodolgy:
First, we need to fully understand the specs and the use cases of our feature, why do the customer needs it, what do they want to do with it, and how they are gonna use it
Then, we are going to set deadlines and compromises if needed — for example: if the clients want the feature two weeks from now, and we estimate we doubt if we can deliver it on time. Then we can start talking about taking a technical debt or (temporarily) simplify the feature a bit (after reflecting it to the client and getting his acception).
Same at the process of the development itself, if we encounter option to do things more elegant, clean, readable, scalable, etc… we must estimate the “worst scenario effort” needed to implement it (we should practice in knowing ourselves) and if it seems too much, we would probably need to first implement it in the simpler and less elegant option, and save the improvement/refactoring to the end, if we will have time.
That’s it for now, the approach I offered is suited to my personality, and naturally, there are probably people that will argue on some of the tips. However, I believe that at least some of the ideas and practical tips would inspire some people. I hope you find some useful ideas/practical tips in this article
Good Luck!
