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
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.
Imagine 250 CSS declerations with !important rules. From MDN:
!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
.alert and others.
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:
- Go with Databases
- Advent of Go Microservices
- API Foundations in Go
- 12 Factor Apps with Docker and Go
Want to stay up to date with new posts?