Hacker News Reader

Comment by trevyn | Hacker News Reader

And my favorite piece of advice: Don't take advice from people less successful than you.

For 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...

This 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.

Among 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.

What if you don't necessarily want to be "in the top tier of success" but just want to be a successful programmer? Come on.

Actually, come to think of it, 2/3'ds of the successful people I know are actually formally trained accountants who have people skills. Although I think accounting and programming have a similar mindset. If those same people were 20-30 years younger, they might be programmers today.

Kent 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

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.

So you're saying he's responsible for 90% of what I hate about software jobs these days (TDD as dogma, Agile, forced pair programming).

Probably, 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.

He 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?

At the risk of outing myself, it's a strange correspondence based approach. The idea is that we never commit to a repository but instead email changes to each other, making a patch queue. This has the benefit of forcing every commit to be code reviewed. The process is that we get an email to start work on some new ticket, which will be a reply from the "tip" email that we are supposed to base our work on, with a new subject. This is a development branch, so to speak. We have separate email addresses for separate projects, so project management is fairly hands-off. Requirements are hashed out in these email chains. This has the benefit of making all of our code "literate" in that it is adjacent the requirements.

This 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

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."

Don't take advice from people more successful than you, because the factors that led to their success may be irrelevant or counterproductive for you.

Dogbert'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."

I'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 ;)

>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.

If you follow that meta-advice, you'll probably end up learning some things the hard way that you could have learned the easy way.

I 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.

Can you think of a stronger predictor of future success? ;)

Of 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.

Such as?

Luck.

Sure, family money.

A 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.

We might have to define success

Reply on news.ycombinator.com