6 ms·
>How do you understand the problem without writing any code? Not OP, but I find this a very good question. I've always found that playing with the problem in c
by carlmr 1y ago
>How do you understand the problem without writing any code?
Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it.
I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it.
It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.
- mixmastamyk 1y agoThis is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
- Espressosaurus 1y agoThey weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in. Not everything has been solved for ten thousand years.
- mixmastamyk 1y agoYou misread. Also, that tech has been around for decades.
- gitremote 1y agoMost solutions to business problems are proprietary, not open source. Tax rules depend on an interaction between national and local laws that can change from year to year based on the ruling government. You can't just take tax rules from ancient Rome to generate 2024 tax software for Quebec, Canada.
- mixmastamyk 1y agoDoesn’t matter, tweak a few constants. One for you nineteen for me… Taxman!
- 6510 1y agoIf I have any representation of the problem in front of me the mind seems to attack it all by it self. I strongly suspect someone with more (or different) experience doesn't need this or gets better results by writing out a representation.
- corytheboyd 1y agoI’ve grown weary of people repeating absolutisms they hear online, too. As is usually the truth in practice, it’s a mess, which is why I’ve seen combinations of upfront planning and code spiking work the best. An upfront plan ensures you can at least talk about it with words, and maybe you’ll find obvious flaws or great insights when you share your plan with others. Please, for the love of god, don’t ruin it with word vomit. Don’t clutter it with long descriptions of what a load balancer is. Get to the point. Be honest about weaknesses, defend strengths. Because enterprise corporate code is a minefield of trash, you just have to suck it up and go figure out where the mines are. I’ve heard so many complaints “but this isn’t right! It’s bad code! How am I supposed to design around BAD code!” I’ll tell you how, you find the bad parts, and deal with them like a professional. It’s annoying and slow and awful, but it needs doing, and you know it. By not doing the planning, you run the risk of building a whole thing, only to be told “well, this is nice, but you could have just done X in half the time.” By not doing the coding, you risk blowing up your timeline on some obvious unknown that could have been found in five minutes.
- skydhash 1y agoIt's not building the whole architecture before coding. It's about getting all the answers before spending time coding things that will probably have hidden bugs. Sometimes you don't have a way to get the exact answers, so you do experiments to get data. But just like scientists in a lab, they should be rigorous and all assumptions noted down. And sometimes, there are easy answers, so you can get these modules out of the way first. And in other cases, maybe a rough solution is better than not having anything at all. So you implement something that solves a part of the problem while you're working on the tougher parts. Writing code without answers is brute-forcing the solution. But novel problems are rare, so with a bit of research, it's quite easy to find answers.
- hnthrow90348765 1y ago>And in other cases, maybe a rough solution is better than not having anything at all. POCs are better for customer-facing, product management driven work. This is because they can be bad at describing what they want. There's more risk of building the wrong thing. POCs can be okay for system design or back-end work (or really anything not involving vague asks), but chances are planning and deeper thinking will help you more there because the problems you solve tend to be less subjective. Less risk of building the wrong thing.
- skydhash 1y agoRough solution in this case is more like a sketch compared to a painting, a few hours of work instead a week or two. The painting can be the main goal, but a sketch can be useful for some part. Kinda like scaling. Instead of going for Kubernetes, use a few VPS and a managed database to get your first customers.