A couple of days ago I was reading an interview with Kate Swaffer, a very popular blogger who suffers dementia (you can check her blog here, it’s really good!). That interview led me to think about a number of things we left aside in our daily work that could push people away from it, or make an approach really hard. Sometimes we choose to do that and sometimes we’re just ignorant.

Sometimes our website is not well prepared for screen readers, or is not crossbrowser. Maybe our CSS doesn’t have line-breaks, or our Javascript is minified without leaving the source at hand. We may often prefer using our time to write more code instead of documenting what we already have. Perhaps we use a very technical language in our blog posts without a real need to do it. The admin of a community site may take decisions that favor a minority of users above others. I myself, being a native Spanish speaker, write most of my posts in English, maybe leaving behind some potential readers. There’s a ton of things we can do to push people away.

But we sure can’t contempt everyone, right? Doing that would be like an impossible dream. People is different from each other, and that’s what makes the world keep running, for right or wrong. But I do think we can know our public, or at least we can try to do it. And I also think the same can be applied to programmers, because the fact that our work is not so evident for the final users doesn’t mean that we don’t need to be accesible for each other.

Code Problems

Let’s suppose you’re an accomplished programmer, with a lot of experience in your area, and you recently begun working in a team where your partners have a lot less experience than you. They still have to follow a lot of best practices, respect coding guidelines, learn about programming patterns and write thousands of lines of documentation. Now let’s suppose you wrote some sort of API they must use to have their work done. The problem is, after a prudential time, they don’t have it done. They don’t even seem to understand what you did with your code, the internal logic of it, or even how your classes and methods should work. You act surprised, because there’s the documentation in your issue tracker, and the internal docs on the code – any accomplished programmer would understand how to use it. But they are not (at least yet) accomplished programmers. Could you blame them for that?

Now you’re at a moment when you’re presented with a list of options on what to do about this. You may cast the blame on them, accusing them to be a bunch of incapable kids, and declaring that you already did all you have to do. You may try to teach them, guide them to become better programmers, knowing the progress will take time. You may review your code and go down a couple of steps, so you have a version not so optimized, but more reachable for their level of knowledge. Or you may quit.

What Can Be Done

If you’re somewhat close to wise, you won’t go for the first option. Incapable people end up being fired in software development more often than not, and sometimes good developers are hard to get, because they’re already busy working somewhere else. But the younger still have the possibility to become really good in the future, so it’s not convenient to baffle them just because they already don’t know how to do something.

Of course you can quit if that’s OK with you. It’s totally understandable if you prefer to work with people close to your same level of expertise and you don’t have the patience to teach.

Teaching is hard, but most of the times a rewarding task. You may take the time to talk with your partners about the dos and donts, and they will sure improve a lot after that, but you know it’ll take time, and time is something that, in many occasions, businesses can’t afford. Sometimes your boss will prefer something done over something done well. If it works, that’s enough, and he won’t want to have you losing your time by trying to create the perfect piece of code.

If that happens, your former code may remain unuseful (and unused) for who knows how much time, and the other not-so-experienced programmers, given the fact that they don’t know how to use it, will need to find their way around the problem, maybe creating new solutions for something you already solved, but not so effective as yours. They will end up losing time however, and the boss will complain because he can’t understand what is taking so much time.

But there’s still something you can do. You can step down your expertise a little and rewrite some of your code to make it more approachable for people with less experience on the practices you’re following. If you’re going full OOP, and your partners are more experienced in procedural programming, in case the environment allows it, such as WordPress does, you can switch some of your code to procedural, and viceversa. Maybe the MVC pattern is a far notion to them, so you may strip your controllers in libraries of procedural functions. You’ll find a lot of cases on your own where you can replace a type of practice with another, and I don’t want to go very technical here.

Final Thoughts

Some people may see the last approach as recommending bad practices, or limiting the practice of developers’ habilites. I would understand that, but I think it’s not that simple. Instead, I think that, as the writer should know his public and how to communicate his ideas to them, the programmer should know the people who’s working with him, the closer the better, and their possibilities to understand given pieces of code. This is a part of the whole accessibility thing, because code should be accessible too.

That’s one of the reasons of the success of WordPress: The majority of its code is readable and easy to understand even for developers with few experience. It’s not that you should write dumb and limited code. Instead, you must write awesomely accesible code, smart enough to be efficient and simple enough to be accessible for the people who’s gonna work with it.

And here’s the real catch about all of this: It doesn’t matter how much experience you have and how well you think you write code, because the fact of your code not being accessible for the people who’s gonna work with it, even if they don’t know as much as you, proves your code isn’t really good, and it needs to be improved.

Some people constantly try to be understood by the others, even if they are good at what they do, because that makes them better. Other people can just live with the belief of being good and blaming who doesn’t understand them. And there resides the difference between the efficient person and the pretentious fool.