Do You Plan Ahead or Figure out Programs as You Are Writing Them?
Anita Olsen

Anita Olsen @anitaolsen

About: Greetings! I am a retired hard of hearing hobbyist coder 😊 I am into learning new things, finance, reading, writing and playing video games.

Location:
Norway
Joined:
Oct 27, 2023

Do You Plan Ahead or Figure out Programs as You Are Writing Them?

Publish Date: May 27
67 49

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?

Comments 49 total

  • Ben Link
    Ben LinkMay 27, 2025

    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.

    • Ben Halpern
      Ben HalpernMay 29, 2025

      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.

  • Syakir
    SyakirMay 27, 2025

    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.

  • SamuraiX[13~]
    SamuraiX[13~]May 27, 2025

    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

  • Nevo David
    Nevo DavidMay 27, 2025

    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?

    • Anita Olsen
      Anita OlsenMay 27, 2025

      Hehe 😁

      I have no idea. One should think that a little bit of planning would save some time but I do not know.

  • Raz Devra
    Raz DevraMay 27, 2025

    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.

  • Jake Lundberg
    Jake LundbergMay 28, 2025

    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

  • Dotallio
    DotallioMay 28, 2025

    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?

    • Anita Olsen
      Anita OlsenMay 28, 2025

      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.

  • Carlos
    CarlosMay 28, 2025

    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.

  • Dennis Lee
    Dennis LeeMay 28, 2025

    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.

  • Nathan Tarbert
    Nathan TarbertMay 28, 2025

    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.

  • Oscar
    OscarMay 28, 2025

    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.

  • Ayoola Kitan
    Ayoola KitanMay 28, 2025

    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

  • Deividas Strole
    Deividas StroleMay 29, 2025

    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.

  • Deividas Strole
    Deividas StroleMay 29, 2025

    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..

  • Tracy Gilmore
    Tracy GilmoreMay 29, 2025

    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.

  • free fairy
    free fairyMay 29, 2025

    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...

  • Tim Lorent
    Tim LorentMay 29, 2025

    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

    • [ ] Go through guidelines of project (if they are there)
    • [ ] Read through your code commandments (rules you want to follow while writing code)
    • [ ] Make analysis & requirements
      • [ ] Check if the BE is ready, is the API production ready?

    Code

    • [ ] Branch workflow

      • [ ] Fetch upstream, checkout forked master, merge upstream master in forked master
      • [ ] Create new branch
      • [ ] git reset --hard upstream/master (to ensure you have the latest commit from master)
    • [ ] Code (make small commits, What's this about Micro-commits?)

      • [ ] Step 1
      • [ ] Step 2
      • [ ] etc.
    • [ ] Testing

      • Avoid testing implementation details
      • [ ] Network and/or CPU throttling: check if UI works as expected
      • [ ] Write tests
      • [ ] Test manually
      • [ ] Check a11y

    Delivery

    • [ ] PR
      • [ ] Check acceptance criteria before you open a PR
    • [ ] Change status in Jira
    • [ ] Delete branch after merge

    After test

    • [ ] Make changes to code if tester finds any bugs or issues

    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

    • DevTools: Lighthouse, axe, Wave, a11y insights, ARC

    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!

  • Imoh Imohowo
    Imoh ImohowoMay 29, 2025

    I rather have it hand-drawn and appropriately labeled before I switch on my computer. 💯

  • nadeem zia
    nadeem ziaMay 29, 2025

    Interesting to read

  • nadeem zia
    nadeem ziaMay 29, 2025

    Good information provided

  • theScottyJam
    theScottyJamMay 29, 2025

    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.

  • JoseP
    JosePMay 29, 2025

    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.

  • حذيفة
    حذيفةMay 29, 2025

    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.

  • Joao Dalbem
    Joao DalbemMay 29, 2025

    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

  • Micah Condon
    Micah CondonMay 30, 2025

    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.

  • АнонимMay 30, 2025

    [hidden by post author]

  • Johny Snow
    Johny SnowMay 30, 2025

    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.

  • John R
    John RMay 31, 2025

    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.

    • Brake the application into major sections, for example, frontend, server-side.
    • Create sub sections underneath each major section.
    • Mark completed tasks off as development progresses or add extra TODOs to resolve a blocker.

    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 :).

  • АнонимMay 31, 2025

    [hidden by post author]

  • Elise Gibbons
    Elise GibbonsMay 31, 2025

    Sometimes, coding is more about refining ideas as you go rather than rigid planning.

  • АнонимMay 31, 2025

    [hidden by post author]

  • Rong Tao
    Rong TaoJun 1, 2025

    YES

  • Devops Kiponos
    Devops KiponosJun 1, 2025

    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.

  • Shahed
    ShahedJun 1, 2025

    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.

  • Giorgi Kobaidze
    Giorgi KobaidzeJun 1, 2025

    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.

  • Charles Koffler
    Charles KofflerJun 1, 2025

    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.

  • T-Roy
    T-RoyJun 2, 2025

    i have a problem that i don't know how i planed it

  • ShatilKhan
    ShatilKhanJun 2, 2025

    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.

  • Adobe Holly
    Adobe HollyJun 2, 2025

    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 😅

  • АнонимJun 2, 2025

    [hidden by post author]

  • 𒎏Wii 🏳️‍⚧️
    𒎏Wii 🏳️‍⚧️Jun 2, 2025

    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.

  • Juliet Cross
    Juliet CrossJun 2, 2025

    CERTIFIED ETHICAL HACKER FOR HIRE IN FRANCE VISIT FUNDS RECLAIMER COMPANY

    I originally hail from the enchanting city of Paris, France, but I have spent the majority of my life in the United States, diligently striving to earn an honest living. On April 21, 2025, I encountered a post on Red note that piqued my interest regarding the potential for profit through cryptocurrency trading and bitcoin mining bots. The allure of generating passive income was irresistible, prompting me to explore new financial avenues. I reached out to a team that initially appeared credible. They presented their terms with clarity, and after careful consideration, I decided to take the plunge, investing a significant sum of $223,500 into their Bitcoin mining bot my optimism quickly turned to disillusionment. Each time I attempted to access my funds, I was met with a barrage of excuses and requests for additional payments to cover various fees and taxes. As weeks passed, it became painfully clear that I had fallen victim to a scam. The initial excitement I felt morphed into frustration and despair as I watched my hard earned money slip away. Although I am not one to surrender easily, I felt utterly hopeless and ensnared in a predicament I had never anticipated. It was during this tumultuous time that a coworker mentioned FUNDS RECLAIMER COMPANY. Initially, who wouldn’t be after experiencing such betrayal? Yet, desperation compelled me to give them a chance, hoping they could assist me in reclaiming my lost funds. Reaching out to FUNDS RECLAIMER COMPANY proved to be the most fortuitous decision I could have made. From the very beginning, they exhibited professionalism, integrity, and remarkable expertise. Unlike the scammers who had deceived me, FUNDS RECLAIMER COMPANY transparently outlined their terms and guided me through every step of the process. Their unwavering commitment to recovering my assets was commendable; they wasted no time and immediately leveraged their skills to track down the fraudsters and reclaim what was rightfully mine. After successfully recovering my funds, they requested my Bitcoin address and promptly deposited the entire amount. I was astounded. In just a few hours, I transformed from a helpless victim into a triumphant survivor, all thanks to FUNDS RECLAIMER COMPANY. These recovery specialists are truly exceptional. If you ever find yourself in a predicament similar to mine, do not hesitate to reach out to them. With FUNDS RECLAIMER COMPANY by your side, you can take a stand against scammers and regain control of your finances. Trust me, you will not regret it.

    HERE IS THEIR INFO:

    Telegram: + 1 (8 1 8) 4 7 4 - 1 7 3 1

    Email: fundsreclaimercompany@zohomail.com

  • cindy huang
    cindy huangJun 2, 2025

    SLOT ZEUS GACOR 2025 Memberikan Rekomendasi Game Online Yang Bisa Menghasilkan Cuan

  • G1itcher
    G1itcherJun 2, 2025

    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.

  • Parag Nandy Roy
    Parag Nandy RoyJun 2, 2025

    A bit of both actually..

  • Nathan Jobe
    Nathan JobeJun 3, 2025

    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.

Add comment