> 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.
Culture _does_ eat strategy for breakfast. And at the end of the day, the culture is what you _do_. Your strategy might be whatever it is, but it is what you do day in day out what matters.
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).
There is definitely a case for throw-away code and as with most things, the quality of the code needs to be balanced with other things. I do however think that code "beauty" is one of these things where with 20% of effort you can reach 80% of the result, which makes it worthwhile to aspire to in most situations.
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.
I _knew_ you were going to come out in favour of Scala :-)
I think beautiful code can be written in most languages, although, like German poetry, you probably need an in-depth understanding of the language in order to see the beauty. In that sense, German is a lot like C++: Full of unnecessary constructs and misplacing one small thing can completely change the meaning and wreck the interpretation. For the record: I like C++ and I love German :-)
While writing this the following story comes to mind: Once I was writing some Perl5 with Qt (don't ask), and a friend of mine was watching over my shoulder and cried out: "OMG, this is Perl, and I understand what is going on!"
Thanks, Jos, for your feedback. Yes, mentioning Scala was necessary here :)
Allow me to thank the Scala team and prof. Odersky for building up on Niklaus With's legacy of beauty of expressiveness, you still see Pascal in today's Scala 3.3+ new syntax, I urge everyone to look at this, it is inspiring beyond the computing domain.
At the end it's not so relevant if something is possible, but if it is appropriate. Is C++ appropriate today, beyond personal preferences? I think it's not. It might make sense for a lifetime C++ programmer, but how do you explain all the intricacies of C++ to a novice, including the obscurities of its build tools?
I particularly appreciate your analogy between C++ and German :))) It's hard to beat German at humanistic precision (I doubt there is any better than German for philosophy).
Conversely, how can German make sense for the aeronautical engineering, if someone was not raised as a native speaker ? A turbofan engine, commonly used in commercial aviation, in German becomes.... uhm, let me take a deep breath, there are five definitions:
Mantelstromtriebwerk, auch Nebenstromtriebwerk, Zweistromstrahltriebwerk, Zweistrom-Turbinen-Luftstrahltriebwerk (ZTL) oder Fantriebwerk.
It's still possible to use German to do good jet engines of course, but if you want to have a foreigner to come to Germany and think in those terms, you will (unsurprisingly) hit a barrier, the same barrier a C++ novice hits today.
Long story short: I respect all effort, also C++ which was invented a long time ago, I just think C++ should have been thankfully abandoned and replaced (with a sense of relief) around 2000 - 2005, because it is hard beyond personal preferences :)
But at the end I agree with you Jos, you can indeed write beautiful C++ code, and I am sure you and others did. With a bit of emotional reluctance, I think you are right: what I see as a too conservative attitude might look spicy to others 😉 There is no universal definition of beauty.
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.
There is definitely a personal and subjective aspect to beauty, but the concept of beauty that I am talking about is one that has functional aspects to it. It's the kind of beauty that is expressed by Howard Roark in Ayn Rand's novel "The Fountainhead": "Nothing can be reasonable or beautiful unless it's made up of one central idea, and the idea sets every detail".
Not that I am an Ayn Rand follower, not at all, but I love that quote :-)
> 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.
Culture _does_ eat strategy for breakfast. And at the end of the day, the culture is what you _do_. Your strategy might be whatever it is, but it is what you do day in day out what matters.
How about training an AI model on carefully handpicked changelists, which Jos extensively commented on? Maybe not yet. But maybe soon.
Or on the entire FreeBSD kernel source code?
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...
There is definitely only so much we can do. But let's at least to _that_ :-)
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).
There is definitely a case for throw-away code and as with most things, the quality of the code needs to be balanced with other things. I do however think that code "beauty" is one of these things where with 20% of effort you can reach 80% of the result, which makes it worthwhile to aspire to in most situations.
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.
I _knew_ you were going to come out in favour of Scala :-)
I think beautiful code can be written in most languages, although, like German poetry, you probably need an in-depth understanding of the language in order to see the beauty. In that sense, German is a lot like C++: Full of unnecessary constructs and misplacing one small thing can completely change the meaning and wreck the interpretation. For the record: I like C++ and I love German :-)
While writing this the following story comes to mind: Once I was writing some Perl5 with Qt (don't ask), and a friend of mine was watching over my shoulder and cried out: "OMG, this is Perl, and I understand what is going on!"
Thanks, Jos, for your feedback. Yes, mentioning Scala was necessary here :)
Allow me to thank the Scala team and prof. Odersky for building up on Niklaus With's legacy of beauty of expressiveness, you still see Pascal in today's Scala 3.3+ new syntax, I urge everyone to look at this, it is inspiring beyond the computing domain.
At the end it's not so relevant if something is possible, but if it is appropriate. Is C++ appropriate today, beyond personal preferences? I think it's not. It might make sense for a lifetime C++ programmer, but how do you explain all the intricacies of C++ to a novice, including the obscurities of its build tools?
I particularly appreciate your analogy between C++ and German :))) It's hard to beat German at humanistic precision (I doubt there is any better than German for philosophy).
Conversely, how can German make sense for the aeronautical engineering, if someone was not raised as a native speaker ? A turbofan engine, commonly used in commercial aviation, in German becomes.... uhm, let me take a deep breath, there are five definitions:
Mantelstromtriebwerk, auch Nebenstromtriebwerk, Zweistromstrahltriebwerk, Zweistrom-Turbinen-Luftstrahltriebwerk (ZTL) oder Fantriebwerk.
It's still possible to use German to do good jet engines of course, but if you want to have a foreigner to come to Germany and think in those terms, you will (unsurprisingly) hit a barrier, the same barrier a C++ novice hits today.
Long story short: I respect all effort, also C++ which was invented a long time ago, I just think C++ should have been thankfully abandoned and replaced (with a sense of relief) around 2000 - 2005, because it is hard beyond personal preferences :)
But at the end I agree with you Jos, you can indeed write beautiful C++ code, and I am sure you and others did. With a bit of emotional reluctance, I think you are right: what I see as a too conservative attitude might look spicy to others 😉 There is no universal definition of beauty.
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.
There is definitely a personal and subjective aspect to beauty, but the concept of beauty that I am talking about is one that has functional aspects to it. It's the kind of beauty that is expressed by Howard Roark in Ayn Rand's novel "The Fountainhead": "Nothing can be reasonable or beautiful unless it's made up of one central idea, and the idea sets every detail".
Not that I am an Ayn Rand follower, not at all, but I love that quote :-)