Software developers need little knowledge to do their work properly and to be successful. Now you think I’m crazy, don’t you? Let me explain.
Delusion emerges because people have to practice a lot to become developers. And their training can extend for a few years. During their training future developers should cultivate certain very specific skills. I would like to sort them into three groups:
· Skills required to map paths between points A and B;
· Skills required to get from the point A to the point B as quickly as possible;
· Skills required during debugging.
And there are a few skills which I separate into fourth additional group, because these skills are necessary to become an excellent developer for really big projects:
· Skills required to build an enormous solution.
Knowledge
Before I talk about the skills groups, I’d like to discuss knowledge a little. Knowledge can make developers’ work more comfortable: they will spend less time with Google and books if they have some knowledge. But knowledge rarely helps to shorten the lead-time of a project. Knowledge really matters when it comes to proving a developer's intelligence. You can ask a developer about history as you ask him about the mediator pattern at a job interview. His answer gives you the information of the same value. Maybe, if you ask him about history it will be a more reliable way to check his intelligence, because he hasn't reviewed history books before the interview.
Skills required to map paths between points A and B
The written code is a path between a current state (point A) and the expected state (point B). One has to find the quickest way between these points to make the lead-time of a project shorter. And one has to find it as soon as possible.
There is a hidden but very distressing obstacle: the expected state isn't a formalized state at all. Of course this is analysts' or managers' problem more than developers' one. But a developer can find out all possible ways to a required direction. He should offer several options of the “point B” at the ends of the shortest ways to his manager or client if there is a possibility to shorten development time significantly. Sometimes you can save weeks and months when you work with Magento using such technique.
Skills required to get from point A to point B as quickly as possible
You have to forget about all ramifications while building path from point A to point B. All subcases and variations should be forgotten. If you try to build the main case and all its ramifications at the same time, you may begin to build solution branches instead of a required solution itself. And of course it is waste of time. I mean you have to develop all required subcases but only after you achieve the goal. And there is a pot of gold on this way. You always can predict path between A and B. But you never can predict all ramifications. And only when you pass the path you will see them all.
Ramifications realization is a bunch of paths like path between mentioned points A and B. Each one has comparable length with the main path. Hence, because the lead-time depends on ramifications realization more than on a solution itself, you will have a possibility to notice that you won't meet the estimated deadline. So you can come back to thinking about the chosen way.
Moreover, from this point you can consider whether some branch is necessary or not. Fewer branches mean shorter lead time.
There is one skill which turns a human into a software developer, but this skill isn't very important at all. The developer has to be able use basic program bricks without hesitation. I mean basic operators and techniques like using variables, tags, functions etc. It is only one skill which is similar to knowledge. But if you look closely, you will notice that it isn't knowledge at all.
A very gainful skill is the ability to find out and use existing solutions. The developer has to look for ready-made solutions inside frameworks, extended code, and among libraries. But you have to be careful with that. Sometimes you can spend more time to find required functionality and to implement it than you would have spent writing and stabilizing your own code.
Skills required during debugging
This group is the largest one. And this group can be extended permanently. I can give only few examples.
A developer has to use debuggers. In my technological area (PHP) a lot of developers don't know how to use debuggers. It's a pity, because it is the second quickest way to debug. Then developers have to be able to understand internal problems through program behavior. It's very useful because it is the first quickest way to debug. Because when you see the cause of a problem through wrong behavior, you don't waste time to find it out.
Developers have to be able to debug by program output and logs. It is the same things in my eyes, but they are two different skills. And they both are very useful in many cases. The last very important debugging skill I want to mention is debug through unit testing. First of all I mean MOCKs and stubs. In complex environments they are the most useful debugging techniques.
Skills required to build an enormous solution
When I told about the last very important debugging skill, I was already talking about this group. Every developer who decided to work with enormous multi-modules solutions or entire applications must be able to work with languages from different programming paradigms (functional programming, imperative programming etc.) And he of course has to feel and understand Object-oriented programming (OOP).
I know that there were a lot of discussions about whether OOP is necessary or not, and most people use it just because it is a requirement for working with Java and .NET. I don't want to begin a new discussion. I just give advice. Even if a developer doesn't want to use OOP all the time, he has to understand it when he feels necessity to organize a big chunk of code instead of inventing his own streamline technique.
When a developer feels comfortable using OOP itself, he has to develop the skills of using SOLID and Patterns. He doesn't have to know them, he has to feel where and why he should use these best practices of code organization. How does that work? Look. Human's brain has very little ability to hold images of certain items. When you can feel a sense of complex structure behind one item you can manipulate such things significantly quicker. When all your team has the same sense of structure behind one item you can communicate significantly quicker. And as you may know, communication is one of the biggest problems in software development (and maybe in any business at all).
All these skills look pale compared to the very last skill I want to point out.
In the first part of my article I told about Skills required to map paths between points A and B. And I want to come back to that group. To be a good developer who can build an enormous solution you should have the ability to use the skills of that group continuously during development. Let me explain. When you have chosen a way and you are writing a very big piece of a very big solution, you can once understand that you miss something not less huge than you deal with already. And this circumstance can deteriorate all benefits of the chosen way. In this situation you should have ability to notice that, stop, think and change your way. If you can't, you won't be able to achieve expected results.
