Search This Blog

Loading...

Monday, July 7, 2008

Do You have the Time to Learn Everything?

Zuidhof asked an interesting question in his blog: do you have the time to learn everything? He gave an incomplete list of newest .Net technologies and software methodologies that any developers worth his salt should know. Going through them can be quite daunting for even the most gifted developers; there are just too many things to learn and not enough time. I am pretty sure that in another year or two Microsoft or the software development world will throw at us another list of "must learn" technologies, and push us the poor developers to upgrade ourselves again.
Getting to learn new technologies are no joke as they can have deep learning curve. WPF and XAML are the classic examples of this. The XAML syntax is completely different from other existing languages and that is a challenge for the beginners. If you are not actively using new technologies at your work and you have to pick them up on your own, you probably will never have the time to learn all new stuffs.
But somehow in an IT world where developer's asking salary is determined by the technologies he mastered ( instead of analytical skills and the smarts), learning new technologies is necessary just to keep up with your salary expectation. It's not so much of a question of whether you have the time to learn any new technologies, you must or else you grow obselete. It's also not so much of whether you have the time to learn everything; you don't.
So obviously you need prioritization. When comes to this, my humble suggestion is that you should prefer technologies ( such as LINQ-SQL, ADO entity framework) over software design philosophies ( such as continuous integration, agile programming etc). There are a few reasons for this:
  1. It's more marketable, as far as the job market is concerned. HR department scans for keywords when comes to hiring. Now you may say that you are comfortable with your job and you don't plan a switch. But still, it's better to retain your marketability, just in case-- I mean, really, just in case-- you need to find a new job.
  2. Technologies are more "quantifiable". A competent team lead can know whether you really know LINQ-SQL, or ASP.NET MVC by looking at your code, but how does he know that you know enough about agile programming?
  3. Technologies are easier to learn, in the sense that you can simply pick a book and start coding. But software methodologies are much harder; they take time and deeper thoughts.
  4. It is said that technologies are ephemeral, but software methodologies are here to stay as long as there is software development. But who cares? Do you think your fellow developers will be impressed if you know the A-Z about software design? I don't think so. They ( and the headhunters!) will be more impressed if you have a lot of technologies under your belt.
Which technologies are more important? I think ADO.NET entity framework and LINQ-SQL are the most important because they are the further simplification and abstraction of the data access layer. Hence, you can apply them gradually in your day job and ease the development task. Unit testing tools and mocking are important as well, but because the employers don't value them as much, so I have to rank them second to the ADO.NET entity framework and LINQ-SQL.
Or, if you are out to amaze your friends with Microsoft technologies, you can try WPF. But my experience with WPF is that it only makes the most impact when you are also an excellent graphic designer. Otherwise as a plain developer the apps you create may not be very impressive and that somehow reduces the fun of learning.

18 comments:

Arjan Zuidhof said...

Hi Soon

Thanks for your elaboration on my poorly worked out list ;-) I agree with the prioritization thing: keeping up with *everything* is such a daunting task that it's a mission impossible by all means. I even left the designer-y stuff like XAML, WPF, as you so aptly use as examples out of the list, while for the average .net developer in 2008 they definitely deserve a place. But the list was just to get you all started.... also agree on theWPF thing: I tried some first steps in in, but as the model behind it (and XAML) is just so totally different, it will take enourmous amount of my finite time to create something that will be blasted to pieces by even the most junior designer.
What I don't completely(but partially) agree with is your choice for focusing on technologies. My assumption is that technologies change faster than methodologies. So: a good understanding of design patterns, agile (if you're into that; I know I am), etc. will in the end help you tremendously in understanding the technology du jour (think ASP.NET MVC)... On the other hand, you're totally right that the technologies do have their place as these are the eyecatchers on our CV's

Soon Hui said...

Hi Arjan,

Thanks for responding to my post and presenting your alternative view.

I agree that a good understanding of software design methodologies are important for certain technologies such as ASP.NET MVC. But give and take, you can't have everything in your life :)

Anonymous said...

Learn Java and forget anything else. You will be set for life. Continue to learn only Java.

Anonymous said...

Who is Joey Wong? Hopefully, you keep her happy.

Anonymous said...

And I think there is another important question. How do you find time to learn? I suppose most of us have to work from Monday to Friday, so the only free time we have is at the weekends. But that is just not enough, because we have to do a bunch of other things.
So how do you find time guys ?

Soon Hui said...

How do you find time to learn?

At night and over weekends. It helps if you have

a)an understanding girl friend or wife
b)no babies to take care of
c)a job that doesn't require you to take lots of time to commute.
d)no TVs, occasional movies are OK, but no series.
e)Sleep early, wake up early! So that you have all the energy to do coding.

That's how you find the time.

Kevin Kerr said...

In my opinion WPF also has the benefit of allowing incredibly well designed application architectures due to the powerful data binding capabilities. But I also agree, a designer developer helps.

