Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Programming: An Outline

prod.facebook.com

Post reply on HN
Print view View original

111–120 of 136 posts

Re: Mastering Programming: An Outline

#111

Post by dasil003 »

arekkas wrote: post #92

After reading that, I don't feel a bit smarter then before. That's usually how it goes when you make a bold, universal statement about something and put it into 10 lines of text. I aknowledge what Kent Beck has done and what facebook is doing but this doesn't deserve to be on HN front page.

True, but then long protracted explanations don't necessarily do a better job, they are prone to missing the forest for the trees. The beauty of the short bullet point is that it makes the practitioner think, sort of like a zen koan. It will be utterly useless to someone who hasn't already put in the practice to be on the brink of enlightenment already, but then again, what other way is there to truly learn?

Re: Mastering Programming: An Outline

#112

Post by wpietri »

plinkplonk wrote: post #70
Teeboo wrote: post #59

Earlier quoted context omitted.

All spoken brilliantly as someone who has not seen the nuance beyond the post. The Facebook note was written by Kent Beck, father of eXtreme Programming (XP) and original Agile manifesto signatory. He is not saying follow this methodology because a company made money. Invert your thinking; he is saying the majority of companies that utilise the following values and techniques have far fewer failed projects and delive…

The man created a methodology [1]. That is wonderful but (imo) it doesn't give him the chops or credibility to tell other people how to program or solve problems. Think about it. Does Grady Booch (builder of yesterday's, now forgotten methodology) have some kind of special wisdom to dispense? If not why does Kent Beck? "Mastering" Programming, heh. That said, sure no one can argue against such 'motherhood and applepi…

> If not why does Kent Beck? "Mastering" Programming, heh.

He is also the person who (re-)originated test-driven development. And his day job for the last few years has been mentoring Facebook's new engineers.

And you ignore that he answered your question in the first paragraph of the piece. You might agree or disagree with his explanation, but ignoring it just looks sloppy.

Re: Mastering Programming: An Outline

#113

Post by joepvd »

srik wrote: post #66
raarts wrote: post #64

Old German proverb: In der Beschränkung zeigt sich erst der Meister.

A bit of searching found this translation > The master shows himself first in confinement Thanks. In the process I found this beautiful poem. http://johnirons.blogspot.com/2011/09/work-in-progress-trans...

Not a German, and not a native English speaker, but I would propose the following (depersonalized, inaccurate, paraphrased, bastard...) translation:

    Mastery reveals itself by the limitations of its scope.

Re: Mastering Programming: An Outline

#114

Post by ry_ry »

0mbre wrote: post #33

Something that is helping me a lot recently is trying to know all there is to be known about the tools/concept that I am using and the problem that I am solving. Too often have I used tools I half understood to solve problem that I didn't define clearly enough.

Absolutely nailed it.

To continue the theme - When the only tool you have is a hammer, every problem looks like a nail.

Re: Mastering Programming: An Outline

#115

Post by ry_ry »

0mbre wrote: post #33

Something that is helping me a lot recently is trying to know all there is to be known about the tools/concept that I am using and the problem that I am solving. Too often have I used tools I half understood to solve problem that I didn't define clearly enough.

Absolutely nailed it.

To continue the theme - When the only tool you have is a hammer, every problem looks like a nail.

Knowing what a technology can do is imho a better first step than diving straight into syntax and implementation.

Re: Mastering Programming: An Outline

#116

Post by elliotec »

Teeboo wrote: post #61
elliotec wrote: post #5

I'd like to see this fleshed out more with examples, because I don't really know what some of these mean.

Well luckily there is a book for that ;-) 1996. Smalltalk Best Practice Patterns. Prentice Hall. (ISBN 978-0134769042) 1996. Kent Beck's Guide to Better Smalltalk : A Sorted Collection. Cambridge University Press. (ISBN 978-0521644372) 1999. Extreme Programming Explained: Embrace Change. Addison-Wesley. Winner of the Jolt Productivity Award. (ISBN 978-0321278654) 2000. Planning Extreme Programming. With Martin Fowler…

