After two years of programming, I can see two ways to learn to code.
⚠️ This is my opinion, if you don't agree with me don't hesitate to give your mind in a comment ⚠️
Practical way
When I started programming two years ago, I was 13, I still wanted to code without reading documentation or without to know basics.
That's how I started to learn HTML, then I learned PHP, in the beginning, I learned the Copy/Paste Oriented Programming. But over time I learned a lot of things through practice. I started to stop copy paste and to test the libs I was using by testing all methods/functions/class which was in those libraries. And that's how I discovered the practical way to learn to code.
Good points
Fast to learn
Very fun
Bad points
- You can skip something important
- It is difficult to debug something when you didn't read the documentation.
Theoretical way
Lately, I discovered the theoretical way. I wanted to learn how to use React. So I went to the getting started and the documentation offers to way to learn React, I decided to try practical way and... I didn't understand anything. Since a few months, I need to know how it works behind the code to use something so I decided to read the theoretical guide and I understood everything.
Good points
- You know how it works
- Easier to debug
Bad points
- It takes a lot of time
- It is sometimes boring
What I prefer
Like I said, since a few months I need to know how it works behind my code to understand how to use something. That's why I started to read a lot of documentation and to code less.
What should you use
I can't say you should use this one because it's personal. To answer this question, you have to try those two ways to know what you should use.
Latest comments (39)
I don’t understand but it’s a good work
<3
geek
Learning to code is just one part of the much larger "learning to think", really. And that's why it's less about the lines of code written and more about the secure grasp of the problem + correct and elegant design of a solution. Beware also of all the appealing shiny new tools and apps and languages that promise to "make it easy" for you - that apparent easiness comes at the cost of robbing you of any chance to actually master the problems and therefore be in control. Essentially whenever you "try" new tools, you are just serving as a guinea pig for the tools, not gaining all that much in the process.
The above being said, learning (of coding like of anything else) is always best as a combination of theory & practice. And the greatest amount of fun comes from doing things as best as they can be done - there is not only personal growth for you in that but also pride in your work and a solid foundation for moving further. With that as with all learning, you can struggle on your own trying to literally lift yourself up or you can search for mentors that are working on interesting (rather than merely popular, this year's hype, to die next year) things and can guide you effectively. Then of course, it's also a matter of whether you can convince them to take you on at all.
I guess the difference here is that we first have to build the bike to peddle it (Don't misinterpret by thinking that you have to build a compiler. But we have to build not just use).
Hi,
As everyone said: excellent!! very interesting.
I lost that will to learn by myself just trying all methods that i find in a language... but your post reminded me of the old days, when programming was fun at that time.
Programming isn't fun anymore ?
Yes, here at work - same thing everyday, nothing more to implement and i dont have new projects to do.
So, i looking for open source projects to contribute - but i have little time at the moment.
That's sad
Learning by doing really works for me. Reading for a long time without doing something bores me a lot, but you know...You just have to learn how to balance learning using the two ways. Nice post 👍
Thanks ^
You're welcome 😉
So I have been coding for about four years now and I would say that your learning will progress with you. Meaning that the more you code the more you learn how you learn. I have done a ton of courses (in fact I still take some courses to get a very quick overview), and I was always frustrated at the end because I fealt that I was just copy pasting and not really learning. Now I learn by building and reading the docs. I have an idea for something that I want to do, do the research on a good stack then just start piecing that all together. Long story short, how you learn is going to just get better and better just like your code.
Thanks for your reply 😄
Excellent post. Thank you. I enjoy both ways as I like to know what's happening in the back. It helps to troubleshoot I believe.
Thanks for your reply guy 😄
An empty dichotomy. Read about Praxis and take a look at this by Richard Gabriel.
Thanks for this ressources
From my experience documentation is king, Though it might be difficult and boring to understand how to read them, everyone style is different. The easier you understand your style the advantage
One more time I totally agree
Thanks for your reply ! Very interesting metaphor
Reminds me how I started coding (when I was about 13 too). I had a computer with Visual Studios (I don't remember how I got hold of it), a grade 4 computer text book (had introduction to QBASIC in it), and access to only 1 hour dial up internet in a cyber cafe during the weekend.
I just used the WYSIWYG interface of Visual Studios to build Windows Form apps with Visual Basic. Didn't really understand what all the code was doing, I just knew if I double click on a button, it'll take me to the part of the code which will run when clicking on the button.
I pretty much followed this strategy to learn HTML and CSS with Dreamweaver's GUI. After some time you just remember the HTML tags and CSS properties.
Only got to real formal programming when I finally got better access to internet.
Thanks for your reply. I love your story
De las dos maneras se debería aprender, sin el concepto no se puede llegar al conocimiento profundo.
Im definitely in the "Practical way" camp, with a lot of focus on motivational factors in it.
If it goes on long enough, you will find that even those who self-built themselves the practical way, will one day pick up missing gaps in knowledge via the "Theoretical way" when needed, to help to improve their "Practical" craft.
Sometimes this can happen naturally as well, with new junior developers from university, educating the seasoned practical dev on specific "O(N)" problems - which for 90% of programming is not needed.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.