Normal
0
false
false
false
EN-GB
X-NONE
X-NONE
MicrosoftInternetExplorer4
There was a comment on the On
Learning Boo post along the lines of : I only focus on learning
frameworks, because they increase my marketability, learning new languages,
ideas like DSLs just takes time away from that effort. It is a fairly
common attitude. I have spoken to people who have told me that their focus is
on learning the Microsoft .NET toolset, commenting that they feel that
is enough of a challenge and one that translates best into career
opportunities. I have seen recruiters and companies assessed with statements
like 2 years of ASP.NET MVC as some means to indicate the competence of
a developer to join a team.
At the same time for many developers the number of new frameworks tumbling
out of Redmond makes it seems like a struggle to keep up. Those who feel that they
must keep up, naturally feel overwhelmed. Restricting their focus to just what
comes out of Redmond seems like a good strategy to manage the problem.
Unfortunately, focusing on learning vendor frameworks is a trap. There will
always be another new framework to learn to do what you were doing yesterday.
Look at the churn in data access frameworks in the Microsoft space. Knowledge
gained is quickly outdated. You end up on a treadmill, learning one vendor
framework after another. You fall into the trap of appraising your next job
solely on the criteria of what frameworks your prospective employer is using, just
so that you can gain some experience using that new framework and keep your
C.V. up to date.
Assessing developers by their knowledge of them, especially through
certifications is an equally bad trap for employers to fall into. At best it is
deceptive about what skills developers actually need. At worst it is a prison
because the investment of knowledge in a particular technology becomes a
ball-and-chain that makes individuals and corporations resistant to change.
Having hired all those skilled Webforms developers and learnt all those vendor
control kits, how could you rationally adopt ASP.NET MVC for your next project?
After all you don't have any experience with it. Should you now dismiss your
entire team and hire experienced ASP.NET developers? Or if you do change, what
good did it do you to recruit people based on their understanding of the
ASP.NET page lifecycle. Would it not have been better to hire people who had
the skills to learn new frameworks?
When I was younger, I used to focus on learning the latest toolkit because I
saw that as the best way to improve my marketability. I spent ages poring
over the internals of MFC, ATL etc. I could talk about the details of the STL,
Boost, Loki with the best of them. I wanted to be an expert on those libraries.
I looked for new jobs when old ones did not offer me the opportunity to use the
latest and greatest frameworks. Did it make me better developer? Maybe, but not
in the way I expected. What I gained from poring over those frameworks
eventually was an appreciation of the common underlying patterns. I might have
learned something from understanding how the internals were implemented too,
but it was pattern recognition of ideas like iterators, factories, template
methods that gave me the most benefit. The next time I tried to learn a
library, seeing how it solved problems I understood, seeing how it use patterns
and principles I recognized, meant that I was able to being working with the
framework faster. But I did this hard way, not by recognizing patterns I was
aware of and seeing where they were implemented, but by discovering them seeing
them repeated.
The reason so many of us get excited by books like Fowler's Patterns of Enterprise
Application Architecture, his work on GUI Architectures of
DSLs
(and the work of others) is that they capture those patterns and principles.
A solid knowledge of the principles relating models, views, and controllers
would enable you to learn a range of web frameworks ore quickly because you
look to see how they solve problems.
Learning new skills such as how to write a DSL in Boo will give you the breadth of aproaches that enable you to deliver better architected applications. The burden of maintenance is greater than the burden of writing, so a better architected application is always a good investment for a company. Far more than squeezing some obscure feature out of your latest framework is.
If anything the industry has moved on from those nuts and bots frameworks,
and the abstractions have gotten better. Less and less do you need to
understand the how and more and more the why? Knowledge of the patterns and
principles provide continuing value to you as frameworks change. It also helps
you understand how to use the frameworks, how to judge their quality against
some kind of best practice yardstick and how to manipulate them when they fall
short of best practice
As someone who interviews people I look more for understanding of the
principles than the minutiae. The problem is that there will always be a new
'better' framework, a new popular paradigm. There is always the possibility
that a new language comes along that we want to use instead for a given
project. People who understand the principles can adapt. People who focus on
the detail are intransigent to change, because they have too much invested in
the framework that they have become an expert in.
Now before someone suggests otherwise I am not implying that people do not
need to know how to use their tools to get the best out of them. Of course they
do. But you will find a more efficient path to assessing and learning new
frameworks through understanding the principles behind them than through
learning each one in isolation.
Posted
Thu, Jun 11 2009 3:12 AM
by
Ian Cooper