This feels like a lot of rationalization for the purpose of excusing writing exactly the sort of code that Kernighan advised against.
Advising against writing complex code is not advising against learning.
The person who solves a hard problem correctly using simple code has generally spent more time learning than the person who solves it using complex code.
Yes, I agree this is true in some (many?) cases. But it is also true that sometimes the more complex solution is better, either for performance reasons or because it makes things simpler for users/API callers.
Yes, there's a valid argument that simple code is not always best performance. Optimizing simple code usually makes it more complex.
But I think the main point stands. There's an old saying that doing a 60 minute presentation is easy, doing one in 15 minutes us hard. In other words writing "clever" (complicated) code is easy. Distilling it down to something simple is hard.
So the final result of any coding might be "complex", "simplified from complex", or "optimized from simple".
The first and third iterations are superficially similar, although likely different in quality.
If debugging is 2 times harder than writing code we have at least two choices. One suggests to write simpler code. But another one means not debugging code at all, which may be achieved by using a programming language way better than C, which allows fixing (almost) all bugs in compilation time.
I like this insight, even though I think they are pushing Kernighan's quip a little too far.
I take away two ideas:
1. Always be learning. I think everyone believes this, but we often come up with plausible reasons to stick to what we know. This is a good reminder that we should fight that impulse and put in the effort to learn.
2. Always be fearless. This, I think, is the key insight. Fear is easy. We fear the unknown, whether they be APIs or someone else's code. We fear errors, particularly when they have real-world consequences. And we fear complexity, because we think we might not be able to deal with it. But the opposite of fear isn't recklessness, it's confidence. We should be confident that we will figure it out. And even if we don't figure it out, we should be confident that we can revert the code. Face your fears and grow.
This article can be summarised in one word: learning. I've noticed over the years that there seems to be a growing divide amongst programmers, between those who believe in learning, and those who don't (and actively try to avoid it); unfortunately the latter has become a majority position, but I still try to show others this article when they don't understand code that I've written and would rather I stoop to their level.
A look around the site at what else he has accomplished, should be enough evidence that he isn't just a charlatan, unlike some others who have made a consulting career out of spouting pompous hot air about methodology.
> You effortlessly wield clever programming techniques today that would've baffled your younger self. (If not, then I'm afraid you stopped evolving as a programmer long ago.)
... Perhaps if we allow that "clever techniques" can yield simpler results than my former self did.
This feels like a lot of rationalization for the purpose of excusing writing exactly the sort of code that Kernighan advised against.
Advising against writing complex code is not advising against learning.
The person who solves a hard problem correctly using simple code has generally spent more time learning than the person who solves it using complex code.
Yes, I agree this is true in some (many?) cases. But it is also true that sometimes the more complex solution is better, either for performance reasons or because it makes things simpler for users/API callers.
Yes, there's a valid argument that simple code is not always best performance. Optimizing simple code usually makes it more complex.
But I think the main point stands. There's an old saying that doing a 60 minute presentation is easy, doing one in 15 minutes us hard. In other words writing "clever" (complicated) code is easy. Distilling it down to something simple is hard.
So the final result of any coding might be "complex", "simplified from complex", or "optimized from simple".
The first and third iterations are superficially similar, although likely different in quality.
If debugging is 2 times harder than writing code we have at least two choices. One suggests to write simpler code. But another one means not debugging code at all, which may be achieved by using a programming language way better than C, which allows fixing (almost) all bugs in compilation time.
I like this insight, even though I think they are pushing Kernighan's quip a little too far.
I take away two ideas:
1. Always be learning. I think everyone believes this, but we often come up with plausible reasons to stick to what we know. This is a good reminder that we should fight that impulse and put in the effort to learn.
2. Always be fearless. This, I think, is the key insight. Fear is easy. We fear the unknown, whether they be APIs or someone else's code. We fear errors, particularly when they have real-world consequences. And we fear complexity, because we think we might not be able to deal with it. But the opposite of fear isn't recklessness, it's confidence. We should be confident that we will figure it out. And even if we don't figure it out, we should be confident that we can revert the code. Face your fears and grow.
If debugging is the art of removing faults, then programming is the art of putting them in.
(2012)
This article can be summarised in one word: learning. I've noticed over the years that there seems to be a growing divide amongst programmers, between those who believe in learning, and those who don't (and actively try to avoid it); unfortunately the latter has become a majority position, but I still try to show others this article when they don't understand code that I've written and would rather I stoop to their level.
A look around the site at what else he has accomplished, should be enough evidence that he isn't just a charlatan, unlike some others who have made a consulting career out of spouting pompous hot air about methodology.
(2012)
> You effortlessly wield clever programming techniques today that would've baffled your younger self. (If not, then I'm afraid you stopped evolving as a programmer long ago.)
... Perhaps if we allow that "clever techniques" can yield simpler results than my former self did.
This article says nothing of substance.