61–70 of 123 posts
Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.
I don't think that's a fair way to judge the content, but I also didn't get more than I expected out of an blog post named "Mastering Programming"
Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example: > Call your shot. Before you run code, predict out loud exactly what will happen. M, okay, but what exactly do you mean by that? Or even poetic, kind of: > Rhythm. Waiting until the right moment preserves energy…
The Rhythm one baffled me as well. I've been coding for 15 years and this bullet was one I couldn't find something to relate to or guess at its meaning. Maybe it was more of a business aspect/market timing for a new product?
You will sometimes need to work very fast in order to push your change while everything else does not change much. In these cases, it's important to be able to enter crunch mode, and it's equally important to alternate crunch modes with slower paced work to not burn out.
At least, that's how I see it...
Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example: > Call your shot. Before you run code, predict out loud exactly what will happen. M, okay, but what exactly do you mean by that? Or even poetic, kind of: > Rhythm. Waiting until the right moment preserves energy…
Slicing: No. Cut the project into appropriate-sized slices. Cut big slices into sub-slices. Hierarchy is your friend.
One thing at a time: Yes.
Make it run, make it right, make it fast: Yes.
Easy changes: No good changes are hard once you own the result. If a change feels hard it's probably not good yet.
Concentration: That's one of two approaches. IMO either rearrange the code so you only need to change in one place, or rearrange your change so that the code only has to change trivially in any place.
Isolation: Depends.
Baseline: Yes.
Call your shot: Yes, but only because it means "know what you think will happen" which means "understand the codebase". If you're working on someone else's codebase, discard this and replace it with "try things and learn from them."
Multiple scales: Yes.
Symmetry: You mean 'factoring'. But yes.
Aesthetics: We define beauty as solving problems efficiency. If it's ugly but it's the best answer, we'll learn to think it's beautiful.
Rhythm: Yep. A time for all things.
Tradeoffs: Yes. You can't make a call til you understand the context.
Fun list: I guess that works.
Feed ideas: Never be afraid to ask what-if.
80/15/5 rule: Situational. If current low risk work is gravy spend 100% on that. If not, dig into R&D.
Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.
I've seen a lot of programmers that love design patterns, SOLID code, and hip new frameworks; but hate talking to users, getting stuff shipped or keeping things running. Even if the code is "messy" and given that JUnit is used by millions of programmers hourly without trouble, I suspect Kent prefers the latter to the former and which makes him a master programmer in my book.
Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.
I've seen a lot of programmers that love design patterns, SOLID code, and hip new frameworks; but hate talking to users, getting stuff shipped or keeping things running. Even if the code is "messy" and given that JUnit is used by millions of programmers hourly without trouble, I suspect Kent prefers the latter to the former and which makes him a master programmer in my book.
I think these tasks are not meant for programmers in the first place. But indeed it's beneficial when programmers know how to handle those things properly.
This looks like an outline for a potentially interesting article. But the language is too vague to even know how to react to the ideas. What is meant by "extracting a subelement"? "Make the problem easy" sounds great but could mean lots of different contradictory things. So please write the articles being hinted at in this outline, but as is, it's a bit tough to get anything from it.
I feel like I know what Kent is talking about behind most of these points, even though his words only hint at the deeper principle. He's trying to be too brief, but I can tell there's depth there.
For many of the points, I had to think a bit, and then it clicked, "Oh, he's talking about xyz. Yep, he's right. But his words don't really say that."
Kent Beck is not some AbstractFactoryStrategySingleton fool. I've learned a ton of insights from him, and I've seen him articulate insights that I had stumbled across and incorporated, but had not been able to articulate.
I'll grant you that some other talking heads often lumped in with Beck have been overhyped and their rhetoric has run ahead of their insight. And no one is perfect. But Beck usually has real insight behind what he is saying, and this IMO is no exception.
Earlier quoted context omitted.
This is the crux of the problem with a lot of software engineering culture as it stands today - blog posts and talks frequently deliver abstract concepts that only really make sense to people who have already grasped/discovered those concepts. The enlightened sit nodding along, while the unenlightened go away confused or misled. Positioned this way, half-understood ideas frequently do more harm than good. TDD is a gr…
> The enlightened sit nodding along, while the unenlightened go away confused or misled. It's the same with maths. It's even worse when the concepts are explained in a circular way. Go to wikipedia and search for a random mathematical concept. I guarantee you that most of the terms used in the explanation have wikipedia articles that link back to the concept you looked up in the first place! Frustrating beyond belief…
It's also that most people who teach just don't have Feynman levels of understanding. Mostly we are all kind of groping in the dark, and we all participate in some kind of cargo cult.
I also think there's a deep problem with how people want to learn math, and other abstract concepts. Look at how frustrated many students get by notions like imaginary numbers, groups, and monads. These things provoke some serious anxiety and confusion because students want to understand what they "really are" in some clear and straightforward way, when really all they are is hard-won abstract definitions that have proven interesting or somehow useful.
In a way it's disappointing that math books need to have "exercises." Why can't they just explain in a comprehensible way? I guess it's because the topics of study are abstract relations that only sometimes have some analogy in the "real world" (of course, some mathematicians believe that the structures of mathematics are in some sense the most real of all)...