Recently, on LinkedIn, I shared my unapologetic opinion that you're not a professional software developer if you don't care to write automated tests to verify your code.
Some people took this into their hearts and decided to call me out as a gatekeeper, actively seeking to harm the industry. Remember that I said nothing about fresh developers who haven't yet learned to write tests. My gripe is for the experienced developers who boldly declare writing tests will only cost you time while you seek to cash an exit from the next ample startup opportunity. I find few attitudes more repulsive than this. I sincerely hope developers working in health, automobile, financial, or energy sectors will never learn to think like certain startup hobbyists lest our society collapse.
Leaving the random commenters be, it made me wonder that it is common to mistake a professional software developer as one who gets paid for writing code. That is a shallow bar and heavily disrespects the people who work professionally. For example, I know and respect many open-source developers who might have little to no income from paid jobs. Yet, their outcomes enable a lot of commercial software development to exist in the first place.
Thus, being a professional means conveying a degree of professionalism through your work.
A practical guide to looking towards professionalism above all is The Manifesto for Software Craftsmanship, where the first sentence nails it:
As aspiring Software Craftsmen, we are raising the bar of professional software development by practising it and helping others learn the craft.
Having read that, you might think that there are professional software developers, and then there are the mythical unicorn-shaped master craftspeople above them all.
On the other hand, I am more interested in exploring the tenets of professionalism. So let's unpack the manifesto and find out what it means to be a professional software developer — or craftsperson, should you prefer that.
Not only working software, but also well-crafted software
For professionals, it is not enough to glue together clumps of spaghetti code and ship it to production. We must care for our work's end-to-end quality and longevity, which requires continuous and opportunistic refactoring of the existing design requiring a stable set of fast-running automated tests. Indeed, the first principle already shows that you can't call yourself a professional if you refuse to write tests. Simple, eh?
Not only responding to change but also steadily adding value
For professionals, it is not enough to follow the orders given by management and stakeholders. The project or product you work on is your ship too. Without travelling too far to the myriad misconceptions of the "Corporate Agile with a Big A", we professionals understand that new information uncovered during the development process may shift the path forward radically. So, we must be prepared to trash our plans yet always keep adding value.
How do we achieve that? Through the Evolutionary Design principle. It guides us first to build a primitive whole and grow its design organically utilizing automated tests (surprise!), test-driven development, domain-driven design, design patterns, and continuous delivery for stable and resilient value production.
Not only individuals and interactions but also a community of professionals
For professionals, it is not enough to write your best code in glorious solitude outside the feedback of your team, community, and the industry as a whole.
Many developers explain that they can't bother collaborating with others because they are introverts and thus achieve their best work alone. Yes, you are entitled to that, but you must talk to your team and users daily to be a true professional. We are in a business that is inherently a team sport requiring excellent communication skills and emotional intelligence. However, it doesn't mean you should be an extrovert who can't shut up, either.
Moreover, you need a community around you that learns from the knowledge you share and nurtures your growth. Then, as a professional or growing to be one, you can write blogs, make videos, present in front of a live audience, and mentor the less experienced ones.
Finally, I find Kent Beck's definition in the book Extreme Programming Explained (1999) particularly apt.
Extreme Programming is about social change. It is about being open about what we are capable of doing and then doing it. And allowing and expecting others to do the same. It is about getting past our adolescent surety that "I know better than everyone else and all I need is to be left alone to be the greatest". It is about finding our adult place in the larger world, finding our place in the community including the realm of business/work. It is about the process of becoming more of our best selves and, in the process, our best as developers. And, it is about writing great code that is really good for business.
Not only customer collaboration but also productive partnerships
For professionals, it is not enough to cash in on short projects and then move on. We must have the mindset to maximize the outcomes of the products we are building. In consultancy, we must foster the relationship with our clients and their value streams.
Being a trusted partner to people has the additional karma effect. When you most need help, someone from your network is more eager to offer a hand if they remember you as a reliable and productive partner. Respectively, if you only work to reap the fruits and see the world burn without a single thought of caring for other people, you will most likely be left to survive alone.
***
The points above might leave you thinking, did I now describe what a senior software developer should be? Perhaps not. I've found it unproductive to divide developers into seniors and juniors as it may fool us to look solely for the experience in years.
Some developers have 20 years of experience backed by a professionalist attitude, and then some developers have one year of experience 20 times, with a hobbyist attitude. So which one do you aspire to be?