3 ms·
And my favorite piece of advice: Don't take advice from people less successful than you.
by trevyn 10y ago
And my favorite piece of advice: Don't take advice from people less successful than you.
- fisherjeff 10y agoI tend to agree with the article in general, which has implications that run counter to that piece of advice. Namely, that current success is not necessarily a predictor of future success.
- trevyn 10y agoCan you think of a stronger predictor of future success? ;)
- andrewprock 10y agoOf course. In a world where success is due in large part to random events, it's easy to come up with better predictors about whether someone will be successful in the future.
- oldmanjay 10y agoSure, family money.
- dredmorbius 10y agoA causal mechanism that seems likely to propogate to the future. Winning the lottery can lead to present success. Having one once, in a fair game (and that's a valid condition to check) is exceptionally unlikely to lead to future success. OTOH, pursing a line of work in which you haven't yet succeeded, but others have, may be an area in which lack of present success doesn't preclude future success. I tend to look to process with more emphasis than outcome.
- yompers888 10y agoWe might have to define success
- Kinnard 10y agoThis strikes me as ad hominen, you're evaluating the person, not their advice. "Bad people can't give honest testimony." https://en.wikipedia.org/wiki/Ad_hominem https://en.wikipedia.org/wiki/Ad_hominem In fact, I think there's a strong argument for getting advice from people who have failed, because, they have lived through failure cases and I'd expect can help you avoid them. "Successful" people could be either privileged, lucky, or both, and their success may not be due to what they attribute it to. I think you want to collect as much data as you need to draw strong conclusions. I therefore favor the adage, "Who is wise? He who learns from everyone."
- hx87 10y agoDon't take advice from people more successful than you, because the factors that led to their success may be irrelevant or counterproductive for you.
- AnimalMuppet 10y agoDogbert's version (from memory, I don't have a link): "Don't take career advice from people more successful than you; they do not seek company."
- mobiuscog 10y agoI'd also suggest to be cautious of risk-taking advice from people far more successful than you, as they often have sufficient wealth / network / environment to weather the storm, that you may not. EDIT: Seems I'm not alone in that thought ;)
- GrumpyYoungMan 10y ago>And my favorite piece of advice: Don't take advice from people less successful than you. Success has many dimensions; one needs to choose carefully which to measure yourself against. I've known wealthy and professionally respected people whose personal lives were a mess and those of more modest means who greatly enriched the lives of those around them. Moreover, the path to success that others have trod may not one that you can take. Times change, possibilities change, and opportunities open to others may not be open to you. My preference is to listen attentively and genuinely to advice from nearly anyone but be very selective about which bits of advice I choose to try and follow.
- nostrademons 10y agoKent Beck is plenty successful - he founded the XP movement back in the late 90s, popularized unit tests, was one of the original signatories of the Agile Manifesto, and wrote JUnit. https://en.wikipedia.org/wiki/Kent_Beck https://en.wikipedia.org/wiki/Kent_Beck If you haven't heard of him, that's a pretty good illustration of his point: success can be fleeting. You can be the foremost programming guru one moment (which Kent Beck was, given my recollection of the late 90s and early 00s) and then fall into obscurity and be just another engineer afterwards.
- superswordfish 10y agoSo you're saying he's responsible for 90% of what I hate about software jobs these days (TDD as dogma, Agile, forced pair programming).
- nostrademons 10y agoProbably, yes. I think people forget everything they hated before TDD, Agile, XP, etc. Namely the endless parade of bugs, management making unrealistic promises, perpetual crunch time, death marches with no end in sight, code fiefdoms where touching any other engineers' code was basically impossible. Software is hard. It is getting marginally easier with time, but it still is a lot harder than most peoples' expectations of what it should be. Hence most developers end up disillusioned, frustrated, and unhappy, but this is a product of our expectations more than our processes. A job isn't supposed to make you happy, it's supposed to make your customers happy.
- tigershark 10y agoHe is responsible for the software engineering evolution from a model that was good for building static stuff like houses and bridges to a model that works well with dynamic stuff with continuously evolving requirements. Why do you hate TDD, agile and pair programming and what software designing methodology are you following?
- superswordfish 10y ago
- mavelikara 10y agoFor a professional programer, if Beck is deemed "unsuccessful", I don't know who among us you will call successful. If you are a professional programer in 2016, you very likely are familiar with the term "refactoring". This term was placed in our vernacular by the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler [1]. In the Preface to the book, Folwer writes: Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy .. ... I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software. ... In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. .... I've left the final word, Chapter 15, to the master of the art, Kent Beck. You might also have heard of xUnit style of testing. Beck had a hand in many of these frameworks. TL;DR - pay heed to the history of your profession. [1]: https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 https://www.amazon.com/Refactoring-Improving-Design-Existing...
- trevyn 10y agoThis sort of demonstrates my point perfectly -- if you look at the most successful people in the world, what percentage would you classify as a "programmer"? And of those, how many are actively programming? TL;DR - If you want to be in the top tier of success, don't take advice from programmers.
- nostrademons 10y agoAmong my most successful people, about 80%. Counting only those who are actively programming it drops to around 50%. It's easy to forget that the definition of success is relative. Someone you consider a success might be considered a miserable failure in life by others.
- rwallace 10y agoIf you follow that meta-advice, you'll probably end up learning some things the hard way that you could have learned the easy way.