I have been wondering if I should plan ahead everything I code in advance since I tend to figure out a program as I go. When I do anything frontend...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
My answer is... YES!
It really depends on context. Am I doing something exploratory, where I don't necessarily know what the end product is going to look like? Then code as you go. You can always come back and refactor later, but for now, focus on getting things to work.
If I'm building something and I know what it ought to look like, then I should try to minimize the refactoring required - take time to design and think through the structure ahead of time.
This is the one way that I see Software Engineering as being different from other types of Engineering... we don't always have to know the end goal before we start building.
Yeah, I think this is one of those things where there are virtues to either and people and teams get misguided if they stray too far in one direction or the other.
In the team context in particular, of course we need ample planning to be effective as a unit, but too much planning dramatically reduces outcomes. In this case I think certain principals need to be in place of the wrong type of planning. You can't just wing it, but you can agree on things which help in the future where too much planning slows things down to a crawl.
pretty cool to see someone admit they just hack through it too - honestly i always end up making tweaks on the fly anyway. you think figuring stuff out as you go can actually lead to better ideas, or does it just slow things down?
Hehe 😁
I have no idea. One should think that a little bit of planning would save some time but I do not know.
for me....
Here’s the workflow I follow:
Use ChatGPT for brainstorming ideas — the what, how, and why.
Start wireframing with pen and paper as soon as I have a rough concept.
Move to Uizard.ai (Figma isn’t my thing) and recreate the wireframe digitally. Then I use Uizard’s AI to enhance it.
Finally, I follow that UI and start writing the actual code.
You can't plan what you've never done before so you must try coding it first.
You perfectly code without planning what you have done many times before.
Hence, you both plan and try coding those partially known.
Based on what works for me, the answer is a decisive nes... yo? Whatever, point is both but neither.
Planning evertything before even writing the first line of code sets you up for unforseen problems that require either a complete redesign or trying to fit things together however you can. Either way, you lose time.
Going in completely blind and just building the program can get you the same problems, just in a different way: the danger there is finding problems only as you get to that part of the program, after you've already built large parts of it that you now need to change.
The middle ground is the way to go: Start writing code, but not as a final implementation; explore the problem domain in code and figure out the fuzzy parts. Then build the real thing and re-use the code that is good enough after some refactoring while re-writing the parts that were only there to support your experiments.
Sometimes this can be done iteratively, sometimes it's a bit more "step by step", but there's almost always a benefit to exploring your options with a prototype rather than as an abstract design.
EDIT: After posting this, I kind of realise this is basically just the same idea Paul Graham described in that quote. I wouldn't have picked "Sketching" as a word for it, because to me it feels more like a process of exploration. Loke walking around and poking at things. Except the "poking at things" means writing snippets of code and seeing how they work out.
as with all things, it depends.
if I’m working on something small, it’s time to hack and slash my way through it. but if it’s remotely complex or I’m working with others, there’s at least 1 flow chart and some breakdown of work (usually using GitHub’s product management tools).
10 minutes of planning up front can save hours of work later
Honestly it's hard for me to imagine all the things I know I'm going to want in my project and how I'm going to do them and it's even harder for me to stick to a static plan, so I mostly start my project with very basic image I had in my head and adopt it as time passes, though this approach of mine is not really that much of a nice one when it's about something like a game dev project, for example when I'm working on a development board, I have a basic image in my head about stuff I'm going to do and I figure how I'm gonna do them and how I can add futures I like when I'm sitting in front of my monitor, but when it's a project like developing a game, since nearly each decision effects over all game quality big time, I wouldn't really freestyle much in situations like that
For me, I live the motto that the data should drive the algorithmic structure, and the algorithm should not drive the data. Esoteric words? Its a belief in interfaces are more important than logic in the long run. So I say, write the code and let it help you "discover" the interface for your data.
When I was younger I would normally plan the rough shape of features in comments.
As I've increased in skill and experience (and age 😭) I found myself planning things out roughly in my head and then implementing as I went.
I don't really agree with planning out in full detail. Usually I find if you do that, once you starting implementing you'll hit some kind of unexpected roadblock or issue that requires a big deviation from the plan, making the plan feel pointless.
I think I do something similar to Paul Graham's method of planning. It kinda depends on what I'm doing though... in other words, if the program I'm working on (likely) won't ever need to be refactored/maintained, I spew more than I plan.
If you think too much, you'll never start—or at the very least, you'll start feeling frustrated.
Just start. The ideas will begin to flow.
From my experience (I'm a front-end developer), for example: I initialize a React project, link it with Tailwind, start with the navbar, then add the footer. Along the way, I realize that pages like "User Profile", "Product Page", “About Us” or legal pages should be implemented too. I draw inspiration from other websites, return to my project, and add a slider. I might notice that the font doesn’t look right, so I search for a better one. As I build more pages, I realize I need routing so implemented using TanStack Router. If I need icons, I install the Lucide icons package or another icon library. I browse sites like UIverse or CodePen for inspiration and sometimes stealing some cool designs, until I find myself fully immersed in the process and actually enjoying the journey without frustration.
I don't particularly like TDD, but I do love some of the philosophies it's built on top of. One of which is the idea of just building your program, one feature at a time. Instead of planning ahead, you go for the most obvious solution, then once you have it working, you can spend some time to clean up your code, and In TDD's case, you'll be leaning on your tests as you clean up to make sure you don't break anything.
The "planning ahead" they're talking about from school is where you figure out the entire project from start to finish, figure out every single feature in that project, and figure out every single class and property you will want to have (using UML), then you build the actual code. Almost nobody does this sort of thing anymore. Classes are too low-level of a building block to be trying to map out from the start.
I still technically do some planning ahead. If I know I'll eventually need something to work a certain way, or be organized a certain way, then sure, I'll make that happen from the start. But for the most part, it's better to let your projects grow organically. If one class or module gets really complex, look for a highly coupled subset of code and extract that out into its own class or module. Organizing a program by "coupled-ness" is the best way to go, but requires the code to first be written so you can get a feel for how coupled different parts are.
There's exceptions. There always are. Just do what feels right to you and don't fret too much about what you think the industry thinks is right.
it depends on the context, and on how your mind works. The more familiar a project is, the I can easily plan ahead at least the next few steps - enough to keep me on track and to communicate them clearly to others. If I'm working on something less familiar, I'll have to make a mess for a while before I understand where I'm going.
None and both, actually your problem is on chosing either evolutionary or waterfall style. So choose non of them, instead use what RUP designers created to choose both.
You need to distinguish between development disciplines and project phases and then take an iterative approach. In every iteration ideally fit in a sprint, which may or may not result in a release, you pass almost every discipline but the product only subtly changes toward final matured product.
In your case, you only identified planning and implementation, but real world projects may identify other disciplines such as test, design, analysis, deployment. Also the projects phases are inception, elaboration, construction and transition.
Also it should be noted that most people think of scrum or other agile methodologies as competitor to RUP, but they are wrong. Since RUP is a meta process model framework, and any agile is a tailored version of RUP. Usually agile replaces modelling as a pre-implementation discipline with mental model of team members build and shared by excessive communication.
Yes and No
For personal development I prefer small development tasks as I find focusing on one big application gets boring quickly, so I do not bother with any project management stuff.
But for work, I map out the applications with a task manager.
When there is $$$ involved, it is very important to track what I am doing.
It is valuable to the team to align with, so they know that has been complete and what is pending. I
tend to use TODO lists, under the hierarchy above.
I think in development it is important to get a good handle on project management.
And the reason I say that is because development gets complex quickly.
Even a relatively small application, when used by 100s of people, expands into a massive amount of work over time and very quickly.
Also a good handle on the applications development results in better work life balance for everyone involved, at least it should do if no one is slacking to much :).
Honestly, I sketch my logic like an artist with messy drafts — planning just enough to not crash the ship, but sailing it as I build. Too much upfront planning kills my momentum. That said, I always regret not diagramming my data flow first 😅
Absolutely, yes!
For me, it's vital to know what I'm going to do. Maybe not in full detail, but having a general idea is more useful than doing something and then having to change it because it wasn’t part of the original plan. It helps me avoid wasting time trying to remember things that could have been documented in the first place.
Plan ahead, of course.
Especially we have AI now.
I usually brainstorm the idea with chatgpt first. Then go deeper with framework choices, folder structure and best practices.
As SRE/DevX, most of the things I write are ugly tools that have no UI. But I tend to write the readme first. And plan and decide things as I describe the nonexistent yet component. Once I have a tool described in that readme that covers my use case and looks easy to understand and use, I start creating what the readme describes. Surely this won't scale for bigger apps, but it suits my flow perfectly.
Two things to consider when working on a project, strategy and tactics.
The strategy needs to be well thought out and planned before even touching a keyboard (what).
Tactics are used when you start coding (how). This is when you "figure out programs as you are writing them".
So the answer is you do both.
It does depend on the size of the task, how many people and systems are involved and how well understood the area is.
In general planning to the nth degree is pointless for pure development purposes but sometimes there are other considerations such as security, safety, licencing, etc.
Only for the simplest and well understood tasks do I find I can commence without plans yet remain on course throughout. Anything more than that and the proverbial "back of an envelope" comes in very handy.
Great question! It really depends on the situation and the complexity of the program.
Planning ahead—like designing the architecture, outlining the main components, and figuring out the logic before writing code—is super helpful for bigger or more complex projects. It helps avoid confusion, makes debugging easier, and often leads to cleaner, more maintainable code.
On the other hand, figuring things out as you go can work well for smaller programs, quick scripts, or when you’re experimenting and prototyping. It allows flexibility and can be faster initially, but sometimes you might end up having to refactor more later.
Personally, I tend to do a bit of both: sketch out the big picture first, then dive into coding while adapting and refining along the way. so yes for me
For me, planning is everything. I always write down what i am going to code a step-by-step guide, like a to-do list for the project. Help with time management and effort needed for the project completion. Add features or fixing bugs is something else.
I don't think you can plan everything in advance, and you have to design as you go along. I'd say, at least for the backend, you have to do a bit of both. You can't design everything on paper, because you can't foresee certain design problems until you've started to implement them.
Totally relate to planning out UI but figuring out the rest as I go - sketching code feels the most natural for me too.
Curious, is there any part you always plan out before touching the keyboard?
Hm. Not that I can recall. Of course, I usually have a general idea but no, coding for the web must be the only exception.
Great question! I usually plan the structure first to stay organized, but often figure out the details and solve problems as I write the code. A mix of both works best for me..
Great question! I usually plan the structure first to stay organized, but often figure out the details and solve problems as I write the code. A mix of both works best for me.
I basically do both
I come up with a small, very vague plan then as I'm coding, I just beat the rough code into shape
Thought it was something only I did
A bit of both actually..
Pretty much the same here, I end up winging it half the time and then fixing what blows up later. Always makes me wonder if strict planning would actually help or just slow me down.
I rather have it hand-drawn and appropriately labeled before I switch on my computer. 💯
Sometimes, coding is more about refining ideas as you go rather than rigid planning.
It really depends on the context. Here's how I usually approach things:
If the requirements are vague, I spend time identifying each detail and potential edge case so I don't get tripped up later. That process can take days or even weeks, depending on the complexity.
Once everything is clear, I try to plan things out—but I’m careful not to overplan. In my experience, things sometimes don’t play out exactly as planned, and spending too much time on overly detailed planning can end up being a waste if requirements change or new insights emerge during implementation.
I avoid jumping straight into coding because, every time I’ve done that, I’ve ended up wasting even more time fixing and refining things. A bit of upfront thinking always pays off.
I don’t believe in the idea that you must figure out an entire program on paper before touching a keyboard. I was taught that way in university too, but the academic environment is quite different—problems are usually well-defined and constrained. When I started working in the real world and was thrown into real-life coding scenarios, it was a shock. I even questioned my career choice at one point. But that was only because I wasn’t used to how dynamic and unpredictable things can be in the industry.
In reality, you constantly adjust—not just your code, but often your documentation and even your initial understanding of the problem. So there’s no single "correct" approach. You move between different methods depending on the situation, with each factor carrying its own weight and priority.
Right now I'm learning to plan ahead before I begin my projects. It takes more time to start but it saves a lot of time in later stages & keeps me sane. I mostly use free AI models to plan out project specs & what modules would be required for the project, of course I have to change those specs later on too as I develop the project, but it's a lot better than losing your mind over code & figuring out what to code.
Almost always: yes. But if it's a small bug or fix, I will just go with the flow a bit more.
I learned this approach from my dad, he was a developer as well. I used to see him writing down notes before actually starting to code. His colleagues would often wonder why, but it turned out that eventually he always wrote better code! It's something I like to call a 'Ticket Checklist'.
Ticket Checlist
Link to Jira ticket
To Do (PCD)
Prep
Code
[ ] Branch workflow
git reset --hard upstream/master(to ensure you have the latest commit from master)[ ] Code (make small commits, What's this about Micro-commits?)
[ ] Testing
Delivery
After test
Prep - Analyse/Requirements
Context:
Goal:
Design:
Scope:
Acceptance criteria
Code steps
Write down all the steps you need to take, make it a small as possible so it’s manageable
Design questions
Analyse the design, ask questions to the designer about interactions, different states (hover, active)
a11y questions
Code & misc. questions (tech, business logic)
Read through the exercise/assignment/ticket properly, make sure you understand 100% what needs to happen.
Understand the data modal (interfaces and types) for the domain you are working in! Communicate with your back-end about what the data models look like. If you understand the model, then you understand the shape of the entire application
Business logic
FE
BE
a11y
Checklist - The A11Y Project
WebAIM: WebAIM’s WCAG 2 Checklist
How to Meet WCAG (Quickref Reference)
How To Do an Accessibility Review | Web Fundamentals
A11Y Style Guide
Links
Anything I found that is useful for the context of the story.
It's one of the things I share in my From Hello World to Team Lead book. Hope it helps!
In fact, in the past two months, I rarely write code by hand. I spend more time analyzing requirements and designing code.
see: dev.to/free_frairy/beyond-coding-t...
i have a problem that i don't know how i planed it
dev.to/zand/from-chaos-to-comfy-su...
Consistency is key in software projects! This style guide is a great resource for developers who want to level up:
rkoots.github.io/styleguide/
YES