thinking

The infinite arrogance of software developers

Yeah, sorry for the bold title, but sometimes I get tired of software developers expecting they figure out the secrets of the universe. And let’s be honest: at some time in my career, I was one of them. Sometimes by accident, sometimes… not. Anyway.

First, a little disclaimer: this post is not targeted at anyone in special, and I’ll not mention anyone here – just quotes, slightly modified. Anyway, although I love my profession, sometimes it feels like we’re this programmer guy from XKCD:

I'm here to solve it with Algorithms, then six months latter: wow, this problem is really hard (Megan: You don't say?)

There are LOTS of things that bother me at this programmer mentality, so I’ll separate this post into multiple sections. If you’re reading this and feels like it’s a personal attack against you, please don’t – I’m not really attacking anyone, just trying to change a toxic mentality that poisons our abilities to be better professionals, people, and human beings.

“Not a real programmer”

The first one is classic: people define what a “programmer” is, based on their own experiences and expertise, and dismiss people that don’t fall into their categories. Wikipedia, for example, defines Computer Programming as:

Computer programming is the process of designing and building an executable computer program to accomplish a specific computing result or to perform a particular task

As for the “Computer program part”, Wikipedia defines as:

In imperative programming, a computer program is a sequence of instructions in a programming language that a computer can execute or interpret. In declarative programming, a computer program is a set of instructions.

So it’s hard to find a good definition on what programming is, but if we try to merge the two explanations from Wikipedia, we get that, to program a computer, you have to design an executable “sequence of instructions” or “a set of instructions” so that you can accomplish a specific result or perform a particular task.
(more…)

By Maurício Szabo, ago

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.
(more…)

By Maurício Szabo, ago