Ask HN: What advice would you give to a self-learn programmer just starting out?
I am self-learnt and will start applying to the new-grad tech jobs in around four months. What advice do you have for me?
* Build stuff you can show people.
* Don't get caught up in formal learning systems such as courses, lectures and classes. They are incredibly useful, yes, and certainly you should use them, but many people cling to them because they are easier than actually teaching yourself to code, and provide sense of security and accomplishment. When I point out to people that they haven't been actually coding, I'll often be told, 'well, this is how I learn,' and then they go on to show me how little they did.
* Don't fetishize the libraries and tools you are learning now. You will throw away many toolsets in your life: get used to learning new things as a permanent part of your job. I had one coworker who came through a bootcamp, and he tried just about anything to get us to add jquery to our dependencies, because he'd spent so much effort on it and felt so comfortable with it. He was more comfortable adding the entire jquery module to our app than bothering looking up the argument structure of the already included helper method from lodash: not because he was lazy, but because he was scared of the trouble involve in learning something. Neither you nor he can afford that.
So please learn about and/or think about the concepts of bigO even if you refuse to use the math's involved.
IMHO, this is exactly the kind of academic fetishization that makes these terrible interview questions so common in the first place: Knowing CS theory isn't going to slim down your build size or resource usage - knowing how to slim down your build size and reduce resource usage will do that.
And besides: no junior developer is going to be handed the kind of task where CS knowledge is remotely applicable. They are going to be building React/Angular/Etc components making backend CRUD APIs. They aren't going to be rewriting searching or sorting algorithms. For that matter, they aren't even going to be deciding what libraries to include that overload your phones resources.
I know more than enough CS theory to play the interview games. How much have I used it on the job? Maybe a couple of times a year, if that. In the first few years, never at all.
You say that you "never" use your CS knowledge if that's the case how to you decide if you are going to use a bogosort or a quicksort? I know that javascript simplifies a lot of these things, but you still need to be able to make informed decisions about performance trade-offs in your applications. And we still have a fairly large tech job market that does not involve any javascript at all, forcing developers to have at least some minor knowledge of datatypes.
Finally even if your target is to be a javascript(Angular/react/"whatever is cool right now on the web") developer at some flashy startup, I can't believe that some knowledge of design patterns, algorithms and datatypes would be considered anything other than beneficial.
And I would maintain that the internet as a whole would be a lot better if it was possible to view a page designed to display some text without having to download every framework created.
Sorry for the rant, I do really agree with you that there might be an unnecessary bias towards actual University degrees, this does not mean that the knowledge they represent (that can be learned without ever stepping a foot outside your door thanks to eh internet)is useless or not beneficial to any tech career.
How does stating otherwise differ from stating that civil engineers don't need to know math the have calculators.
>> decide what are of programming is in your focus i.e. mobile, embedded, web. Choose desired language. Here from my perspective, there is no language which fits for all solutions. Solution can be created almost in every language, but level of struggling with certain sub-task (functions/actions) might be huge.
>> Read a books about software engineering - how to write code effectively. This will teach you how to organize your code, how to write function, how to write readable code, how to write psuedocode.
>> Read a books about software architecture - here you can learn how to think about application, functionality, usability.
>> Learn basic principles like pointers, memory management, loops etc.
In parallel you have to write code regularly. It's much better to have real world problem which you are trying to solve. It's very important choose suitable level of difficulty. So do just small steps.
I can say programming task at universities are focused on certain aspect of programming or CS. If you are self-learner you have to keep motivated for a long time, so would be fine to have task where you can see and use results. So wouldn't try to solve university home-works. I don't want to struggle with matrix transpose if I don't it at all. I would rather create something which can help me verify my daily outcomes of current full-time job.
Or another (my personal) example... I am working with databases, documents, excel sheets, configuration files etc. I hate repetitive tasks. In case of I have to do the same thing at least a three times per week, I am trying to get everything automated, especially in case if it help me minimize effort, shorten time, reduce errors and typos, validate something, make better decisions.
It is also good points for my promotion in current or next jobs. HR and manager than look at me as "able to solve business/work issues through programming" than just "be able to program something".
(out-of-topic: it's good to have some hard number how you improved something, HR and managers loves story, numbers and savings, but this is another topic)
I now work for him. I guess it's networking in action.
Just keep doing what you like doing. If what you like doing is coding (and you can keep your work organized, do back and fix things, pay down technical debt as it arises) then you'll have no problem churn out successful projects -- and attracting people and job offers to you on that basis.
Write some more code.
Write code again.
Do it everyday.
Do it until you can't live without doing it.