When looking for advice, IMO the first question you need to ask is "what has this person actually built?"
Personally, I find that the people whose advice I love to read are guys like John Carmack or Jonathon Blow or Casey Muratori or Tim Sweeney. Those are guys that have or are continuing to solve difficult problems and have tons of hard won practical advice. When I look at someone like Uncle Bob or Ron Jeffries, I see people that struggle to write sudoku solvers and are mostly famous for giving advice, not for building great software.
If somebody explains a concept eloquently and uses good logic, you should consider what they have to say, even if they’re a dog or a cat and not a famous programmer. You shouldnt ignore arguments or explanations from people without glorious careers
To use a games example, the game programming patterns gentleman is most famous for his book, not for his game engines - yet the book is extraordinary and anyone would be poorer for skipping it
Uncle bob has clearly articulated a number of ideas I’ve found useful over the years, and so what if he also said some things we don’t agree with? He’s human
That said, the opinions of accomplished people like carmack and blow are definitely worth listening to. They are eloquent and have very interesting opinions
The answer to my question doesnt have to be famous or amazing, just a reasonable demonstration of individual capability. Would you want advice on, say, wood working from someone that cant show you a well crafted chair or table they made on their own? A lot of the refactorings he does in his book IMO are not good, and a lot of the SOLID principles dont really apply in languages outside of Java, and even there their effectiveness is a matter of opinion and taste more so than provable value. I dont really hate on Bob, I just would encourage new coders to carefully consider whats been accomplished by the people that follow a certain paradigm. The majority of the most succesful projects in history have had nothing to do with TDD or SOLID. So, take whats useful from those methodologies certainly, but I'm more interested in how the undeniably great people and projects work as compared to Bobs opinions.
I don't entirely disagree, but I have to keep in mind that this is an ad hominem argument. It's also an argument that would be used to eliminate or discredit academia and the vast majority of those in public service - both of which I think have their place to an extent.
Ad hominem doesn't necessarily mean fallacious or invalid. Bob's whole brand is being a self-styled authority on what constitutes clean, high quality code. So yes, his achievements and personal credibility are important here.
Well, I'm not saying you should discredit advice from people who haven't made great works (IE, most of us), just that it's a question you need to ask to put their commentary in perspective.
Especially when someone like Uncle Bob says: "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes."
Well, alright, in that context he's asking us to just take his word for it, but there are no tangible arguments here. Whereas Casey Muratori has a much more thoughtful exploration of this topic ( https://caseymuratori.com/blog_0015 ), and he's also written some very excellent code (in terms of solving difficult problems and doing useful things)
Yes, some Talkers have great ideas, and some Doers offer terrible advice. I think a more nuanced mental framework that avoids ad-hominem is "opinions" vs "experiences".
Some Talkers peddle opinions because they haven't got any experience. Most Doers peddle the experiences they had. Why does this matter? Anything can be opinion if it isn't backed by data. Many opinions that look great on paper are terrible in practice. If someone is offering you an experience (or anecdote), at least they have a single data point to back it up. A surprising amount of influence is exerted on the internet based on "one guy's opinion".
The better Talkers aggregate experiences of others to back up their opinions. This tends to provide better evidence than a single anecdote, and can be done even if you have no hands on experience with the subject.
So to your point a better way to frame it might be "what data/evidence is this person giving to support their argument?"
In my experience, the greatest teachers rarely have the official title "teacher". I learned more from one programmer in 5 months working with him than I did in my entire computer science degree. (And no, I'm not saying professors or degrees are useless, just that I don't think title's and reputation necessarily tell you much about how much a person will teach you.)
And honestly, reading "Uncle Bob's" advice, I find a lot of it is outright bad (here's a good breakdown: https://qntm.org/clean ), or specific to Java's quirks, or has no actual backing other than that Bob think's it's a good idea.
It is great you had a mentor. I met few people I could learn from and books (including Bob’s) were very helpful. He promoted TDD, good names, short functions etc Is he too dogmatic? Are his function too short? Probably yes.
I never treat his proposals as a silver bullet, but a great source of inspiraton. I wish there were more people teaching those things.
I do not agree. Take the example in football, Maradona was one of the greatest players, but he was unable to teach and to be conscious about how he did what he did.
Having a talent to solve problems does not mean you can teach them. Many times the opposite is true, people that do not have great talent but a good self reflecting and observing and analysis capacity can extract the insights and general rules of a give discipline.
The former plus a good experience on the field is best source o advice, and to my knowledge Uncle bob have both.
But these guys develop their programs in isolation and they deploy to users only the final result or a limited number of beta versions. They almost never evolve their code bases to a second version. They work on video games.
If I work in isolation from the users, don't have external requirements, don't care about future versions of the software - sure, their advice might be useful to me.
> They almost never evolve their code bases to a second version.
This isn't necessarily true, a lot of code can and is reused between games (math, physics, audio, etc.)
In terms of isolation from the users, that isn't really true either -- the users are the rest of your team. You have to build tools for the team to use and they better be at least somewhat usable, and you need to have something workable quick so you're not blocking your artists and level designers, etc.
I like the concept of Talkers vs Doers, that I leant from Nassim Taleb. Whenever reading advice on the internet, one should check the author and ask themselves "what has this person actually *done* that gives credit to their words?".
Because I'm interested in video game development, and it's a good litmus test since the solutions have to be high performance and developed very quickly. I could also mention people like Peter Norvig or Alan Kay though, I just listed the ones that initially came to mind
Developers who did not seek permission to write code their way. We used their software and in some cases can see the code. Their output is attributable to them rather than faceless teams.
clean code was published in 2008, two years after jquery. the world was different then. and there is a large audience of laggard adopters who still live in that world.
Personally, I find that the people whose advice I love to read are guys like John Carmack or Jonathon Blow or Casey Muratori or Tim Sweeney. Those are guys that have or are continuing to solve difficult problems and have tons of hard won practical advice. When I look at someone like Uncle Bob or Ron Jeffries, I see people that struggle to write sudoku solvers and are mostly famous for giving advice, not for building great software.