Software developers have to repeatedly and continually learn massive number of new concepts, procedures and techniques related to the latest languages, frameworks and technologies up and down the stack.

The best way to learn would of course be to continuously read books in the spare time one isn't solving problems on the job and apply that knowledge.

I personally find reading books too time consuming for me. Books are presented in a depth first fashion, delving into multiple areas in depth one by one. This is not ideal for becoming productive quickly. There is no explicit ordering of how necessary / frequent a particular concept / technique is either.

What other sources of information / classes of sources are highest yield for picking up new technologies quickly [In the sense of getting productive fast].

An example of a high yield resources are well made slide decks. As an example, a slide deck on a language(e.g. javascript) made for experienced developers new to the language is much faster to process than a book. I can absorb the major features of the language, the syntax etc from a good slide deck in a fraction of the time it would take to read the introductory chapter of a book.

Any general comments (or specific sources) on how one would go about learning a new tech stack quickly would help too.

My current stack is linux, apache, python, django, dynamo, js, backbone

New Comment
14 comments, sorted by Click to highlight new comments since:
[-]elharo130

The only things that have ever worked for me to learn new technologies and techniques are

1) Taking on a major project in the language/technology

2) Classes

and I've learned a lot more from projects than classes. I've never found textbooks, slides, web pages, and the like, to be useful absent a concrete project to anchor my learning to. That said, if I do have a concrete project, then written materials such as books are hugely useful in accomplishing that project.

In brief, I advocate a sink or swim approach. For instance, if you want to learn Android programming start building a real Android app. Read the first couple chapters of a good Android book at the get go, and some of the official tutorial on the web, and then start coding. Refer back to the book, the tutorial, and the API documentation as needed during development.

After you've completed 2-3 projects in the new technology you'll have the basics down and start to see mistakes and flaws in your early understanding. At this point it's good to attend talks and read books and articles about best practices in the technology. E.g. if you're building PHP web apps, this is when you'll start learning about REST instead of just hacking together whatever seems to work. If you're programming in Java, this is when you read Effective Java. But first you need to have a basic familiarity with your tools and know how to use them, before you can start learning how to use them as a master craftsman.

Of course I have a sample size of one here. Different people learn in different ways, and you may learn differently than I do. But this is what has consistently worked to keep me at the forefront of every technological wave I've chosen to surf for about 20 years now.

Of course I have a sample size of one here.

Make that a sample size of two. This is my experience as well.

[-][anonymous]00

I am not sure how much the "learning in depth" can be avoided. This may be a prejudice, but it seems to me that software development typically really has a lot of inferential depth compared with... I don't know... plumbing.

In addition to this, software development is in motion. You can use the same screwdriver for decades, but software frameworks are developed so quickly that even remembering their names becomes a difficult task. (I can't even remember all frameworks in Java.) So it's not like they can't be taught effectively... it's more like there is so much of them that the few people able to teach them effectively didn't have time to learn the topic and write a book on the topic yet. (Maybe they will do 5 years later, but then you will want to learn something different, or a new version different from the old one will appear.)

If -- somehow -- we could choose the best programming language, or just say best 10 programming languages, two or three frameworks for each of them, remove everything else, and freeze the progress... then within 20 years we would discover efficient ways of teaching them, so that how we learn them today would probably seem completely ineffective in comparison.

But that is not going to happen, for many reasons, at least during the following decades. (Some of those reasons are good, such as progress, some of them are bad, such as reinventing the wheel either because of ignorance or for profit.)

Anki decks are great when you don't go into depth. Or when you go into depth using some other source (such as a book), and then use Anki decks to memorize what you learned there.

In my opinion, a good way to learn is to get a lesson from someone who really understands the topic, knows how to explain it, and especially is later available to answer your questions. A week of education this way easily beats months spent reading online tutorials written by people who overestimate their own understanding of the topic, or just don't care and do it for adsense (w3schools, roseindia...). But in my experience people are usually averse to pay for this. (It's like in their cost-benefit calculations they assign almost zero costs to their time and they horribly understimate how much time would they need.) The second best option is to read a book on the topic, or perhaps a few of them.

My current stack is linux, apache, python, django, dynamo, js, backbone

This does not provide as much information as it seems to do. I can install Linux (using the installation wizard) and run a few programs from the command line. Linus Torvalds invented Linux and probably knows everything. Where are you on this scale? Where are you on the Python scale: are you able to write "Hello World" or what exactly? How about the many things you did not mention here, such as: do you understand algorithms, computational complexity, formal languages, automata, functional programming, etc.? That could make a huge difference in choosing the right way to learn a new language.

Also... what exactly are you trying to achieve? Add a few keywords to your CV, or some other specific goal?

Linus Torvalds invented Linux and probably knows everything.

Doubt that very much. Linus is the creator of a kernel, which is only a small (though important) part of the whole shebang people call "Linux".

For most people, it probably doesn't matter all that much whether your "stack" includes Linux or FreeBSD or any of the other kernels you can find.

