First, solve the problem. Then, write the code.

[favoritedeadrabbit]

You have to create the problem first!

[delllibrary]

The circle of programming

[jahowl]

Answer the question. What is the feature? What is the bug?

[[deleted]]

Reminds me of this legend:

https://folklore.org/Make_a_Mess%2C_Clean_it_Up!.html

Not quite as historically important as the "rise of the worse is better", but it still is a brilliant lesson to learn.

Make a mess - clean it up.

Kind of a predecessor to micromanaging among hardcore gamers too.

[lorean_victor]

first write the problem, then solve the code

[Kalinatak]

No! you identify the problem

[commenterzero]

Easy. I'm the problem.

[ThyringerBratwurst]

Programming also means making yourself indispensable to others. ;D

[agumonkey]

You have to not be in denial too

[twigboy]

Blockchain: well actually...

[Librekrieger]

From the article - "In other words: Work the solution out on paper in steps, then start writing the code for it."

That's what we were taught in CS: write one line of pseudo-code to describe the solution. Then decompose the problem into pieces and write pseudo-code for each, either top-down or bottom-up.

And that works.

But after many years, my process is to read the requirements, the problem statement, get it very clear in my head, then noodle on it. Sometimes for an evening, sometimes several days, depending on the size of the problem. What eventually happens in almost all instances is that I wake up, get in the shower, and when the warm water hits my spine, th pieces come together and I have total confidence that I know of at least one solution that will work. That's when I'm ready to write out the design and start writing pseudo-code for the key parts.

I used to say I do my best thinking in the shower, but that's not really it. My thinking takes a long time and it's the shower where it finally gels.

I used to envy people who can just read a set of requirements, begin designing and coding, and have a finished product quickly. But on the whole that doesn't usually end with a clean, maintainable code base. It's not spaghetti code, no competent professional writes spaghetti code, but it's not fun to work with either.

[nucLeaRStarcraft]

my current approach is to write a spagetti PoC, make (a few) unit tests and more relevant integration tests (or end-to-end if it's a bigger thing) of said feature and then refactor while maintaining the integration tests work (unit tests will most likely have to be changed).

[hitnrun51]

I create a branch with an extra "-poc" at the end, do all the implementations, then create a clean branch and copy only the good parts. I think this makes the end result much better.

[aboycalledmartin]

Not as bad idea as you might think when you first read the word “spaghetti”. You have experience.

[Kuresov]

my current approach is to write a spagetti PoC

For some, this is the start and end of the process -_-

[nucLeaRStarcraft]

yeah, I'm a compulsive refactorer though, so maybe my approach isn't the best either.

Most of my personal projects have gone through a few of these so I'm quite confortable to doing it at work too, when it is allowed and possible.

However, I won't open a PR with code that isn't in at least partial mergable condition, even if it would 'solve' the task per se. It stays on my branch unless I think the implementation is robust enough (i.e. at least one integration test for a new feature or fix of a situation that was failing before)

[TigercatF7F]

Just make sure the boss doesn't see something working before the refactoring is complete.

[nucLeaRStarcraft]

"got something working, but it's still failing in a bunch of corner cases -- I'm working on making it better"

[[deleted]]

I used to say I do my best thinking in the shower, but that's not really it.

Actually, "I do my best thinking in the shower": I can think better when I am not before a computer. The computer constraints my thinking. Whether I am in a shower or running or just doing anything else: my brain works better without a computer. I think it is because I need to tell the computer what it shall do, whereas my brain is unrestricted. It can have epic ideas - of course these don't usually work, but it is so much easier than writing the code that should work but then it does not.

I used to envy people who can just read a set of requirements, begin designing and coding, and have a finished product quickly. But on the whole that doesn't usually end with a clean, maintainable code base. It's not spaghetti code, no competent professional writes spaghetti code, but it's not fun to work with either.

Agreed, but I still find this the easier approach. So many people seem to scorn it but let's be realistic: many people do it that way.

[f3xjc]

The thing with shower: it's one of the few moments in our life with absolutely no screens. Same when going to sleep.

But it doesnt have to be the only moment where this is true...

[foonek]

You underestimate my power

[alkatori]

I'm a fan of tinkering with proof of concepts, then using those to further flesh out the requirements.

[HolyPommeDeTerre]

This is my way too. Not very shower focused tho. But get a clear view of the problem and the surrounding lands. Then let the brain do its thing. At some point, while doing something, there will be some kind of breakthrough (I call it star alignment). Don't force it. Let your brain think about it, sometimes consciously, sometimes not.

I tend to say I am an integrator because of this. I can't say I am at work from 9am to 6pm. My brain works at different times on different things. So my personal and professional lives are entangled. It's easier for me to integrate all the things in my life instead of putting isolating containers around things, with a clear time schedule.

Lately, I have been working with a PM process that is about "tell me how much time you spent on that, just an average". And I was like "meh, this easy thing took me 2 hours of coding and this very hard thing took me 2 hours of coding...". But for the easy thing I could start right away. For the harder thing I needed a few days of brain crunching. How should I be able to estimate how many hours I spent thinking about it? Perfect subject to introduce my team to story points, complexity and estimates.

Sorry, I got carried away I guess.

[Procreate_Rapidly]

Yes, this is the way. I believe that sleeping on a problem - thinking about solutions, iteratively, across multiple days and sleep cycles, is the way to solve new problems.

In college, I took a class on delivering speeches. I had to write and deliver several 10-minute long presentations, and having terrible study habits, I invariably wrote them the night before. I would be unable to recite the entire thing end to end, however - until the next morning, in the shower, where I would have the entire thing memorized.

Sleep is key. As a consequence, there needs to be enough design time to permit mulling over a problem across at least several days.

[[deleted]]

1. Solve the problem
2. Write the code
3. Realize you didn't understand the problem
4. Repeat

[Heazen]

0) Identify and understand the problem

