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?
Is specializing beneficial in IT industry?
self improvement;skills
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.