Depends on the context. As part of a team (code already exists that I can reference), and simply "useful"? Less than that, probably about one week at most.
I wouldn't be doing anything large or complex in that short a period, but absolutely can become useful with smaller stuff in that period.
And I say this with experience, thought in a different context: Years ago my manager introduced me to a new codebase by giving me a bug to fix. It was in a Django site, and I'd never done any python before. Took about half a day to figure out what was going on (for comparison, nowadays it would maybe have been 20-30 minutes), and a bit more to fix.
But I did figure it out on my own, taking some work off of another developer who was focusing on more complex work. I would call that "useful".
That’s just the point, as a “senior developer”, I’m looking for someone who can select “New Solution” and start a project from scratch or at least start a new major feature. Anyone can pull up an IDE in almost any language, step through existing code, pull up a watch window and fix a bug. That’s something developers can do with three years of experience. Bug fixing is something you put your more junior developers on.
I have no idea why all of the old folks (again I am in my mid 40s) consider it some great skill that excuses them from actually keeping up with what’s going on in the industry.
* My bugfixing example was indeed trivial, just the first thing to pop into my mind. It was mainly aimed at the use of the word "useful", which is woefully ambiguous.
* Sounds like we agree when talking about someone who already knows the technology stack.
* No matter how skilled the developer, there will be ramp-up time when they not only don't know the framework, but also don't even know the language.
* That ramp-up time being significantly shorter for a senior dev is what we're talking about, and how selecting for the specific stack like you're describing isn't necessarily going to be worthwhile - learning the domain is likely to take longer than learning the technology.
Oh, and:
> Anyone can pull up an IDE in almost any language, step through existing code, pull up a watch window and fix a bug. That’s something developers can do with three years of experience.
Thanks for the compliment I guess; I was describing something from around 3-4 months into my first job.
No matter how skilled the developer, there will be ramp-up time when they not only don't know the framework, but also don't even know the language.
And if a company is using a popular language/framework they can find senior developers who know the language and the stack. Why should they hire someone who hasn’t taken the time to learn both?
That ramp-up time being significantly shorter for a senior dev is what we're talking about, and how selecting for the specific stack like you're describing isn't necessarily going to be worthwhile - learning the domain is likely to take longer than learning the technology.
Not really. If someone has ever been exposed to a similar framework - take your typical MV* framework for example - even a developer whose only been active for three years can easily transition.
I have no idea why old folks (putting myself in that category) think they can get by without keeping up. Do you really think that someone who has 15 years of experience but haven’t kept up with the industry won’t be at a disadvantage over someone with 5 that has? On the other end, you have people like me that knows what it’s like being behind the curve and vowed never to put myself in that situation again.
You can’t imagine how long it took me to unteach a 50 year old who had been doing ASP.Net web forms for years how to even develop in ASP.Net MVC using server side rendering let alone client side frameworks.
He was only eighg years older than I was but didn’t keep current
