|
|
|
|
|
|
by m_0x
1036 days ago
|
|
|
You're stating > you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done". Somebody might interpret this statement as if nobody (in their context) should worry about writing good code. If you're writing good or bad code it doesn't matter as long as it works. Package and ship it and call it a day. But the author addresses this: > It's not even about good work. This is also a given. That's the default expectation, it's part of the package. The cake will be good. Then I'd say that you're paid for "good code that gets the job done". |
|
|
The comment you quoted refers to great/eloquent code. But you took it to mean something different.
Given the rehashing of these same memes in dev communities since the dawn of programming, I don't believe there is a strong agreement on what "good code" even means practically speaking, even though we mostly agree on abstract principles.
IMHO, I think there is an understandable hesitation among developers to accepting that they're doing 'job for hire' work, instead aligning more with the idea that they're put in charge to produce something "beautiful".
Ultimately, it's all messy machine code with goto's and jumps everywhere and "elegant" data structures turning into bits mashed together in memory. The comments, naming conventions, coding formats, etc are all long gone.
This is in stark contrast when producing something physical where the finer engineering aspects shine through in the final product.