SuperJason said...

Soon Hui, that's not having a work-life balance, and it's not realistic. You can't waste your entire life writing code.

I do a little bit of learning and playing on the side, but I also use work time to learn. It's the cost of doing business. If the company I'm working for doesn't like it, I can go somewhere else.

Wim Haanstra said...

I dont agree with the people that you can always make time for learning the newest and coolest technologies.

Ofcourse, if you want to keep yourself in the market you will have to find SOME time somewhere, but dedicating your complete life to it is just insane.

Anonymous said...

knowing and using "software design philosophies ( such as continuous integration, agile programming etc)" is a discipline, not a skill.

It's like saying "i am never late to work" on a resume.

Paul Simpson said...

Without attention to disciplines, architect's buildings would collapse, like so much of our code does! I understand the author's perceived need for technologies as his priorities. However, this is not good long-run thinking. Please see this article for a differing, and excellent, point of view: Being Smart Does Not a Good Developer Make

Google Ninja said...

If you enjoy what you do, playing with new stuff is fun and interesting. I listen to podcasts on my way to and from work, and come up with projects for myself in my spare time. If it is a particularily stressful day/week/month, extra-curricular learning may take a back seat to sitting in front of the tube, but as I genuinely enjoy learning new technology, those phases rarely last long.

As for the most important stuff to learn, I would say as a business developer, C# 3.0 features (extension methods, lambdas, etc), LINQ, WCF, Alt.net (MS OR/M, Testing framework, IoC containers, and Build scripts are significantly worse then what the open source world offers), Modern methodologies (SCRUM, Agile, DDD, TDD, etc)

John said...

I would qualify about learning technology over methodology. The only time this advice makes sense is 1) you work as a consultant or 2) you are a junior developer and you plan to stay there.
As a lead developer and hiring manager, I much prefer someone who can prove they understand the fundamentals of writing good software over the latest technology. I advise people to know about new technologies and where they may be applicable (10% of your time). Learn the ins and outs of certain technologies when you have to use it to solve a business problem (30% of your time). Spend the rest your time (60% of your time) learning the fundamentals of software such as OOP, design patterns, TDD, etc. and eventually you will move into more lead\architect roles.

macmariman said...

I would definitely prefer methodology over technology. Learning the fundamentals will help you understand better and faster the technology, I would find useless a LinQ expert who doesn't have a clue on OOP unless I have a very specific need. Moreover many technologies that people are struggling to master now might no even exist five years from now.

vr said...

I've done Java for 10 years, a year ago switched to C#,it took me maybe a month to learn most of the tricks. If you know one OOP learning another language is not that hard. Learning to use TDD for example takes a lot more time and will power. You need to change the way you code from the first minute. It's a different way of thinking.

Soon Hui said...

I much prefer someone who can prove they understand the fundamentals of writing good software over the latest technology. I advise people to know about new technologies and where they may be applicable (10% of your time).

I agree with you, John. However in this real world if you don't know the right technology, you won't be able to pass through the HR. While it is good to have a solid understanding of software development, without proper technology buzzword you can't even pass the first stage.

Sad? But this is the reality of life.

ZagNut said...

I also agree with John. A guy at my last job spent all his time trying to determine which design pattern(s) to use for each task he needed to complete. He was so fixated on this, he didn't care whether his code "worked with the whole" or not.

I think the most important things are programming ability, and an open-mindedness to learn from peers.

Peter Seale said...

The original post has to be trolling. Rebuttal:

1. You recommend LINQ to SQL over fundamentals. LINQ to SQL in its current form will be obsolete in 3 years. Fundamentals: never.

Mark your calendar. 3 years. I work with SharePoint, so I know what it's like to be burned by technology upheaval. My SharePoint 2007 skills will be a commodity in a year, worthless within 5.

2. You set for the ASSUMPTION that fundamentals are not useful on real-world projects. At this point we are having an argument over semantics: what defines "fundamental". I'll just say: fundamentals to me are "learning project management skills" or "learning proper OO design" or "improving my estimation skills" or "learning C#, just C#." I wish I was an expert on EVERY SINGLE ON OF THESE POINTS, TODAY.

Quick note to everyone else: before throwing yourself into heavy learning of the next Microsoft technology stack, take A SINGLE MINUTE and think to yourself: "HOW LONG until this technology expires?" If you do this one thing, you'll save yourself a big hassle.

3. Your goal seems to be to "get a job" rather than "provide value."

Ok, now for skill expiry dates. Let's do this:

* Entity Framework - will significantly change in next version. 2-3 years.

* LINQ to SQL - will significantly change in next version, or will be retired outright. 2-3 years.

* OO fundamentals - late 70's-present

* C# - v1: 1999?-on v2: 2005-on v3: 2008-on. C# has only added functionality, so skills are not replaced, but complemented. Good for the forseeable future.

* Project management skills: eternal

* Estimation skills: eternal