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

11–20 of 136 posts

Re: Mastering Programming: An Outline

#11

Post by tobltobs »

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.

Re: Mastering Programming: An Outline

#12

Post by quincyla »

There is wisdom behind these bullet points. This wisdom could be better communicated through a series of fleshed-out articles with real life examples.

Otherwise, these points are difficult to contextualize, retain, and apply.

Re: Mastering Programming: An Outline

#15

Post by [deleted] »

sgentle wrote: post #9
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 agree. I actually think it's the single most important skill for beginner to intermediate programmers. Not structuring the code or managing complex abstraction, just having a reliable mental model of the program and the environment. I've often seen beginners struggle because they get so used to the compiler or the (often manual) tests catching errors that they just try things "to see if they work" without understan…

[deleted]

Re: Mastering Programming: An Outline

#18

Post by badminton1 »

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 "easy change", that incurs technical debt, fix a problem... but lower productivity for following changes. Also sets a bad example for other people to follow.

Post reply on HN