Tips on managing longish term self projects?
Posted by teapeeheehee@reddit | ExperiencedDevs | View on Reddit | 5 comments
I have a generous amount of time to finish up a set of tasks. I'm confident I can do it, tho it is novel for me so there's some ambiguity I'll need to work thru but for the most part confident.
I have like 4 months to finish thesd tasks up. In reality they should take about a month each. Ive always been the type to procrastinate and be motivated to only truly start when it comes down to the wire, but I want to change and become a better and do thing incrementally and ahead of schedule. (plus it would be wish to finish this sooner to give more time for qa and testing and possibly adjust to changes).
So yes it's a lack of discipline on my part. But that aside, does anyone have any tips, advice (mental/prsctical/any advice welcome) on how to start longer solo projects and work on them in a smart, incremental way that keeps me accountable to myself?
polaroid_kidd@reddit
Three things I've learnt (recently)(for a SAAS)
Building the contract first forces you to think how you would like to consume the product you're building. Keep in mind pain points you've encountered in the past and be sure to avoid them. I use the open api spec and generate the swagger docs from them.
Now that you'll know how the api will be consumed, you can Build the DB model in a way that avoids expensive operations. There is no point in having a friendly api if the DB operations behind them take ages when at scale.
For the UI, using Storybook helps you to keep a grasp over your components. It helps you keeping yourself in check when adding new features. Is devs have a tendency to build super reusable components, but the drawback of that is that their usages require larger configurations. You can still build them like this, but Storybook will help you keep sane defaults for them.
I know that these aren't the most fun parts, but because they're the foundation, getting them done early on will set you up for getting the rest done. From their on out it's "just" implementation details.
jrodbtllr138@reddit
I’d break it up into smaller and smaller chunks, and then set up agreed upon release times for weekly milestones.
I still typically procrastinate each milestone, but it’s a weekly procrastinate and build cycle instead of a longer one.
TheWhiteKnight@reddit
Daily scrum updates
uriejejejdjbejxijehd@reddit
Just like in Office, fragmentation is the main enemy. Create time blocks without interruption (and that includes the cell phone and checking the regular websites).
Other than that, you have to be more diligent in breaking down into smaller work units because the blocks of time you have for side projects will be smaller and further apart.
advizzo@reddit
For large solo projects I’d recommend doing some sort of demo at least 1x a month. You need to de-risk the project anyway to avoid bus factor since you’re the only one with knowledge on it.
While you’re developing, in async comms I’d recommend continuously making documentation updates and posting publicly.
Is there any oversight on this project, any stakeholders, any other engineer reviewing the code? Answers to these questions will determine what kind of accountability you need.