You set a goal, and you started. First, you should plan for deadline and when to finish off some feature till 18th of this month. And when to complete the login feature etc etc.
But in my experience, none of my neighbour senior software developers or engineers ever shown/told such know-how or manual.
And I met a mentor, and thanks to him: this is how I defined my manual to do the project.
Disclaimer:
- This cannot be like an absolute answer. We all have a unique style.
- this may be full-stack version.
When I start developing a project (Version August 2023):
1. Define a topic.
- It will motivate you, and it is your ultimate goal.
2. Scan/define list of features
- This does not have to be tech related words to describe. In my case, I define a list of features (e.g., authentication (signin, signup, remove account).
3. Scan for tech lists to achieve its feature.
- This step, I matched up with #2. For authentication: https://stackoverflow.com/questions/38635092/how-to-create-json-web-token-to-user-login-in-django-rest-framework
4. But choosing an 'easy to understand/apply on your project/code' is always good.
Mistake I made. To make a decision at this point, this is the time to search for some similar examples. At least how someone used it.
For example, rest_framework_jwt.views.obtain_jwt_token.
You got the keyword. First, search exactly how it shows. Then from the url I mentioned at #3, one of respondent emphasised 'token'.
rest_framework, jwt, token = User/Authentications
Be patient: To make this, I should understand how token works and so how it allowed sign-in feature to work.
5. Searching for some similar instance that someone already did.
Mistake I made. From non-CS degree's perspective(?), I still have some paranoia that 'copying is not good'. I often start on my own, and did not really searching for other's work. Or I could say: I had no clear insight like how/what to search for.
Although you can do so, but still referring other's work first will protect you to get stuck at some point.
One more thing, I will mention this at #9 but I recommend you save some 'easy to achieve blueprint' if some feature looks challenging. I am not sure how other senior level software engineer would comment about this line, but still: I would have some insurance - just in case.
6. Use draw.io to organise your plan.
Mistake I made. This is my thought but I would not start making this unless you have done the step #5. Once you have some vision to remind them of, then you may do this step.
7. Make a simple EDR.
Mistake I made. This is the step I often felt hardness. But now, I can say: this should be the last step to make it in your planning. As drawing diagram was also to have some insight about the project (when it gets bigger scale), this clearly define you what to create.
I always feared to make this. To do this, I believe I should do this when I am still planning on it. This doesn't look like the phase to make it once you finished the project.
8. Keep checking your progression speed with Kanban.
This one does not have to be special or professional. But I used Kanban management tool on github's project tab. You may not believe 'do I need it?' but my answer is yes. This will help you much especially when the project scale or its length is larger or limited.
9. Try not take longer than a week.
Mistake I made. In my case, I already feel exhausted when I get stuck at some point. But as a non-degree developer, I realised one fact. This software development as a business is more like time.
Still, I strongly believe that I should NEVER give up the quality. In the end, it would work like karma. However, you should equip one confident blueprint to achieve a feature - this is for your worst-case scenario. You should at least have one insurance.
10. Finally, if you stuck longer than an hour, then searching for another example.
As a junior level, I do not think I ever attempted using Rust language all of sudden to my project. It may look amazing but what is the point if you cannot make that feature in the end?
I believe these are the most stable step-by-step manual.
Extra.
Mistake I made. This is quite a personal issue but I finally decided 'I should have separate repositories for client and server'.
In my recommendation, just go for a split-version.
For example, if you have both client and server folder in the same root folder - this may look stable. To describe, some people hate using styled-components and rather using a separate css file instead. Yes, this is where I made a mistake. I believed that 'not using a popular stack to achieve a feature' may look like I am staying behind the industry(?) standard.
Not always. So now I always searching for 'if I do not use styled-components, will I be seen as out of date(...) developer'? At least for this client and server repository issue, the conclusion was 'it really depending on your preference'.
It is really your choice. But personally, I would say just don't work on a single repository. Unless you do that for learning purpose, don't.
Top comments (0)