How do you break ground and start making progress on a big coding task?
How do you take the first steps in a daunting and complicated software project?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (8)
The first thing is I do not fool myself into thinking that I am going to be coding anytime soon. Having started coding too soon many times in my youth, it always led to a great deal of pain later. When I have taken the time to fully understand the problem and develop a comprehensive implementation strategy, it not only turns out better, it is a much better experience for both me (my team) and my client.
For me, the most important thing is understanding the problem. I spend a fair amount of unstructured time thinking with sporadic efforts to write a statement, a few paragraphs, that say what I am trying to do. If there is someone who cares, I show it to them and discuss it. It is never going to be exactly right or final but I keep going until I feel like I have written something profound.
Eventually, I want to get to work... still no coding. Long ago, I found that it is tremendously useful to document the components of the problem. Since I almost always am working on web tools, I start with a list of people who will use the system and then what each of them will want to accomplish. As much as I can, I try to actually find one or two people to represent each user and work with them to fully understand each user story that concerns them.
Having a comprehensive list of users and user stories, I like to focus on what information is being managed for each of them. This becomes very granular and lots of user stories will want to refer to the same information. I have found that it is important to include the redundant information. Eventually, though, after having worked with any users I can find to confirm completeness, I extract a list of unique facts the system needs other than manage.
At this point I do stupid pencil sketches of possible UI tools for each user, never, at this point, trying to make them consistent or efficient or combined. Just a visual expression of what the user story might look like on screen.
While doing that, I also start thinking through the database schema. I sort the data elements into categories and think about relationships. I like to do this in pencil on paper. This forces me to rewrite each element's name every time and that encourages evolution in the naming scheme that is very helpful. It is also easier to draw a long relationship like around the edge of the page when you realize that should happen than to use a computer tool. I am never satisfied until the diagrams are fairly pretty. I find that attractive, well organized entity diagrams make much better databases.
Of course, all of this should be shown to/collaborated with anyone else who will listen. If you can get your bosses/colleagues to listen to you, make a formal presentation with slides and stuff. Creating this explanation will improve your understanding of the task tremendously. It will also give you way to inform others so that they can help you out. Never be defensive. Always seek criticism. Be very flexible.
After that comes choosing the tech and organizing the programming effort. I sort of do what I just described but about the technical details instead. I am a big fan of thinking before coding. Make a prototype if you are doing anything unusual.
I have had a few occasions in my career to start a green field project that was expected to take a year or two before production. Being very thorough and patient up front will improve your life infinitely.
I typically try and break it down into smaller chunks wherever possible, first of all in a bullet list and/or diagram. Once I start to see the components involved, I then try and further break each of those down, just to the point where I know enough to start spotting obvious 'gotchas'.
I like to build little POC (proof of concept) versions for the more complex parts as well, since it can really speed things up when you come to do the 'real thing' later on. The danger is of course that the POC ends up in production 😅.
It helps when I can see some progress, so early on I try and get to a point where something works and is demonstrably part of the way there.
So basically start with some high-level part that changes, even if the inner-works still have lots of work to do. I find this better than starting with some underlying logic which doesn't feel as close to finish.
In a ideal world, I start writing ::
.... until
like this (dev.to/pengeszikra/wannabe-js-fram...)
If we talk about whole project, tackle the hardest pain point FIRST. Do NOT work on authentication, infra etc until you solve this one problem.
Start with a prototype of the Minimum Viable Product. Break it down, build it up piece by piece. Just get started :)
Avengers, Assemble!
I have a cold beer 🍻 with an LLM