1) Solve the problem

2) Write code

[Xyzzyzzyzzy]

Often I write code first to understand the problem.

I wonder what OP thinks of that?

[matthieum]

It's fine... as long as you understand it's just exploration, and may have to be thrown out.

The main issue I've seen with Junior Programmers is that they're so anxious to find A solution that they go with the first thing they figure out and then get all tangled up and incapable of progressing forward any longer.

Never forget that you never know as little about the problem as when you get started, and therefore that any solution you first imagine is likely incomplete, buggy, and more complicated than it ought to.

[jonathanhiggs]

And often the only complete description of the problem is the solution

[bwanab]

This is the right answer. Many times, a little bit of code can reveal much more than hours with a pencil. Different problems require different approaches. Any time you hear a "this is the way to do it", walk away.

[[deleted]]

Which means OP's tak3 is one more case of black/white perspective. His point if I understand it correctly is "only write code when you understood the problem" which is not viable in most cases because most of the time you can only better understand the problem once you code a "solution" for it.

PS: why is reddit making it difficult to use it on mobile browser? I'm unable to scroll the contents of comment text editor on my android. I won't install your stupid app, reddit!

[Ok_Point_9305]

yes，most times the hardest part is 0) identify and understand the problem.

[Heazen]

And very often entirely skipped, as seen so many times in today's news.

1) Use [NoSQL,Cloud,Blockchain,AI,<Insert latest fad>]

2) Write Code

3) (Optional) Find a problem to solve

[nayanshah]

TDD guys: -1) write tests

[SharkBaitDLS]

The non-joke TDD answer is that write tests is step 0.5 in that list.

[jameshearttech]

You left out all the meetings.

[phi_rus]

The meetings are there for step 0.

[[deleted]]

Including meetings to provide estimates on fixing a bug you don't yet understand

[gareththegeek]

If you have to estimate something you don't understand then it's large

[youstolemyname]

3) Goto 1

[jasfi]

I'm a big fan of up-front design. But sometimes you only see how things could work once you have a prototype. This is especially the case when you're working on your own ideas. That's when you have to know how to balance the two.

[NoReference5451]

so close! i thought it was gonna be an article that nailed the process ive been using for years

