Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
dakkarant911290di generally dont start working until i have a visual/ux design
vintprox1962290dLet the code do talking for you - even remind you of something you forgot.
Take the most fitting approach: components for separation of concerns, or start with sketch in Figma and extend upon it (not free).
If you've got a business process to describe, best bet is BPMN diagramming (using any bpmn.io-based editors).
Also, one could start with TDD because of the same struggles as yours. It isn't fast at starters, but it's worth it when your application's development jumps into agility.
bahua13262290dI list out requirements and functional arrangements, until I like how the backend looks. That's the part that gets my attention. Making it pretty is not my farm.
SortOfTested24535290dI put my fingers on the keyboard, get comfortable, take a nap, and my muscle memory writes the code while I sleep.
1001101112825290dI started thinking about it just now, and two things popped to my mind right away: I really couldn't say, and it depends.
I think you're wokflow is going to be very different it you're a freelancer, or developing solutions for external clients to being a developer in a company mainly maintaining and improving upon existing products. In the latter case you're definitely bound to certain company policies, e.g. a common UI/UX design framework/palette across products and whatnot, or even just being tied to a certain cloud provider... whereas side projects, again, are a completely different animal.
At work we do kanban, so I basically just pick an issue that's either assigned to me or free for grabs and start working on. I know our products pretty well, so it'd pretty straightforward all in all... with side projects the design phase gets easier project by project. Nowadays I like to draw a picture clear as possible in my head and jot down the specs and reqs as clearly and precisely as possible, so that I can just basically start wherever I need to. I usually write the necessary boilerplate first if I know I need it and then start writing tests and proceed from there. I usually like to go backend first, and work from there, but it depends.
It seems it doesn't really matter how well the app has been planned, however, as brainfarts happen and some things may work differently than anticipated or some specs change or whatever - refactoring seems to me a necessary phase of development. And in the end, I like to clean up any mess that I may have left behind and optimize as much as I can.
IntrusionCM6262290dIn the end, there will always be a phase of polishing and fixing up things.
Project planning shouldn't be fixed, as in "only do that and be done".
It's valid to collect things that should be changed / must be changed.
But - finish first if possible.
Stick to the plan - when you realise that some "unknowns" or critical things make the plan unrealistic, it's fine.
Redo the planning based on your new knowledge, communicate that to everyone and it's fine.
TLDR - A plan can be wrong, announcing a new plan is always a last resort.
Otherwise - finish first, collect and fix later, so you don't run in the trap If never finishing
scout2995289dHave to have a plan, otherwise I can’t find the confidence to go on
PaszaVonPomiot168289dI design core principles first and that has to be good.