ChatGPT can read your shirt with zero issue. I screen snipped it, and had the following interaction: >> You >> Uploaded image >> what does this say >> >> ChatGPT >> The text on the shirt is a leetspeak representation of the quote "The measure of intelligence is the ability to change," which is often attributed to Albert Einstein. In leetspeak, letters are often replaced by numbers or other characters that resemble the letters. Here's the text translated into standard English letters: >> >> THE MEASURE OF INTELLIGENCE IS THE ABILITY TO CHANGE. >> The text at the bottom appears to be "ALBERT EINSTEIN" represented in a similar leetspeak style. RIP
I have been grappling with the idea of readability vs consistency vs optimized. But to bring this altogether with, must be “easy to change”, mind blow. So simple, but so true. My design approach has forever changed.
kind of own recipe... every time I begin working on a US, I spend the most reasonable amount of time NOT WRITING CODE, resisting the temptation of writing, but reading well the requirements, looking how this must fit into the existing software, and designing the solution. I try to figure out, without writing a single line of code, all the data circuits, the layers, classes and so on. Most of the time, the whole meditation exercise goes less than 10% of the time estimated. This gives you the opportunity to refine this design and avoid programming vices, since you have nothing materialized, but in your gray tissue only.
When I say aim for readability, I mean both as text, like it were English, and I also mean "does that block of code really need to be a block or can we turn it into a line?" Recently I added a comment to a pull request and said I would move that block to a method. The response was "but it's only called once". My response was "I mean readability in the sense that a new person learning this specific class file will come to this block of code with the intention to focus on a subsequent section of that block and get distracted by it." Even if you're only executing the method once per transaction, a block of code that adds cognitive complexity should become a line of code.
If you remove a block from its usage context and put it somewhere else, when you need to connect multiples of these together, it can make the code less readable, not more. It's tradeoffs all the way down. I prefer commented code blocks in somewhat larger methods - I consider it the best of both worlds. If I don't need the details of what it does I can jump to the next block of code. If I do then it's right there. When I need to fully understand what it's doing, it makes it a lot easier. I think a killer IDE feature would be to setup a view that lets you inline-expand method calls. This way you could still easily get the full context with many small methods.
I have heard that argument before, but top be honest, I don't get it. The logical conclusion is that functions obscure meaning, and all code in-line is the ideal, that makes no sense to me. Functions give us the chance to assign meaning to otherwise arbitrary blocks of code. I don't care how many times a block of code is called, if I can describe what its is meant to do with a name I prefer to do so.
I think a lot of time is spent on trying to figure out the ultimate design principles, and not enough time is spent on the human element of coding If you have apathetic developers in survival mode who are resentful towards their company and their boss, or who are not supported by a proper set of motivations, it doesn't matter what design/architecture principles you pick, you aren't going to end up with a masterpiece
I speak about medium sized projects with different skill levels and roles. The software design is a key part to get the project done. A good design is able to show the team members how to produce good software.
Thank you! Another really great video. What do you think about 'convention'? As the convention that the team may be already familiar with - used in this or previous projects - and obviously, if it's not a terribly bad designed convention. Following conventions in my opinion also plays extremely important part in making the code readable at the whole system scale. The worst thing is if every subsystem of the system is using different design patterns - even if correctly applied - but to a concepts for which there is already a well design convention across the team.
Do you believe there's a universal metric or principle that can be applied to evaluate the 'elegance' of a software design, or is elegance always context-dependent? How might we reconcile differing opinions on what constitutes an 'elegant' design in a collaborative environment?
I think it was Bob Martin who once said that 'good software must be boring to read' in the sense that there is no trickery, no obscure or tweaked meaning in it. This and SLA (Single Level of Abstraction) is a must for me. Not sure if that qualifies as 'elegant' but for the minimum 'goodness' of the design I think is ok.
Only metric I can think of is change cycle time. How long does it take, in aggregate, to go from starting to make a change to that change being used by users. But it is quite abstract and far away from actual code and technologies. And involves much more than that.
7:50 - Method split is not getting enough love even today. Too bad, because it's one of the best refactorings to improve readability, clarity and add more context and meaning to your code. Instead, I see engineers prefer to leave multi-line comments instead of refactoring their code...
In my first decade as a software developer I thought the problem was that it were too few poets and way too many engineers in software development, nowadays I think the main problem is the textfile itself, maybe we should have some c4 capabilities in the daw - forcing the developer to think about modules and relationships before he even can write his first if-else
ChatGPT can read your shirt with zero issue. I screen snipped it, and had the following interaction:
>> You
>> Uploaded image
>> what does this say
>>
>> ChatGPT
>> The text on the shirt is a leetspeak representation of the quote "The measure of intelligence is the ability to change," which is often attributed to Albert Einstein. In leetspeak, letters are often replaced by numbers or other characters that resemble the letters. Here's the text translated into standard English letters:
>>
>> THE MEASURE OF INTELLIGENCE IS THE ABILITY TO CHANGE.
>> The text at the bottom appears to be "ALBERT EINSTEIN" represented in a similar leetspeak style.
RIP
I have been grappling with the idea of readability vs consistency vs optimized. But to bring this altogether with, must be “easy to change”, mind blow. So simple, but so true. My design approach has forever changed.
kind of own recipe... every time I begin working on a US, I spend the most reasonable amount of time NOT WRITING CODE, resisting the temptation of writing, but reading well the requirements, looking how this must fit into the existing software, and designing the solution. I try to figure out, without writing a single line of code, all the data circuits, the layers, classes and so on. Most of the time, the whole meditation exercise goes less than 10% of the time estimated. This gives you the opportunity to refine this design and avoid programming vices, since you have nothing materialized, but in your gray tissue only.
One step that really does good things for me is to, even before the design, define the problem using the user-centric verification language
When I say aim for readability, I mean both as text, like it were English, and I also mean "does that block of code really need to be a block or can we turn it into a line?" Recently I added a comment to a pull request and said I would move that block to a method. The response was "but it's only called once". My response was "I mean readability in the sense that a new person learning this specific class file will come to this block of code with the intention to focus on a subsequent section of that block and get distracted by it." Even if you're only executing the method once per transaction, a block of code that adds cognitive complexity should become a line of code.
If you remove a block from its usage context and put it somewhere else, when you need to connect multiples of these together, it can make the code less readable, not more.
It's tradeoffs all the way down.
I prefer commented code blocks in somewhat larger methods - I consider it the best of both worlds. If I don't need the details of what it does I can jump to the next block of code. If I do then it's right there. When I need to fully understand what it's doing, it makes it a lot easier.
I think a killer IDE feature would be to setup a view that lets you inline-expand method calls. This way you could still easily get the full context with many small methods.
@@bobbycrosby9765 A block of code that populates a list to be passed downstream is not that kind of example.
yes, naming blocks of code is a significant tool to help readability
I have heard that argument before, but top be honest, I don't get it. The logical conclusion is that functions obscure meaning, and all code in-line is the ideal, that makes no sense to me. Functions give us the chance to assign meaning to otherwise arbitrary blocks of code. I don't care how many times a block of code is called, if I can describe what its is meant to do with a name I prefer to do so.
I think a lot of time is spent on trying to figure out the ultimate design principles, and not enough time is spent on the human element of coding
If you have apathetic developers in survival mode who are resentful towards their company and their boss, or who are not supported by a proper set of motivations, it doesn't matter what design/architecture principles you pick, you aren't going to end up with a masterpiece
Readable in the sense that I can read it... Without getting a headache
I speak about medium sized projects with different skill levels and roles. The software design is a key part to get the project done. A good design is able to show the team members how to produce good software.
Thank you! Another really great video.
What do you think about 'convention'? As the convention that the team may be already familiar with - used in this or previous projects - and obviously, if it's not a terribly bad designed convention.
Following conventions in my opinion also plays extremely important part in making the code readable at the whole system scale. The worst thing is if every subsystem of the system is using different design patterns - even if correctly applied - but to a concepts for which there is already a well design convention across the team.
Love how the choice of tee matches the video topic
Nice guidelines video, whats means/express the "Cohesive" and "Good separation of concern" parameters at min. 15?
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Do you believe there's a universal metric or principle that can be applied to evaluate the 'elegance' of a software design, or is elegance always context-dependent? How might we reconcile differing opinions on what constitutes an 'elegant' design in a collaborative environment?
I think I'd vote for 'Cost of change' to be that metric. Software that's easy to change is equivalent to well-designed software for me
I think it was Bob Martin who once said that 'good software must be boring to read' in the sense that there is no trickery, no obscure or tweaked meaning in it. This and SLA (Single Level of Abstraction) is a must for me. Not sure if that qualifies as 'elegant' but for the minimum 'goodness' of the design I think is ok.
exactly, because otherwise why would we need a good software design ? for the looks ?@@jangohemmes352
Only metric I can think of is change cycle time. How long does it take, in aggregate, to go from starting to make a change to that change being used by users. But it is quite abstract and far away from actual code and technologies. And involves much more than that.
Guiding principles :
1) Understandability/Readability
2) Easy to change
the essay by Jack Reeves should really have been provided as a reference. good coherent summary overview of design - as a noun - in any case.
7:50 - Method split is not getting enough love even today. Too bad, because it's one of the best refactorings to improve readability, clarity and add more context and meaning to your code. Instead, I see engineers prefer to leave multi-line comments instead of refactoring their code...
In my first decade as a software developer I thought the problem was that it were too few poets and way too many engineers in software development, nowadays I think the main problem is the textfile itself, maybe we should have some c4 capabilities in the daw - forcing the developer to think about modules and relationships before he even can write his first if-else
not that the poets and squareheads problem is solved in any way - just the lesser evil
I expected clickbait from anyone except Dave Farley.
Readable for whom? For another expert programmer, another domain expert or for any person who wants to know what this program does?
i lost focus on first watch, because i was trying to decipher that dam t-shirt :D
I'm not sure what i took away from this video, the t shirt is cool though.
If you have favs of text or IDE, might as well settle the decades old debate of tab or spaces. For some fun sake. Haha
first view lol