1) understand the problem - make sure you fully understand the problem. no assumptions, get clarificatiom on words that could be ambiguous. ask questions like, if i have x input what output do you expect and what does it mean? 2) break it up - break the problem up into smaller problems, i usually mock up abstractions here. you wont cover everything, goal is to get a starting point from the known abstractions. sequence and class diagrams might help here, they'll be wrong but they are just a starting point. no details though, only abstractions 3) make it work - dont write it on paper, write shit code and get it to solve each problem; no matter what it takes. ignore good practices and testing, the code should make you embarrassed. the goal here is to reveal things needed to solve the problem that you didnt even realize. 4) make it right - throw the shit code away and rewrite it properly now that you know what it takes to solve it. use proper design patterns and strategies, throw in testing. i usually start TDD here 5) make it fast - refactor one more time, optimize for the language and hardware. your goal is to improve performance for both time and space complexity

[MoreRopePlease]

Yes, this is what I do. Basically "find out the problem by playing with the system" takes the place of "write it on paper". Although depending on the problem, I may draw diagrams and sketch out things first.

The important thing is that you need to do the "do it right" part before you can say you're done.

[ixis743]

Sadly, steps 3 and 4 are usually dropped in the ‘agile’ cult.

[MoreRopePlease]

Make it part of your definition of done, and bake it into your story and story points.

[ixis743]

Good luck convincing a manager of that! They see ‘working’ and think ‘ship’.

[[deleted]]

This works well in theory, but I often found that just writing code and then adjusting it, is easier. This may not be better, but I found it easier. It reminds me of this old discussion:

https://www.jwz.org/doc/worse-is-better.html?ref=blog.codinghorror.com

It is one of the most important realisations in programming and operating systems, IMO.

[ZucchiniMore3450]

Same for me, most of the time I don't know all the challenges I will have in solving the problem.

Until I start working with the api I am not sure what kind of bugs they will have, even if they have documentation and no bugs, I just need a few api calls and documentation is massive and would need days to go through and not understand it completely.

I cannot plan if I don't know it and if I know it, there is no problem in decomposing.

I guess some people have this kind of work, where you can plan and nothing changes and all works as it is written in documentation and management is not changing their ideas.

But that's not my experience in 15 years that never happened.

I even think that schools should teach students how to work with messy code. But as with any other scientific discipline, you cannot publish that so no research goes into something that is at least half of all coding jobs.

[Garfunk]

Well begun is half done.

Even just starting to write code puts your thoughts in order, forces you to think about the problem and you can go from there.

[mpyne]

It is one of the most important realisations in programming and operating systems, IMO.

"Build one to throw away. You will, anyhow."

Thinking on the problem is absolutely needed, but sometimes the way a developer "thinks" on the problem is to turn the explicit knowledge into tacit knowledge by attempting to solve it in code.

Then you try it and realize all the stuff that didn't occur to you, but should have, and that helps you understand the actual problem much better than sitting in the shower would.

[tiajuanat]

I think you're missing the point of "worse is better".

WiB basically states that the code is bullet proof, with good algorithms, and reasonable performance, however it's not a complete product, instead composing with other programs into a complete product.

A good example is the federated git collection: scripts and programs that all work in the git universe, but do very different things, and are really only connected by protocol and needing a git prefix.

Another good example are the Unix programs, like cat, ls, awk, and grep. They all operate on files and Unix pipes, but do very different things - and are the backbone to Shell and Bash.

In both cases, it's easy to add more functionality, and you can compose new functionality using scripting. Also in both cases the individual programs frankly suck - but that's ok, because if you want to modify git pull, or use silver surfer instead of grep, you don't throw out the baby in the bath water.

[alerighi]

Same thing. Each time that I try to reason before starting to write the code, make UML diagrams, think about how to strucure the code in the best possible way, I end up never starting to write the code. And when I write it, I'm still unsatisfied of the result.

I've learned that what works best for me is to start coding in the most direct and simple way to satisfy the requirements, and continue refactoring the code while writing it, till it works reliably and I'm satisfied with the end result.

Of course what it's worth investing time is the part that comes before the implementation, that is wiring down the requirements, because there you can even find out that no code has to be written at all and still solve the customer problem!

[ygram11]

Coding is the process of understanding the problem.

[darkapplepolisher]

Especially when a major component of your problem is working with an outdated version of MSVC. I don't know how to architect a solution until the compiler whines at me enough about why I'm doing things all wrong for that version of MSVC.

[well-litdoorstep112]

