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

1–10 of 136 posts

Re: Mastering Programming: An Outline

#3

Post by dmolony »

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.

Re: Mastering Programming: An Outline

#4

Post by xufi »

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.

Agreed. Thats what i'm trying to improve on myself while relearning the technologies I want to learn . As the saying goes "trial and error" .

Re: Mastering Programming: An Outline

#6

Post by PeCaN »

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.

A similar one when dealing with compiled languages with good type systems (Haskell, OCaml, Rust, Mercury) is to periodically build even when your code is broken and try to guess what error the compiler will give. This helped me a lot with those languages.

Re: Mastering Programming: An Outline

#8

Post by keyle »

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 not right for the current project. They hold large amount of domain knowledge in their heads. They admit when something is twisting their brains, draw it on paper, talk about it and then bang it out. They fantasize about what-ifs, in a perfect world, scenarios. And they love to share knowledge.

Re: Mastering Programming: An Outline

#9

Post by sgentle »

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 understanding what they're trying. But they don't consider two important questions: "what do you want to happen?" and "what do you expect to happen?".

If you can answer both of those, you can figure out whether your code will work before you write it. In many cases when programmers struggle it's because they don't know the answer to one or both. They're left just trying stuff until something works, but there's a lot more things that don't work than things that do, and a lot more bad solutions than good ones.

Post reply on HN