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

Products

Technology Providers & OEMs Technology Providers & OEMs

TDG rapidly generates accurate budgetary proposals to help suppliers bid more, win more, and sell more.

Asset Owners and Utilities Asset Owners and Utilities

TDG streamlines the capital planning and conceptual design processes to accelerate project timelines and deliver better outcomes.

EPCs, AECs, and Consultants EPCs, AECs, and Consultants

TDG enables engineering firms to deliver more value to their clients & increase competitiveness.

Individuals Individuals

TDG works for individual engineers who want to grow their business and reduce their non-billable time.

Solutions Solutions

Take a peak behind the curtain to learn how TDG works.

Academic Academic

Transcend supports students and professors around the world to incorporate TDG into their curriculum.

Resources

Articles Articles

Read posts written by Transcend team members sharing their points of view on the company mission, vision, and products.

Webinars Webinars

Watch on-demand webinars like Transcend’s popular ‘How To’ series.

E-books E-books

Learn about Transcend software with short informational e-books.

Case studies Case studies

Understand how Transcend’s customers are utilizing TDG to bring more value to their customers and grow their businesses.

FAQ FAQ

View a list of the questions we are most frequently asked about our company and our software

Transcend tools Transcend tools

Access a number of tools Transcend has developed to help engineers and industry professionals take back their time.