While I've graduated in business administration, I had considered computer science.
But at the time, I believed that programmers were creatures that were basically alienated from the world, working in cold, dark rooms looking at the screen all day, every day.
Not that I was (totally) wrong, but I felt it was too much of a fit for me. (Yes, I know how weird it sounds...)
One thing I take to me from university is the mindset. And from that... basically empathy:
I’m sure you encounter multiple times something that makes you question the developers’ sanity:
What the hell were they thinking?
Being a developer myself, I can empathize and know that, maybe, they are trying their best and maybe they are just not aware of the flaws in their “babies”, sometimes they thought they were aiming for someone else.
The problem arises when we start talking about big players that have entire departments and pipelines and even passing through a lot of people... you still have something bizarre at the end.
I’m not gonna give names, but that’s because when I had the idea for this post I forgot to annotate to whom I was mad. But I was mad because it was software aimed at a specific group of people, or at least it should be, except it sure didn’t feel like that.
But let's give you an example: let’s say you want an app for runners to take notes... you would probably expect it to have speech-to-text capabilities, but instead, they go with a bigger keyboard and some strong spell check and corrector. This is an awful example, but it was something like that.
So you, as an outsider, can see what they need.
Sometimes the client will actually think they want the bigger keyboard with the spell checking... and then you have to say NO. You have to argue and convince them that they are wrong and that they need the speech-to-text.
I see too many people that are too good for their own good.
They will listen to what the client says he wants with a “yes man” mentality, they will already start doing it, and then end up with something really complex and cool, that simply moves the problem from one place to another, but does nothing to actually solve it.
Try to know who is the client, what is his workflow, and where, whatever you’re doing, would fit.
Check the competition (and even other things) and ask the client: why not use this?
Try to find the root of the problem and act on it.
The last tip is to have a total, unbiased view of the problem.
Companies are hasty to ignore candidates that have no experience with their product, after all, why hire someone that doesn’t even use it, right?
And there lies a big mistake because someone new to the product will make the right questions and have the power to influence the product in a way that benefits everyone.
Learning about the product will be easy, and if it’s not, then it’s one place where it can improve, with the help of a beginner.
So, go out of your way and look up to those to be your colleagues.
Or at least, find beginners to give feedback about the tools.
And it should go without saying... LISTEN to them, even if with a grain of salt.