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 think that pretty clearly illustrates that Kent and Ward were wrong and Cedric was right. And yet I still listen to both of them about other things.
Nobody has it all figured out. You figure out what things you can trust a person about, and you learn from them, and you move on to someone else for some of the rest.
[edit] But I confess that I have a similar relationship to Josh Bloch that you have to Kent Beck. I can't listen to code advice by someone who wrote 2 collections APIs without understanding the basics of variance or apparently even the Liskov Substitution Principle. Throwing exceptions because you decided not to implement part of a public interface is an unforgivable offense that others have duplicated because if it was good enough for Josh it was good enough for them. He has done next to nothing to atone for that sin. You aren't an effective programmer. I don't want to hear you talk about the subject you so obviously know nothing about for 500 pages.
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 was picking out some new darts at a billiards store and me and my buddy were discussing what size, weight, etc. to get (i.e. "best practices").
The owner laughed and said the only thing that matters in picking a dart is how well you can hit the target with it.
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.
Classic middlebrow dismissal.
I've always been of the mindset that if the code isn't a little "gross" it's probably not doing anything very interesting.
Please list a project of equal complexity that has been written beautifully from start to finish in your opinion. This myth of beautiful coding needs to stop! Code is not a masterpiece from Van Gogh, it needs to ship. This determines quality, not the usage of some obscure/mainstream/unreadable/oh-look-how-cool-I-am idiosyncracy of the language. If you ain't shipping, it's completely useless.
The code, imo, is some of the highest quality js I've seen. It is also incredibly comprehensive and easily as complex.
High quality != shipping fast. They are separate quantities, it is easy to have one without the other but very rare to have both.
My point wasn't to ship crap, it was about obsessing on quality over actually shipping (and cutting some corners). This is something I learned at my first job, we obsessed over quality and never shipped. Guess what happened? :)
We believe we are more like machines than like other people. But at the end of the day we're the same trumped-up monkeys smashing away with imperfect tools.
If you look at our fellow productive monkeys, they aren't using the prettiest tools, no. But the tools they are effective with have a certain beauty to them. They often have a single purpose, and they do it very well (the Unix model knew this 40 years ago). Nicks and dents don't matter, unless they're on the working surfaces, in which case they have to be repaired or replaced, so resilience in certain dimensions is an absolute must.
A master does learn to work with their tools instead of against them, but within reason. If a better tool is available, or they can modify the existing tool to fit them better, they won't hesitate for a second to do it. That is what is meant by 'A craftsman does not blame his tools.' If you know you're using a bad tool, that's your fault. Get better tools.
Details in this excellent summary comment by someone else: https://news.ycombinator.com/item?id=9848097
I specifically recommend studying the "Project Oberon" book which is now available as a PDF from Prof. Wirth's own site, I believe.
libfreetype is an example of a great library, clean and well documented...
beautiful coding isn't a myth, it actually works... write code like poetry and it pays off 10 fold... less errors, easier to reason about, malleable... the benefits are extreme... try to actually experience something before making unfounded claims... i've been writing beautiful for over a decade now... once you realize code is written once and read 100 times, you'll come to the realization of doing it clean and right the first time pays of in the future, which means less work and bullshit...
> write code like poetry
When a code base reaches a certain size it's hard to write "beautiful code". Please don't pretend that it is just as easy when you have multiple complexities/priorities. If you write so called beautiful code in complex projects, good for you.
for a novice, he might be enlightening
don't underestimate how much you know, or assume that everyone else knows it
As far as I can tell, she didn't avoid that trap, despite identifying it. Occasionally I wonder if I avoided it. There are so many ways for a project to fail and when you know too many you can become a nervous wreck. Over most of the course of the '10s I've noticed that I'm a lot more comfortable with certain classes of imperfection, because they are immaterial to the job at hand, or represent an unknown that we haven't tackled yet (if you don't know how something should actually work, making it 'perfect' might make it perfectly wrong, and then where are you?). It's like a chess game. Half the board is full of pawns to be sacrificed for some higher priority. You have a contingency plan for any threat, but you can't act on them all at once.
Probably everybody does this, but their set points are different than mine, so we argue over code reviews.
The less you start off with, the better your understanding will be, and then you should learn to expand your horizons with other programming paradigms: logical, functional, and many others.
Totally agreed on other paradigms not being teached enough though.