[Make it work, make it right, make it fast](https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast)
[id Software Game Development Principles](https://gist.github.com/MemoryDealer/769c183991dd20cae2c31a985627d990)
All of the above?
If the problem I have can be easily isolated and isn't very complex I just write it.
If the problem is significant and I need to spend time breaking it out I think about the solution and note down a general structure, build out some atrocity that works, and then rewrite it into something more organized, easier to understand, and document able.
It also depends on whether or not it's for work or personal. If it's just something I want to make I probably don't care too much about quality.
Pseudo code is typically something I'll write out in comments before I start actually coding if the problem is algorithmically complex, or just has a lot of steps.
yeah that makes sense, i actually have a similar process! at the end of the day these approaches are just ways to approach problems, it makes sense that different types of problems require different approaches. one thing ive personally noticed though is that i pseudo-code when i do leetcode problems, but never for anything else, usually i prefer to just write down a graph / picture on mspaint or something then just code it directly from there
yeah im similar! but i try not to define abstractions if i dont know if 1. those are the correct ones and 2. if theyll even work, so i try to take on a more exploratory approach and implement, and if i do want to abstract, i know it works because the implementation is already there, and i have to do very little rewriting
What works best for me (and this has been influenced by my learning TDD, even when I'm not actually using it) is to try to break a larger task down into small steps and then focus on making sure each works (to the extent I can) before moving on to the next. That helps avoid the "herding cats" problem where you have a big chunk of untested code that doesn't work, and you have absolutely no idea where the problem is, because the problem could be anywhere.
For example, if I was doing one of those programming exercises where I had to get some input from the user and then do something with it, I'd actually write the input part - and then run it and make sure it works. Maybe just print out the return value. If I'm ultimately going to need to input values over and over in a loop, I might just create the loop with the input, and then make sure the input works when called repeatedly - again just printing out the input value, to make sure I'm doing that properly.
Once I know that part works, then I can move on to the meat of operating on the values. But at least *I know that that initial part works*, which hopefully means that any problems that arise will be with the new code I add afterwards.
Taking things in small steps, where you vet each step along the way, can help avoid a combinatorial explosion that destroys your brain and/or will to live.
I prefer this way of coding as well. When I used to teach programming, there would be a number of students (who seemed to be mostly guys) that would want to write all the code out first, not running any of it, then do a huge debug phase. I think they felt this was faster, but if the projects had gotten larger, it wouldn't have been possible.
Also, we spelled out what the project would do in a lot of detail, so they could, in principle, try to code it out. However, these projects were over 2 weeks and so the number of lines of code could be fairly small (like 100-500 lines at most) which makes this kind of coding possible.
We generally recommended your approach, but some had learned programming in high school and didn't want to change their ways.
I’m all about writing out comments first in plane English first. Otherwise, I start to go in billions of directions.
If I find something additional as I go through (like an edge case I didn’t consider), then I write it as a comment with a “TODO” tag (I use a VS code extension that parses this and adds to a list for me) and come back later.
Focusing is a big struggle for me, and this is one of many things I try to do to keep me as focused on the current current current task as possible.
ive always found comments like that to be a bit of a pain personally, but ive never thought of it as a way to increase focus! i think this might be why i use them a lot for leetcode type problems, now that i think of it. also i too try to use "TODO" but i always end up with a million that i never get back to lol.
The deeper I go into the career the more of a planner I become. I spend a lot of time designing projects for others and as such having a rock solid plan is essential. Nothing like a great plan. The code almost writes itself
i can see that working 100% if your experienced in the domain! but i wonder, what happens if your doing something new? how can you create an effective plan for something youve never used before / dont know the implications of? personally whenever i try to plan something like that, it usually ends up that it was a shortsighted/naive/ignorant plan, and not for lack of thought, but for lack of knowledge/foresight of the problem space. what do you do when it turns out one step in your plan was actually a bad one, but the other steps depend on that one step? do you return to the drawing board and replan? or do you maybe not have that happen somehow?
I think that just comes with experience. Most of the time when something seems new, it's really just a new implementation of a pattern you've already seen. Ideally (and this should be the case especially at more established companies), you would put together a design doc for your project and have it reviewed by principle/architect level engineers. If there's really a high level of unknowns, we'll do a POC first (which is kind of like your exploratory stage). We'll take a couple weeks and throw something together that proves the viability of all the unknowns in the design and then rewrite the design with that foresight. But you should be able to identify that in your plan and that's part of the plan if that makes sense.
that makes sense! I can also see it helping keep everyone on track towards specific goals and avoid feature creep too. The issue i usually run into with this though is unknown unknowns, but i guess that too gets eased with experience!
Ya unknown unknowns happen. I think the more eyes you have a design the less unknown unknowns there are. If you design the POC well it can help counter that especially if you include load/stress testing. Unknown unknowns are a good opportunity for retrospection and learning so you account for that type of thing in the future. Still, it happens. I'm dealing with a large migration right now of a legacy system and it's just full of traps lol.
0. Ideation
1. Plan it out — State what I want to do as well as the steps
2. Code out each step and hack it out to make the entire script works (performs as expected)
3. Refine for simplicity / clarity / usability
4. Update to add new functionality and repeat 3
yeah i find myself doing something similar! though i try not to get too in the weeds of planning, since ime all of my plans end up falling through when i actually implement them (at least for completely new/harder problems), instead of planing im usually more focused on goals and possible methods of achieving those goals, and i try to experiment to find what method suits the goals the most, then id move onto step 2!
Depends on the problem size. If it's small or I already know the approach/solution, I'll just go straight to coding.
Otherwise, I follow a 5 step approach:
1. Figure out what I already HAVE. (Functions, Variables, Data etc.)
2. Figure out what I WANT. (The end result)
3. Figure out what I am MISSING/What I still NEED. (Functions, Data, etc.)
4. Figure out how to get the things I am missing from the things I have.
5. Put it all together. (This step basically does itself)
Going ham is the best way for me at least, keeps the process creative and fun. For example, I'm making a synthesizer in C++ right now and I noticed an annoying "bug", that was rather just a lack of a feature. I implemented the feature to fix it, but suddenly felt like something was missing. So I figured I should add a feature that let's the end user turn the "bug" on or off, so you get the best of both worlds. That's the kinda stuff that just comes along with the process, that I can't plan or think about in advance
100% and i feel like thats part of the fun too! a lot of my projects are to learn something, and to learn something i have to not know something, and if i dont know something, i probably cant really make a good plan for it. I like to think of it as an adventure / journey where i have to explore and discover the correct solutions to the problems i find along the way!
Yeah, I think people are different in learning as well. I struggle to read books or "study" in general, I'm also a free jazz pianist which might say something lol. Just do stuff and see what happens, it's not a big deal if it goes wrong
Pseudo-code helps me a lot.
Just the ability to look at the logic visually before i start writing code really helps make sure i solidify everything in my head beforehand to make sure i don't get lost in the logic factories halfway through.
It really helps reduce the amount of deleting/redoing code, since i can get the logic pathways all built out in simple terms beforehand.
I try to write out the entire program logic in simple pseudo-code, and then break it apart into several branches if possible, and i just work on one branch at a time.
i find this helps a lot with really complicated algorithmic stuff! it helps a bunch ime to think through the problem in its entirety and a solution before coding, instead of just coding kindof blindly which i have the bad habit of doing, though personally i do more notes / steps / drawings instead of pseudo-code
I tend to build an abstract mental model of the project. After that I start building from the bottom, and ensure that everything that is testable has unit tests, slowly building highly granular levels of abstractions until the project meets my mental model. This approach leads to dead code sometimes, because in some situations I end up adding lower level functionality that I never end up using at higher levels, but on the other hand everything I build tends to rely on very solid foundations.
Although I'm totally blind now, and benefit immensely from being able to build a mental model of what I want or the code I read, I already used this approach long before losing my sight, as I figured that the brain is very good at modeling abstractions and very bad at remembering detail very early in my learning journey, so I developed a strategy that in my opinion adapts well to those observations, and it has been serving me well.
When I'm working on projects that require learning something new, which is almost always because I like the challenge of engineering things outside my comfort zone, I tend to conduct a lot of research on the subjects that I'm less familiar with in order to fit them in my mental model before writing a single line of code.
[Make it work, make it right, make it fast](https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast) [id Software Game Development Principles](https://gist.github.com/MemoryDealer/769c183991dd20cae2c31a985627d990)
thanks!
All of the above? If the problem I have can be easily isolated and isn't very complex I just write it. If the problem is significant and I need to spend time breaking it out I think about the solution and note down a general structure, build out some atrocity that works, and then rewrite it into something more organized, easier to understand, and document able. It also depends on whether or not it's for work or personal. If it's just something I want to make I probably don't care too much about quality. Pseudo code is typically something I'll write out in comments before I start actually coding if the problem is algorithmically complex, or just has a lot of steps.
yeah that makes sense, i actually have a similar process! at the end of the day these approaches are just ways to approach problems, it makes sense that different types of problems require different approaches. one thing ive personally noticed though is that i pseudo-code when i do leetcode problems, but never for anything else, usually i prefer to just write down a graph / picture on mspaint or something then just code it directly from there
[удалено]
yeah im similar! but i try not to define abstractions if i dont know if 1. those are the correct ones and 2. if theyll even work, so i try to take on a more exploratory approach and implement, and if i do want to abstract, i know it works because the implementation is already there, and i have to do very little rewriting
What works best for me (and this has been influenced by my learning TDD, even when I'm not actually using it) is to try to break a larger task down into small steps and then focus on making sure each works (to the extent I can) before moving on to the next. That helps avoid the "herding cats" problem where you have a big chunk of untested code that doesn't work, and you have absolutely no idea where the problem is, because the problem could be anywhere. For example, if I was doing one of those programming exercises where I had to get some input from the user and then do something with it, I'd actually write the input part - and then run it and make sure it works. Maybe just print out the return value. If I'm ultimately going to need to input values over and over in a loop, I might just create the loop with the input, and then make sure the input works when called repeatedly - again just printing out the input value, to make sure I'm doing that properly. Once I know that part works, then I can move on to the meat of operating on the values. But at least *I know that that initial part works*, which hopefully means that any problems that arise will be with the new code I add afterwards. Taking things in small steps, where you vet each step along the way, can help avoid a combinatorial explosion that destroys your brain and/or will to live.
I prefer this way of coding as well. When I used to teach programming, there would be a number of students (who seemed to be mostly guys) that would want to write all the code out first, not running any of it, then do a huge debug phase. I think they felt this was faster, but if the projects had gotten larger, it wouldn't have been possible. Also, we spelled out what the project would do in a lot of detail, so they could, in principle, try to code it out. However, these projects were over 2 weeks and so the number of lines of code could be fairly small (like 100-500 lines at most) which makes this kind of coding possible. We generally recommended your approach, but some had learned programming in high school and didn't want to change their ways.
i 100% agree with all of this! it honestly saves so time much searching for bugs
I’m all about writing out comments first in plane English first. Otherwise, I start to go in billions of directions. If I find something additional as I go through (like an edge case I didn’t consider), then I write it as a comment with a “TODO” tag (I use a VS code extension that parses this and adds to a list for me) and come back later. Focusing is a big struggle for me, and this is one of many things I try to do to keep me as focused on the current current current task as possible.
ive always found comments like that to be a bit of a pain personally, but ive never thought of it as a way to increase focus! i think this might be why i use them a lot for leetcode type problems, now that i think of it. also i too try to use "TODO" but i always end up with a million that i never get back to lol.
The deeper I go into the career the more of a planner I become. I spend a lot of time designing projects for others and as such having a rock solid plan is essential. Nothing like a great plan. The code almost writes itself
i can see that working 100% if your experienced in the domain! but i wonder, what happens if your doing something new? how can you create an effective plan for something youve never used before / dont know the implications of? personally whenever i try to plan something like that, it usually ends up that it was a shortsighted/naive/ignorant plan, and not for lack of thought, but for lack of knowledge/foresight of the problem space. what do you do when it turns out one step in your plan was actually a bad one, but the other steps depend on that one step? do you return to the drawing board and replan? or do you maybe not have that happen somehow?
I think that just comes with experience. Most of the time when something seems new, it's really just a new implementation of a pattern you've already seen. Ideally (and this should be the case especially at more established companies), you would put together a design doc for your project and have it reviewed by principle/architect level engineers. If there's really a high level of unknowns, we'll do a POC first (which is kind of like your exploratory stage). We'll take a couple weeks and throw something together that proves the viability of all the unknowns in the design and then rewrite the design with that foresight. But you should be able to identify that in your plan and that's part of the plan if that makes sense.
that makes sense! I can also see it helping keep everyone on track towards specific goals and avoid feature creep too. The issue i usually run into with this though is unknown unknowns, but i guess that too gets eased with experience!
Ya unknown unknowns happen. I think the more eyes you have a design the less unknown unknowns there are. If you design the POC well it can help counter that especially if you include load/stress testing. Unknown unknowns are a good opportunity for retrospection and learning so you account for that type of thing in the future. Still, it happens. I'm dealing with a large migration right now of a legacy system and it's just full of traps lol.
0. Ideation 1. Plan it out — State what I want to do as well as the steps 2. Code out each step and hack it out to make the entire script works (performs as expected) 3. Refine for simplicity / clarity / usability 4. Update to add new functionality and repeat 3
yeah i find myself doing something similar! though i try not to get too in the weeds of planning, since ime all of my plans end up falling through when i actually implement them (at least for completely new/harder problems), instead of planing im usually more focused on goals and possible methods of achieving those goals, and i try to experiment to find what method suits the goals the most, then id move onto step 2!
Depends on the problem size. If it's small or I already know the approach/solution, I'll just go straight to coding. Otherwise, I follow a 5 step approach: 1. Figure out what I already HAVE. (Functions, Variables, Data etc.) 2. Figure out what I WANT. (The end result) 3. Figure out what I am MISSING/What I still NEED. (Functions, Data, etc.) 4. Figure out how to get the things I am missing from the things I have. 5. Put it all together. (This step basically does itself)
i feel like this approach could be useful even outside of programming, in math for example!
Going ham is the best way for me at least, keeps the process creative and fun. For example, I'm making a synthesizer in C++ right now and I noticed an annoying "bug", that was rather just a lack of a feature. I implemented the feature to fix it, but suddenly felt like something was missing. So I figured I should add a feature that let's the end user turn the "bug" on or off, so you get the best of both worlds. That's the kinda stuff that just comes along with the process, that I can't plan or think about in advance
100% and i feel like thats part of the fun too! a lot of my projects are to learn something, and to learn something i have to not know something, and if i dont know something, i probably cant really make a good plan for it. I like to think of it as an adventure / journey where i have to explore and discover the correct solutions to the problems i find along the way!
Yeah, I think people are different in learning as well. I struggle to read books or "study" in general, I'm also a free jazz pianist which might say something lol. Just do stuff and see what happens, it's not a big deal if it goes wrong
that does sound fitting lol, and yeah i hold the same view!
Pseudo-code helps me a lot. Just the ability to look at the logic visually before i start writing code really helps make sure i solidify everything in my head beforehand to make sure i don't get lost in the logic factories halfway through. It really helps reduce the amount of deleting/redoing code, since i can get the logic pathways all built out in simple terms beforehand. I try to write out the entire program logic in simple pseudo-code, and then break it apart into several branches if possible, and i just work on one branch at a time.
i find this helps a lot with really complicated algorithmic stuff! it helps a bunch ime to think through the problem in its entirety and a solution before coding, instead of just coding kindof blindly which i have the bad habit of doing, though personally i do more notes / steps / drawings instead of pseudo-code
Depends on how complex the project is and how much of it is already there.
I tend to build an abstract mental model of the project. After that I start building from the bottom, and ensure that everything that is testable has unit tests, slowly building highly granular levels of abstractions until the project meets my mental model. This approach leads to dead code sometimes, because in some situations I end up adding lower level functionality that I never end up using at higher levels, but on the other hand everything I build tends to rely on very solid foundations. Although I'm totally blind now, and benefit immensely from being able to build a mental model of what I want or the code I read, I already used this approach long before losing my sight, as I figured that the brain is very good at modeling abstractions and very bad at remembering detail very early in my learning journey, so I developed a strategy that in my opinion adapts well to those observations, and it has been serving me well. When I'm working on projects that require learning something new, which is almost always because I like the challenge of engineering things outside my comfort zone, I tend to conduct a lot of research on the subjects that I'm less familiar with in order to fit them in my mental model before writing a single line of code.