Framework fatigue: How many frameworks do I need to know?
jeviathon.com
jeviathon.com
When did getting a job become more about knowing a specific language and not being a good programmer?
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.
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.
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.
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.
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.
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!
Hiring managers and head hunters need to take note of this article.
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.
They didn't want a programmer, they wanted someone with known Drupal experience, who could hit the ground running, and wouldn't fall back on writing new software to solve a problem that could be quickly (if not perfectly) solved in Drupal. PHP based content management systems job are only tangentially related to programming. Drupal (and Joomla, etc.) exist so that companies can manage their websites without a programmer.
That may not be fair, but it's how the hiring companies (direct or recruit) will look at. If you want those jobs get a Drupal site or two under your belt, and downplay your 10+ years of PHP on your resume and during the interview conversation.
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.
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.
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.
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.
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.