You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Students from] elite schools dove headfirst into complicated problems, with code as their only weapon.
Meanwhile, my friend wrote his code only after thoroughly understanding the problem. He used almost all the allotted time to think about the problem. He did not write code until minutes before the deadline.
He became a champion.
He knew that banging out code would not solve the problem, but cool, collected problem solving would. — (Please don’t learn to code, TechCrunch, source)
Not everyone can, or indeed should, become an engineer.3 But being able to think through a problem is a very useful asset to anyone. Better still, to be able to communicate a problem or solution so that anyone could understand it!
Footnotes
Could you explain the problem to a child? The Feynman Technique (how to learn anything) ↩
These are a little too much. It's very detailed, but it's a lot to sift through to make sense of the code. A better way might be to have limited notes and split out each function to show what it's doing — individually, not in bulk. For instance, this style of documentation comes a looong time after this. And even that document (learn you a Haskell) is too dense in text and not formatted very well. TL;DR: Notes should be just simple enough (and not simpler) to view at-a-glance, with a more thorough understanding of the individual pieces (somehow) ↩
Not everyone can, or indeed should, become an engineer.3 But being able to think through a problem is a very useful asset to anyone. Better still, to be able to communicate a problem or solution so that anyone could understand it!
Footnotes
Could you explain the problem to a child? The Feynman Technique (how to learn anything) ↩
These are a little too much. It's very detailed, but it's a lot to sift through to make sense of the code. A better way might be to have limited notes and split out each function to show what it's doing — individually, not in bulk. For instance, this style of documentation comes a looong time after this. And even that document (learn you a Haskell) is too dense in text and not formatted very well. TL;DR: Notes should be just simple enough (and not simpler) to view at-a-glance, with a more thorough understanding of the individual pieces (somehow) ↩
Please don't learn to code ↩
The text was updated successfully, but these errors were encountered: