3 ms·
I think it's hard to jump straight to "do it right" as step 1, because it's often not actually clear what "right" means until you actually have running code. Ed
by anyonecancode 3y ago
I think it's hard to jump straight to "do it right" as step 1, because it's often not actually clear what "right" means until you actually have running code. Editing is easier than writing. Few essays, books, or software projects can skip having at least a first draft.
There are two problems that tend to keep much software in what is essentially the "draft" stage, though. One, articulated by many on this thread, is that business incentives really push to "if it's working well enough, it's working well enough." And as some have noted, that's not necessarily a problem! We're, most of us, writing software for pay here, not for fun or personal expression. But! As engineers, we have more insight into if it's really working "well enough" (assuming that we, as engineers, have also taken the time to make sure we understand the product we're building). Things like performance, security, and maintainability are part of making sure it's "good enough," but our non-technical partners and stakeholders can't necessarily see this, and part of our role is to help them see this so that they are making truly informed decisions on if it really is "good enough."
Second, and I feel bad saying this, there's often a dearth of widespread technical ability to actually take code from "ok" to "good." I don't mean this in an elitist way of saying some programmers are just better than others -- I do truly believe that with proper support and mentoring almost anyone who wants to become a better programmer can (see my user name). But I think that as an industry, we actually do a poor job helping our colleagues advance and deepen their skill. The ratio of skilled programmers to new is too small, and of skilled programmers with ability and inclination to level up their junior colleagues even smaller.
That's a decision by business leaders, who by and large have decided that junior-heavy, cheaper dev teams are "good enough."