This question is so often asked that we have created a separate file for it. See here.
2. I know how to program in X, what should I learn next (or how can I get better/more well-rounded at programming)?
http://norvig.com/21-days.html is a great article about learning to program in general. There's a specific section in this article that suggests: Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
First off, this is a terrible question to ask. Unless you are an absolute beginner with sub six months of experience, you shouldn't be asking this. Learning to program by yourself is always fueled by a goal.
- Some people want to make a bot
- Some want to make a minecraft plugin
- Some want to make their own game
- Some want to build a website
- A chat application
- etc
Do not look for sources of internal motivation from other people... internal motivation, i.e. stuff that you are not paid to write, comes from you. You can use the macro ++projects for some project ideas, but ideally try to find a space that really interests you.
If you're interested in building large scalable frameworks read up and work on that. If you enjoy web design and A.I. read up and work on that. Search through GitHub, read articles and take notes of what interests you.
Your reasons to program are your reasons to program, work on what you enjoy. The best we can do for you is #project-listings - don't expect to be inspired. If you want more stuff to look at, try contribute to open sourced software by browsing GitHub. Outside of that - it's all you dude.
This is another one of those questions that you just genuinely should not ask after a while; if you are a beginner it's okay to think about this, but after some time you should have it figured out. By this I mean, it does not matter if you copy and paste. It doesn't matter if you need to type something out with your toes; do you understand what is on the screen? - Would you be able to answer in depth questions about it? That's what matters. You shouldn't care how someone moves code around.
No question is a stupid question, and if the other answers here highlight FAQ as such, that's not the intention (we wouldn't answer them if that was the case), but this question is one of the extremely good questions to ask. How could you possibly know the answer to this if you did not go through the process? Well I'll tell you the answer: It depends.
The real question people are asking here is "can I get a job without a degree in computer science?". Yes, you can. But the real question is should you? That also depends. Degrees are fantastic for giving you a wide spectrum of knowledge in the computer science field.
A good degree should give you an overview of hardware, software, web development, software development, software process, math, programming, data structures, logic, AI, algorithms, design patterns, a variety of languages and more. The reality is there are very few which actually tick all the boxes (And there are more boxes than what I just listed, depending on what it is you want to do). So the real answer here is if it makes some genuine sense to you to acquire a degree, then do so.
You should take into account finance, the actual degree itself, location, experience, time. If you're not sure about how good the degree is, your university or college should have an open day. Go to it and annoy the crap out of someone who is on the degree program. Ask them what they learn about and Really drill them for the topics you think you are interested in. If you're not sure what topics you're interested in, but are convinced programming is for, you should be looking to see if they have a lot of variety.
With all degree programs, you should be doing your own work outside of the course. Setup a LinkedIn, and a GitHub. Start contributing to open source software in whatever way you can. If that means making a pull request to correct a typo or to better explain something, then do that. Ideally, make your own projects, learn your own things, explore. Employers want people who are capable of operating by themselves.
In the case that you decide that you do not need a degree (which, depending on the job market near you, or what particular thing you want to do, you might require one), you are definitely going to need to do a hell of a lot of self-learning.
As mentioned above, contribute to open sourced software, try to do side jobs for people, if you're looking to be employed as a front end developer, get some side jobs doing websites for friends and family and put everything you got into them. Build up a portfolio.
Most importantly make the decision soberly, after a lot of thought and discussion. Signing up for a university degree is a massive, life changing decision. In some countries the expense is often crippling, so do not make this decision in haste. If you need to take a year out to work a part time job whilst you figure out what the hell you actually want to do, do that. The world isn't going to run away on you.
The answer is different for different people (google "learning styles" for more info on that). A simple recommendation is to "be passionately curious". Ask questions, read stuff about the topic in hand. Most importantly practice/experiment with the topic.
The world's greatest marathon runner didn't read a bunch of books about running and then go out and break records - they got good by running... a lot.
There are a lot of possible answers for this question, some say you should use feature rich editors, some say you should use feature light editors, some say somewhere in the middle.
Vim, emacs, visual studio or intellij? text editor vs IDE? -- what actually is an IDE? Linux is my IDE. Linux? I use windows. Windows? I use mac. Mac? ... you get the point --
All of this is by in large opinion, there are some ways to be objective about it, but at the end of the day, an editor is a tool. You are the user of that tool, what you do, what you think, and how you use that tool matters way more than the tool itself.
Try out all of the tools that seem relevant to your space. Give each of them a month or so (trust me, you have plenty of time, a lot more than you think). It may be worthwhile in a small way to gather the opinions of others as a starting point, but remember what you personally think matters much more, so the sooner you get to developing your own opinion by using the tools yourself, the better.
This is one of the questions that the answer should be immediately apparent without you having to ask it. If your objective is to learn how to, say, render graphics in 2D games, it might seem attractive to ask if you need to know matrices/vector/physics or some particular branch of math that you think you might need.
Similarly if your objective is to learn Haskell, it might seem like a good idea to ask if you need to know propositional logic beforehand. Think about actually asking the question first, though. If you are reading through the "how to 2D graphics" document/book and it talks about these branches of math and uses them as if you should know them like the back of your hand, then yes you need to go learn it.
tl;dr if you're reading through some learning material and it talks about something completely alien to you as if you should know it, google and understand that thing first. Most materials will tell you what you need to know before you begin learning.
In short - No. If that's the answer you wanted to hear, stop making excuse and go write some code. For the more detailed answer see below:
You don't really need math as a developer, unless you are working in a space that explicitly requires it (e.g. Data Science, Graphics programming, statistics, finance, etc - you get the idea). That being said, some standard competency when it comes to math will certainly help you. Computer science derives many concepts from math, so being able to trace through history and see why a concept exists, how it came to be, and the true nature of it - that's a useful tool. Not to mention that math will help you quite a lot with mentally juggling abstraction. Logic and and various other elements of math can be found directly in some languages, many languages contain a math library that is easier to navigate with a basic understanding of math, etc. That being said, if you're just going to be writing some CSS or you're going to use a CMS or you're just a configuration monkey, no math is going to help you.
In short: Math is not required for most positions, some positions do require it, and a good understanding of math is a nice tool to carry with you on your travels as a developer.
The first thing to know about freelancing is that programming is not the hard part of freelancing. That would be finding clients. You'll also have to manage client expectations and potentially deal with issues such as non-payments, scope increases, and schedule changes. You'll also have to be aware of legal and tax like issues for the area you're working from and the area your client is in. So, how do I find clients? Look for meetups and other events in your area where you can meet people in person. Never underestimate the value of an in-person relationship. It is tempting to look online and there are many sites that offer chances for freelancers and clients to advertise. But, these are highly competitive, leading to low prices. What languages/tools/frameworks should I learn? Whichever one will get you clients (see the first two points) How much should I charge? What a reasonable rate is varies dramatically by location. Use tools such as glassdoor to decide on what you think is a reasonable hourly rate for you. Then note that your hourly rate as a freelancer should be higher than what you would receive as an employee. Ideally you want to then charge the client by the hour. This avoids both parties being short changed (e.g., if it takes more or less time than you expect) and allows for changes in spec or scope. If a client does insist on a fixed quote you should ensure you have a very rigid specification and multiply how many hours you think it will take by your hourly rate, and never forget Hofstadter's law