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.
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 ;)
"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:
Code is an art, not a science. Okay, fine, it's also a science. But thinking of it as an art is highly productive.
Everyone's code is a little different. That's a good thing.
Being a great coder means putting more effort into your code than users will necessarily be aware of.
Messy, misaligned, or inconsistent code is an evil in and of itself.
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.
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.
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.
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.
I am an OpenEdge (aka Progress) developer that loves clean code and good looking applications that are easy to use. My main pet project is the Progress DataDigger
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.
Read a gentle introduction to application security. It's a far more approachable way to begin thinking about writing software that isn't totally insecure from day one, while also not bogging you down with technical details.
My advice is to find a solid and a bit lengthy material (either a online course, a book, or a long YouTube tutorial crash course) and just stick with it from top to bottom.
There are two reasons: 1) the quality and 2) the mentality. In my opinion, those materials have far better qualities to give you a solid foundation for furthering your knowledge in the future. They are better structured. Thus, instead of independent concepts spreading around the Internet, following along the materials will help you construct concepts on top of each other and you'll be able to link one from another. Also, it's a great practice of perseverance to follow along a lengthy task, which I think it's a common thing in the coding world.
Projects are great, but they can sometimes be the worst way to learn at the very beginning.
I've seen too many people get discouraged because they started out with a project that sounded easy to them but then turned out to be way too difficult. For example, they'll say something like "I'll just code up a quick social network," and then it'll be too hard and they'll give up on coding completely.
If you're curious, I've written the full explanation here:
The main point is to take even one afternoon to learn just enough of the basics to get an idea of what sorts of projects are reasonable. When I say "reasonable" I mean small enough to maintain momentum and significant enough to keep it interesting.
Learn the logic, theories and concepts. Nowadays it's too common for people to focus on "getting things done" without understanding what they are doing. Knowledge trumps a quick fix every time.
Start a personal project, something that genuinely interests you. Solving contrived problems in isolation is not nearly as valuable as having a vision and solving each problem along the way.
Find a project that you're really excited about implementing. Nothing beats an actual project in learning how to code. But be prepared that you might not succeed or have picked too hard a project.
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.
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.
Read a gentle introduction to application security. It's a far more approachable way to begin thinking about writing software that isn't totally insecure from day one, while also not bogging you down with technical details.
My advice is to find a solid and a bit lengthy material (either a online course, a book, or a long YouTube tutorial crash course) and just stick with it from top to bottom.
There are two reasons: 1) the quality and 2) the mentality. In my opinion, those materials have far better qualities to give you a solid foundation for furthering your knowledge in the future. They are better structured. Thus, instead of independent concepts spreading around the Internet, following along the materials will help you construct concepts on top of each other and you'll be able to link one from another. Also, it's a great practice of perseverance to follow along a lengthy task, which I think it's a common thing in the coding world.
Projects are great, but they can sometimes be the worst way to learn at the very beginning.
I've seen too many people get discouraged because they started out with a project that sounded easy to them but then turned out to be way too difficult. For example, they'll say something like "I'll just code up a quick social network," and then it'll be too hard and they'll give up on coding completely.
If you're curious, I've written the full explanation here:
simplestepscode.com/dangers-of-pro...
The main point is to take even one afternoon to learn just enough of the basics to get an idea of what sorts of projects are reasonable. When I say "reasonable" I mean small enough to maintain momentum and significant enough to keep it interesting.
I hope this answer is useful!
Learn the logic, theories and concepts. Nowadays it's too common for people to focus on "getting things done" without understanding what they are doing. Knowledge trumps a quick fix every time.
Start a personal project, something that genuinely interests you. Solving contrived problems in isolation is not nearly as valuable as having a vision and solving each problem along the way.
Learning to code can be tough. Don't give up just keep CODING and you will get better.
Find a project that you're really excited about implementing. Nothing beats an actual project in learning how to code. But be prepared that you might not succeed or have picked too hard a project.
Clean and tidy code is much more important than you'd think.
Try and find opportunities to fix bugs first. Even for a 1 line fix, you need to learn to understand how all the rest fits together.
Pick your battles.
Start coding with TDD
Be egoless: blog.codinghorror.com/the-ten-comm...
Your users will always do what's least expected and most infuriating.
Get Your Swagger Down Pat.
Find a goal, something you want to do with code.