

Framework fatigue: How many frameworks do I need to know? - zephyrfalcon
http://www.jeviathon.com/2010/12/framework-fatigue-how-many-frameworks.html

======
tlrobinson
_"When did getting a job become more about knowing a specific framework at not
being an expert on the Java language"_

When did getting a job become more about knowing a specific language and not
being a good programmer?

~~~
dstein
When did getting a job become more about programming and not being a good
problem solver?

~~~
roel_v
When you already know that the problems you're trying to solve require
programming, you might as well narrow your search for efficiency.

If you don't know that your problem requires programming, and you put out an
ad for a 'problem solver', the chance that you'll actually hire someone who
knows programming, and recognizes that the best way to solve the particular
program is programming, are slim to none.

~~~
derefr
"Expert in efficiency analysis, human factors, and process modeling and
automation." Your problem might best be solved with programming, building a
(human or robotic) assembly line, or making a bunch of individuals _want_ to
solve little bits of it semi-manually (reCAPTCHA, freerice, Mechanical Turk);
really, what everyone wants is someone who knows which kind of solution a
given problem calls for, and can then get it done, regardless of solution
space. NASA calls these "systems engineers."

------
stcredzero
_It doesn't matter what language a developer knows, they are all similar._

All procedural langs are pretty much the same. Functional langs are
significantly different. Skill with applying OO concepts translates across
languages pretty well, so long as you are cognizant of little differences
which cause impedance mismatch. (Static method inheritance in Java vs. class
methods in Smalltalk/Ruby.)

 _How many frameworks do I need to know?_

One fewer than will fatigue you!

~~~
dpritchett
I _still_ don't get Factor and I have looked at it several times now. The last
time all I learned was that it runs on a Squeak VM. One day....

~~~
tedunangst
I don't believe Factor ever ran on Squeak. It generates its own native code.

~~~
dpritchett
I could've sworn I saw the mouse logo at the top left corner of my window when
I fired it up. I guess that's one less thing I know about Factor after all.

------
f1gm3nt
This reminds me of a recent conversation I recently had with a company in my
area. They wanted to hire a PHP developer, I sent them my resume which
included 10+ years of PHP experience as well as working with many different
frameworks. However I was not not offered the job since I had not worked with
Drupal for at least 2 to 3 years.

Hiring managers and head hunters need to take note of this article.

~~~
variety
To be fair, sometimes proficiency in some framework or CMS or vertical skill
area _does_ matter a lot more than you think it does. Remember now, the
problem isn't that they get candidates who don't know $whatever_niche_topic,
it's that they "don't know what they don't know", i.e. they have no inkling
that the general "depth of terrain" in that area is much greater than what
they were able to size up from their casual acquaintance with it... or that
they _think_ they can hit the ground running on a project that a serious heavy
hitter with 5-10 years experience in that "niche" area been working on, when
of course they can't.

That said, if your interviewers are doing their jobs properly, they should be
able to filter for (or simply ask about) that level of skill awareness during
the phone screen.

More likely, when you get told _post-interview_ that "we need someone with
more experience in X" it's usually a polite way of saying that they just
weren't, you know, _all the into you_ , and are trying to save face on both
sides by pointing to something dry and objective, rather than things that
actually matter. Like you know, the fact that you were underdressed (or
overdressed), all those awkward silences you had with that second or third guy
you interviewed with (remember, the one who announced his presence in the room
by slouching in a chair and saying "I'm hungover"), or that you seemed to
exhibit a slight latency in your recognizing some technical term that's common
coin in the circles they run in (and so therefore, you just don't have enough
chest hair), etc.

~~~
variety
_all the into you_ => _all that into you_ , of course

------
moondowner
"A talented developer has an interpreter and compiler in his head and thinks
in pseudo-code anyway."

So true, if you think this way, you will adjust to almost all OO languages
very quickly. Also it's always good as a developer not to favor only one
language and/or one framework. Don't get me wrong, I don't say you should be
Jack of all trades master of none, it's good to learn and 'master' a chosen
language or framework, but during the learning you should not be 'blind'
towards the other options and not have any interest in them.

