4 ms·

Understand the problem and solution before coding. It sounds simple, but it's hard to have perfect discipline. Especially if you have a strong bias towards act

Understand the problem and solution before coding. It sounds simple, but it's hard to have perfect discipline. Especially if you have a strong bias towards action like I do. It's shocking how applicable this is! Don't code an algorithm before having a firm grasp of the solution. Don't write code in an interview before you're sure you've uncovered everything your interviewer wants. Don't slam out a UI before understanding how all of the edge cases should act. Unless the point of the code is exploratory, the code should be a foregone conclusion by the time you start. The more you practice this, the more you'll uncover bugs and underspecifications before you've spent days going down the wrong path.

throw1234651234 4y ago
I am biased toward over-planning. I have found your approach to work best for work I expect to take several days. In that case, actually putting together a lucidchart / draw.io diagram about what service will get refactored where is a huge help. It also keeps data flowing uni-directionally (yes, compiler will prevent circular dependencies, but there are ways to make code dirty without ever hitting that). On the other hand, this diagramming does take hours and some people do fine with it. I can also do ok without it, but find it to generally be worth it, especially because I get interrupted all the time, so it's good to have a clear picture of the end goal.
pca006132 4y ago
I guess this really depends on how complicated the problem really is and can you really know everything before you code. I have very limited memory, so I often write out pseudocode/notes about some properties to help my reasoning. For some problems, I will write scripts to try out some idea, verify my assumptions, while thinking about the problem.
rjh29 4y ago
I am on the opposite extreme, I get so wound up designing stuff that I never write any code. I basically force myself to write something even it's imperfect and messy because it can be easily changed. And writing the code helps me understand the problem. As with all things, moderation is good here.
hirvi74 4y ago
As I have aged, I have done this more and more. I take inspiration from the famous pianist, Glenn Gould. He would study a piece of music for weeks or more. Taking all kinds of notes, truly studying and understand each measure, etc.. He did all of this without touching a piano. Once he was satisfied, then he'd play the piece.
raldi 4y ago
OTOH, I find that writing some prototype code is one of the best ways to understand the problem and solution before starting to write the real program. If you’re worried about lacking the discipline to throw away the prototype, do it in another language.
- iKlsR 4y ago
  Great advice, that's why I bought https://runjs.app/ https://runjs.app/ (not affiliated), I can quickly prototype pretty much anything with this and then port it to my actual target lang/framework after. Not hampered by the browser, npm, project setup or privacy concerns.
- jakevoytko 4y ago
  Your approach feels similar to mine, actually! I write lots of exploratory code (and mention it in my comment). I just view it as trying to understand the problem and solution instead of coding, since it's not usually the production code I'm going to commit.
dahart 4y ago
Hear hear! The generalization of this is figuring out how to prioritize multiple problems. Deciding which problems to solve in what order, and how much time to spend on each, is a difficult and important and never solved problem. But it’s quite valuable to practice and budget your time. This might sound different from understating the problem before coding, but it’s really almost the same thing, taking time to think about the approach carefully before diving in, making sure the requirements will be met, etc. Prioritizing multiple problems is very similar to planning the steps of solving a single problem. Maybe the main difference with the higher level prioritizing is that prioritizing has to be revisited periodically and/or continuously. Working in a software company, this is what the best PMs do really well, they figure out which features and bugs to work on that make the most difference, and they understand when to listen to the programmers and let them refactor things without making public-facing progress, and also when not to.
whoomp12342 4y ago
how do you go about doing this? sometimes you dont know what will go wrong until you try it out and get feedback
turboponyy 4y ago
iterate, prototype, patch, refine

throw1234651234 4y ago

I am biased toward over-planning. I have found your approach to work best for work I expect to take several days. In that case, actually putting together a lucidchart / draw.io diagram about what service will get refactored where is a huge help. It also keeps data flowing uni-directionally (yes, compiler will prevent circular dependencies, but there are ways to make code dirty without ever hitting that). On the other hand, this diagramming does take hours and some people do fine with it. I can also do ok without it, but find it to generally be worth it, especially because I get interrupted all the time, so it's good to have a clear picture of the end goal.

pca006132 4y ago

I guess this really depends on how complicated the problem really is and can you really know everything before you code. I have very limited memory, so I often write out pseudocode/notes about some properties to help my reasoning. For some problems, I will write scripts to try out some idea, verify my assumptions, while thinking about the problem.

rjh29 4y ago

I am on the opposite extreme, I get so wound up designing stuff that I never write any code. I basically force myself to write something even it's imperfect and messy because it can be easily changed. And writing the code helps me understand the problem. As with all things, moderation is good here.

hirvi74 4y ago

As I have aged, I have done this more and more. I take inspiration from the famous pianist, Glenn Gould. He would study a piece of music for weeks or more. Taking all kinds of notes, truly studying and understand each measure, etc.. He did all of this without touching a piano. Once he was satisfied, then he'd play the piece.

raldi 4y ago

OTOH, I find that writing some prototype code is one of the best ways to understand the problem and solution before starting to write the real program. If you’re worried about lacking the discipline to throw away the prototype, do it in another language.

iKlsR 4y ago
Great advice, that's why I bought https://runjs.app/ https://runjs.app/ (not affiliated), I can quickly prototype pretty much anything with this and then port it to my actual target lang/framework after. Not hampered by the browser, npm, project setup or privacy concerns.
jakevoytko 4y ago
Your approach feels similar to mine, actually! I write lots of exploratory code (and mention it in my comment). I just view it as trying to understand the problem and solution instead of coding, since it's not usually the production code I'm going to commit.

dahart 4y ago

Hear hear! The generalization of this is figuring out how to prioritize multiple problems. Deciding which problems to solve in what order, and how much time to spend on each, is a difficult and important and never solved problem. But it’s quite valuable to practice and budget your time. This might sound different from understating the problem before coding, but it’s really almost the same thing, taking time to think about the approach carefully before diving in, making sure the requirements will be met, etc. Prioritizing multiple problems is very similar to planning the steps of solving a single problem. Maybe the main difference with the higher level prioritizing is that prioritizing has to be revisited periodically and/or continuously. Working in a software company, this is what the best PMs do really well, they figure out which features and bugs to work on that make the most difference, and they understand when to listen to the programmers and let them refactor things without making public-facing progress, and also when not to.

whoomp12342 4y ago

how do you go about doing this? sometimes you dont know what will go wrong until you try it out and get feedback

turboponyy 4y ago

iterate, prototype, patch, refine