Learn just in time Or Learn just in case

Question

This is not a question but more of a discussion.

A while ago I ran into a blog post which talked about learning just in time or just in case. It was about three years ago when I just started learning about OO. I have been programming since 1995 in procedural world. Over the last few years fearing my skills are facing Obsolescence, I started learning .Net. After learning basics of C# and OO (6 months), I went thru the 'Data Access Tutorials' by Scott Mitchell on the ASP.NET site (6 months). Then I figured I need to apply DAL to Webforms so I spent another 3 months learning basics of session management, postbacks, cross page postbacks etc. Then I started following the Alt.Net crowd, and I realized that DataSets aren't that useful in enterprise Apps so I ditched that thing. So then I tried my hand at learning Patterns(another 3 months or so) and quickly ran into the wall, basically because most patterns are using animals, cars and pizza's, I couldn't figure out how they applied to the real world.

I realized I need to learn the SOLID principles by Uncle Bob but than I heard Joel saying these principles are stupid and can't be applied in real world development. that confused me even more.Then I tried to learn some simple Data Access Patterns such as Subsonic Active Record Pattern(2 months). Again I realized that Active Record Pattern isn't that useful in Enterprise Apps. Then I spent several months reading up on DDD, TDD, Agile principles, SOLID, DI, Service Locator, Repository, DAO, and countless other acronyms hitting a BRICK WALL every time.

---

Sorry about the long post.

Recaping:

• right now I feel I am proficient with c# 3.0 (not at Jon Skeet's level yet and will possibly NEVER get there)
• different ways of writing data access code.(straight ADO, Active Record, full blown ORM like Nhibernate)
• some basic UI patterns such as MVP

I was thinking the next logical step would be dive into DI like StructureMap and after that I still got WPF, WF, WCF, ASP.NET MVC, Functional languages like F#, IronPython, IronRuby and on and on and on. All of those will take years out of my leisure time. But I don't mind. My only hobby is LEARNING.

Realizing you can't learn all of these to the nth degree, what would be the right order for the aforementioned things that I should learn?

Answer 1

I would suggest finding some project that requires one of the skills you're interested in, and dive into that. Learn what you need to work on a modern, actively maintained project.

The problem many people face from learning via books/blogs/etc, is exactly what you described. There's a big difference in understanding a pattern in a simple case vs. applying it in a "real" application, especially a large, maintained codebase. Working on a project that utilizes the patterns/languages/technologies you are interested in will force you to understand them fully.

Open source projects are a great way to go for this... But it is important to find something you will truly be interested in working with for a long period of time.

Answer 2

Learn incidental details like patterns, frameworks and syntax Just In Time.

Learn core fundamentals like languages, OOP, and functional programming, Just In Case.

To find out what to learn and what not to learn, listen to podcasts.

Answer 3

I think you are missing a fundamental aspect of learning: practice. You seem to have a fair amount of frustration with not being able to break through on various technologies and I suspect it's because you aren't taking what you are learning and putting it to use. It isn't until you actually start making use of the technologies in real-life situations that the lightbulb goes on, at least most of the time.

It's ok to dabble, as long as you're just doing it for fun AND are enjoying yourself. There are technologies where I've taken a little detour and learned just enough to help me with something else, but for getting to actually know something, you need to work with it in a real setting.

In my opinion, you need to do a little of both: just in time and just because. Expose yourself to various technologies to get an idea of what is out there. When you run into a situation where a technology that you've seen will become useful, dive deep into it and put it into practice. You need to have at least a few areas where you have some real depth to be a good programmer; you can't have a shallow understanding of everything -- not that I'm implying that you do; just that it can be that way if all you do is learn without a purpose.

Also, not everyone agrees with Joel Spolsky on the SOLID principles -- and I'm not even sure he does himself. I'd suggest that perhaps there was a misunderstanding of the difference between a principal and a law. I'd have to revisit the follow up podcast with Uncle Bob to be sure.

Answer 4

You can't possibly learn just in case, because there are too many technology out there. I also doubt you can learn just in time, because normally you will have tight schedule.

Learn what you interested :)

Set up a project yourself, and along the development you will encounter various of problems. From there you can start to investigate what skills are needed. You will learn something, by knowing "why you want to learn it". You can learn easier, and use it, instead of just memorize the theory.

Answer 5

No technology or methodology is perfect. You seemed disheartened to learn that DataSets, Active Record Pattern, and others have their disadvantages. However, these same techniques may be completely appropriate in other situations.

Part of the learning process is understanding its advantages and disadvantages, so you will be able to apply it in the right situation (just in case). Edison supposedly said he had to first learn "a thousand ways not to build a light bulb". I think the same mindset applies to software development too.

I would advise you to seek out both the pro's and con's when you learn something new. This is a great asset in your career growth and certainly isn't something that should be discouraging.

All the best.

Answer 6

Where do you want to go? That's my initial question at the end of this because there are a few different options:

• Management - If you want to be a Team Lead or Manager then it may be better to learn about management and people instead of technology, e.g. PeopleWare is a book about this.

• Architecture - If you want to be an Architect then you may need to revisit patterns as well as look into practices with an eye toward the big picture that is a key of having this role.

• Rock Star Developer - If you want to be a famous developer that trains other developers then maybe you want to explore Thoughtworks and see if they can help you build your skills.

There are probably other choices for the end but those are the main ones aside from staying as a plain ol' developer.