The setup

Recently I read a tweet about someone pointing to errors they did commit as junior devs, because everyone has been a junior, and everyone has committed errors (even as non-juniors). Which led me to think about a facepalm story of mine (second below). But that facepalm story became one of the tenets of my thinking, so I thought revisiting some of these stories of my junior years, that shaped how I think about programming, seemed like an interesting post. One of them I know I have written a bit about before. But will repeat it just because it lines up so nicely. The first two stories are during my first job ever as programmer. The other two stories are from my third job.

Consequences of tech decisions

At my first job we were creating a control system for a prison, handling some elements like cell doors and intercoms. The way that the system was created was having a multilayered control system software in which there was a central control installation, then each wing will have their own, and there was a third layer for floors on each wing. The floor installation will be able to control only the elements from that floor, the wing will have control over all elements of the floors for that wing, and the central could control everything. All the information was stored on Access DB, but each computer had their own copy, with only the information needed. On a timer (I don’t remember the frequency), the database information will be copied to the upper level (floor to wing, wing to central). The way that all was linked (the hardware elements and the computers) was all done using RS-232. And, well, the system couldn’t handle copying the database while performing operations at the same time. The people that originally created the system decided to, basically, give priority to the DB information transfer when it was time. Which meant that for like 1 or 2 minutes, you would not be able to use any of the elements of the system.

Can you spot the issue? If, for example, one person was having any kind of medical emergency, or being attacked, or whatever else, and just happened that at that time the copying started … then good luck to the prisoner (or the guard). That seemed to me a massive mistake. Ethernet was a thing, why not use that to do any communication between computers, and leave the rs232 cable exclusively for the control?

Maybe, on the (equivalent to) VNQ (DAI) that I did back then, we talked about possible ramifications of our work, don’t remember. But that moment, on my first job, is when I realised that there were, indeed, such consequences to what we do as programmers. Maybe we can close our eyes/ears to that, but it is, nonetheless, a reality of our work.

The recurring error

When you were on a wing, on that system, you could select a floor to actuate upon. Then you would select the cell that you were operating on, a window appeared and showed you what you could do on that cell (lock/unlock the door, talk through the comms, check some sensor, and when you were done you came back to the main screen.

For some reason, every time you came back the first floor would be selected, instead of the floor that you had selected before. It was a small error, wasn’t affecting me that much, but I knew that it was wrong. When I left the company I had not fixed that error.

It was either Chema or Fer who found that, while doing some refactoring, I had written 1 when I was supposed to have written i (not enough facepalms). They implemented a checklist of manual test for regressions, to avoid making the same mistake as I did. It would be a few years before I learned about the glory of automated tests. But that left a mark about testing and regression that I still carry with me. Also, sort names do suck.

Give me speed

On my third job I was modifying/improving two different systems for the same client, a professional body. The first one was the registry of the members of the professional body, and their membership fees. It was created in VB6, and was replacing an existing system that was running on MS-DOS.

Once I had the chance to see the secretaries that were in charge of the whole process using them both, I was basically devastated: using the DOS version of the application they were tabbing away, selecting, writing at such speed that it was a bit difficult for someone that did not know the system to follow up. Meanwhile, in our new system they had to write something, then use the mouse, the select something else. Of course, it was a new system for them, but I knew that it wasn’t only that.

First thing that I did the next day was to revise the tab order in all the screens. I remember thinking as well that the visual order was incorrect, but don’t think I did too much about it because of the following story. There could have been other things that I could have done. It stayed with me the fact that user experience makes such a massive difference. We are creating our software for users, and if the users cannot be effective using the systems we create … we need to change our systems. Nowadays, especially in the web, we can use things like A/B testing to check hypothesis (I remember Cazoo doing that non-stop while I was in there).

Talking to the accountant

The second system I was working on for that professional body was an accounting system. The end of year procedure was not working, the amounts were not matching. I did not understand anything about accounting, so I started going there in the evenings, after my normal hours, when the accountant was going to work, to sit down with him, and try to fix the issue. We were doing that twice a week, for about an hour each time. I think we did fix the issue at the end.

The main procedure was so long that VB6 complained that we had reach the limit for a procedure (just sort of 6k lines). So I created a second procedure that was called from the first one to continue with the process. I was so naive back then to complain how stupid was for VB6 to have that kind of limit. Now I know better.

Now, we can talk about clean code, testing, and some other technical stuff here. But I learned about that later. What become an indelible memory was the fact that I was sitting there, with the person that had the domain knowledge, revising the code, and checking with him all the assumptions that the code (and therefore me) had. Of course, by the time I read Extreme Programming Explained the rule The Customer is always available resonated with me because I had already seen first hand how important it was.