5 Traits of an Excellent Developer (Part 3)

Huba Albu
3 min readJan 13, 2021

* good communicator
* deep technical experience
* refactoring skills

Photo by Jason Rosewell on Unsplash

Good Communicator

Once a brilliant person told me if somebody says something it is because they want to be heard. This is so true in a never-ending feed created by tech-giants like Facebook, Twitter, Instagram, LinkedIn and many more. The easiest thing for a person, in 2020, is to open any social media app and post something. Does that mean we are full of clever ideas and values which will rock the world? I don’t think so. To be a developer nowadays, one must communicate, because solo players are rarely needed, software development is a team game.

“Fact /fækt/ — things that are true rather than things that have been invented” — Oxford Dictionary

“Opinion /əˈpɪnjən/ — your feelings or thoughts about someone or something, rather than a fact” — Oxford Dictionary

The hardest thing for me was to understand the difference between a fact and an opinion. Simply put, they are neither synonyms nor interchangeable. Statistically, the amount of data shared around the world makes it impossible being true to a large degree.

Having this said, nowadays it is even more important to have good communicators among us, not because we are just desperate to be transparent towards the organization with our work, but if we can’t express ourselves about what has to be done as a professional, how can one expect others understanding the needs of a developer. Because of these circumstances, I’ve had many discussions with managers, PO’s, CFO’s and many more stakeholders, about why we do things when they seemed unnecessary from their perspective. The usual pain point is how to write code, when and how to write automated tests, how well those tests are covering the needs of the business and how to combine all this with estimations with deadlines. Wiring code is just a fraction of the time spent by a developer, even while writing code, more time is spent on refactoring it than coming up with the initial, brute, optimistic version.

“estimation /ˌestɪˈmeɪʃn/ — a judgment or an opinion about the value or quality of someone or something” — Oxford Dictionary

Given the AGILE hype of nowadays, one can just go with the flow to fit into the industry standards, perhaps trends, used by most companies disregarding their needs and abilities, one would say we are drunk on Agile. When one is mentioning Agile, immediately two aspects are meant, the iteration of scheduled work and estimations. Of course, it makes sense to understand the work and effort needed to be done, but for me, an estimation is as good as an “estimation” and nothing more, not a promise. By definition, it is not fact-based, which can’t result in any binding towards a promise. Translating this to the day to day work of a developer, it has to be clear for everybody what we mean when we give estimation and also the way of communication has to make sure what is conveyed is relevant and well-understood by all parties. One could consider being a good communicator as a discipline of a developer.

“Professionals have standards and disciplines.”

Conclusion

Everything that we say has some value, if it is good or bad it is not up for me to decide, but what I can guarantee is whenever a software craftsman, a professional with standards shares their argument, it will have a weight.

--

--

Huba Albu

Technical Lead - Passionate leader and developer at Siemens