Similarly apache is going to be largely invisible to people who use a web framework at a higher level of abstraction than CGI (that would be most of today's frameworks).

Bottom line - I agree that describing one's "stack" in the above form is uninformative. Say not the names of products you had to memorize; say the things you can make them do.

The goal is to speedup becoming productive in that environment.

where productive =

desigining and implementing pieces of a big application (pieces 1K - 5K LOC, full project (50K LOC)) it implies making atleast 'not-bad' design and implementation choices and being able to think with the language/ frameworks with reasonable fluency to propose designs quickly. giving meaningful feedback to other programmers who are doing similar activity.

i realize that it takes time to get really good at and knowing the internals of the whole stack. Looking for approaches wherein the time to productivity can be reduced.

Okay, I seem to get it. Originally it seemed to me like: "I want to know everything without having to actually understand everything (just give me the most important bits and I will memorize them)."

But now I guess you simply want the information well-ordered, meaning that if you invest e.g. 100 hours of your time into learning, you get the most value anyone could get from 100 hours. Where "value" could mean perhaps: how useful it would be for average programmer's average task.

Two possible issues:

1) Maybe sometimes specialization provides better results. For example in 20 hours you could learn how to declare variables in 1000 programming languages, or... well, something else, that would be connected with what you already know, and would allow you to do some useful new thing. (Because knowing to declare variables in 1000 programming languages is rather useless.) So you could have different specialization paths. Perhaps too many of them.

Possible real-world examples: Using many programming languages / many frameworks, or becoming good at one or two of them. Learning many different things (algorithms, databases, GUI, networks, cryptography, etc.), or becoming a specialist for e.g. databases (or even e.g. Oracle databases).

2) Maybe it is important to know in advance how much time do want to spend totally. For example, let's say that knowing an information A can bring you $1000 profit, information B can bring you $500, information C can bring you $200, but a combination of B+C can give you $2000. If you know at the beginning that you will take two lessons, you can take B and C, which gives you $2000. But if you go incrementally, the best choice for the first lesson is A, then the best choice for the second lesson is B, giving you only $1500.

Possible real-world examples: If you want to spend one day or one week learning, just learn Excel. If you want to spend one year, learn Python, or perhaps Java or C#. If you want to spend 10 years, learn mathematics, formal languages, computational complexity, and at the end apply the knowledge to the programming language(s) or your choice. -- In other words: the more time you have, the more meta you can go.

I have seen people starting with PHP, because it provided useful results after ten minutes; only to hear them complaining a few years later than they can't keep up with all the new PHP frameworks, but they are scared to death from switching to another language. On the other hand, I have seen people who study theoretical computer science for years, but they would have problem to write a simple calculator app -- but also they don't need to, as they make money writing theoretical papers; and they would be able to make the calculator after a 3-days course in one language (and after a single 2-weeks course they could do it in 10 or 20 languages).

The #1 skill I've needed to foster since I began to program professionally is the skill of -not having to know exactly what is going on-. It's a very difficult skill to foster.

I work with, no joke, around 250 different technology frameworks/stacks. I don't get the luxury of only having to work with one operating system. If a client uses it, I have to know how to work with it.

The trick isn't expertise. It's a generalized knowledge of how people tend to construct frameworks, combined with -really good- debugging tools and skills, and high levels of Google-Fu.

The first part - understanding how people tend to create these frameworks - is the most important. If you can get a strong grasp of this, you're 95% of the way towards understanding any given framework.

Another important skill is knowing when to give up on a framework as being incomplete/unworkable/unmanageable. Those 250 are just the frameworks that have made the grade.

[-]Shmi20

So, what resources would you recommend to facilitate learning this skill?

I heartily recommend pretty much all of Jerry Weinberg's books to all software developers. The Quality Software Management series is awesome; a lighter but still impressively useful starter book is Are Your Lights On, which teaches how to ask the right questions when you have no freaking clue what is going on. Secrets of Consutling is another good one.

You won't find a line of code in these books. What they tend to teach you (well, me, anyway, YMMV) is how to gain an understanding of the non-technical essence of a problem. In 99% of cases the technology isn't the issue anyway; the problem-solving skills (or lack thereof) of the people involved are.

For the remaining 1%, pick a few products or frameworks that appeal to you and become intimately familiar with them, at the "critiquing a work of art" level. Then attempt to build something equally challenging; a virtual machine, an emulator, an OS kernel, a compiler, a whole video game, a web framework, that sort of thing. Deep expertise in any given thing will transfer well, if you have also mastered the art of problem-solving in general, i.e. when you have (to start with) no clue what is going on.

I used to be a decent Java expert, but nowadays I'd go to some lengths to having that kind of label slapped on me; the pay is much better working on problems at a higher level of abstraction.

Are Your Lights On is a good all-purpose introduction to problem-solving, but it's a bit... basic (worth reading anyways, just because I found it amusing, though). Are Quality Software Management and Secrets of Consulting a little more in-depth?

Very much so; QSM especially (originally a 4-volume series, JW has reissued them in ebook format along with other titles).

Personally I'd recommend practice; I can't comment on Morendil's book recommendations, as I haven't read those books, but now I'm thinking maybe I should.

I can't really think of a way to simulate business requirements (Morendil is quite right - 99% of the time, the biggest problem is getting past the client's own lack of understanding of their problem), but you could simulate the programming side of the equation.

Throw yourself into a technology you've never worked with before, and try to solve a problem that seems appropriate to it. Say, try to get a process to insert the contents of an Excel spreadsheet into an Access database using Apache POI feeding into ODBC drivers (provided you have no experience with either POI or ODBC) in a two hour timeframe.

Software developers have to repeatedly and continually learn massive number of new concepts, procedures and techniques related to the latest languages, frameworks and technologies up and down the stack.

Do they? That sounds kind of wasteful.

IMNSHO the best software developers are those who spot the underlying patterns, so that they don't have to continually relearn new stuff that will be obsolete (but sadly still need to be maintained) in five years.

Read books that address the deep stuff, you'll save lots of time.