191–200 of 216 posts
Earlier quoted context omitted.
It absolutely is, though many people would agree with you.
Statistically 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.
HTMX project has an impressive simplicity that is worth reading: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
Earlier quoted context omitted.
The craft is solving the problem, not endlessly circling around it. perfect is the enemy of good
My 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.
I really like the go standard library. It's all really clear and easy to understand https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/... https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/...
It's worth noting, Go's stdlib isn't perfect, but that's part of why it's so good. You can see how they've deprecated certain methods/fields/etc while maintaining backwards compatibility.
Earlier quoted context omitted.
it's strange seeing someone with absolutely no pride in their craft.
The craft is solving the problem, not endlessly circling around it. perfect is the enemy of good
> make it work, then make it pretty, then make it performant
Solve the problem first, then improve the solution
Earlier quoted context omitted.
My 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.
Your “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.
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…
Earlier quoted context omitted.
My 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.
Your “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.
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.
Earlier quoted context omitted.
What are these iternant code students trying to achieve with all this? Performance? Productivity? Lower defects? Safety critical code seems to still be usually in C/C++, for reasons having nothing to do with the language being safe. Why are these people not studying Erlang, MISRA C, Rust, some kind of formal proof solver language, or OpenCL? What do people aspire to one day work on that would make the Haskell or LISP…
Mastery, perhaps. They see some sort of role model and figure the tools they use are a roadmap to becoming a distinguished engineer themselves. If only it was that easy. It is interesting how functional programming has to consider data organization completely differently, but sometimes it is just that, a tool or methodology, not a philosophy to subscribe to. Ideally, the good (or future good) engineers realize this a…
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
A painter might study and practice enough to be as good as Michealangelo, but the attempt to be 'more good' or 'better than Michaelangelo' stops as soon he starts a serious painting. He has to finish the painting with the skill he has at that point.
I agree code should be unattached and you can throw it away. As soon as you start coding a program for a client, your attempts to become 'more good' as a coder and to write more ideal code, have stopped and it's time to make some code you can throw away or sell to the client.
But all the 'training' paintings you made on the journey to becoming 'good' have to be kept, because you trashed thousands of attempts along the way in pursuit of an ideal painting. The good painting is framed and hung on my wall. The commercial painting is sold to the client or trashed.
Yes, give up on 'good code' at work. Keep the ideal of good code as a direction to improve towards, not an end result in commercial works.
As soon as 'good' became explictly defined/bike-shedded it died anyway..... it's an infinite direction, not a limited thing that can be defined and boxed up.
Earlier quoted context omitted.
> Don't copy and paste the same implementation x times because that way there's only one place to fix it. But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I think the purpose of questions like the ones by OP is not to figure out "rules" (which are useful only for beginners) but to figure out where and why rules were broken. Sometimes (often) the answ…
> But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I find that's a smell of limited languages: Maybe a language has poor error handling semantics, maybe it's not expressive enough to make a parameter generic. It can also be a smell of not understanding the language well enough, too. Maybe there is no need to copy and paste, but the programmer didn't…
But you can only do what your tools allow you to do.