To be wrong, even when you’re not

There’s a time when we must assume that we are wrong – even when we are doing the right thing. At my last job, I realized that it was happening with me.

After Nubank, I began to work on a company that, in a way, was a bet in my career – most of the systems in this new company were written in C# (a language that I had never written a single line), there was a huge codebase without a single line of test, the systems did not run on the developer’s machines, and one of the reasons that I was interested in working with then was to organize this codebase, in Clojure, with microservices. Also, to coach the development team, so we would migrate away from monolithic systems to a better architecture, with tests, microservices, and multiple programming languages.

In other words, to apply what I learned at Nubank in this company.

It was a long journey, first to be able to make the code, at least partially, compile on my Linux machine (the default configuration of our development machines was Windows with Visual Studio). And no, there wasn’t simply a matter of swimming against the flow that made me want to work on Linux: it was simply because the mandatory configuration of our Windows workstations was a very slow machine with a very slow antivirus and monitoring systems (to see if anyone was installing pirate software). Also, we had no access to USB, could not download external software, and our antivirus sometimes identified our git blobs as “suspicious software”, effectively corrupting our code every git commit. My machine booted in 10 minutes, and I had to wait another 20 for Visual Studio to be responding (and I’m not faking these numbers).

Then, the migration to Clojure. It wasn’t really that difficult to write the code. The problem was to publish it – the company did not want to use docker, nor containers, nor continuous integration/delivery. We migrated our code from TFS to Bitbucket to GitLab, then to a self hosted GitLab, then back to Bitbucket. Also, we had to fight – a lot – to be able to access our Q/A docker environment, as we had no access to production, staging, or homologation environments. We caught lots of bugs only in production, because we simply had no idea on how the calls for external APIs worked (there was not a single mocked/stubbed external system, and the very few external services that did offer sandboxed environments were so misconfigured that even API versions were different).

Then, after a long fight, more than a year later, we lost.

New systems were being developed with docker, but without tests (based on the wrong assumption that it slows down development). All tests were manual, in the production environment, and the Q/A machine that we fought so hard to have was simply not used (so much that I had to write a script to silence loggers, because there were lots of systems that did not work, throwing an exception and logging it on our logging management systems). We had horrible regression bugs, but people simply didn’t care.

The last weeks at my job I was trying to organize some acceptance tests in our Q/A, mocking external APIs, but a few days before my final day on the company I realized that I was the only one suffering from the lack of tests. All other developers were simply producing new code, putting it in production, and checking if things were working or not at that moment, not caring if it would break old code. Every hard-coded line that I removed was either ignored by other people, of re-hard-coded again in a new commit (sometimes bypassing code review entirely). My boss asked me “why I wasn’t fixing bugs”, and after other episodes where I simply lost my patience (I’m not someone that is known for this behavior), I had to assume that I was making a fool of myself.

That whole year taught me a very important experience that I think it’s better Illustrated with an example: for me it’s unacceptable to put a single line of code that I don’t know what it does. This means that I need to test it, I need to be able to run it on my machine and to integrate on a Q/A environment. The simple idea of pushing code to production before any of these steps is completely alien to me.

But it was not for the company that I was working. In fact, for they my practices were as strange or even worse than what I felt about theirs, or even just a waste of time. For example, when a feature changed, the first thing I did was to change my integration test, and then my unit tests drove me to what I needed to change in the code. For they, it was just a matter of changing the code to the new behavior, and if the code had tests then fix every test that breaks, even if the assertions did not make sense, sometimes to the point of deleting the whole test and re-writing it – so, in their view, tests were just things that get in the way.

And I know that my way of working was not wrong. In fact, I probably don’t need to work overtime and can give a certain level of confidence in all my deliveries because of my practices. Yet, in my previous context, I was wrong – I could not force anyone to work with tests; I could not discuss best practices because our views are not the same; and every time I tried, I just stressed myself, lost time, and wasn’t able to get my message across. The arguments that I used – less regression bugs, more confidence, less overtime – these weren’t that hard to solve in their view, so that it would justify changing paradigms.

So, I left the company. I learned a huge lesson, one that I probably wouldn’t otherwise, considering that every company that I left was for something better, more structured, with better practices. I think what we created in that company were one of the most beautiful systems created by scratch, but every single developer, leader, director and coach that worked on project have left the company, so probably this will become legacy in no time. I would love to keep working on it, but it’s time to go.

Also, in my whole professional life, in every single company, I’ve met people that were not satisfied with the chaos that they worked with. For they, I say: please, look away for alternatives. I’ve seen many friends ignoring other languages, other practices, other editors because they felt that “it slows down their code writing”. Don’t fall into this trap – the world isn’t black or white, and most times we need time to really be productive when we change paradigms.

And I can assure you, you won’t regret it.