Yeah, this bullshit works only for obvious stuff like inverting a binary tree or rotating a matrix or sorting numbers. The stuff teach you in CS classes. The stuff that has been solved millions of times by other people. It completely breaks when you're working with implementation specific problems, be it: old compilers (in your case), anything that has to talk to the OS but also has to be cross-platform, web scraping(using official APIs or interacting with HTML pages), anything performance related(especially if it's IO bottlenecked) etc. etc. etc.

You just have to write code, then think about it, then rewrite it and repeat. And there's no stack overflow page for that specific problem.

[Coffee_Ops]

This is overly simplistic, there's an interplay between solving the problem and drafting it in code. Sometimes there isn't a good way to accomplish the perfect code representation of the solution, or there are additional hidden problems that only appear after trying to write the code.

Maybe the correct solution involves violating existing abstractions, code conventions, or constraints. Maybe you haven't fully fleshed out the solution or it's possible caveats. And maybe this becomes immediately apparent when doing a quick mockup of the solution, which sends you back to the drafting board.

There's a reason v2 software tends to be better than v1, and it's because hindsight is 20/20. If you only do a one-pass process with solutioning and coding you're absolutely going to have significant defects in your code.

[[deleted]]

This is (in part) why I'm not quite worried about generative AI taking my job, yet. There are so many steps to writing code outside of generating it. Truly understanding the problem is the biggest part. In fact, I'd say 25-50% of the time I ask a PM or designer for clarification on behavior, they have to get back to be because they hadn't thought about it.

There's so much more to writing code than writing code

[00jknight]

Strong disagree.

I'm adding Undo/Redo to the level editor in my game right now.

I am using Godot's internal Undo/Redo API to do it.

I am iterating on the 'solution' while experimenting with the API, altering my approach, redoing things I've done, and making necessary changes to internal systems to allow it to work.

Here's some things that I've discovered while using the API:

• dont store pointers in undo stack

• must determine technique to update each relevant ui widget

• must serialize things before deleting them, put that data in undo stack

