Grady Booch interviewed by Software Engineering Radio highlighted the essentially needed qualities of a valuable/good/great software developer:
- Being a good abstractionist
- Being a good team player with good communication skills
Who is a good abstractionist?
A good abstractionist is one who knows how to abstract an idea and can implement the so created abstraction using a programming language. Note that what is in bold here are necessary requirements (i.e. "knows how to abstract" and "can implement it").
So what is "abstraction"?
Put in simple terms, an abstraction is a simplification of something that may be complicated. For example, a man is a simplified view of a complex biological mass. A computer is a simplified view of a collection of components that act together (CPU, storage,...). A CPU itself is an abstraction of some other details. The same concept applies to software as well. For example, a word processor may just be a word processor for you. But the people who implement it see that a word processor is a complex integration of multiple software components together. One such component may again be an abstraction of several other "sub-abstractions". Hence we see that we can think and talk of different levels of abstraction.
Prof. David L. Parnas (still alive) presently at University of Limerick in Ireland who is respected for his initial research and hence formulated software engineering principles about 30 years ago which are still valid and set the foundation for modern development, describes the meaning or properties of "abstract" as follows:
- Not vague, theoretical or highly mathematical; abstract means - expressing a general property.
- Abstract implies a many-to-one mapping.
- The abstraction represents many things equally well.
- The abstraction models some aspects of the real things, but not all.
- Eliminating detail is the approach: The interesting issue is which details should be eliminated. Eliminate the details that are likely to change.
If you could understand the above clearly, David Parnas has more goodies for you. The above was captured from the paper on "A Procedure for Interface Design". If you couldn't understand, don't panic and you will feel comfortable with my simple explanation.
Being a good team player with good communication skills
I have seen people who oppose, but this turns to be true if you are into legitimate software development. If developers cannot understand and cannot explain themselves clearly, what good can you expect in the software they create? If they cannot communicate, they won't be good team players too. Specially when the project is large, having poor communicators put the project in risk not only because they don't understand what is required to be done and don't get the questions that springs in their minds clarified, but also because they become a painful burden to other team members.
This does not suggest that we need to know all the grammar and the related of English language and practice them with perfect correctness. English is such a painful language with lots of unnecessary complications. This holds true for our own mother tongue as well. In reality, all the natural languages used by us have unnecessary components (But I have heard that Sanskrit was an exception, wasn't it?). What matters is sympathetic communication. And for that purpose, one should be able to read, write and speak well. Even a reasonably written reply to an email counts.
In other industries, communication skills may not be a great issue, but in software, there's no choice. There's nothing strange in refusing the applications of highly (technically) skilled people with poor communication skills even by our own country's software firms.
To be a good developer
Your knowledge on latest Microsoft tools or Java Enterprise Edition (or any similar technical soundness) will prove to be useless unless you enrich yourself with the ability to abstract, implement the abstractions and communicate well. Spending time on English will improve your communication skills. Abstractions? A good technique is to embrace software design patterns (Learn and then make sure you code as well. Also see if you can combine patterns and analyze the consequences).