5 ms·

Framework fatigue: How many frameworks do I need to know?

47 points by zephyrfalcon 16y ago

tlrobinson 16y ago
"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 16y ago
  When did getting a job become more about programming and not being a good problem solver?
  - roel_v 16y ago
    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 16y ago
      "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."
  - tlrobinson 16y ago
    I would define a good programmer in part as someone who can quickly learn new languages and frameworks. Granted you could define a good problem solver as one who could easily learn how to program if necessary, but I think it takes a lot longer to be become a great programmer than it does to learn another language once you are one.
  - GrandMasterBirt 16y ago
    Sorry. For a development position you need two pieces of CRITICAL mental capabilities: 1) Problem solving: How you approach problems. 2) Coding skill: How you implement the solutions given in (1). If you don't have 2, you suck. 2 is not limited to a language. HOWEVER knowing the nitty gritty details of a language is actually very critical often. Imagine you never worked on ruby before, heard of Rails, read a book, made a hello world program, thats that. You are a good programmer. Now you apply for a job where you are expected to make an RoR application that will serve a minimum of 1 million hits per hour (they are solving the scaling problem). You got to make the code clusterable and efficient since in this case buying 100 servers is out of the question (lack of funds). Sorry you are going to need more than a ruby newbie for this one. Now I am in no way implying that a good developer can't write an amazing ruby program having never touched ruby before, quite the contrary. That developer just might not be able to start as a senior ruby developer. Probably give that person 1 year with ruby and you got yourself a guru. But you need some minimums. I guess what some people don't realize when hiring is that don't expect miracles from someone until approximately 1 yr after employment. That is when they understand the system, frameworks the system uses, the development strategy, problems, etc. This is when you start to see a good developer make amazing contributions. If you are hiring now because you need something shipped in 2 months, you have wrong reasons a person who knows the frameworks is going to have a better start, but its not a solution.
    - tlrobinson 16y ago
      "Sorry you are going to need more than a ruby newbie for this one." I would say you need someone with experience scaling web applications, not someone who's an expert in a particular language. I doubt Matz himself would have been much help to Twitter in scaling.
  - puredemo 16y ago
    A long, long time ago. I've always been an excellent problem solver, it definitely didn't get me any jobs until I was a programmer.
- joe_the_user 16y ago
  Just for the record, I believe the transition happen at the very latest in the 1970's for human resources and upper-management. The mentality has been around for a long, long time. The one compensation is that if you can get past the gate-keepers and talk to your future co-workers, they should care more about your problem solving abilities than your acronyms. But if they don't, they wouldn't be pleasant co-workers anyway. Personally, I would say that there's been a different transition that's happen more recently. That is a transition toward management being more interested in proving some point than accomplishing a job. When you have that situation, you really can get the problem that even your future co-workers care more about the acronyms or proving their smartness or whatever, than accomplishing the task. But it's hard to track such subtle sea-changes.
stcredzero 16y ago
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 16y ago
  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 16y ago
    I don't believe Factor ever ran on Squeak. It generates its own native code.
    - dpritchett 16y ago
      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.
- GrandMasterBirt 16y ago
  Good point. Procedural programming, OOP, and Functional are different. Would be a bigger mountain to climb. If you are smart though you pair up a newbie with an expert and watch the newbie change for the better (or quit).
f1gm3nt 16y ago
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.
- dpritchett 16y ago
  It's easier for the hiring managers to pass on you and wait for someone with 2 years' IT experience, all in Drupal. I'm not sure how you can pre-qualify yourself in a situation like this other than maybe showing them your portfolio.
  - f1gm3nt 16y ago
    Yeah that's absolutely true. Point well taken =)
- synnik 16y ago
  There is a flip side to this coin -- for all you know, they interviewed 10 people with 10+ years of PHP experience, and the 2-3 years of Drupal were then reasonably a deciding factor.
  - f1gm3nt 16y ago
    Another really good point. I never thought if it this way. I had assumed that pointing out I had worked on large projects for a few large companies was enough.
- variety 16y ago
  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.
mishkovski 16y ago
Two: .NET for server-side and jQuery for client-side.
ojbyrne 16y ago
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.
deleted 16y ago
[deleted]
raganwald 16y ago
Everything old is new again. Joel Spolsky's Lord Palmerston on Programming, from 2002: http://www.joelonsoftware.com/articles/LordPalmerston.html http://www.joelonsoftware.com/articles/LordPalmerston.html
- moondowner 16y ago
  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.
