Communication is a Core Skill for ProgrammersMatthew QuirosBlockedUnblockFollowFollowingJan 11Photo by Thomas Drouault on UnsplashWe, programmers, draw much of our professional pride from our ability to solve problems — in writing the most time- and space-efficient algorithms, in designing highly scalable architectures, in crafting the most stylish and clever names for functions and variables, and in shipping five-star apps that positively impact the lives of many people across the globe.
Thus, we strategically build our careers — our whole lives, even — towards the constant sharpening of our technical skills.
We spend plenty of time and money studying to become full-stack and cross-platform.
We take refreshers on CS theory and practice in Hackerrank or Leetcode on a daily basis.
We buy books on best practices and design patterns which, according to popular people in Medium and Quora, “everyone should totally read”.
We work on weekend projects to maintain an active Github profile.
We farm reputation by answering questions in StackOverflow.
The list is long, and it only goes on.
All these are often done at the expense of one’s soft skills.
Soft skills are the skills that one employs in the management of oneself and of the people with whom one works, such as customers and colleagues.
These include leadership, emotional intelligence, persuasion, listening, being a motivator, and building valuable relationships.
Hard skills, on the other hand, are highly-specialized and often scientific knowledge employed in the task of solving a problem or building a product.
The coinage “hard skills”, however, is a misnomer for skills that are often perceived to be difficult, carrying with it the unflattering notion that people who have good soft skills, in comparison, specialize on skills that are simple and quick to learn.
In reality, without self-awareness and spending an inordinate amount of time on deep, thoughtful reflection, soft skills are incredibly hard to master.
One such commonly-ignored soft skill is communication, or the ability to convey an idea or information to another person.
I, for one, like many programmers in their youths, once expected that people who are assigned to directly work with me should just, by default, have a solid understanding of technical principles without much explanation; otherwise, either they shouldn’t be working in the tech industry or they are idiots.
Many young programmers think that formal documentation and processes are simply bureaucratic red tape which only serve to slow down software development and thus should not be respected.
In the articles that we write and in our representations of programmers in popular culture, we celebrate introversion and eccentricities in personality which fundamentally make it difficult to collaborate.
Programmers must, however, learn to communicate.
In the first place, a great majority of the environments in which the activity of programming is done is within an organization where a programmer needs to interact with non-programmers.
Often, we must correspond with a product manager to flesh out the technical specifics of business requirements so that difficulty can be gauged, feasibility assessed, and on those grounds, tasks be prioritized.
We may need to provide and justify estimates to a project manager who is making sure that the project is within budget and on schedule.
We need to work closely with designers to work around the limitations of target environments, identify missing flows in user interaction, or spot issues with the design of information.
And instead of taking offense, we must collaborate with QA in reproducing and identifying the sources of bugs, or to discuss whether something is an issue to begin with.
In communicating with colleagues in these roles, we must constantly be careful about the words or the tone that we use to convey our ideas.
A critical element of high-performing teams is team dynamics, and if the way that we communicate courts conflict or drama, then we are effectively introducing dysfunction into the team.
Why do these other roles even exist?.One might ask.
Nothing is stopping a programmer from liaising directly with clients so that requirements can be gathered.
Project managers are a thing of the past anyway, when waterfall was more popular than Scrum — a programmer can also just directly liaise with the CEO and justify estimates using pure logic.
Designers are utterly useless; any coder can slap in custom fonts, colors, and icons — in vector, even, instead of JPG.
And why do we even need a dedicated team of testers when we can just write the unit tests ourselves?Products that are truly valuable and successful are those that become non-trivial in scale and which require multidisciplinary expertise; hence, they are impossible to do alone.
Code, by itself, does not a business make.
The reality of the work involved in the above roles is that, just like programming, they take plenty of time and energy to even accomplish especially when upheld only to high standards.
If a programmer were to do everything by themselves, nothing would be done well.
It would only eat away all the hours which could have been focused on writing code instead, which is the primary function of a programmer.
Additionally, the dismissing colleagues’ roles as in the manner above is an act that comes from a position of proud ignorance.
It is shortsighted and reductionist.
Product managers don’t just write business requirements for our purposes — that’s just the part of the job that faces programmers — they keep products valuable by constantly studying customer behavior and trends in the company’s line of business.
Project managers do a lot more than justifying estimates — they plan and adjust schedules, create budgets, assess risks, and manage the allocation of resources.
Designers, on top of developing a good taste for art, study a lot of psychology, human-computer interaction, and even neuroscience to incorporate scientific findings into the company’s products.
And testers, unlike unit tests which function merely in a development environment, ensure that products behave as expected even after deployment to production.
They are invaluable in eliminating developer bias, thinking of “unhappy paths”, documenting the steps to reproduce errors, systematizing test workflows, and automating simulations of user interaction, the part of development work which most programmers consider to be a drudgery.
The universe beyond the programmer’s screen is much bigger.
We ought to be humble, for we may not have an exhaustive knowledge of the day-to-day operations and responsibilities of people in roles that aren’t ours.
Truly, it is odd how we came to refer to people who don’t code as “non-technical” when they are, in fact, technical to the field in which they specialize and in which we do not.
But, perhaps, communication skills derive a greater deal of importance not so much from the need to interact with non-programming roles but from the need to communicate with other programmers.
We often debate with each other on abstracts, scrambling for an explanation as to why one solution, process, or framework is superior to another, lest we be dismissed as merely imposing our personal preferences.
Many times, engineering teams arrive at an architectural decision not even because it is objectively better than alternative options — it was merely advocated more eloquently.
It is common for us, too, to discuss and agree upon standards of working, such as version control workflow and code style.
We enjoy teaching each other about advanced programming techniques and industry best practices.
Eventually, as we rise into more senior positions, the responsibilities of conducting one-on-ones, providing feedback, and managing conflict become inevitable.
Others may argue that there isn’t a need for communication skills where a programmer is hired specifically for the purpose of only taking orders.
However, even a programmer who merely follows orders still needs to ensure, through communication, that non-negotiable requirements are well-understood.
Even interns and junior software engineers are expected to speak up when they find an error in the specifications, or to ask questions wherever there is ambiguity.
A role where a programmer must produce something of great value without ever needing to communicate simply doesn’t exist.
Communication, therefore, is a core skill for programmers.
.