For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Antonio Silva -
Carrie -
Talha Ahsan -
Balraj Singh -
Top comments (30)
No single programming paradigm is more important than any other.
Don't buy into any particular school of thought.
Don't over-abstract your code.
Avoid object oriented programming, and languages that enforce that style of programming, especially whilst you are a novice.
Focus on the data that your programs are handling, rather than what it is doing. The former informs the latter.
Learn to use a debugger. Use it early. Use it often. Don't put it off until you have a problem. Step through your code to see how things change during execution.
Why stay away from OOP
for me it was comfortable to start with c# it's well structured and easy to understand.
Javascript on the other hand is a mess to read and to write if you'r a novice, but just my oppinion ;)
++ on the debugger
"Programs must be written for people to read, and only incidentally for machines to execute." -Abelson & Sussman, "Structure and Interpretation of Computer Programs"
Conclusions you should reach from this statement:
Don't give up.
Programming languages weren't designed keeping beginner friendliness in mind. Everytime you feel like "I don't get it. Maybe I am not meant for this" remember that most of the great programmers and engineers have gone through that.
This field is very very new (when compared to other Engineering disciplines). People are still trying to figure out the right ways to do things and they are changing every day.
Edit: Another important point, when learning a new language or framework, make sure to have a project or idea you would like to build with it and work towards it. Most of the learning (and retention) happens while building an app.
Note: Of course, there are languages like Elm and Elixir who prioritise making compiler messages more understandable and helpful.
Yep, I think it's important to have a project or idea and the patience to work on a basic default app, like a dummy blog. I found myself too willing to skip steps early on when too much of my attention was focused on the project.
Balance is 🔑
Redo something you struggled to do. Redo it at least twice. Redo it until you can do it automatically. Your abilities aren't measured by what you accomplished, they're measured by what you can do. So if you did it once, you maybe got 25% of what was there to get out of it. If you do it again, that second time it will go much more smoothly, you won't trip up on most of the things you got stuck on the first time, it might take you a day instead of a week. So much quicker and smoother, which means your time is better spent and your brain is less interrupted, leaving you more time to take away useful realizations. The third time you do it, you might get it in a couple of hours (or at the very least, you can practice until you're able to do it that quickly). You're sort of caching the lessons you learned in your head.
That project that was hard but you did it once, that's right at your sweet spot, you already did the hard part, the 80% effort that got you 20% of the knowledge. Do it a second time for 20% effort and 80% knowledge. Plus, you'll see how far you progressed, which will help you realize that yes, you can do this.
The reality is that any programming task you do is a bunch of smaller tasks put together. So if you practice something you know you can do, it gives you the opportunity to see and practice those smaller tasks that can be combined in other ways to do other things. Meaning that repeating a task or project will be very useful on the next different task or project.
It would also be worth reading the Little Book of Talent and / or Talent Code. Quick reads full of wonderful advice for becoming competent in a domain.
Programming is learning and problem-solving. Be comfortable with the idea that you will never know everything, but don't ever get comfortable with your knowledge. Dealing with bugs is part of the job (in some cases, THE job).
Keep practicing both easy and difficult problems - Read theory about a problem, but develop the solution by yourself. Even if not the ideal solution, it will give you necessary confidence to attack the next problem.
Do not be lead into believing that any coding technique or programming methodology is better than the other. Each has its own usage in today's word depending on the scope, application, implementation and requirement.
I actually wrote about my thoughts on this over on my blog, rather than copy and paste it all :) Give it a read id love to hear your thoughts
assortment.io/posts/how-to-become-...
As you start to get comfortable with a language/toolset, build something real.
Even if it's small and simple and even if you or anyone else never really use it. Just make it something real that has to adhere to real world constraints.
A lot of how languages are structured and implemented, how tools are structured and presented, how documentation is written, how questions are asked and answered online, assumes a certain real world context. One of the best ways to start getting that context is to build something that someone could actually use.
You'll find that when you try to build something that could actually be used you'll start running into problems that you wouldn't see in an "introduction to ..." tutorial. Getting past those problems will force you to gain a real and practical understanding of the tools you're using. Also, hitting those problems will force you to read though and understanding the documentation for the tools you're using.
One of the things you'll hear over and over again is someone asking "what is the best way of doing ..." and someone else answering "well, it depends...". That "it depends" comes from a lack of context (i.e. there are a lot of correct ways of doing it and picking one depends on your context). It's great to know all of the ways of doing it, but building something real, giving your project that context, is how you can start narrowing down the choices behind "it depends".
A lot of concepts in programming don't really start making sense until you see them or the need for them in the wild, so start exploring the real world. This is not to say skip the intro tutorials. Definitely do them, but don't live only in the theoretic world forever. Pass between the theoretic and the actual worlds often so you can explore and understand both.
Learn the tools (your IDE of choice). Do you know what the function keys on your keyboard do? Ctrl+F? Ctrl+S?
Error messages tell you where it's broken. Google the error message if you don't know how to fix it.
Read a lot. From a lot of different sources.
Use source control.
Keep at it. Don't forget that "academic cycle" ennokni.deviantart.com/art/Academi... (confusion > frustration > idle > epiphany > solution) always works.
Your objective is to achieve a stage when you see a task your mind already can give you a basic algorithm of how it's going to work within code, and then keep growing comprehension/data cycles memory.
Also - don't forget to make your variables readable, use whitespace, comment out more difficult barely readable functions. Don't spawn too much classes which only do single thing.
And try at least basically optimizing your code when you write it - always think how an ugly cpu-bloat/memory-hog will make you do the same work twice.