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

21–30 of 136 posts

Re: Mastering Programming: An Outline

#21

Post by vessenes »

tobltobs wrote: post #11
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 would have thought that in area like IT where everything gets reinvented every decade (or less) a master programmer wouldn't have to look at the details to assess a "new" technology.

I'm no master, but I am middle aged. I like to learn at least one new technology a year; I always learn something from working hands on that I might not have understood just from ideating about it.

Re: Mastering Programming: An Outline

#22

Post by andyjdavis »

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 new things wrapped up in spin and hype the task of peeling that stuff away to get an honest assessment becomes unappealing.

Re: Mastering Programming: An Outline

#24

Post by tomc1985 »

tobltobs wrote: post #11
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 would have thought that in area like IT where everything gets reinvented every decade (or less) a master programmer wouldn't have to look at the details to assess a "new" technology.

Agreed; too much commitment.

I hate 'trying everything' because I never feel good at anything, and more often than not "new technologies" in this scene are just someone else's old ideas, rehashed and made more complicated. Mastery requires focus.

Re: Mastering Programming: An Outline

#25

Post by pm »

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…

I've seen both, so I'm guessing there are multiple things that make a productive programmer.

Re: Mastering Programming: An Outline

#26

Post by endgame »

shadesof wrote: post #10

> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change. This is my favorite bit. Katrina Owen mentions this in her talk on refactoring. "Make the change easy; then make the easy change." https://www.youtube.com/watch?v=59YClXmkCVM

This is excellent advice, and I've seen it replicated as far back as Fowler's book on refactoring. Does the trail go further back than that?

Re: Mastering Programming: An Outline

#27

Post by wallace_f »

dmolony wrote: post #3
bcbrown wrote: post #2

> Call your shot. Before you run code, predict out loud exactly what will happen. That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.

I do this with life in general. You soon realise how bad you are at estimating, but it helps you improve.

Sounds like a good idea and seems to be worth a shot. Actually, I am thinking about why I put so little effort into this, currently. I will take your suggestion and see how it goes :)

Re: Mastering Programming: An Outline

#28

Post by davnn »

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…

I would say "try" fits very good but "use" often comes later.

Re: Mastering Programming: An Outline

#30

Post by caconym_ »

badminton1 wrote: post #18

While the author is known (technical coach at Facebook, creator of XP software methodology), I sort of disagree. You can follow this guide and still be a low value programmer. This guide won't take you to mastery level. And, there is also a sense of irresponsibility around one item: "easy changes". Easy changes as in, duct tape programming? That's pretty much turning your project into a Jenga tower... you add your "e…

Did you only read the bold text? This is very different from "duct tape programming":

> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change

Post reply on HN