Take the 2-minute tour ×

As a junior programmer, how much time should I spend focusing on new libraries or language features, as opposed to learning how things worked before those libraries came about? How dangerous is it to learn these libraries before I can understand the details of their implementation, or even fully appreciate the problems they solve?

This came up as I was doing a bit of research on Reactive Extensions. One thing I do know about .NET events and asynchronous programming is that they're kind of a pain, so I can sort of intuit what's exciting about the framework, and even some cases where our own product could probably benefit from it. But I have not yet spent much quality time with events or asynchronous programming in general. I find I have to remind myself about things like delegates, lambdas, even what the IEnumberable and IEnumerator interfaces look like, before I can really get the RX concepts. This makes me apprehensive about spending time learning the framework, out of a worry that I won't truly understand it, or I'll end up using it inappropriately.

I have similar feelings about LINQ, though in that case it's more about not fully understanding how it's implemented. I'd spent more than enough time with collections to understand and love what LINQ can do right out of the box, but not enough time to understand how it does it, or the best ways to use it. Not knowing what's going on behind the scenes makes me nervous about doing something grossly inefficient, or just plain dumb.

This makes me think I need more time with the foundational stuff that led to the development of these libraries - but that leads me to think that I'd probably get a higher ROI, and help my team more, if I spend what little time I have to learn new things getting acquainted with the stuff that would make all our lives easier.

Though I'm coming at this from a .NET perspective, I'm sure there are analogs on other platforms. I guess the real question is, can you ever get the most out of a "paradigm shifting" feature without having spent some real time drudging through the old paradigm?

share|improve this question

6 Answers 6

up vote 3 down vote accepted

You should use libraries when you actually need them. There are too many libraries to learn and learning them deeply without a real need is a waste of time IMHO. Read books, blogs etc. to gather information about libraries, programming techniques etc. Eventually you'll have an "index" in your head so that you know which libraries/techniques could be used to solve a certain problem or where that information could be found. There's no need to memorize how to actually use a certain library. You will forget it, if you don't use it regularly. Just remember what to use/where to look for. You can find an up-to-date usage example in a couple of minutes. Code real projects and use suitable libraries when needed. Read about new things when not coding and apply when it seems suitable for a problem.

In .net I would use the latest stuff if there aren't any restrictions in the target platform. E.g. writing a bunch of loops and ifs to filter collections is just stupid, if you can use LINQ. Try to choose best tool for the job. Don't force use of a new tool, if it doesn't fit.

share|improve this answer

I made the mistake of spending a lot of time trying to learn libraries and everything in them and all that came out of that was that after 3 years, I still didn't know how to program. It wasn't until I started creating projects for myself to work on and then finding a job that forced me to code that I begin to learn how to program. If anything I'd spend time getting an overview of design patterns, databases, etc. and create a blog or something to talk about what you learned so that others can benefit (and helps you remember).

share|improve this answer

Learning few important libraries is fine. But do not spend all your time in learning libraries.

    1. Learn the basic Data structures and algorithms 
    2. Learn how to use version control, how to unit test.
    3. Learn how to design software. Start by reading design patterns. 

There are many other things. But these are some things to start with.

share|improve this answer
"design patterns." and "design software" are orthogonal. –  Raynos Jul 26 '11 at 10:49
What is 'orthogonal'? –  Vinoth Kumar C M Jul 26 '11 at 12:33
not related. Learning design patterns will not teach you how to design software. However design patters are useful. –  Raynos Jul 26 '11 at 12:45
that's what I meant. :) –  Vinoth Kumar C M Jul 26 '11 at 13:41

My suggestions are:

  1. Learning is not limited by time in computer world due to fast growing speed. You have to learn always.
  2. Try to grasp a general knowledge of all major fields (like game development, web development, cryptography, etc.)
  3. Don't learn tools or platforms in your general study. Just concepts.
  4. Choose your specialty field. For example decide to become a web developer.
  5. At first, learn something to do the job. Don't learn parallel tools or platforms. For example ASP.NET MVC does the job as good as PHP. Don't learn both of'em. Instead of PHP, learn SQL Server, or instead of ASP.NET MVC, learn MySQL.
  6. Keep your movement from general study to specialty and expertise. In web development, try to become C# master for example, or CSS master.

Remember Eiffel Tower? Become that.

share|improve this answer

You'd get further learning languages in-depth and a good variety of them than learning libraries. In five or ten years the new hot libraries will be totally different. You can always pick up a library by Googling the documentation, but it won't help if you don't know what it means when it says it takes a delegate.

share|improve this answer

You raise a valid point. I have seen people (myself included) learn about a framework (Spring in the case) without having suffered from/deeply understanding the problem it solves. The result was abuse of Spring's functionality to solve problems which wouldn't even have existed if we didn't use Spring at all.

Moreover, every technology has its implementation details, there is no perfect abstraction. That means you will get bitten if you don't even attempt to understand how the framework/library you use is implemented. Again, this is bitter experience talking.

So, to answer your question:

Every hour you spend on deeply understanding the technology you are about to use will save you two of reverting stupid changes later on.

share|improve this answer

Your Answer


