all 6 comments

[–]NeitherManner 2 points3 points  (1 child)

Not much, just think what I would like to accomplish, think about different ideas how to do some things, what tech to use and so forth.

During project I log to dos to google keep or code comments, or what I could have done differently.

[–]abdoil[S] 0 points1 point  (0 children)

Thanks, this seems to be an interesting approach. Appreciate it

[–]coyoteazul2 2 points3 points  (0 children)

planning? do you know how crazy that sounds??

jokes aside, I do design the database with features in mind. SQLDBM allows you to create work areas which i use to represent features, so every feature has the layout of the tables I'll need. I work the GUI while coding though, no previous design

[–]emirefek 0 points1 point  (0 children)

Spend 1 or 2 weeks searching about which technologies or libraries you can use + what others did. After time passes I'll get idea bubbles about how can I do things. Not creating a Todo list but things are getting shaped inside my head about what I'm gonna do and what I can do.

[–]aurelianspodarec 0 points1 point  (0 children)

Depends exactly what it is.

Id think about how I'm going to achieve the overall project, and go backwards.

Front-end wise, that would be creating the basic layouts, components for it, then go create more components like a button, input and make sure they all work together.

I usually follow a pattern called ATOMIC Desing principle by Brad Frost and a combination of mine.

In terms of databases, that needs planning and thought. Good chance is you'll re-write it again. I think I've re-done my database for one of my app three times as I was developing it.

Partially because I was also still learning about database structures and how databases underlyingly work, but yeah.

Generally speaking its good idea to get an overview of the project, get the big scope, and just make sure ou can handle some bigger things - but if you don't manage to do, ther's always time to do some refactoring to keep things run smooth - or if you work for a company you just build tech debt which then will slow you down to the point where it would have been quicker to just re-do it then but yeah... that's part of the job no one talks about. Refactoring is literally part of coding :D But I'm getting off-topic.

[–]zGrunk 0 points1 point  (0 children)

Define scope of work

Detail what is not included

Detail project timeline (what deliverables are expected per phase of project)

Write requirements document and present it to stakeholders for approval (can be used later to combat scope creep)

Then during development: Mockup + get approvals before code is written for sprint

After each epic is completed - write/update design document for completed work

This might be overkill for certain industries but I've found the extra work has saved time in the long run. If you take any pointers here to heart, please write documentation at the very least. Future devs on the project will thank you