3 ms·
Another way to state the problem is "you have to do it badly before you do it well". Not strictly true in every case, but software is in a broken state for most
by buzzybee 10y ago
Another way to state the problem is "you have to do it badly before you do it well". Not strictly true in every case, but software is in a broken state for most of its development and then suddenly works at the end, which is really weird and off-putting to human intuition. When the code just barely works then it works forever(given the same environment and inputs), while with most other processes it would be a improvement in success percentages or yield rates or other measures.
It also leads to an issue with never really knowing what good code looks like, because we have to consider both the "it's still in development and therefore expected to be broken but easily debugged" state and the "it's in production and should be fast, reliable, practical" state. It can be great at one and not the other if the stakeholders aren't approaching it in a balanced way.
- agentultra 10y agoSometimes it never gets to a "working" state and plods along in a "mostly not prone to errors." This works for games but when you get to payment systems, autopilot cars, and operating systems... Well it's not a good enough way of thinking. You need tools to help you think at a certain level of difficulty. Even for programmers we shamelessly glorify that level isn't very high... Yet hubris sometimes pushes us to make silly claims. I cannot disagree that "practice makes perfect." That applies at so many levels. One has to be comfortable with throwing things away and trying again. Practice dutifully and intentionally. Then realize what you don't know and where your limits are and have the humility and boldness to find ways to reach beyond them.
- kiba 10y agoDon't know how you write code, but I typically fix all visible bugs before moving on. If I want to complete a project, I make sure to scope a minimal set of features.