Out of all of Decide’s values, there is one that we give special importance to, even though we have not bothered to define it precisely: excellence. It may seem initially that it is not necessary to define this word, but looking it up in the Spanish Dictionary of the Royal Academy, we can read this definition:
“Superior quality or advantage that merits singular appreciation and esteem”.
We definitely need to be more specific. With this definition, nobody at DECIDE would know what is expected from them exactly when we tell them that excellence is a company value.
For this reason, and some others, I have decided to write a post on what I consider excellence to be in the area of Software Development, and what I expect when I say I want this value to be the cornerstone of our company. This is going to be a heartfelt post, and it is quite likely that I’ll get carried away by emotion more than once.
For me, excellence in software development includes the following aspects, more detail will follow:
- Proficiency / Knowledge
- Passion / Pride
- Integrity / Humbleness
At this point I think this is a good time to completely rejection the common belief (widespread in Spain at least) that ‘programmers’ are people who don’t have to understand anything and they just have to read a design (created by a ‘designer’) and turn it into lines of code.
And even at the risk of sounding temperamental, I would go as far as to say this idea is a scam: it is impossible to develop quality software that way. If the ‘designer’ were the least bit competent, it would be easier for him to develop the software than hand it over and explain it to a programmer. Moreover, the type of ‘programmer’ that fits in well with this picture is a newly graduated intern who has never programmed in his life. In other words, the best you can expect from this approach is mediocre software designed by mediocre people and programmed by mediocre people. There. I’ve said it.
For me, the only valid profile is that of developer, and not programmer (it is a matter of words, but this concept has been quite well defined in this article, sent to me years ago by Juan Javier Domínguez, Area Manager for Operating Research at DECIDE). One of the main qualities of a true developer is excellence.
Proficiency / Knowledge
One of the pillars of excellence in general, and particularly in the world of software, is knowledge. Software is a truly vast discipline, not only due to the quantity and variety of different programming paradigms and languages that exist, but also because of the different methodologies, design patterns, frameworks, development environments, best practices, … It is impossible to master them all (or is it?), but to be an excellent developer it is not really necessary. It is necessary, however, to master those that you use:
To be an excellent developer, you need to master the programming languages you use. And let’s not forget that mastering a language means much more than just having a command of its syntax. In fact, that is the easiest part. To master a language you at least need to have a basic notion of its running environment and its compiler (if there is one for that language). And you also need to know the most popular libraries written for that language, as well as the best practices that have been defined for the language. You must also know the most popular tools to guarantee the quality of the code. And to this we must add many hours of work. We must not forget that software development is a craft , therefore it is not something you learn through books but by experience.
In order to achieve excellence as a developer it is also essential to have an in-depth knowledge of the methodological context you are working in. I’m not going to speak up for any particular methodological context here, although the ones I prefer are well know. But I do think a good developer ought to know how to adapt to the methodological context in which he or she is working, whether it be a cascade or iterative methodology or a non-methodological or agile environment.
A good developer must bring on added value in any context, although the fact of the matter is that it is easier to do so in some contexts rather than in others. And to do this he needs a detailed knowledge of all the artefacts that are used in the methodological context, in order to have a broad understanding of the project.
Design Patterns, Frameworks, Libraries
A good developer must have a thorough knowledge of the design patterns he uses. In my opinion it is not necessary to have a thorough knowledge of all existing design patterns. I think it’s important to have an idea of what is possible with each design pattern, that way your intuition can decide when you need to use a specific one. However, when you do make the decision, you must have an in-depth understanding and knowledge of that pattern.
I think that a good developer, prior to using any library or framework, should do the same operation manually. We need to rid software of the idea of ‘magic’. Software has no life of its own, everything it does is written in the code, and if you’re going to resort to a library or framework to simplify matters (which I recommend), first you need a thorough understanding of what that library does and, wherever possible, how it does it. All of this is required in order to expel the ‘magic’ factor from software and to avoid uttering sentences such as “it throws an exception” or “it says that…” What do you mean by exception? What exception? Where does the exception take place? If you do not understand, everything becomes magic. The attitude of a good software developer must focus on understanding what’s happening, and this is achieved by thoroughly understanding all the parts that make up your software.
How can somebody say that they’re good at their craft without being an expert in the use of their tools? This applies fully to software: you cannot be a good developer if you do not master your development tools. Every time I see developers moving their mouse up and down, surfing around the menus to find what they’re looking for, with a tool they use eight hours a day every day of the week, I really get worked up.
One of the essential productivity factors in software development is selecting and handling supporting tools. So whether you program using vi, emacs, Eclipse, MS Visual Studio or Notepad, if you want to be a good software developer, you need to master the tools you use. Once you’ve looked for something three times on the menu, why not learn the shortcut? One of the best developers I’ve known, @alvarogonzalez, spent time every now and then studying the shortcuts in Eclipse. He got to know every single one. Furthermore, whenever he interviewed somebody, one of the things he watched most was how many shortcuts the interviewee used. And I agree with his approach: an excellent developer must master the tools he uses—whatever those tools may be.
Passion / Pride
Software development is fun, and rightly so. You can spend hours upon hours developing software. Even days at a time. Good software developers enjoy their work. They enjoy programming. When we were kids we all played with Lego blocks (or Tente, in my case) and we did our best to build things, always limited by the number and shape of the parts at hand and the boundaries of our imagination. In the world of software, the first limitation does not exist. With a more or less state-of-the-art laptop we can create nearly anything. We can unleash our imagination and make things we can be proud of. Software development can become something fascinating.
And feeling this passion, being proud of the outcome of your work, is necessary if you are to become an excellent software developer. I think the code you write is a reflection of yourself, of the eagerness you put into your work. It so happens that I am currently reading the Biography of Steve Jobs by Walter Isaacson. And among the many things that have drawn my attention is one of the teachings of his adoptive father, Paul Jobs: whenever he built a piece of furniture, he used the same quality wood for the front as for the back. He used to say that you had to take equal care of the parts you can see and of those that go unseen. This is something Steve Jobs applied throughout his life, and it is equally applicable to excellence in software development. You have to be just as careful with the parts that you can’t see as with those that you can. You have to make software that you can feel proud of, both on the inside and on the outside. An excellent developer enjoys showing the ‘inner parts’ of his software, the techniques used and the way complex issues were overcome. A good developer feels proud of his work and, to say the least, is not aware that anything needs improving.
You cannot be an excellent carpenter if you do not love carpentry. Likewise, you cannot be an excellent software developer if you do not love to program. It’s that simple. This passion is what drives you to learn something every day, it arouses your curiosity in every new development, in short, it pushes you to be better every day.
Honesty / Humbleness
In order to excel, a software developer needs to improve every day. There is not a place called ‘excellence’ waiting for you to take a seat when you get there. Excellence is a path rather than a place. The world of software is continuously evolving and you need to learn new things every day to remain in this area of ‘excellence’.
But in order to learn, in order to improve every day, one must take a humble approach. Wise guys who think they know it all stop learning. You must be aware of your shortcomings to feel motivated to keep on learning more. A humble approach is useful. The more you know, the more aware you become of everything you still have to learn.
On the other hand, another important factor among excellent software developers is honesty: you cannot know everything and you should not have a problem with admitting there is something you don’t know. Being an excellent software developer entails being able to value knowledge and experience—both your own and that of others. And that’s why you have to know when you do know something, and may therefore contribute some knowledge, and when you do not know and are better off listening and learning.
If you bring passion into what you do, you know what you are doing and you actually value knowledge and experience, then you have to be able to admit when you don’t know something, you have to know how to value other people’s knowledge just like you value your own. If it ‘annoys’ you when somebody who really does not know much about something becomes opinionated about things you understand well, make it a point not to do the same to others.
Having said this, are we excellent at Decide?
The answer is no, but we try to be. We strive to be better every day. We try to bring together the principles in this post, and we try to get people at Decide to be actually or potentially excellent. I am strongly convinced that all of the people working at Decide will sooner or later become excellent software developers, and I know that many of them already are.
I may never be able to say that Decide is excellent, but I can say that every day Decide is better than it was the day before, and I can also say that we put special care into the quality of all the software we produce. And I can add that at Decide we seek and value excellence above all things.
This said, will we ever reach excellence? Maybe not, but as I said earlier, excellence is not a state but a path, and I am sure that is the path we are trying to follow at Decide.