Bridging the Gap
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!
Patterns and Practices
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.
How do you tend to see solutions to the problems you are tasked with each day?
Do you lean towards imperative instructions and objected-oriented abstractions or declarative and functional approaches?
Which best practices and principles does your mind jump to first when you are coding? SOLID or DRY or KISS? Can you achieve all simultaneously, or are they in some ways mutually exclusive?
What about when you are working with a team or client? Scrum, Event Storming, Chaos Strategy?
What do the solutions to your problems look like — are they technical or social in nature?
With this foundation, let’s begin to ask the question “What Can Counseling Teach Software Developers?”
1. We All Have Our Preferred Approach
Orientation == Paradigm
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.
Practitioners of CBT often use cognitive restructuring in the same way that developers accustomed to Object Oriented programming might use static analysis and cyclomatic complexity measurement tools.
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.
There is a healthy professional discussion about the efficacy and application of each of these orientations for both counselors and patients.
We Should Be Professionals
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.
But just because your preferences are working for you doesn’t mean that they are right and all others are wrong.
As a champion and with enthusiasm, express your preference, without attacking what is probably someone else’s job and possibly their preference.
2. Keep Your Toolbox Well Stocked
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.”
Sound familiar?
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.
But, that doesn’t mean there isn’t value in expanding our horizons!
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.
Preference
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.
Think of all the tools you use to accomplish your tasks and deliver a quality product you are proud of.
However long your current mental list is, I believe this statement can apply to you:
It’s important to have many tools in our toolbox.
I think having a well stocked toolbox, filled with various languages, frameworks, and paradigms, is a sign of an experienced software crafts(wo)man.
This doesn’t mean you need to learn every new JavaScript library or write all your applications in functional languages, and it also doesn’t mean you need to be a polyglot programmer.
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.
Perspective
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.
Learning new programming languages or paradigms is also gaining experience — the experience of those who came before us.
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.
3. It’s All About Communication
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.
The Means of Communication
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.
Our work is so very dependent on communicating with other people.
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)?
Do you ever forget that your keystrokes or frustrated remarks are being read and heard, not by machines, but by others, whose job is also to communicate effectively with you?
I know I do.
Improving Communication
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.
Is there someone in your life you feel is good at communicating with others? Is there something you appreciate that they do when communicating with you?
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:
“I look forward to meeting with the development team — they are the ones with the skills to solve these tough technical problems, they are great listeners, and communicate their thoughts and ideas so well!”
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.
How do these thoughts make you feel?
Do you feel they are realistic? If not, why?
They make me feel happy and seem like a goal I want to work towards.
Let’s Review
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!
Looking to grow your software development toolbox? Are you a JavaScript dev wanting to learn about .NET and C#? Checkout my post below for a great introduction.
.NET, C#, and ASP.NET for Javascript developers: Part 1, The Ecosystem
Top comments (0)