On code clarity: you can't be proud of something I can't read
1–4 of 4 posts
Re: On code clarity: you can't be proud of something I can't read
#2Are developers often proud of their code? I'm pretty sure most developers who open up their projects to the world and say "look at what I built" are proud of the result of their code, not the code itself.
I'm not sure I've ever met a developer who is genuinely pleased with their code beyond a nice implementation of an algorithm or a neatly abstracted class. Most of us are deeply, sometimes overly, modest and humble about how readable our code is.
Re: On code clarity: you can't be proud of something I can't read
#3On the analogy of the architect ... It's probably wrong to say that "it was built on a shaky foundation that will collapse sooner rather than later" and it's more accurate to say that another architect or professional engineer might not be able to understand the intent behind the drawings/plans and thus make necessary changes without compromising the building's structural integrity.
Re: On code clarity: you can't be proud of something I can't read
#4Are developers often proud of their code? I'm pretty sure most developers who open up their projects to the world and say "look at what I built" are proud of the result of their code, not the code itself. I'm not sure I've ever met a developer who is genuinely pleased with their code beyond a nice implementation of an algorithm or a neatly abstracted class. Most of us are deeply, sometimes overly, modest and humble a…
I don't think it's fair to separate the code and the software itself. I personally don't feel proud of the result of a piece of software if the code is crappy, i.e. spaghetti code, (almost) unreadable, unmaintainable, ...
I think what the author wanted to emphasize was the importance of code clarity, as many of us developers don't actually care. Bad code builds up negative tech debts that somebody has to pay at some point in the future.