You might think that no two professions could be more different.
Software development is an applied extension of Computer Science and has created some of the most complex systems in human history (and all without a physically tangible product!).
Software Development — abstract, logical, based on measurements and calculations — this is a “hard” science.
Counseling, an applied extension of Psychology, deals with the issues we humans have navigating the social structures of our societies, our own often unspoken inner selves, and conflicts we feel between our needs and our wants.
Counseling — humans empathizing with and providing tools to other humans through communication, practiced mindfulness, and self-reflection — this is often thought of as one of the most “soft” sciences.
But are these professions really so different?
I have my own thoughts about calling a science “hard” or “soft,” as it can be used as a means of trivializing (soft) or elevating (hard) the work behind and output quality of a science. So, I am using them here to speak to the assumed difference that separates the two fields of counseling and software development.
Is there something that counseling has to say that could help us software developers more fully enjoy our work, leave us with better client relationships, and produce better applications?
Let’s explore this further — but first some context!
As software developers, we are all familiar with the different programming paradigms adopted by programming languages, frameworks, libraries, tools, and the other developers around us.
Do you lean towards imperative instructions and objected-oriented abstractions or declarative and functional approaches?
With this foundation, let’s begin to ask the question “What Can Counseling Teach Software Developers?”
While counselors don’t ask themselves the exact same questions as the ones above, they have similar decisions in their work. They have to decide which approaches to their profession they identify with and want to pursue.
This is called an orientation, and the options available are as varied as the paradigms in software development. Examples of orientations include art therapy, CBT, DBT, psychodynamic, solution focused, and psychodrama.
Each of these orientations (you can also think of them as methodologies) has a set of tools that counselors can use to help their clients.
All of these approaches have their own academic and professional champions, thought leaders, techniques, historical context, and research supporting their efficacy in different situations.
In counseling, these different orientations are examined and debated through journals, peer-reviewed papers, conferences, and discussion groups.
If you are thinking this sounds a lot like modern software development, we think alike!
We software developers need this discussion to be part of our profession. We need healthy and robust dialogue and debate about how we approach our work. This applies to both technical and social techniques.
However, we need to also behave like professionals. When we debate our techniques, we need to debate based on merit and evidence — not through personal attacks or blog posts with a headline like, “Tool X has completely destroyed tool Y, and why you should switch now!!!”
You might have already chosen your preferred software development paradigm or project planning method. I hope they are helping you feel empowered and productive.
As a champion and with enthusiasm, express your preference, without attacking what is probably someone else’s job and possibly their preference.
If you ask a counselor what their orientation is, they might tell you CBT, but if you ask them what approach they will take with the next client that walks through their door they will tell you, “It depends.”
In counseling, the orientation that, as a principle, adopts and melds all other orientations is called Technical Eclectic Psychotherapy. The practitioners of this orientation do not align themselves or identify with any specific theory. They take a “right tool for the job” approach, with the “job” being their patient’s mental and emotional health.
In software development, this isn’t very common. Even when we suggest using the “right tool for the job” approach, we tend to stick to what we know. Learning how to use a new set of tools for each project would be a very difficult and time-consuming thing to do.
Counselors have Continuing Education (CE) requirements they have to fulfill to keep their jobs, so even if a counselor’s orientation isn’t Technical Eclectic Psychotherapy, they are still exploring new research and ideas.
A counselor could have a cognitive-behavioral orientation their entire career, but they are required to continue exploring and learning their field.
As mentioned, we software developers have our preferences for how we practice our craft.
There are probably some approaches you are more comfortable with than others. There are likely some you find more exciting than others.
Some might be more difficult to grasp or apply initially, but they help you reach your goal in an elegant way.
However long your current mental list is, I believe this statement can apply to you:
I think having a well stocked toolbox, filled with various languages, frameworks, and paradigms, is a sign of an experienced software crafts(wo)man.
To put it simply, I think there is real value in something like “Continuing Education for Developers,” not only learning in the areas you are comfortable and already heading, but also branching out into new unfamiliar spaces — into areas where you are ever-so-slightly uncomfortable.
My recommendation comes primarily from the position that there is value in gaining perspective.
The more we, as software developers, gain in experience the better equipped we are to tackle the next new problem, and in our profession it seems like we are constantly solving new (to us at least) problems.
These new languages and paradigms can help us look at our own code through new eyes, and can also help us interpret the code of other developers, who themselves might have had a slightly different set of tools.
Things we take for granted (Encapsulation in Object Oriented Programming) can seem strange when looked at through a different paradigm (Functional Programming).
I am, culturally, a Westerner. I learned to eat my food with forks and knives. Why do we use this cutlery when so many others in the world use chopsticks?
You might come to look on your familiar tools with a new appreciation and insight, or you might realize that the world beyond yours is just as complex and interesting.
I think discussion-level familiarity with a number of tools outside the core set we prefer to work with should be our benchmark. Any proficiency beyond this is a bonus.
Having this foundation gives us a more objective perspective on our craft. It also helps us learn to communicate our ideas and concerns in new ways with people who might be looking at the same problem from a different direction.
In counseling, there is no progress without communication.
One might instinctively think I’m referring to what happens between a counselor and their patient during a session in an office somewhere.
This communication is important for the patient to reach goals and solve problems, but what happens between the patient and the people they interact with in their lives outside the counselor’s office is as significant.
As developers, we have to communicate with others on a daily basis.
Maybe it’s through Slack, email, or phone.
Maybe it’s in meetings with our teams, the business, our bosses, clients, customers, or while spending time with our friends and family when we leave the office.
We also communicate through pull requests, code comments, git commit messages, the names we come up with for variables, and documentation we write.
It’s easy to forget this due to how much we spend our time working with displays, keyboards, code editors, debugging tools, web browsers, and consoles.
Take another look at the list above mentioning all the ways we communicate with people each day.
How do you approach them (both the methods of communication and the people themselves)?
I know I do.
A counselor, helping a patient who wishes to improve their communication skills, could ask them to think of someone in their life they view as a skilled communicator and what the patient could do to start moving themselves in that direction.
A counselor could recommend to a patient to be more mindful when communicating with others.
The counselor could also ask them, “What are your goals when communicating?” and if those goals are not being reached, to be flexible and try a different approach.
I have a feeling that we software developers generally think we are only valuable when others come to us for our technical skills. There’s no arguing that these are important skills to have — but I believe it’s also valuable for someone to come to us for our skills in communicating.
Imagine a world where the business stakeholder says:
Wouldn’t that be nice!
Imagine if we didn’t regularly leave meetings drained and pessimistic — feeling we didn’t accomplish our goals or get our point across.
Imagine if all our team members felt happy and fulfilled, and when they didn’t they felt they could come to us first because we, as a profession, are pretty good at communicating.
They make me feel happy and seem like a goal I want to work towards.
While counseling might seem at first glance to be on the other end of the professional spectrum when compared to software development, we have seen there are things they have in common.
In addition to the commonalities, I have pointed out three areas where I believe software developers can learn from the counseling profession.
- Having our own preference does not require bashing others: Our field is large enough to foster many different paradigms, tools, libraries, frameworks, and languages. We can all have our preferences and espouse their benefits without bashing everyone else’s — this is how scientific fields work and thrive.
- Gaining experience by educating ourselves in new areas gains us perspective: While a strict “right tool for the job” approach to software development might be out of reach for most of us, we can still continue to grow our sphere of knowledge — and we should! Learning about languages, paradigms, and frameworks beyond those we use for our daily work brings us the experience of others in our field. It allows us to look at our work and the work of other developers through new eyes and with new insights.
- Communicating is a core part of our work and we should value it: It’s easy to misread the lines of code you write every day for what they really are — a form of communication with not only the computer but also your fellow developers. Our jobs are packed with tasks of communicating. Questioning whether or not we communicate effectively in all the different mediums we use, and growing those skills, is important if we want to become truly skilled software development professionals.
I have a Part 2 planned for this topic where I hope to explore several other parallels between counseling and software development, and the insight we can draw from those connections.
Let me know your thoughts on any of these ideas and if you found this post interesting.
Do you know any good ways to grow your skills into new areas? Do you have recommendations for ways to improve communication in the workplace?
Maybe you have some thoughts on ways we can all professionally promote our passion of software development!
If so, please leave a comment!
And, if you made it all the way here to the end, thanks for reading!