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, I plan how I want the CSS image or the web page to look like before I even start to code though but apart from that, I pretty much jump into it right away. I admit it would probably have saved me some time if I had just sat back and planned out the desired outcome more before I started coding.
Here is an interesting excerpt on the topic from Hackers and Painters by Paul Graham:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
Do you follow a particular structure while you code? Do you plan ahead or figure out programs as you are writing them?
Top comments (45)
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.
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
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
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.
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more