And the next discussion topic was “Are you programmer professionals? And what does it mean?”
What promised to be a C++ meet-up about topics that could spark a flame war turned into a thought-provoking moment.
It started lightly with the east-const vs west-const question (obviously east-const is the right answer), then things got much more foundational.
The April Italian C++ meetup introduced a twist in the continuity of the meetups. While all the other editions consisted of a conference-like talk given by one or two experts, this one was an open discussion. The presenter, the brilliant and twice-almost-colleague Davide Bianchi, introduced a topic at a time and then called two community members to discuss different opinions and perspectives.
It was a fresh take on the meetup idea, departing from the monodirectional flow of information and ready-made presentations. But that’s enough context, back to the question – can we programmers be considered professionals? This is legit, thinking that I heard, more than once, that our work can be done with the same proficiency by a high school student.
The core of the problem is, for sure, that no one but us programmers understands what we do for a living. And I am not only referring to family and friends, those who routinely ask us to fix their printer or recover their lost files, because we work with computers. I am also referring to our colleagues from other departments, people who manage us, and eventually to clients.
Going deeper into the matter, we have to admit that the programmers’ community itself is not fully in agreement when it comes to how programmers’ work has to be done. The language, the tool, the process (if any), and how wide the indentation has to be. Even worse, experienced developers tend to be very opinionated, causing further confusion for anyone outside our circle who tries to make an opinion.
The meetup debate focused on a specific aspect of professionalism – whether appearance is enough (possibly paired with speed of execution) or content is equally important (usually paired with longer development).
This triggered the thought that, in most cases, if you are a senior programmer, you are your measure. Only you know what you are doing, only you decide how to do it and which path to tread, only you state when it’s done. Whether it’s a patchwork that, in the right conditions, appears to work, or a miracle of software engineering, the customer won’t be able to tell the difference. Even worse, the customer may confuse your effort to fix the mess in the former case with dedication and think you are doing a great job, great value for their money (this happened).
The money question (would the money be yours, would you pay for developing something in this way?) can be a starting point to identify overengineering, but it is very abstract. A software project may cost a lot of money, the kind of money a programmer usually doesn’t have to spend.
My first reaction was to defend my work and blame the others (to err is human, to blame someone else, even more). Of course, I always pick the best solution in the interest of the client., I’m always right. Other programmers may get this wrong, but not me. Then I came to sense and admit that sometimes the hindsight proved me wrong. I have good excuses for that, such as the customer is likely to change their idea, or the feature looks like a foundation and in the future they would like to build on it, and so on. But at the end of the project, it turned out that I could have saved some effort, i.e., some customer money.
Even worse, although I am convinced my programming approach enforces the best practices, producing robust and hard-to-misuse code, I have to admit that other approaches have their value. Maybe you need to forge something quick and dirty to win the client over the competition, or to stick with C++98 style because the dev team mates are as flexible as rocks.
The recent criticism of clean code, even if it finds me in total disagreement, is a clear sign that programmer pundits do not agree even on core issues.
So, in the end, I believe that being professional for a programmer, as long as there are no general agreements in the profession, is about open, transparent communication and customer focus.
Always declare and explain your approach, respect your users and customers, and try to wear their shoes. You are smart and intelligent, otherwise you couldn’t work as a programmer, but remember that the world is plenty of people with a different kind of intelligence who have no way to remember what does -e 18 mean.
Open communication means providing early notification for problems and delays, while presenting alternative solutions that could work for the customer, mitigate or eliminate the risk of being late with their product.
Try to educate them, but consider that maybe you can remember what -e 18 means on the tip of your fingers, but this doesn’t imply that it is the same for everyone else.
In the end, thanks to the Italian C++ community (and the brilliant and tireless coordinator Marco Arena) for giving C++ programmers this rich and interesting calendar of meetups. And thanks to Davide for bringing the innovative interactive format and chairing it dynamically and entertainingly. The video of the meetup can be viewed here (and you can also see yours truly).
Now it’s time to implement that generalized lock-free container reusable for every type, that I need just once for ints in a single-thread application…