------
verysimple
My partner and I are both programmers and I was recently tasked to hire our
first employee.

We have a certain ideal environment in mind that we would like to create for
other programmers. In short, the plan is to hire the right people, trust them
with their responsibilities and respect their freedom, time and space. We rely
on our own past experience and other niceties straight from Peopleware. Some
of the key criteria we want to go for are curiosity and interest in
programming (what have you done in the past, what do you like about it, what's
your next move, etc), problem solving ability (puzzle, maths, etc), autonomy
(do you teach yourself, can you improvise, etc). Language choice and
experience give some weight, but are not our primary interest.

We believe it might provide the right ingredients for a well balanced culture
within our team.

But that's only one side of the coin. Somethings can't be ignored and during
my exercise in finding the ideal hiring process for programmers, I was made
aware of some legitimate concerns by HR people from various types of
companies: \- training someone involves losing money with the promise of
seeing a diamond in a rough blossom into a jewel. Can you afford it? \-
programmers, especially Y generation, can be very unstable. You hire someone
today and there's no guarantee that he'll be with you 6 months from now. But
in your mind, you're grooming him for at least the next 3 or 4 years. \- there
are deadlines. sometimes you need somone right here and now that can land with
wheels running. That means having to pass over some really nice resumes. \-
you have a small team and lots of work. Each needs to pull their own weight,
there's no time holding newbies' hands.

In my opinion, the ideal candidate for your company depends of your short and
long term goals with him/her. If you're a startup, with only one product with
dependencies on a framework and other tools that aren't likely to change much
in the next couple of years, it makes much sense to hire someone already up to
speed with said tools, even more so if you don't have the budget to train
someone. If on the other hand you provide various services likely to span
multiple horizons, betting on people that have the general ability to grasp
this stuff is more appropriate. If you're google you can get the best from
both worlds.

------
raganwald
Everything old is new again. Joel Spolsky's Lord Palmerston on Programming,
from 2002:

<http://www.joelonsoftware.com/articles/LordPalmerston.html>

~~~
moondowner
I knew I've heard of Joel Spolsky, and when I opened the post I knew why, he
wrote one of the best introductions to Mercurial.

------
ojbyrne
Basing technology decisions (or an argument in a blog post about making
technology decisions) based on something Kevin Rose said is just a bad idea.

The bit about "but after placing the individuals, he decided to branch out to
other technologies and the developers he hired, weren't able to make the
transition" is just laughable.

------
geebee
I completely agree with Chris's assertion that it's better to hire for talent
than knowledge of highly specific frameworks. Things are going to change
anyway, so ability to learn quickly is far more important.

However, I only wish his last statement were true, that "applying that to a
language or framework is just a matter of figuring out the syntax...and that
is the easy part".

I guess it depends on how you define easy, but if this were true, I wouldn't
have framework fatigue. I suppose it's easier to learn spring MVC if you
already know Struts2, but for me (I should only speak for myself here), it
actually isn't easy. Ditto for ant to maven, or SVN to git. You're in far
better shape if you already know something related, but you're far from in the
clear.

Reality is, it takes (me) a long time to get truly competent in a framework.
It can take months to get competent, and it can take well over a year to
really master it, and that's when you _have_ a related background.

------
GrandMasterBirt
Funny. The only framework I've been heavily drilled on is Java Concurrency, oh
and they make sure you know JUnit well enough to write a test case (erm a few
method calls and a bunch of autocompletion from the editor?)

Everything else is: Do you know spring? What is IOC? Ok good enough. Do you
know Hybernate? What is ORM?

Guess you've been looking for the wrong job or you've been giving the job
search to the wrong person. If at an interview someone just whips out "Lets
get into the nitty gritty details of your struts2 knowledge" I would just
leave, unless I don't have food at home and no money to pay for more.

------
mishkovski
Two: .NET for server-side and jQuery for client-side.

