How to code like a wastewater treatment plant

The coding process has a lot of parts we tend to forget, like documentation, testing, or even the most administrative parts, the worklog. But if you look at coding from a different perspective, you can make your coding process, but in reality, any type of work process much more in line.

I would lie, if I tell you, that I’m an expert in wastewater. I started to work at Transcend some months ago, and although I did my homework, I’m still having issues with a lot of technological details. But I saw enough, to tell you, that like almost every pipeline, it can be viewed in a standard way.

You have the flow… water, that generally comes in from a city, and in the end, you need to provide a much cleaner water into a river. Your job is the same, as a coder: you have the data flow in from documentations, product people, or in a sample way, the task and the acceptance criteria, and you have to provide a clear result into the master branch.

In the sewage plant, you will probably see some kind of pool at first. A place, where the water just goes through slowly, usually zigzagging around walls, and it let any kind of large heavy things to settle down. This is the grooming part of any development, where we can discuss the detailed situation about the requirements, add our most important notes from the developers, and remove anything, that’s unclear, or not really a development requirement. You need time for this, so does the water to let it settle, and you need to look it from a lot of directions, like the zigzagging water.

The next step is the primary clarifier, that has a lot of different methods, but the goal is simple: remove as much organic matter, as the water has. This is where you code, where you do the job, where you can do the programming the best you can. I think this is the most straightforward part of the whole process. You could say the little cells that usually do the job of breaking down organic matter into smaller parts are you, breaking down the requirements into bits.

In the water world, you probably will se an aeration tank after this. A much less moving part, with a lot of air literally scouring through the pool. You also need air, a little breathing room after this huge amount of work. This is where you leave your code, probably push it up for a pull request, and deploy for a testing environment, run integration tests, and in the best-case scenario do this automatically within a pipeline. When you next come back to work, you will have a lot more extra energy, possible feedback from others and much more oxygen dissolved in the water.

Then comes the secondary clarification, which is the recurring cleanup: you fix the bugs, adjust your code to the recommendations, and do the aeration part again, while waiting for the next iteration. And you do this again and again, until your code is passing the requirements, and able to go through the very limited filter, to be on the road to production. If the description is clear, and you removed most of the grit before, your job is easier, you have less iterations.

I missed a very important part: the worklog. In every part of the previous steps, there is a lot of organic waste, that is removed from the water. This is the sign of you doing jour job. All of this waste is coming together, and in the end, it can be used for later clarification – like the experience you get, that makes your job easier next time – but most importantly, it gathers up in one place, and you need to remove it from the plant. This is your worklog: after every step, you need to remove the waste, and you need to log your work, to keep the whole process clean and clear. The more waste you leave in your plant, the more it will pile up, and will make the whole system disastrous.

Thankfully, you can use the waste also to generate energy as biomass, so think about your worklog as additional fuel: it motivates you, by looking at the charts going down, reaching goals, and be part of an amazing project – hopefully.

To finish up the process, you need disinfection, to make it finally approved. This is the final test on a staging environment, before going to production, and somebody from the product giving you the go.

Do you also see the similarities between the two process? If you do, I hope this was helpful, and provides you another way of thinking about the usually boring things like grooming, testing and logging your work.

Gábor Kovács – Software Engineer Team Lead at Transcend