3 ms·
maybe you can, to some extent, exploit the nature of software? i'm thinking about how i have learnt, and how that ties in to the points you list above, and one
by andrewcooke 17y ago
maybe you can, to some extent, exploit the nature of software? i'm thinking about how i have learnt, and how that ties in to the points you list above, and one obvious connection is that you are automatically guided to "highly granular areas for improvement" if you continuously refactor and revise (polish) you code.
typically, to learn a new language, i solve a problem. the result of solving that problem is a chunk of code and it's usually a bit of a mess. you can use the mess to help identify what needs to be refactored. this then guides you towards learning more about the language, because often the mess is a direct result of not using the tool well.
note that what you're exploiting here is the fact that it's a lot easier to identify "a mess" than it is is to identify a gap in your understanding of the language; identifying the mess helps guide you to the gap.
at a higher level, the conclusion here is that you have not finished learning once you've written some code in a new language. in fact, you are just starting. it's only through repeated (obsessive?) polishing of the code that you achieve a deep understanding of the language.
(and i think this also applies to languages you know pretty well - i use python at work, and have used it for years, but i am currently working on the fourth major revision of my lepl parser library and am still learning as i rewrite particular aspects).
- raju 17y agonote that what you're exploiting here is the fact that it's a lot easier to identify "a mess" than it is is to identify a gap in your understanding of the language; identifying the mess helps guide you to the gap. That's an interesting way to look at it. I guess I do struggle, because of the way I learn a new language or a technology. I spend a lot of time reading books, or other people's code, but I don't spend enough writing out a solution for I fear it will be not the right way to do it. Your suggestion turns this around on its head - try and write a solution, no matter how unpolished or un-idiomatic is, then step back and see what could be improved. I like your take on this. Although, I will admit, I am still a little puzzled. Take, for example - I am currently spending time learning Clojure, and decided to attack the 99-Lisp-Problems to help me out. For a particular solution, I wrote a function that was about 8 lines long and I could not find a better way to solve the problem. A quick Google search revealed a solution that was a one-liner! I guess that's my feedback loop - Other people's solutions to the same problems.
- andrewcooke 17y agoyeah, i think there has to be sufficient "surface area" for you to "find a way in". the simplest way would be to write a larger app, but in your case you could increase your chances for learning by working on other problems and then going back over earlier work - it's possible that you learn something on a later problem that helps you see the one liner in the earlier problem.