Ljubljana, Slovenia

One programmer is not like the other

I consider myself a problem solver. You might have an image of what a “problem” is in the programming world, but I should be clear - most often than not, the problem is inheriting a project from another programmer, or using one of such projects as a dependency. In the extreme, you realize that you are solving problems created by other programmers and find that you tend to dislike the whole bunch, just because you don’t agree on the definition of problem.

If you’re looking for suggestions how to not have these conflicts - I suggest you don’t even bother. I’m working for a client at the moment, where I have almost no technical contacts and I must use some of their web components. They have an 2 week release cycle for bugfixes to their platform, so best case scenario is that you wait at least 2 weeks for a fix.

If you’re like me, and you think that this client is like any other, you’d hum to yourself “why should I care?” and wait those two weeks. But this client is not like any other - their product is used constantly, bug fixes are high priority, and even when the problem is clearly on their side, they try to find a way to “offload” it to you because you can fix it faster.

Okay, you open those javascripts. You are amazed at the spagetti code you see and you discover a few more bugs along the way. Clearly, one programmer left and a different programmer did some patchwork on the product, because the approach differs so much. Think about the difference of validating the form when an user clicks the submit button, or validating the form as the user types things into fields. Now blend those two approaches together and imagine that ugly step child.

Imagine 250 CSS declerations with !important rules. From MDN: “Using !important is bad practice and should be avoided because it makes debugging more difficult by breaking the natural cascading in your stylesheets.”

Do you know what BEM is? None of that around here. Struggle with high depths of CSS selectors and somehow manage to override those !important rules from the above. It’s also a fine thing (not) that there are several classes which overlap between site and product, like Bootstrap’s .btn, .alert and others.

Fine.

You find a way to fix a bug somebody else caused and doesn’t acknowledge or can’t fix for two weeks. Bypassing all their code in the process - because fixing it as they suggest will create new bugs, meaning you have even more shit on your plate. Phew. Gratitude? No. People are butthurt as you, the servant, how dare you to suggest a “correct” way of fixing the issue.

I was trying to be philosophical at one point, suggesting development practices that would solve their issues - a CSS reset that would keep conflicts to a minimum. A BEM approach to writing their CSS, that would also enable sane styling of their embedded components. A rewrite of a part of code which handles error messages, so that they are provided over a consistent interface, and don’t touch the DOM / presentation logic. The list continues.

But I see that there is no point. Their project is… where it is. Their programmers have moved on, and whatever programmer is still there likes to keep his plate organized much in the same way Microsoft provides upgrades to their browser. Giving them butthurt about best practices is like trying to make a rock cry.

Being a programmer is the cause of so much frustration, and it only becomes apparent when you’re a really good one. If you’re not in a place which values best practices over, let’s say, “it just works”, then chances are that you’ll have a nice hard swim up stream trying to change this mentality. And when you’re working for other people, you’ll just have to accept that you can’t.

While I have you here...

It would be great if you buy one of my books:

I promise you'll learn a lot more if you buy one. Buying a copy supports me writing more about similar topics. Say thank you and buy my books.

Feel free to send me an email if you want to book my time for consultancy/freelance services. I'm great at APIs, Go, Docker, VueJS and scaling services, among many other things.