So you want to learn about programming pt.3

Part 3: Choosing your weapons of choice.

So you want to learn about programming pt.3

People that master skills look terrifying to newcomers, but they also get the job finished sooner 😅

In  every field of science there are new and exciting things coming out all  the time, and programming is not an exception. Everyday you hear about  new languages that promise to solve world hunger and cure stupidity, and  it’s hard to resist the temptation of losing a few hours trying them  out.

There’s nothing wrong about chasing after a new technology  you believe is going to be the next big thing, but be aware that  continuously following trends will make you a jack of all trades master  of none kind of person. You should focus on becoming proficient with at least one technology  stack, because chances are that you’re going to need a pay-check to get by, and companies don’t really go after those guys/girls that know 250  languages. They’re usually looking out for very specialised talent, and the more you know, the more you’re worth.


Choosing a language isn’t all that hard.

Usually  this choice will be easy — it’s a matter of picking one or two  languages that you’re most comfortable with. This usually relates to how  many years of experience you have, and if you have none or if all you’ve done so far is college handouts, take a good look at this post's picture above☝️which is a picture of Batman's utility belt.

If  you wanted to put batarangs on this utility belt for each language and  tool you know very well, it becomes quite obvious that only a few can  fit. This advice is valid even for experienced front-end developers,  which some times get lost in the ocean of frameworks that are out there  in the wild wild web.

Again I am able to see your virtual thoughts through your screen:

If I just started out with a language, it’s all I know and I really like it, why would I consider learning one more?

Good  question! In your path to mastery on your wonderfully chosen language,  you’ll eventually find evidence of what it can do well and what it’s  terrible at. But you’ll have to control your inner fanboy (if it’s  there) to see it.

Let’s take Java for instance, since it’s still a  very popular choice. It’s a great general purpose language. It’s strongly typed and that’s  good, and you can do pretty much everything with it. So where’s the  catch?

As a quick example, I can tell you that Java sucks for  scripting. When sane developers want to write code very quickly they use  something else, because aside from Java’s natural verbosity which  builds larger code bases, they might not want to be worried about  writing out variable types. This makes Java unsuitable in rapid  prototyping environments, and you should be very aware of this.

Failure  to acknowledge that languages have shortcomings that make them wrong  choices for certain use-cases will result in achieving fanboy status and  you’ll end up using a single language throughout your entire life.  Flowers will dwindle as you pass in the street and your feet will start  smelling despite not having noses.

Once you make up your mind it’s easy!

The  folks at PluralSight, CodeSchool or any other online school will be  more than happy to provide you with beginner and intermediate level  content for all your learning needs, but ultimately it’s practice that  enables you to truly ascend to the next level. In your learning path,  you should invest time in learning (in no particular order, and only for  “server side languages”):

  • File handling
  • Concurrency primitives such as threads
  • Networking
  • Connecting to and using databases
  • Web frameworks

You  can implement ideas that you have listed in a scribble book somewhere  in order to practice more, but you’re going to reach a point where  you’ve depleted all your creative brain matter. At that point I’d advise  you to start participating in Stack Overflow. It will probably be the  first time that you’re qualified to answer some questions, and please,  do it. Not only is it a good way to give back to the community, but it’s  something you can display proudly in your CV and show off how cool you  are.

You should be looking out for questions that you can’t  answer. These should be more advanced questions that use libraries or  frameworks that you might be interested in trying out. If you feel like  it, head over to the documentation pages of that library or framework  and see the available resources.

If you feel that you’ve handled  enough libraries at this point, you can also become more familiar with  the ones you already use in their official documentation pages. For  instance, if you learned networking, you can try to learn how to perform  asynchronous requests so that you don’t block threads from doing other  relevant work.

What’s next?

Once you feel  that you have a pretty good grasp of how all of concepts I’ve listed  above are performed in your language of choice, there’s a few things you  can do next.

If you really feel comfortable using the language  and it’s all dead simple to you, consider learning front-end languages  (HTML, CSS and JavaScript) in order to become a full stack developer.  Keep in mind that this is probably going to feel like you’re starting  over from scratch, but you’ll be a very valuable asset in a company if  you can handle both front-end and back-end technologies.

TL;DR

Become  a pro at least on one language. Move on to different technologies only  when you know enough libraries from your utility belt of languages.  Don’t learn every new technology, cherry pick each and every one you  decide to spend your time on. It’s better to master additional languages  than to master just one and then try everything new. Remember that  you’re physically and temporally limited to only a few mastered  languages. Don’t master a language just because you think it’s cool. If you lose  time with it, you should be looking at ways you can capitalize on it and  earn money from consulting or other projects after mastering it. Doing  it just for giggles is just a huge waste of time.