Is specializing beneficial in IT industry?

Question

For the past few years I started wondering if it makes sense to learn advanced techniques in some fields of IT, or is it better to be just good at everything, and use the simplest code possible everywhere.

I will use C++ as a language for comparisons, since I'm a C++ developer.

As a C++ developer you can write truly interesting code, ranging from code that looks like C with simple functions all around, to template meta-programming stuff, sometimes intermixed with pure abstract classes.

I've started noticing that I'm leaning towards the later lately.

The problem is, that with larger solutions programmers are rarely working alone, and most likely skills don't overlap that much either. So some parts of code I write might be confusing to other team members, and the other way around.

I might like STL and templates, while other people might prefer pure abstract classes everywhere, others will rely on dynamic_casting, or code generated by VC wizards. While some just enjoy everything written in a very simple, C like manner.

This also backfires with the fact that people who haven't worked with, say, with virtual classes, might not even know why the new class they've derived is broken because of simple missing virtual destructor. So the code you write paves a way toward memory leak if some other people decide to reuse your code later on.

Do you have experience working in environments with multiple developers with different skill-sets? Do you try to find a common dominator in your environments? Does using the skill-sets of every person even works in larger projects?

Answer 1

In 1985 I was highly specialized for one PC. My progs were studied by users and the factory that made these PC provided my progs to all users. The PC extincted three years later. The language was very specific, OS too. All this soft became useless. My knowledges too.

Now I would never put all egs into one basket.

Answer 2

There's a short term answer, and a long term answer, and neither is absolute.

In the short term there tends to be a better return on investment in specialized skills. If two people are applying for a job doing C++ (or Python or Oracle...) and one is more clearly more competent at the job at hand, they will generally get picked for it. Some companies look for broader skills, but that's usually in strategic hiring (after school, management training programs, etc.) rather than specific tasks. If I really need someone to help me get my databases straight over 6 months, I want an SQL rock star, not someone who has a little bit of everything, and also played high school baseball and speaks Latin.

In the long term things flip. A good CIO/CTO/CEO/Entrepreneur/Leader needs to be able to converse on many levels and many topics. Specializing may have gotten them there, but being a generalist tends to be more important. It isn't until later that learning things above and beyond the job (spending 3 months is support, learning test automation, a lateral assignment in South America) start to pay off.

Of course there's a more tactical bit of advice, which is learn what interests you. :-)

Answer 3

I would say a good team should have a common denominator of knowledge and skills shared by all developers. All competent C++ programmers should have at least a basic understanding of e.g. templates, and know whom to turn to if they see something above their limit. They also should share some more or less common idea of how "good code" is supposed to look. And they should have a more or less realistic picture of their own current skill level, compared both to others in the team and to the "ideal", e.g. the top guns on SO.

Of course, not everyone may be senior even in a good team - it is perfectly OK to have juniors. However, everyone (including themselves) should be clear about the fact that they are juniors (even if only regarding their C++ skills), and they need mentoring plus supervision of the more experienced team members to learn the best practices and apply them correctly.

Now, of course, such teams are rare in real life. However, we should strive towards this ideal. If it turns out that some code you wrote was confusing or unintelligible for another developer and this caused a bug / memory leak / ..., you can bring this up on the team retrospective, and brainstorm ways to avoid such problems in the future. You may decide to establish common coding conventions, to train members lacking specific knowledge / skills, to have workshop(s) discussing the pros and cons of specific coding idioms / patterns / techniques, etc.

The all-important issue here is communication. It is no accident that agile methods focus so much on this. E.g. XP includes pair programming, which makes it naturally easy to spread knowledge and information around within the team, and for new team members to learn the local culture, coding idioms and best practices. Pair programming is not always possible, but communication and discussion within the team should be encouraged and suppported by any means.

Another issue lying behind your examples is code ownership. That different team members use completely different, or even opposing, idioms can easily happen in a project where everyone has his/her own fiefdom, exclusively "owning" some part of the code. However, it happens significantly less often in projects where everyone may touch any piece of code, and where people are - to a greater or lesser extent - regularly rotated between different modules and code parts. This helps share knowledge, increase the "bus factor" and also helps the team forge working, common practices and coding idioms.

Answer 4

is it better to be just good at everything

No. You can't be good at everything. Be good at what gets you hired for the longest time if you are doing programming for living, that is do what the market wants (some will say do what you want but its up-to you!).

The problem is, that with larger solutions programmers are rarely working alone, and most likely skills don't overlap that much either. So some parts of code I write might be confusing to other team members, and the other way around.

This is not how it usually goes. In a project with 10 people, you are likely to find 1 DBA, 2 people for testing, 1 graphics designer and the rest are all developers. Other developers with your area of expertise need to understand your code. But the DBA does not. Hence you talk to pears. It is not common to be the sole C++ developer in a project unless the project core language is Java and you are brought in for integration or because you know a legacy application that uses C++ or the likes. In any case you should learn to write readable code by others and you shoul learn to read other people's code. In good projects, there are coding standards, most developers follow them and that makes code more or less have the same flavor. If you don't get something, just ask, you are supposed to be a part of a team and everyone should help everyone else - This is team work, part of that is to share knowledge with your team. If you have a better way to do things you demo that to the rest. If they like it, fine, if not, go with the flow - It is that simple!

Answer 5

Personally, I think it is hard to avoid at least some specialization. I would just try to focus more on a some-what broad field instead of a really specific one. Let me use 'Bill' and 'Bob' as examples here to describe why I think this is important. So this one large company has a large mainframe of brand X, and the languages it is programmed in are called Xasm and Xc. Bill and Bob are put on a team that is dedicated to improving the security of this mainframe. Bill focuses on security programming in general, and learns the theory behind active venerability management and such, while Bob devotes himself to programming on the machine, and how to migitage threats on this machine's special OS. Suddenly, the company that makes X brand mainframes sells itself to Y and X's designs are phased out. Now because Bill has a great amount of expertise on the field of threat mitigation, along with the knowledge of how to use the old mainframe, he is still of great value to the company, as only minor retraining is required. Bob, on the other hand, only knows about how to mitigate threats that exist on X brand mainframes, many of which may have no counterpart on Y.

I rest my case