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
Matija Sosic -
gohashira -
Giuliana Olmos -
Jesse Williams -
Top comments (30)
"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:
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
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.
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 🔑
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-...
My advice would be to keep playing. Build things just for fun, build things because you like them, do things your language was not designed for. If you are working in a database 4GL, try to build a game in it. This lets you look differently at the language and at programming in general.
Don't give up!
People who have done this longer than you still make mistakes!
You will never know all there is to know about programming, it's impossible.
Don't compare yourself to others..
If it takes you a little be longer than someone to figure something out, it doesn't mean you're a bad programmer, try to stay confident.
If you seem to pick things up quickly, it doesn't mean you're a superstar programmer and you need to stay humble.
Impostor's syndrome sucks, almost everyone deals with it, you're not alone.
Take care of yourself, make sure that development does not deter you from the things you enjoyed doing before you got into programming.