I didn't mean the entire Kent Beck bibliography, this is obviously a different thing than his books or he would've referred to his books. I just would like to see this particular outline expanded slightly is all.

Re: Mastering Programming: An Outline

#117

Post by plinkplonk »

wpietri wrote: post #112
plinkplonk wrote: post #70

Earlier quoted context omitted.

The man created a methodology [1]. That is wonderful but (imo) it doesn't give him the chops or credibility to tell other people how to program or solve problems. Think about it. Does Grady Booch (builder of yesterday's, now forgotten methodology) have some kind of special wisdom to dispense? If not why does Kent Beck? "Mastering" Programming, heh. That said, sure no one can argue against such 'motherhood and applepi…

> If not why does Kent Beck? "Mastering" Programming, heh. He is also the person who (re-)originated test-driven development. And his day job for the last few years has been mentoring Facebook's new engineers. And you ignore that he answered your question in the first paragraph of the piece. You might agree or disagree with his explanation, but ignoring it just looks sloppy.

"From years of watching master programmers, I have observed certain common patterns in their workflows. From years of coaching skilled journeyman programmers, I have observed the absence of those patterns. I have seen what a difference introducing the patterns can make."

Is this the paragraph? I fail to see how such self declarations of uber competence and self labeling as "master programmer" should be accepted by others on his say so. Sure he originated/pushed TDD.(and what happened to that project on which all these 'masters' worked?) You seem to think it is a good practice, worthy of elevating Kent to 'master'. Which is fine I don't.

If his day job is to train FB engineers, and he enjoys it, good for him. If Facebook needs its engineers thus 'leveled up' by TDD etc, good for them. It is a free market.I have no quarrel with any of this.

However in my experience, the very best programmers (in any subfield of programming - Linus/Carmack/whoever, or even very good anonymous programmers working on simple CRUD systems) don't go around calling themselves 'master programmers',putting themselves at the top of imagined pyramids, or offering pithy aphorisms about how they can 'coach' other 'journeyman'(and so lesser skilled as compared to 'master' programmers) into 'mastery' by following "patterns".

This is just standard agile coach/methodologist talk. If someone calls himself a 'master' programmer, he better have world class code/coding skills on a consistent basis to back it up. Methodology religion propagation doesn't cut it (imo, ymmv and that is all right).

Re: Mastering Programming: An Outline

#118

Post by sklogic »

andyjdavis wrote: post #22
keyle wrote: post #8

Sadly just an outline but I didn't mind that. Good read. I'd add a few things I've noticed over the years. Great developers like to pair program on tricky stuff, because they always learn something. They will try 2 different implementations if they're not sure which is best, and then the right one will then be obvious. They back their arguments with real world proofs. They try most fringe/new technology, even if it's…

> They try most fringe/new technology I have actually found the opposite. The best programmers I have known are often the most reluctant to try new technologies. At least until the technology appears to have reached some sort of critical mass and it has been shown to be virtually guaranteed to increase their already very high levels of productivity. Partly this is just an experience thing. After you see enough shiny…

Exactly. I have not seen a new thing in many years. All the so called "new" things are simply rebranded decades old ideas.

Re: Mastering Programming: An Outline

#120

Post by samirm »

sklogic wrote: post #118
andyjdavis wrote: post #22

Earlier quoted context omitted.

> They try most fringe/new technology I have actually found the opposite. The best programmers I have known are often the most reluctant to try new technologies. At least until the technology appears to have reached some sort of critical mass and it has been shown to be virtually guaranteed to increase their already very high levels of productivity. Partly this is just an experience thing. After you see enough shiny…

Exactly. I have not seen a new thing in many years. All the so called "new" things are simply rebranded decades old ideas.

Isn't everything?
Post reply on HN