Attempting to prevent learning of poor techniques when self-teaching

Question

A big problem of learning alone is that you don't always figure out the preferred style for a language, the most "pythonic" (in the case of Python) way to do it, or how to write code in keeping with the language's features.

Another problem with learning alone is it is very possible to learn to write code that is really terrible - "mislearning", I suppose. Both of these things are true for really any subject one self-studies.

What are some ways to prevent the learning of poor techniques or styles when self-studying?

Answer 1

I think there are two phases here: the first is just being aware of what the correct idioms and best practices are, and second is attempting to apply what you learned and getting feedback.

For the first phase, you can get a lot of mileage by doing research and casting a wide net. In particular, I personally find the following Google queries to be pretty useful at giving me an overview of the best practices and general "feel" of a language:

• "X best practices"
• "X style guide"
• "X idioms"
• "X common mistakes"
• "X philosophy"
• "X ecosystem overview" (or "X popular 3rd party libraries")
• "X tips and tricks"
• "X history"
• "X advanced features"
• "X linter"
• "X style checking tools"

(Replace "X" with the name of the language. If the language name is common word like "Go" or "Swift", try replacing "X" with something like "Go language".)

This will obviously return a wide range of results, not all of which will be useful, but it's a good way of getting the "lay of the land". Some of the results will be directly useful (for example, you might uncover a popular and comprehensive style guide or a useful linter), and others will be more useful for getting context behind the design and intended use of a language (for example, googling about the language's core philosophy).

Other things I personally find helpful is to browse through the top-voted questions about a particular language on StackOverflow or SoftwareEngineering.SE (previously Programmers.SE). The knowledge won't be immediately useful (or sometimes comprehensible), but it does give you a feel for what sorts of issues programmers using that language tend to worry about, what advanced features people want to learn to use, and what keywords might be helpful when refining your queries.

Something else you can do is to keep an eye on news aggregates for the language of your choice. For example, I like browsing through http://reddit.com/r/python for Python-related news -- every now and then, you run across an article that teaches you something new or reveals a point of contention within the community that's worth keeping an eye on.

Keep in mind that after reading through all of these resources, you'll likely find it hard apply them all at first -- in some cases, you might not even understand the articles you dig up. This is fine: the idea is to be aware of them in the first place so you have a direction to grow towards.

It'll probably be a good idea to start small -- start by finding a style guide and writing your code to be compliant with it, for example. Or maybe try figuring out the recommended best practices for organizing a larger project and using your language's package manager.

---

The second phase is actually getting feedback on the code you wrote. This can be tricky to do as a self-learner, since you have no direct way of getting feedback, but there are a few things you can try.

One resource to try is CodeReview.SE, though it's probably best to submit relatively small programs for review.

Another idea is to contribute to an open-source project. The more popular projects tend to be relatively picky about following best practices and idioms and will code review your submissions before accepting them. As before, start small: try and find a small and easy bug in their issue tracker, and start with that. It can also be valuable to try googling "open source for beginners" -- that reveals plenty of resources and websites that attempt to connect projects looking for help with beginners.

Answer 2

There is more to your question than just "how to program". For that, however, a good guide is to learn who/where a language was developed and emulate the code that those people write. For Scala, for example, get Programming In Scala by Odersky et al, who created the language. Textbooks are not in general a good guide in general. Many do a terrible job, using old techniques with a new language or using new syntactic styles without understanding the semantic intent.

For the general question, how to avoid being misled about what is important and how to think, it is a hard problem. Long term, you need to learn to think critically about things and weigh conflicting evidence. One guide to "who gets it right" is to look at the papers referenced in various places. Who is writing those papers? Who gets referenced a lot. It isn't a perfect guide, of course, but if a lot of people consider someone authoritative, they probably are.

For many things in Math and CS I find wikipedia to be pretty trustworthy, especially for more or less established knowledge. The fact that bad information can be driven out by other, more knowledgeable, people is a plus. I have found the occasional bit of garbage, however, but it tends to disappear fairly quickly on technical articles (unlike pop culture). If something "feels" stupid, it may be. But you can examine the edit history of the articles there at least and see if the dumb thing is recent or has been bouncing in and out. For new discoveries, wikipedia will be in flux for a while as the idea settles down and people come to some consensus. This also explains why text books don't do a good job initially if things are changing (paradigm shift). They can be too much influenced by old thinking and unsettled experimentation with new ideas.

Another suggestion is to cultivate people with more knowledge than yourself and against whom you can bounce ideas. The chat rooms as SE, of course, are a good example of where to find such people, but you may have some access to professionals in your community as well.

---

