Software Engineers look for best patterns, best algorithms to apply in their work to optimize the app as much as they can, while Designers look for emotions of their clients so they need greater empathy on their part.
The nature of our work says that we differ at greater lengths, but that doesn’t mean we can’t synthesize our behaviors together. For example, I believe Software Engineers can apply empathy to formulate better algorithms and implementations in engineering an App or Software, while Designers can also look for best algorithms that can make their design more creative and intuitive. It all takes the willingness to synthesize our discipline.
With that in mind, these disciplines are what I believe that we can learn and apply as Software Engineers coming from a Designer’s perspective:
Emphasizing empathy in what they do
Designers emphasize empathy because it’s needed to come up with creative ideas and design what they can come up with. In dealing with clients, designers have to be empathic in communicating with them to draw out creativity based on their requirements and themes.
I’m not saying Software Engineers don’t have empathy. We do have, but it’s not obvious in what we do as we’re only concerned with technical implementations that suit best on the app we’re working on. This is quite hard to determine and use especially that the nature of our work don’t actually need empathy.
So, how do we apply empathy in our work? One suggestion I could give for Software Engineers is to be more thoughtful of implementations we need to consider such as appropriate design patterns and thinking of maintainability as one of the core importance when starting a feature or projects. In this way, we make sure that everything is easily maintainable the moment we get back into old features when some of it introduces bugs and refactor them as much as we can.
With empathy in the way we design our code and our projects, we think of future Software Engineers who will hop aboard in the project so that they understand what folders to look for, understand how the code works the first time they hop aboard the project, and what appropriate design patterns to apply when they add new features since we empathize what was it like to get started with the app with little to no knowledge on how it works. This way, we decrease the friction and possibility of introducing new bugs as this is so common in Software Development as we go ahead and build things.
Gaining clarity of goals and expectations
Some Software Engineers (including me, sometimes) tend to jump right off the bat and start coding without gaining clarity of goals and expectations of the particular feature or task we’re working on. Because, we just care about implementing better algorithms, applying new “syntactic sugars” we’ve learned when self-learning, and just focus on engineering better app with better performance overall. I get in this habit of jumping into coding as I am only concerned with coding. But we need to get this out of our habit and practice better communication, gaining clarity of the features and tasks we’re working on.
This is different when you’re a designer: You always ask clients for clarity because it’s hard to create something from scratch without having to know the look and feel of the design you’re working on. It’s harder to draw conclusions of what design feels right and great for the clients.
Either way, it ’s definitely applicable to us Software Engineers. This makes our work more intentional and fast since we gain clarity of what we’re doing. This also makes us better Software Engineers in general than the majority who doesn’t practice gaining clarity of what they’re doing.
Conceptualizing first before solutions
Designers often conceptualize and starts with ideas first before suggesting solutions to their clients. This can be helpful to determine to see if what works and what doesn’t work.
I think we can apply the same as Software Engineers by conceptualizing tech stacks that suit the project or specific features. Which patterns suit our use-case? Which tech stacks suit our current project?
It’s better to conceptualize first than jumping right off ahead and go with what you’ve learned. Of course, the experience is valuable. But sometimes we need to see each project into a fresh perspective so that we avoid biases.
As what the designer David Airey says in his book “Work For Money, Design For Love”:
Don’t blindly trust your experience
Details, Details, Details!
You will see designers who create a style guide with a detailed explanation of its UI styles/UI kits and when to use that particular style. This should also be present in Software Engineers. Paying attention to details also allows you to become a great Software Engineer than the rest.
How to apply this discipline from Designers? Here are my suggestions:
Applying detailed comments
To apply this discipline, Software Engineers can choose to document some parts of the source code that needs documentation and a few details. For example, what does that particular helper class does and when do developers use the function.
But, too many comments doesn’t help you produce better code maintainability. So only use it when appropriate.
Functions/methods should be as verbose as possible
Another approach is to make sure your source code is readable and verbose that newcomers can understand what it does without too much thinking on their part. Doing it this way, we can detail our code so that our future selves and future Developers will be thankful for.
This is very appropriate when you’re working with API documentation/API designs since you need to elaborate and detail its functionalities per se.
We should not limit ourselves in adapting our own discipline as Software Engineers. Sometimes, great things happen when we learn to apply the discipline we learned from other people with different professions. And it’s magical if we can apply what Designers are doing to produce great work in Software Engineering.
Thinking from a “Designer” perspective gives life in your daily coding, gives motivation, and allows you to think creatively as an Engineer while seeing things at a different perspective.