6 ms·
This mentality is how you end up inheriting terrible codebases.
by farresito 3y ago
This mentality is how you end up inheriting terrible codebases.
- Zetice 3y agoI would rather write “bad” code that lasts long enough to be inherited than write perfect code that sits idle in a repo because I missed the market.
- farresito 3y agoWriting good code doesn't necessarily take more effort than writing bad code; in fact, my experience tells me otherwise. Teams that write good code iterate faster.
- Zetice 3y agoThe point I'm trying to make is that the pursuit of "good" code is futile, as it does take more effort to achieve than writing functioning code. But in a way you're right; if there is no to ensuring your code follows more conventions, go for it. That's exceedingly rare, however, as a situation to be in.
- bluefirebrand 3y agoWhat property of the "good code" allows them to iterate faster? Is it because it's perfectly abstracted and encapsulated and SOLID and DRY? Or is it because it's written in a manner, easy to understand, easy to extend, and easy to throw away and rewrite if necessary?
- nurettin 3y agoIt's abstracted a little bit, but every abstraction is designed to lift a roadblock and reused multiple times like an old tool. And special effort has been spent on avoiding technical debt (hard coded stuff, untested stuff, overloaded or missing properties) to the point of doing things with less effort.
- eternityforest 3y agoEveryone's opinion is it's based on the code they actually work with(And devs have lots of personal projects which adds bias, because they think stuff is a good idea just because it works on 1000 line projects)... I'm guessing solid and dry are a big part, but lack of cleverness, language choice that doesn't require cleverness, and heavy reuse with libraries and frameworks, and choice of feature complete libraries is probably a lot of the speed. Something in C is going to be more work than JS or Python or Dart and work takes time. Code you write takes more time than code that already exists, unless the code that exists disappears one day.
- johnnyanmac 3y ago>Or is it because it's written in a manner, easy to understand, easy to extend, and easy to throw away and rewrite if necessary? This. But IME when you write for this purpose you tend to end up with code that is in fact confusing, not documented, and not test covered. So you need to slow down even if your goal is to one day completely re-write that module. Perfect abstractions are never perfect unless you completely architect out the product, down to every single edge case. That's virtually impossible with a large codebase, be it due to an API or even compiler level bug.
- happytoexplain 3y ago>because I missed the market This is not relevant to the vast majority of developers, realistically (and is an important caveat to your original comment).
- Zetice 3y agoIt absolutely is, though many people would agree with you.
- johnnyanmac 3y agoStatistically speaking, most developers are not working for startups. And of course, large companies have the sway and politics to go around not being first. e.g. Apple isn't worried about missing the market, they are trendsetters and they light a market up even when 10 years late to it.
- Zetice 3y agoYour “market” can be an internal customer.
- zer8k 3y agoit's strange seeing someone with absolutely no pride in their craft.
- throwmeout123 3y agoThe craft is solving the problem, not endlessly circling around it. perfect is the enemy of good
- johnnyanmac 3y agoMy craft is not leaving a dumpster of a solution to the next people to look at my code when business logic inevitably changes. If someone's solution to seeing my code is "we gotta re-write it", I have either failed or a much more novel solution was discovered that makes my code irrelevant. I hope it's not the former.
- Zetice 3y agoYour “craft” is not to write code, it’s to solve problems. If you can’t be proud of the problem you’ve solved, you are no engineer. That’s the main difference between an engineer and a scientist.
- gitgud 3y agoI think coding is a balance of 2 problems The first is the business problem, most important. The second is the problem of maintaining and iterating on the solution to 1… Without solving the first problem, the business dies and you don’t even need to care about the second problem… however the second problem can also kill the business if not solved eventually…
- johnnyanmac 3y agoSure, and a civil engineer can solve a water leakage problem with duct tape. Real prideful moment. As I said, it depends on the project. I'm not going to approach a leaky faucet the same way I would an industrial sewage pipe. Fortunately the industry is big and I can choose to work on larger problems where longevity is valued over throughput. You're fine whipping together a React App in a weekend While I'd be more the end of maintaining the React repository. To each their own.
- ska 3y agoMost people would, I'm sure. On the other hand, those aren't the only two choices, by a long shot.
- tom_ 3y agoThe whole point of the rules in the second paragraph are that you can then fix it without needing to replace the whole thing in one go!