Let me also note that in a formal setting the quality of textbooks is less of an issue, as a good teacher can compensate for poor materials. But the self learner doesn't automatically have that guidance, of course.

Answer 3

For the idiomatic way to write code, usually the best place is the standard library of your language, you can also look for big open source projects and see what they do.

For not learning garbage, like in most topics, is not that easy, like other commenter said, become critically minded. That requires spending time learning. Something I found very useful is chatting with experienced people, usually with IRC but there are other ways.

Something else that's very important is not becoming a cargo-cultist: don't believe that X thing is THE SOLUTION. There are no silver bullets, and different ways of solving problems are better/worse for different situations, so don't marry a design pattern / paradigm / language / development methodology. Something I found really useful is spending time actually testing what you see; for example: don't blindly say that you need getters for all classes, try writing code without getters and see if that really generates any problem or instead you get more writable code and faster development omiting it. Just be careful because things that work well for single-developer/small projects might not work well in other environments.

I'd also suggest becoming polyglot because different languages and paradigms show wildly different ways of doing things. You get very different solutions to problems when you use Javascript, Haskell, Rust and D.

Answer 4

Everything you learn is temporarily correct.

This is the mindset you need when learning new things (in the IT). Even if you by chance happen to learn the perfectly accepted "right" way to write Python in your example, you still will look at that code five years later and realize that you have improved so much over that.

In the IT business everything is constantly in flux. May it be that new languages with new ideas appear (e.g. functional programming), or that best practices turn out to be not that good after all, or something is over-hyped but essentially bad and simply gets out of fashion. In all cases you advance and improve yourself, unlearn old habits and learn new ones.

So when you learn a new language, don't accept what you learn as the one and only truth, accept it as the current best known way to do things. Verify what you have learned and ask yourself: "Is there a better way?" If you find one, use that, despite what the books tell you, because those might be outdated as well. If you don't, then consider that you just haven't found a better way, yet, not that there is none. And if you realize at some point that everything you did was completely wrong, don't worry, be happy that you improved.

With that mindset knowledge become building blocks that can be interchanged at any time. Learned a new technique? Replace the old one and adjust the surroundings. Suddenly there is no longer a "wrong" or "right" way to do it, just the current and the better way. And if you no longer quantify as "true" and "false" your brain will memorize things differently, and it will become much easier to upgrade old knowledge.

A part of the reason is that the brain tends to harden something learned more, if certain emotions are associated with it. If you are excessively happy that you finally learned the one and true way to do things, your brain will set that in stone for you forever. If the same thing is just some information equally irrelevant as everything else, your brain will not put too much effort into storing that. This also means that you will forget things easier, but especially in IT most knowledge from 5 years ago is irrelevant anyways. And those things that stay true and correct will be memorized more clearly simply because you repeat them often enough.

Answer 5

Everything you've mentioned is also true of more "traditional" classroom environments. Novices (and non-novices) often have trouble "thinking in a language" or following best practices. This is not specific to self-learners.

The only way you fix this is through practice, by actually writing code. You should spend more time writing code than you do learning about it. Try giving yourself homework assignments, or look for assignments online or in a text book.

The rest happens more naturally than you might expect. For example, any code you write now will look like garbage to you in 6 months. This is perfectly normal, and it's a sign of how much you're learning and improving. I think trying to learn about "best practices" and shoehorning them into code you're writing now is a bit of a wasted effort. Instead, move on to the next topic, and then revisit your code in a few weeks to see if you notice anything you could have done differently. Take those lessons with you when you start your next project.

You should also try to read code, which will also happen pretty naturally as long as your "homework" assignments are at the right difficulty level. Your homework assignments should require you to consult documentation and tutorials, and read the code in them.

Honestly I don't think you should worry too much about this, especially if you're just starting out. Focus on writing code that works, does what you expected, gets the job done, and that you understand. Do that as often as possible, and then rinse and repeat. You'll pretty naturally learn "best practices" just by reading documentation and examples and incorporating those in your own code.

Answer 6

I could share what helped me and what I share with my students (who eventually have to end up self-learning things anyway) is to associate what you are learning with something standard.

For instance, I have started learning iOS on my own. I asked a couple of iOS developers, got a recommended book, and decided to use that. While the book is used, I mostly end up learning things from stack overflow and apple documentation (which is how I learnt everything I know anyway - official documentation and stack).

Another thing I do is compare what I am doing (coding, designing and deployment) with the suggested ways of doing by the official documentation. Back when I was still building windows apps and UI, I would spend hours and hours on how to design the UI as per Microsoft.

Same goes to learning anything. There is always some kind of documentation, a mentor, an experience person and forums like stack where you can get to the right techniques. That way, you still get to learn on your own but at the same time, you avoid the pitfalls.