Learning & Software Development. Multi-skilled Developer
You are having your first project. In the beginning, you know almost nothing about programming languages, business domain, development process, efficient practices and other good things. In the beginning, you know almost nothing about political games, external factors, progress reporting, human stupidity, fear of mistake, boredom and other bad things. You can’t do your job effectively. Suddenly, in 10 years, you are becoming a great software developer. Or you buried by mediocrity and never ride the wave. Why? What should you do to advance or just survive?
I think one of the most important factor is perpetual, passion learning. Learning is the most important thing that drives software development forward. Learning is the most important thing that drives you, as an individual, forward. It drives your team, as a group of people, forward.
source: Ashiro’s LabZone
I believe, learning is a key attribute of a good software development process. Process that empowers learning will work, process that impede learning will fail.
Basically there are three levels of learning. First, you learn as a person. Then you learn as a group of people. Finally, you learn as a whole organization. This post focuses on a personal learning.
I have own vision on software development. Most likely it is caused by my personal background and products I’ve worked on (all of them web-based).
Software developers solve problems. To solve a problem in a cool way, you need to be a multi-skilled professional with quite solid knowledge from as many related disciplines as possible. Only this will give you a complete vision of the best possible solution.
Deep Specialization vs. Broad Knowledge
We are stepping on a slippery ground of deep specialization vs. broad knowledge. My belief is that on the current stage broad knowledge is better. Why? I can provide some analogies that prove nothing, but still interesting.
Software development is a young discipline. It has its own properties that are not fully understood by most people. You can’t apply mass-production to software development so far, since you can’t formalize it enough. You can’t write product specification, create design and generate complete application from UML diagrams (yes, I am aware about Model-Driven Development, but it is not even close to mass-production).
Look, there are so many related topics, from psychology to programming languages, from ToC to pair programming. There is no best way to write software so far. If you can’t apply mass-production to software development, you can’t do it efficiently with people who has very narrow specialization. You can’t put it on a conveyer.
Let’s take science and look back for 300 years. We will see that many
discoveries were made by generalists. Let’s check Wikipedia.
- Isaac Newton: physicist, mathematician, astronomer, natural philosopher, alchemist, and theologian.
- Galileo Galilei: physicist, mathematician, astronomer and philosopher
- Christiaan Huygens: mathematician, astronomer, physicist, horologist, and writer of early science fiction
- René Descartes: philosopher, mathematician, physicist, and writer
It was common 200-300 years ago. In modern science you can’t discover anything without deep specialization. There are people who has broad knowledge, but it is rare these days. More often you will find people like:
- Barton Zwiebach: string theorist
- Max Tegmark: cosmologist.
- David Joseph Bohm: quantum physicist
There are rare exceptions for sure, like this one:
- Stephen Wolfram (born 1959): physicist, software developer, mathematician, author and businessman.
What is the point? Software development is not a science obviously neither ‘tangible’ industry, so all such analogies don’t prove anything. But I think software development is somewhere at 17 century in comparison with science and in 19 century in comparison with usual industry.
Taken this speculation into consideration, team of generalists with some specializations can create a better software than a team of highly specialized people. It is not obvious and we need to evaluate this assertion. I can throw some arguments:
- Architecture. Developer may know nothing about testability. As a result he creates hard-to-test solution. High specialization can lead to local optimizations, but weak architecture as a whole. If no one understands how does it work as a whole — it’s a bad sign.
- Fragility. Highly specialized team hardly pass a “bus test”. If one of the key persons will be hit by the bus, development will stop.
A Multi-skilled Software Developer
I believe in multi-skilled software developers. The right question to
ask is “how much skills should I have and how deep?” It really depends,
but here are the skills/domains/attributes every great web developer
should have. The list is sorted by priority and I put hours that should
be spent on formal education:
- Curiosity and passion
- Self-reflection / problem solving
- User Experience (1000 hrs)
- Programming (OOP/OOD, tools, practices, etc.) (8,000 hrs)
- Testing (200 hrs)
- “Sense of beauty” (Graphic design, visualization, etc.) (200 hrs)
I insist that these skills are very important for any really great web developer, but they may vary depending on software development type. I expect questions like “Why the hell you put User Experience before Programming?” The reason is that UX is an important part of problem solving. It is more important than implementation itself. UX gives developer a right perspective and affects solution highly. Without UX you can beautifully implement a crappy solution and 90% of existing software does exactly that is exactly that. They are crappy, unusable and bloated with unnecessary features.
Great developer should have a “sense of beauty”. It’s hard to formalize, but in general he should be able to say “this button is ugly” and “this menu is beautiful”. “Sense of beauty” is a very important property, it affects everything: visual design, documentation, architecture, source code. Everything. You can (and should) train it.
In the next post I will share my vision on Learning as a Team.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)