What is your development strategy?

Question

Hello HN, what is your development strategy?I am a relatively experienced hobby developer who recently joined the workforce. In one of my recent projects, which as a small solo project, I noticed that I was not putting in my best effort when it came to the quality of my code and work. I was so focused on the hand-off that I forgot some parts of the main feature, which ended up not working.My question is: how can I prevent this from happening again?Do you use lists or mental models to remember the main objectives? And how do you assess your own work to ensure that you didn't miss anything?

codingdave · Accepted Answer

There are many ways to approach requirements, how to document them, how to manage them, break them into work. You'll get a thousand opinions of how to do this, but this sounds like the key you are missing - a list of required functions. It doesn't matter too much where you document these, just that you do document them. Later, if you can perform those functions in the app, it works. Otherwise, it doesn't.
Personally, I like the approach of documenting requirements from the end user's perspective. Most organizations have landed here, in my experience - Start with the customer, define their needs, document what they need to do, what steps they need to take, what they put into the system, and what they get out.
Then go deeper to design and code technical solutions to those requirements. Break it down into workable chunks, and work one piece at a time. You can put aside the big picture while working a specific task, but once it is coded, step back up to the big picture and test the product as the user would, actually perform the tasks as they would. If the tech work you performed matches up with the user-based requirements, you should be good. From there on out, iterate and improve.

PaulHoule · Answer

The worst term in the software industry is "bug tracker", really you should call it an "issue tracker".
You should use some tool like GitHub Issues, JIRA, or one of many others to break down all of your work items. This fits into practices like
* Kanban: there are a limited number of outstanding tasks you can handle at once, if you are allowed to have N items running at once (my current employer has N=1!) you can't start more than N items and have to finish one before you start one. I've seen the same practice used at cafes, where they don't take a new order unless they have space in their queue.
* Estimation: Once you have tasks enumerated you can estimate the tasks and then add the estimates up to get an estimate for your project
* QA: you can have another person check each feature you work on as you complete it if you have your features all enumerated.