+972 52-548-6969
Core skills vs. Current skills
Given a choice between a developer who can explain what MVC is vs. a developer that knows .Net 3.0, I would always choice the first developer. I just had finished talking about this with Jeremy Miller and Udi Dahan about the most important things that you need to have in your developers. The converstion started from talking about making design "compromises" for non-advance developers. And moved to the reasoning behind this approach.
Basically, there are a lot of developers that chase that technological rainbow, investing all their time in technology, and not on understanding. This is a great treatise about the subject:
Frankly, it is a much better investment to understand the design of software than the mechanics of it. It makes it much easier to pick up the mechanics at a later date.
Companies that don't understand that is doing themselves a dis-service, because they are basically hiring a programmer whose only interest is to use current technologies, not the business problem or the best way to solve that. Technical solution isn't the only way, or even the recommended one.
Comments
Just to let you know that I completely agree with your point here.
When you focus on the core skills and architectures/patterns behind the solutions you can use that in more programming languages.
Instead of needing to rely on other peoples goodwill and "way of doing things".
Like Ivan, I agree. A good developer (one I would have in my shop) should have some key qualities:
good problem solving skills. I like a person that thinks through problems and tests ideas (both positive and negative) and isn't afraid to say he/she is wrong
has the aptitude to pick up technology. New stuff comes at us all the time but some will get it, others won't. It's the ones that can adapt that I'm interested in.
abstracts themselves away from technology to understand what's going on. Coders are great, but for long term sustainability I want a person that isn't solving the problem always with the same hammer every time.
What I'm not interested in:
People with lots of letters after their name and stacks of books they've read. Okay, I'm one of those guys, but the ones I meet are ones that can't program their way out of a paper bag so if you have the proof to back up your academia, we're good to go.
CVs with pages and pages of "know this technology x years". Don't care, other than a passing interest if you can pick something up new (see above)
Buzzword bingo people that know all the right things to say, but have no clue what they mean. Far too many interview with people talking Agile but when the rubber hits the road, they can spell it and rattle off a couple of names but have no clue what it really means.
Completely agreed.
Btw, Castle Stronghold is looking for .net 2.0 developers. Must know SQL 2005, VS 2005 with Resharper 2.5, log4net 1.29, NHibernate 1.0 (newer versions wont be accepted). A solid understanding of Castle 1.0 is a plus.
:-pp
Hammett,
You got it wrong, you need at least five years experience with Castle 1.2.4 or 1.2.7 no other versions are acceptable, NHibernate experience is a plus.
Trying to understand concepts without having the right tools can be a problem. Language and tools help us understand those concepts better.
http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis
For example, if I was a BASIC programmer (as in DOS BASICA haha), I wouldn't have access to OOP, anonymous methods, polymorphism, partial classes, etc. I would be back at line numbers to GOTO! eww...
It is still Turing complete, but things like MVC would be a big, big hassle to implement.
The latest tools can even restrict us from making stupid design decisions. For example, Spec# pretty much exemplifies the benefits of DBC. Erlang is geared towards concurrent programming.
BTW, I'm not sure if MVC is such a great example either. I've read it being defined in this way - entities (model), form in designer view (view) and code-behind (controller). That seems obvious to me, but is that definition wrong?
I would've preferred it if you used IoC. :-). Your slides did a very good job of explaining it.
Chris
I would argue that a developer that truly knows .NET 3.0 can explain why you need MVC. :P
You're right, good programmers should relay on solid background that is not related to a particular environment or technology. Knowledge of pattern can be used in almost all programming environment, while knowledge of .net 3.0 is lost if you move to a team that develop in .net 1.1.
You have to separate the Specialists from the Generalists.
You will always need specialists that can solve particualar technology problems. They might be the ones that design the solution and they might only be in a project for a little while, but they often are as important as the genealists.
You have to separate the Specialists from the Generalists.
You will always need specialists that can solve particualar technology problems. They might be the ones that design the solution and they might only be in a project for a little while, but they often are as important as the genealists.
might NOT be the ones that design ^^
Michael,
My company usually hire people for the long run, so this may affect my judgment, but I would tend to take the more well rounded dev first, simply because I find them so much more rare. It is not very hard to learn a new technology as long as you have some idea about the basic concepts.
Chris,
I used MVC just as an example of a fairly common patterns, but the idea is a developer who focus on building software, not learning the tools.
I want to be able to talk about responsibilities and maintainability with my team members, knowing XYZ 3.5.1.2 newest feature isn't interesting.
Oh, and I agree that the tools that you are using can make a huge difference.
Steve,
No, actually.
I have met with some people who could literally go and build a workflow, connect it to a WCF service on the other hand, and end up with a completely unmaintainable solution.
They understand the technology, not the design.
Patrik,
I agree, but I wouldn't hire someone for technical knowledge alone. Chances are, if they are focusing on technical details alone, without giving the broader view a bit of thought, they aren't really valuable.
Speaking from that dev perspective, choosing that route means that you keep having to chase the technology curve, not fun at the least.
Speaking from my point of view, I would like to have someone who understand software, grokking technology isn't hard, when you have already grokked the way software is done.
Actually I'm starting to understand what Ayende means.
Using cool features like LINQ, EntLib (i.e. policy injection, ), .NET 3, Silverlight etc. without strong architectural & process knowledge is like giving an excitable kid a tractors, cranes, concrete mixers & more and telling him to build the Sydney Opera House... which he'll screw up - big time!
Chris
This is a great post, and you make a great point. Too many times companies think that only people with the exact skill set they need are the only people for the job. However, a solid developer with 'Core skills' will work out better in the long run.
I think it comes down to how long it takes to learn one or the other. Developing a working understanding of MVC could take one or more failed projects and some serious time. Learning how to use .Net 3.0 can be learned from reading feature lists and messing around with some adhoc apps. I'd rather hire someone who it would take less time and mistakes to train!
Comment preview