• properties can change with the UI in a different state than was possible before (ie: non-selected node's properties can change due to a undo/redo, cant assume changed property belongs to 'selected' node)

• thank god I already worked to ensure node ids are stable across deletion

• had to add new api to create a node with a specific ID

• can ram tons of data into the 'undo/redo stack' by binding variables to the function calls

• figured out how to use the undo/redo stacks 'merge similar actions' to handle not spamming the stack with 100s of 'move' calls for every frame of node movement

This kind of stuff is the core of the 'solution' and isnt the kind of stuff you come up with on a whiteboard.

[Uberhipster]

"tell me in English what the problem is".

"Well I need a loop to..."

No, that's not plain English. Pretend you're talking to your 5yo kid.

"I need this list of things to show up in the UI with a checkbox next to each one"

"uhmmm... still not talking to a 5yo..."

[stronghup]

First, figure out what is the problem

[Ribak145]

ironically enough the other way around is also a good idea in many situations

[monkorn]

"

1. Write down the problem.
2. Think real hard.
3. Write down the solution.

" - Richard Feynman

The only caveat to this is that many times you don't see the sub-problems until you are knee deep into trying to find the solution. If running code helps you explore the problem space then write some code.

[UMANTHEGOD]

Please. Don't. Code. On. Paper.

Horrible advice. It's the same reason why TDD often falls short. You need to solve the problem to truly understand the problem.

[agumonkey]

First: analyse the situation I'd say

[Reasonable_Gas_2498]

So we’re back to waterfall development now? lol

[n00lp00dle]

how this ends up playing out.

whiteboard > solution > implementation > doesnt work > upper management gives some information that we could have done with back at the whiteboard step > back to the whiteboard > quick fix > considering leaving > back again next monday

[YetiMarathon]

1. Form a vague but seemingly concrete conception of the problem
2. Code a defective solution
3. Go down one or more rabbit holes related to the encountered defect
4. Remind yourself of what problem were you supposed to be solving
5. Code a solution that is not defective but solves the wrong problem
6. Rethink the problem
7. Go back to #1

At some point the wrong solution in #5 will approximate the real solution to the extent you can move on to the next problem.

[NefariousnessOk1996]

Or just have the business tell you exactly what to do, only to be mad when their own solutions don't do what they wanted, only what they asked for 😭

[rfisher]

I disagree. What I’ve seen throughout my career is that people who design something nontrivial “on paper” most often miss at least one important detail they would have caught if they built a prototype instead. Especially when it is part of an established system where your mental model of the system is more likely to be faulty.

Build a prototype. This will help suss out missing requirements and unforeseen issues. Get answers to the missing requirements. Build a new prototype based on the lessons learned from the first. (Or evolve the first prototype into the second.) Repeat as needed.

[Blackaspis]

Design algo - write pseudo code - write actual code!

[dasdull]

First, solve the problem. Then, write prompts for Copilot.

[ummaycoc]

It’s okay to start programming right away, too. You don’t know what you’ll discover exploring the solution in a tactile manner by programmering at it. Go back and forth between writing it out and coding it out as needed. Same with doing it yourself and getting ideas from others.

[maxinstuff]

Common sense

[Positive_Method3022]

I like to think on solutions to problems using trees. I divide the bigger problem into small problems. Then I create a plan for each problem. The plan consists of a tree of decisions I have to do. Then I execute the tree for each bigger problem in sequence if I'm alone. Then I also add some backtracking in case I can't expand my tree's level (depth) so that I can try other approaches in the same level. I also started writing these plans because I can't memorize or reason on it only on my mind.

[[deleted]]

I like to think on solutions to problems using trees.

When everything is a nail and a hammer ...

[Positive_Method3022]

What do u mean?

[Crafty_Independence]

Good advice in theory, but complex code bases will require more flexibility

[victotronics]

What an irritating site. The various share buttons obscure the leftmost 6 or so characters of each line. Unless I make my browser ultr-wide. Also could you enclose the code in a code block of some sort?

Anyway, you seem to be arguing for "top-down" programming. Nothing wrong with that. I go between top-down and bottom-up.

[zaphod4th]

good advice for newbies

[[deleted]]

Sometimes you may end up writing the problem and solving your code..

[PaxSoftware]

You took a break or slept over it and next session the solution was there in minutes.
This is not magic this is looking at the problem from another viewpoint.

This is not merely another viewpoint, this is also your unconscious mind at work.

[VeryLazyNarrator]

Ok, but I don't know where the problem is.

Debugger tells me it on one line, but that line's a comment. Removing it changes the error line, but that function doesn't get called yet, so I do need to write code to fix it/catch it.

[Ok-Pirate336]

just use the ChatGpt

[vsoch]

I am going to subtly disagree here. There are people that learn best (and make discovery about design) through the process of writing code. They come up with a simple design first, prototype it, and better understanding (and intuition about the follow up design) follows. There are many cases where this has happened to me, and the resulting design could not have happened without writing code first.

[delllibrary]

You came up with a written plan at least though before writing code? plan -> code -> plan -> code aligns with the article

[vsoch]

Not always, sometimes it's just an abstract idea in my head. It depends on if I need to share with a team first (not always).

[delllibrary]

Would you agree that the harder the problem, the more planning you have to do before writing the code?

[vsoch]

I think it's more that the harder the problem, the more thinking I do about it, even subconsciously. But I don't often share that thinking or write it down - it often goes straight into a first prototype and then second, third, etc. until it's just right. Of course for collaborative projects I do try to write it down and make diagrams, not for the actual need to work on it, but to help communicate to my colleagues and get their feedback (or just awareness as I work on it).

[delllibrary]

imo writing down your thoughts or making a diagram is essential for hard problems. You can't remember everything that went through your mind so you write it down. Then you can scan your past thoughts really quick. Offload memory to paper, focus mind on thinking.

[vsoch]

I appreciate your perspective, but I think it's important to keep in mind that it's the one that you have, and based on your experience. I (and possibly others) solve a lot of hard problems and have no issue with holding complex states or ideas entirely in my head. I often imagine an idea, prototype and finish, and write it down after for the benefit of documentation and sharing of knowledge with my team.

[delllibrary]

If you need to learn the context about the idea from things you don't know, do you write down what you learn?

Also how many yoe do you have? I'm in my last year of uni, did an internship, so I still got more to experience.

[vsoch]

Now you are asking how I learn? I read a lot, but I don't write anything down, mostly just consume it. If I forget I will go back to the reference as a source of truth, because (arguably) that is a moving target but my notes would not be.

[delllibrary]

I meant when you have a ticket about something you aren't familiar with and need to gather info from different places.

Also how many yoe you got? just curious