How do people learn how to do anything related to coding on their own
This may seme like a vague question, but how do people figure out anything related to computer science, such as coding or command line, on their own. It's just so unbelievably hard doing the simplest of things. I get tons of error messages or nothing works, even with following a tutorial exactly. The problem is not following the instructions, it is that when you follow the instructions it still does not work. This happens so often. The problem is made worse by unique system setting, having a different versions of windows, etc. How do people actually learn this or get things done? How is anything done when the guides are so infective? At the pace things are going, I cannot imagine ever actually doing anything useful.
20 comments
I find it hard to learn programming if I'm not intrinsically motivated. As another person mentioned, the learning curve is immense and it takes a lot of time to get a productive state.
Here's what I'd recommend:
* If you could build anything, what would you build? Have a clear vision and make sure it excites you. It could be an app, it could be a game, it could be the next GPT-3, it could be a calculator. Whatever the case, this is your north star & what you should work towards
* Forget about tutorials, focus on your building vision
* Seriously, don't overthink it - just start building
* Start small. Break it down into layers and tackle each step as you get there (eg. first I will create a webpage, then I will figure out how to share it with my friend, then I will make the webpage do something, then I will make it look pretty, etc.)
* When you get stuck, Google the problem. Don't think anyone's judging you, literally ALL 100 million developers before you Googled "javascript how to add another item to the end of an array"
* If you get stuck, have the mentality that GIVEN ENOUGH TIME you will find a solution to the problem
* Programming is a creative endeavour. If you don't know how to move forward, step away and take a break. You'll likely come back with 100 more ideas to try
* Focus on your vision. Work towards building it. I promise in a few weeks you'll be amazed at what you've managed to build
Here's what I'd recommend:
* If you could build anything, what would you build? Have a clear vision and make sure it excites you. It could be an app, it could be a game, it could be the next GPT-3, it could be a calculator. Whatever the case, this is your north star & what you should work towards
* Forget about tutorials, focus on your building vision
* Seriously, don't overthink it - just start building
* Start small. Break it down into layers and tackle each step as you get there (eg. first I will create a webpage, then I will figure out how to share it with my friend, then I will make the webpage do something, then I will make it look pretty, etc.)
* When you get stuck, Google the problem. Don't think anyone's judging you, literally ALL 100 million developers before you Googled "javascript how to add another item to the end of an array"
* If you get stuck, have the mentality that GIVEN ENOUGH TIME you will find a solution to the problem
* Programming is a creative endeavour. If you don't know how to move forward, step away and take a break. You'll likely come back with 100 more ideas to try
* Focus on your vision. Work towards building it. I promise in a few weeks you'll be amazed at what you've managed to build
Hard? You should have seen 35 years ago when you got a new computer, turn it on and all you got was C:/ ...with no internet.
Of course back then, with MS-DOS 3.3 or similar, you'd get a stack of manuals/books to go along with your software.
When I started using computers for the first time my opening prompt was:
When I started using computers for the first time my opening prompt was:
(c) 1982 Sinclair Research Ltd
Literally the story of my life.
It took me a few attempts to teach myself:
1) started drag&drop with simple logic using Delphi. It was fun but eventually ran out of ideas for problems to be solved and moved on to 3D modelling and then life happened.
2) Some years later, started watching some MIT videos where some math professor was teaching python via mathematical problems. It was awfully boring,so I stopped shortly after.
3) Got a job that eventually evolved into doing technical things. Got bored and started learning basic programming so O could solve more complex business problems. O was hooked. Automations, efficiency going up,etc. It all started from really basic database triggers and then gradually was getting more complex with integrations and etc.
I've also tried many tutorials,in the same way you did. For instance, recently I've tried Erlang. The language is beautiful but got stuck for hours in like step 3 because of some odd database related issues. It took much longer than I thought it will. The same with JAVA and Maven,etc. I think getting stuck on the infrastructure as opposed on the actual programming problems is very often problem. It's super frustrating, but what it does eventually it requires you to stop and really understand what os going on with that command line, some DB connection or a particular version. It's slow, painful process. If you manage to go through it,many many things become much easier afterwards.
1) started drag&drop with simple logic using Delphi. It was fun but eventually ran out of ideas for problems to be solved and moved on to 3D modelling and then life happened.
2) Some years later, started watching some MIT videos where some math professor was teaching python via mathematical problems. It was awfully boring,so I stopped shortly after.
3) Got a job that eventually evolved into doing technical things. Got bored and started learning basic programming so O could solve more complex business problems. O was hooked. Automations, efficiency going up,etc. It all started from really basic database triggers and then gradually was getting more complex with integrations and etc.
I've also tried many tutorials,in the same way you did. For instance, recently I've tried Erlang. The language is beautiful but got stuck for hours in like step 3 because of some odd database related issues. It took much longer than I thought it will. The same with JAVA and Maven,etc. I think getting stuck on the infrastructure as opposed on the actual programming problems is very often problem. It's super frustrating, but what it does eventually it requires you to stop and really understand what os going on with that command line, some DB connection or a particular version. It's slow, painful process. If you manage to go through it,many many things become much easier afterwards.
The hard answer is most do not learn CS related skills on their own, I sure didn't, but I was lucky perhaps. Ha, my first "benefactor" would have to remotely tunnel into my computer to literally force me to watch him run commands or remotely debug my code.
The reason everything is so hard is because technology we use today is inherited from decades of prior artwork and can be at times intolerable even to "pros". My benefactor went on and on about the meaning behind what makes a "hacker" exceptional compared myself. This is hard to communicate or understand but can be realized, after thousands of hours of struggle.
(My second benefactor told me something recently) I had a hard time realizing, in regard to returning to university, after a decade in the industry. He said, You have to interact, books aren't enough. Since he was a polymath professor, I could not argue, simply because my strategy thus far in this regard, objectively wasn't working out, irregardless if I was capable or not. I feel as though this is true because it's hard to rival yourself, you must see others (such as on HN) do better and take that as a challenge.
Trust me, if you have potential, simply make yourself known wherever you wish to be. Keep making mistakes.
The reason everything is so hard is because technology we use today is inherited from decades of prior artwork and can be at times intolerable even to "pros". My benefactor went on and on about the meaning behind what makes a "hacker" exceptional compared myself. This is hard to communicate or understand but can be realized, after thousands of hours of struggle.
(My second benefactor told me something recently) I had a hard time realizing, in regard to returning to university, after a decade in the industry. He said, You have to interact, books aren't enough. Since he was a polymath professor, I could not argue, simply because my strategy thus far in this regard, objectively wasn't working out, irregardless if I was capable or not. I feel as though this is true because it's hard to rival yourself, you must see others (such as on HN) do better and take that as a challenge.
Trust me, if you have potential, simply make yourself known wherever you wish to be. Keep making mistakes.
They learn from first principles by starting to organize things. The tools used for working from first (principles, materials, observed rules etc.) are based on organizations of observations of whatever is at hand.
If you're learning from someone else's first principles and it's not working for you, which is really common, try the break-fix opportunistic approach instead. Take something already built for purpose and use it until it breaks, then fix it. Always use every workaround possible in the meantime. Work around whatever you can't fix; even if you think you'll end up with a pile of workarounds, it will be a really well understood pile which is quite different.
This way you'll still get to first principles eventually as you understand the system more. You'll have infinite chances to design your own as your knowledge and experience increase. But some people have better results working in this way instead of starting from first principles. They are sometimes known as results-oriented personalities as opposed to process-oriented. In that they work backward from the needed result (which may be even completely improvised) as opposed by working forward with their own organizational ground-up process.
If you're learning from someone else's first principles and it's not working for you, which is really common, try the break-fix opportunistic approach instead. Take something already built for purpose and use it until it breaks, then fix it. Always use every workaround possible in the meantime. Work around whatever you can't fix; even if you think you'll end up with a pile of workarounds, it will be a really well understood pile which is quite different.
This way you'll still get to first principles eventually as you understand the system more. You'll have infinite chances to design your own as your knowledge and experience increase. But some people have better results working in this way instead of starting from first principles. They are sometimes known as results-oriented personalities as opposed to process-oriented. In that they work backward from the needed result (which may be even completely improvised) as opposed by working forward with their own organizational ground-up process.
That's why you start in high school or college. At that age you are naive enough, have more patience and time to learn this exhausting type of work.
I spent one summer in high school just to learn how to upload files via FTP. I would go once a week to an internet cafe (no internet at home) and I'd try to use shareware software(FileZilla did not exist yet) or upload files with Internet Explorer to some free hosting service, but nothing would work. When school started, a CS teacher overheard me asking a colleague about uploading files and recommended I use Total Commander's built-in FTP feature. From that day on, I knew how to upload files.
I honestly don't know what to recommend. I'd say use Linux because a lot of tutorials are doing that. But Linux might bring even more troubles, or you could be exchanging one set of problems for another. macOS might be a good compromise.
For me it was difficult learning how to use computers and how to program them. But I find it rewarding to solve problems and that gets me through the pain.
I spent one summer in high school just to learn how to upload files via FTP. I would go once a week to an internet cafe (no internet at home) and I'd try to use shareware software(FileZilla did not exist yet) or upload files with Internet Explorer to some free hosting service, but nothing would work. When school started, a CS teacher overheard me asking a colleague about uploading files and recommended I use Total Commander's built-in FTP feature. From that day on, I knew how to upload files.
I honestly don't know what to recommend. I'd say use Linux because a lot of tutorials are doing that. But Linux might bring even more troubles, or you could be exchanging one set of problems for another. macOS might be a good compromise.
For me it was difficult learning how to use computers and how to program them. But I find it rewarding to solve problems and that gets me through the pain.
Do you have a specific question? What stage are you at? Are you approaching the problem with an obsessed enough mindset (they call us nerds for a reason)? If you're having trouble getting a program to work, you have to keep at it no matter how long it takes. It gets easier over time.
It may be harder than when I got started, since software back then tended to be more self-contained. But if you can install Python/IDLE and get it to run, that should be enough to start playing with code.
As for computer science (algorithms etc.) it helps to have some reasonable mathematical maturity, so you can understand things like big-O notation intuitively. I'm not sure if that's what you were asking though.
It may be harder than when I got started, since software back then tended to be more self-contained. But if you can install Python/IDLE and get it to run, that should be enough to start playing with code.
As for computer science (algorithms etc.) it helps to have some reasonable mathematical maturity, so you can understand things like big-O notation intuitively. I'm not sure if that's what you were asking though.
When I started coding it was copying other people's code and running it. I didn't deal with anything else such as libraries, modules, frameworks, complex environments or advanced features.
I recommend starting with Hello World. From there add code and methods to that working tutorial and see how far you can go. When comfortable, start making your own app from scratch. Reading + copy/pasting people's code will be a large part of learning a new language.
For tutorials that add complex features, be aware that they have more advanced error situations which require more experience to get out of.
I recommend starting with Hello World. From there add code and methods to that working tutorial and see how far you can go. When comfortable, start making your own app from scratch. Reading + copy/pasting people's code will be a large part of learning a new language.
For tutorials that add complex features, be aware that they have more advanced error situations which require more experience to get out of.
>This may seme like a vague question, but how do people figure out anything related to computer science, such as coding or command line, on their own. It's just so unbelievably hard doing the simplest of things. I get tons of error messages or nothing works, even with following a tutorial exactly.
You keep at it, understand and remember some simple things at first, read man pages/google for others, and eventually you make mental patterns and learn to understand what's going on, even when it's not working "as it should".
You keep at it, understand and remember some simple things at first, read man pages/google for others, and eventually you make mental patterns and learn to understand what's going on, even when it's not working "as it should".
[deleted]
Turn into a snob? When a tutorial from a certain domain disappoints you, stop following links into that domain. Seek operating systems with smarter people, and fewer errors. Look for languages with high quality in implementation, documentation and ecosystem.
See you in a few years, when you you'll ask for advise as there aren't jobs for people whose stack is arm, *bsd, sqlite/postgres/redis, cl/elixir/go.
See you in a few years, when you you'll ask for advise as there aren't jobs for people whose stack is arm, *bsd, sqlite/postgres/redis, cl/elixir/go.
Things I wanted to do kept me motivated. I guess my inclination to mathematics also helped.
I actually take pride in being mostly self-learned concerning computing. "Only the self-learned is learned. Others are taught." Erno Paasilinna.
I actually take pride in being mostly self-learned concerning computing. "Only the self-learned is learned. Others are taught." Erno Paasilinna.
This is the key personality trait required to be a programmer.
What's your background? What are you trying to learn?
Just trial and error mostly, and digging through example code. And learning to google. I always thought everyone just knew how to look for solutions to their problems online, but when observing others learning to code I realized this is not the case. It takes practice to know how to word what you're searching for.
But to go on a bit of a tangential rant about doing it "on our own":
I don't think many people do it on their own _really_. Most people eventually get to a point where their code is out in the world for feedback. Whether it is something they're getting reviews on at their job, or a personal GitHub account, or their blog.
I learned enough to hack stuff together through trial and error in a little bubble to start with, but then I started blogging and getting involved in the community of a framework I'd been using. I would post questions and try to contribute answers, and all of that expanded my knowledge (even answering a question usually involves learning).
Later, as a junior programmer, I was on a team that had a _very picky_ teammate. He'd point out every nitpick he could in code reviews. Things that might not necessarily "matter" in practice in _that_ particular scenario, but that were just not as efficient or well implemented as they could be. I put "matter" in quotes because my mindset is now: of course it matters. Knowing what tradeoffs I'm making and not getting complacent with quality always matters, as I learned from these reviews.
And when reviewing my code he always asked "Why" questions. Why did I chose to use this data type vs that one? Would a hashset be better here? Why did I go with a LINQ method? What iterations are involved in this, and why do we need it? Why is there a null check here, why would this ever be null (a harder question than one might think considering we were working in a huge, old, proprietary codebase)?
Every code review was a bunch of questions and improvements, and it was extremely useful. I learned to predict the kinds of questions he'd ask me and look for answers in advance, often finding better approaches in the process. And when he asked "Why" in the next review, I'd get to explain exactly why, and how other options were subpar in this case.
I'd credit him with a very big chunk of my development as a programmer: mostly learning about the importance of why I'm doing something this way vs another way, digging into internals, deciding if the performance tradeoffs of my approach are worth it (and _knowing_ the performance tradeoffs), and paying attention to details.
I'm technically what people refer to as "self taught", but I definitely didn't do it on my own.
But to go on a bit of a tangential rant about doing it "on our own":
I don't think many people do it on their own _really_. Most people eventually get to a point where their code is out in the world for feedback. Whether it is something they're getting reviews on at their job, or a personal GitHub account, or their blog.
I learned enough to hack stuff together through trial and error in a little bubble to start with, but then I started blogging and getting involved in the community of a framework I'd been using. I would post questions and try to contribute answers, and all of that expanded my knowledge (even answering a question usually involves learning).
Later, as a junior programmer, I was on a team that had a _very picky_ teammate. He'd point out every nitpick he could in code reviews. Things that might not necessarily "matter" in practice in _that_ particular scenario, but that were just not as efficient or well implemented as they could be. I put "matter" in quotes because my mindset is now: of course it matters. Knowing what tradeoffs I'm making and not getting complacent with quality always matters, as I learned from these reviews.
And when reviewing my code he always asked "Why" questions. Why did I chose to use this data type vs that one? Would a hashset be better here? Why did I go with a LINQ method? What iterations are involved in this, and why do we need it? Why is there a null check here, why would this ever be null (a harder question than one might think considering we were working in a huge, old, proprietary codebase)?
Every code review was a bunch of questions and improvements, and it was extremely useful. I learned to predict the kinds of questions he'd ask me and look for answers in advance, often finding better approaches in the process. And when he asked "Why" in the next review, I'd get to explain exactly why, and how other options were subpar in this case.
I'd credit him with a very big chunk of my development as a programmer: mostly learning about the importance of why I'm doing something this way vs another way, digging into internals, deciding if the performance tradeoffs of my approach are worth it (and _knowing_ the performance tradeoffs), and paying attention to details.
I'm technically what people refer to as "self taught", but I definitely didn't do it on my own.