4 ms·

> 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

by bcbrown 10y ago

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

dmolony 10y ago
I do this with life in general. You soon realise how bad you are at estimating, but it helps you improve.
- xufi 10y ago
  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" .
- wallace_f 10y ago
  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 :)
PeCaN 10y ago
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.
- caconym_ 10y ago
  My process in these languages (Haskell I know pretty well, now in the process of learning Rust) is to sprinkle in `undefined`s and `unimplemented!()`s and whatnot so I can continuously use the compiler to check my work without actually running the code. It's a good way to test assumptions and refine a mental model, and it's also just plain useful for catching boneheaded mistakes as you go. I'm not sure if I'd say I use it as a crutch, but I certainly miss it when I have to use languages like ruby and Python.
sgentle 10y ago
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.
- deleted 10y ago
  [deleted]
mathattack 10y ago
I like the intellectual honesty. "Write it down" takes this one further.
deleted 10y ago
[deleted]
sargas 10y ago
That's great from beginner to master levels. Although master programmers call shots that are correct almost always :)
aphextron 10y ago
Agreed. This is akin to "rubber duck" debugging. Highly effective.

by bcbrown 10y ago

dmolony 10y ago

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

xufi 10y ago
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" .
wallace_f 10y ago
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 :)

PeCaN 10y ago

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.

caconym_ 10y ago
My process in these languages (Haskell I know pretty well, now in the process of learning Rust) is to sprinkle in `undefined`s and `unimplemented!()`s and whatnot so I can continuously use the compiler to check my work without actually running the code. It's a good way to test assumptions and refine a mental model, and it's also just plain useful for catching boneheaded mistakes as you go. I'm not sure if I'd say I use it as a crutch, but I certainly miss it when I have to use languages like ruby and Python.

sgentle 10y ago

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.

deleted 10y ago
[deleted]

mathattack 10y ago

I like the intellectual honesty. "Write it down" takes this one further.

deleted 10y ago

[deleted]

sargas 10y ago

That's great from beginner to master levels. Although master programmers call shots that are correct almost always :)

aphextron 10y ago

Agreed. This is akin to "rubber duck" debugging. Highly effective.