moondowner 16y ago
"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.
GrandMasterBirt 16y ago
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.
verysimple 16y ago
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.
geebee 16y ago
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.

47 points by zephyrfalcon 16y ago

"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 16y ago
When did getting a job become more about programming and not being a good problem solver?
- roel_v 16y ago
  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 16y ago
    "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."
- tlrobinson 16y ago
  I would define a good programmer in part as someone who can quickly learn new languages and frameworks. Granted you could define a good problem solver as one who could easily learn how to program if necessary, but I think it takes a lot longer to be become a great programmer than it does to learn another language once you are one.
- GrandMasterBirt 16y ago
  Sorry. For a development position you need two pieces of CRITICAL mental capabilities: 1) Problem solving: How you approach problems. 2) Coding skill: How you implement the solutions given in (1). If you don't have 2, you suck. 2 is not limited to a language. HOWEVER knowing the nitty gritty details of a language is actually very critical often. Imagine you never worked on ruby before, heard of Rails, read a book, made a hello world program, thats that. You are a good programmer. Now you apply for a job where you are expected to make an RoR application that will serve a minimum of 1 million hits per hour (they are solving the scaling problem). You got to make the code clusterable and efficient since in this case buying 100 servers is out of the question (lack of funds). Sorry you are going to need more than a ruby newbie for this one. Now I am in no way implying that a good developer can't write an amazing ruby program having never touched ruby before, quite the contrary. That developer just might not be able to start as a senior ruby developer. Probably give that person 1 year with ruby and you got yourself a guru. But you need some minimums. I guess what some people don't realize when hiring is that don't expect miracles from someone until approximately 1 yr after employment. That is when they understand the system, frameworks the system uses, the development strategy, problems, etc. This is when you start to see a good developer make amazing contributions. If you are hiring now because you need something shipped in 2 months, you have wrong reasons a person who knows the frameworks is going to have a better start, but its not a solution.
  - tlrobinson 16y ago
    "Sorry you are going to need more than a ruby newbie for this one." I would say you need someone with experience scaling web applications, not someone who's an expert in a particular language. I doubt Matz himself would have been much help to Twitter in scaling.
- puredemo 16y ago
  A long, long time ago. I've always been an excellent problem solver, it definitely didn't get me any jobs until I was a programmer.
joe_the_user 16y ago
Just for the record, I believe the transition happen at the very latest in the 1970's for human resources and upper-management. The mentality has been around for a long, long time. The one compensation is that if you can get past the gate-keepers and talk to your future co-workers, they should care more about your problem solving abilities than your acronyms. But if they don't, they wouldn't be pleasant co-workers anyway. Personally, I would say that there's been a different transition that's happen more recently. That is a transition toward management being more interested in proving some point than accomplishing a job. When you have that situation, you really can get the problem that even your future co-workers care more about the acronyms or proving their smartness or whatever, than accomplishing the task. But it's hard to track such subtle sea-changes.

stcredzero 16y ago

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 16y ago
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 16y ago
  I don't believe Factor ever ran on Squeak. It generates its own native code.
  - dpritchett 16y ago
    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.
GrandMasterBirt 16y ago
Good point. Procedural programming, OOP, and Functional are different. Would be a bigger mountain to climb. If you are smart though you pair up a newbie with an expert and watch the newbie change for the better (or quit).

f1gm3nt 16y ago

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.

dpritchett 16y ago
It's easier for the hiring managers to pass on you and wait for someone with 2 years' IT experience, all in Drupal. I'm not sure how you can pre-qualify yourself in a situation like this other than maybe showing them your portfolio.
- f1gm3nt 16y ago
  Yeah that's absolutely true. Point well taken =)
synnik 16y ago
There is a flip side to this coin -- for all you know, they interviewed 10 people with 10+ years of PHP experience, and the 2-3 years of Drupal were then reasonably a deciding factor.
- f1gm3nt 16y ago
  Another really good point. I never thought if it this way. I had assumed that pointing out I had worked on large projects for a few large companies was enough.
variety 16y ago
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.

mishkovski 16y ago

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

ojbyrne 16y ago

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.

deleted 16y ago

[deleted]

raganwald 16y ago

Everything old is new again. Joel Spolsky's Lord Palmerston on Programming, from 2002: http://www.joelonsoftware.com/articles/LordPalmerston.html http://www.joelonsoftware.com/articles/LordPalmerston.html

moondowner 16y ago
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.

moondowner 16y ago

"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.

GrandMasterBirt 16y ago

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.

verysimple 16y ago

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.

geebee 16y ago

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.