As a developer, can you handle power?
Are you able to cope with choice?
If tasked with a project, right now, can you list 3 or more ways to implement the project that would all be the same to the eyes of the user?
Can use use tools to quickly generate a solution?
Can you do the same without those tools?
A developer today has more choice, more power, more tools, more frameworks, and more patterns than ever before. It's hard not to put on blinders and focus only on a small part, to seek to understand just a corner of the programmer's world - be an expert in your area. It generally pays better too, for a little while.
Then technology advances, reverts, reinvents, and casts the expert aside as obsolete.
Specialization is for insects.
Posted By Mike On Monday, April 07, 2008
Filed under developer |
Comments (1)
DylanW
-
Monday, April 07, 2008
9:50:01 PM
Personally, I think specialization is important, but I may be arguing semantics. I don't consider that I "know" a technology until I know it back and forth and have used it practically a couple of times. That, and I'm assuming we're talking about specialization within software development as a whole rather than on programming specifically.
Specialization is an economy of scale problem, and so it is necessary in some cases more than others. It keeps developers from getting burnt out on large projects or in more chaotic environments. If I have to jump from planning to UI design to database design to coding in the same day, I'm not going to give each one the attention it deserves. (That may be fine for a small project, but it's not going to fly for a larger one. Also, I'm a bit of a perfectionist.) I'm also probably going to be so fried by 3pm that I can't think straight. (Realistically, it's worse for me--on an extermely bad day I might have to jump from ASP.NET to SharePoint to setting up an FTP login to calling technical support for our accounting software.)
And you might want to be careful of statements like "specialization is for insects." Because it's as much of an exaggeration to say "generalization is for people who can't play nice with others."
The tradeoff isn't to become a jack of all trades but master of none. The tradeoff is to at least have a general knowledge of the technologies and skills tangential to what you deal with on a day-to-day basis, so you know what to look for--either by brushing up on something yourself, or by finding someone who can fill in the gaps.
Incidentally, I'm probably on the bad extreme of the "3 or more ways to implement the project" example. I can usually give 3 or more options as to how to do something, based on what I know and what I guess the future requirements to be. But I talk in terms of balancing pros and cons rather than making recommendations.
And the tools thing--I can use them to generate a solution, but they make me feel... uncomfortable... if they generate messy code or hide their inner workings. But then I don't just notice code smells, I have full-on code OCD.
