(Like this article? Read more Wednesday Wisdom!) One of the problems with software engineering is that 99.9% of the time, and in the short term, bad code works about as well as good code. It might be slower, it might use more memory, it might be hard to extend, it might be hard to find and fix bugs, but by and large it kinda works. So if the only thing you care about is whether code kinda works here and now, and you are not inclined to change your ways, you might want to stop reading now and read
> One of the engineers proposed having a chat with the team responsible for the upstream system and tell them not to send that particular state change so that we wouldn't have to consider it.
> I am abhorred and endeared at the same time by so much innocence.
I'm glad to hear you say this. For me, maybe its because I lack trust in anything that I cannot directly control, but forward progress for me is always about something I have direct control of. I cannot guarantee other teams hold up their side of the bargain, so I focus on the aspects of the system I can fix to handle the 'environment' it's working in (sometimes that other team is a massive open source project that has even less control *cough* kubernetes *cough* [as opposed to another team in the same company where leaders may be shared and have influence]). That philosophy has always served me well and ensured that even when the contract is broken, the system continues to function.
> Or is this an unwinnable battle?
I have mostly resigned to this being unwinnable. I am trying again to win this battle. But its slow and painful and amounts to 1on1 convincing a person at a time. Critical mass looks like enough 'leaders' pushing I guess. And/or enough code that 'copying/pasting' any random snippet leads to the same result (as much as I hate copy/paste code).
This is where science/engineering meets art for me. And subjectiveness creeps in which makes it hard to 'win' (because what is 'winning'? is it even correct?). So, the table is already tilted against us. Beyond this, timelines motivate some folks to not care about these aspects (not necessarily their fault, they are at a different spot in life).
I find myself using the phrase that has always captured it so succinctly. "Culture eats strategy for breakfast". Individuals can shine in any culture, but the group culture has significant pressure to avoid change.
At the end of the day, there's only so much you can do. Code reviews, standards (including enforcement), and culture are about the only levers you can pull, right? If we view it through this lens, it becomes simpler. We can only pull certain levers, so why worry so much about finding more levers. Maybe I'm oversimplifying...
Writing "beautiful" code takes time, particularly taking the code from good -> great. It's a bit subjective on what is "great" code vs "good" code, but it is always good to cultivate great habits in writing solid code.
In most practical situations I've noticed that spending time writing beautiful code always has to be a bit tactical and has to be balanced carefully with priorities, project velocity and ROI. Sometimes we need code that gets the job done quickly, and in some others we need reusable code that's of good maintainable quality. So a subjective decision has to be made, depending on the situation.
In short, it's not always about how beautiful our code is, it's more about what the task definition is and if those requirements are met (with time in the picture).
I completely agree to the necessity of beautiful code, which is the platform for good reasoning and good contracts.
What is often forgotten is that beauty requires an adequate programming language to express it.
In terms of general-purpose programming languages the worst disease ever created is C++ (definition by Niklaus Wirth, visionary creator of Pascal; I 100% agree, the C++ ecosystem is a monstrosity).
The most beautiful and expressive language (by a margin, there is hardly any competition) is Scala 3.
Unless you like Haskell, which is the faculty of immutability and functional jurisprudence (fantastic for academic research, unusable in real-world projects, you do not want a language preventing a loop when a loop is appropriate).
Programming language capabilities & expressiveness are currently seen as a detail: this is a fallacy. This fallacy will need to end in the first place, otherwise we are trying to make good music on poor musical instruments.
Look at rust for example, it is heading in the right direction, it has type classes, no class inheritance (the trillion-dollar mistake of SW development, way worse then nullable values).
Rust brings so much innovation, it is getting somewhere, even with all the limitations of the borrowing mechanism. But if you want to declare a lambda in Rust, one of the most common operations in today’s SW, your guts revolt in anger, and then you write the damn lambda.
We want beautiful code? I am absolutely in favour of doing that. But please, first let's deprecate miscarriages like C++ and let's stop devising other syntactic and semantic monstrosities, hard coded into language specifications.
Without a collective power of will and without a collective effort, I fear we will remain buried in the ugliness of (way too many) language specifications.
In a nutshell, for what you describe in the article, good ergonomics is not an option, it’s a necessity.
Early on in my career I had to write an assembly-language program and send it to someone completely untested. It was not perfect, but I crafted and commented the code so they could understand what I was trying to do at each step, giving them the ability to find and fix the little error.
Another thing I often needed to do as a consultant was pick up someone else's massive assembly-language program - written for a platform I hadn't used before thus a language I hadn't used before - and add functionality. It was always delightful to be able to trim the code down to a smaller footprint while also making it more easily understood and managed.
I even detest stumbling across sloppy shell coding. It's just not necessary. A level of elegance leads to better efficiency in execution, as well as much easier maintenance going forward. I can indeed be a pain in the @$$ over this, but given I expect my audience to take what I have created and adjust it to their environment, it is required.
Yes, Yes, Yes. I was just bringing up this exact mindset in a code review this morning. My favorite is, I wrote it this way because that it how it was written last time. AHHHHHH!!!! If you continue to base your work on old standards, your work, and you will never evolve and you will quickly become obsolete.
While I agree to some extent, the problem I have with this positon is that beauty is subjective, and differs heavily from person to person. My elegant, concise, clean program is someone else's hopelessly terse and unfactored mess. Their well-designed, extensible, best-practice-following module is my horribly over-engineered design pattern cargo-culting YAGNI fest.
Now, you could simply say that I'm wrong and they're right (or vice versa), but in that case you'd be getting into more specific and objective attributes of the code, and using the word "beauty" for such a thing seems like a misuse of the term.
> One of the engineers proposed having a chat with the team responsible for the upstream system and tell them not to send that particular state change so that we wouldn't have to consider it.
> I am abhorred and endeared at the same time by so much innocence.
I'm glad to hear you say this. For me, maybe its because I lack trust in anything that I cannot directly control, but forward progress for me is always about something I have direct control of. I cannot guarantee other teams hold up their side of the bargain, so I focus on the aspects of the system I can fix to handle the 'environment' it's working in (sometimes that other team is a massive open source project that has even less control *cough* kubernetes *cough* [as opposed to another team in the same company where leaders may be shared and have influence]). That philosophy has always served me well and ensured that even when the contract is broken, the system continues to function.
> Or is this an unwinnable battle?
I have mostly resigned to this being unwinnable. I am trying again to win this battle. But its slow and painful and amounts to 1on1 convincing a person at a time. Critical mass looks like enough 'leaders' pushing I guess. And/or enough code that 'copying/pasting' any random snippet leads to the same result (as much as I hate copy/paste code).
This is where science/engineering meets art for me. And subjectiveness creeps in which makes it hard to 'win' (because what is 'winning'? is it even correct?). So, the table is already tilted against us. Beyond this, timelines motivate some folks to not care about these aspects (not necessarily their fault, they are at a different spot in life).
I find myself using the phrase that has always captured it so succinctly. "Culture eats strategy for breakfast". Individuals can shine in any culture, but the group culture has significant pressure to avoid change.
How about training an AI model on carefully handpicked changelists, which Jos extensively commented on? Maybe not yet. But maybe soon.
At the end of the day, there's only so much you can do. Code reviews, standards (including enforcement), and culture are about the only levers you can pull, right? If we view it through this lens, it becomes simpler. We can only pull certain levers, so why worry so much about finding more levers. Maybe I'm oversimplifying...
Writing "beautiful" code takes time, particularly taking the code from good -> great. It's a bit subjective on what is "great" code vs "good" code, but it is always good to cultivate great habits in writing solid code.
In most practical situations I've noticed that spending time writing beautiful code always has to be a bit tactical and has to be balanced carefully with priorities, project velocity and ROI. Sometimes we need code that gets the job done quickly, and in some others we need reusable code that's of good maintainable quality. So a subjective decision has to be made, depending on the situation.
In short, it's not always about how beautiful our code is, it's more about what the task definition is and if those requirements are met (with time in the picture).
I completely agree to the necessity of beautiful code, which is the platform for good reasoning and good contracts.
What is often forgotten is that beauty requires an adequate programming language to express it.
In terms of general-purpose programming languages the worst disease ever created is C++ (definition by Niklaus Wirth, visionary creator of Pascal; I 100% agree, the C++ ecosystem is a monstrosity).
The most beautiful and expressive language (by a margin, there is hardly any competition) is Scala 3.
Unless you like Haskell, which is the faculty of immutability and functional jurisprudence (fantastic for academic research, unusable in real-world projects, you do not want a language preventing a loop when a loop is appropriate).
Programming language capabilities & expressiveness are currently seen as a detail: this is a fallacy. This fallacy will need to end in the first place, otherwise we are trying to make good music on poor musical instruments.
Look at rust for example, it is heading in the right direction, it has type classes, no class inheritance (the trillion-dollar mistake of SW development, way worse then nullable values).
Rust brings so much innovation, it is getting somewhere, even with all the limitations of the borrowing mechanism. But if you want to declare a lambda in Rust, one of the most common operations in today’s SW, your guts revolt in anger, and then you write the damn lambda.
We want beautiful code? I am absolutely in favour of doing that. But please, first let's deprecate miscarriages like C++ and let's stop devising other syntactic and semantic monstrosities, hard coded into language specifications.
Without a collective power of will and without a collective effort, I fear we will remain buried in the ugliness of (way too many) language specifications.
In a nutshell, for what you describe in the article, good ergonomics is not an option, it’s a necessity.
Oooh, I love this!
Early on in my career I had to write an assembly-language program and send it to someone completely untested. It was not perfect, but I crafted and commented the code so they could understand what I was trying to do at each step, giving them the ability to find and fix the little error.
Another thing I often needed to do as a consultant was pick up someone else's massive assembly-language program - written for a platform I hadn't used before thus a language I hadn't used before - and add functionality. It was always delightful to be able to trim the code down to a smaller footprint while also making it more easily understood and managed.
I even detest stumbling across sloppy shell coding. It's just not necessary. A level of elegance leads to better efficiency in execution, as well as much easier maintenance going forward. I can indeed be a pain in the @$$ over this, but given I expect my audience to take what I have created and adjust it to their environment, it is required.
Yes, Yes, Yes. I was just bringing up this exact mindset in a code review this morning. My favorite is, I wrote it this way because that it how it was written last time. AHHHHHH!!!! If you continue to base your work on old standards, your work, and you will never evolve and you will quickly become obsolete.
While I agree to some extent, the problem I have with this positon is that beauty is subjective, and differs heavily from person to person. My elegant, concise, clean program is someone else's hopelessly terse and unfactored mess. Their well-designed, extensible, best-practice-following module is my horribly over-engineered design pattern cargo-culting YAGNI fest.
Now, you could simply say that I'm wrong and they're right (or vice versa), but in that case you'd be getting into more specific and objective attributes of the code, and using the word "beauty" for such a thing seems like a misuse of the term.