What my digital design project tought me about engineering

This last semster, I completed my digital design course at university, one of the most interesting, mind-blowing, courses I took since starting my bachelor degree. At the end of the semester, we had to implement a simple project using Verilog and implement it using an FPGA. In this blog, I aim to outline some reflections and things I learnt while building the project.

The project, briefly.

We were asked to implement a finite state machine for a traffic light system. The system included three traffic lights that had to run in a continuous cycle. In addition, there was a pedestrian button that, when pressed, shouldn’t immediately change the lights, but instead wait until the currently active traffic light reaches red. Only then would the pedestrian signal turn green. Afterwards, the next traffic light in the sequence (the one that should’ve been on before the button was pressed) resumes as expected. We (me and my project partner) decided, for many reasons, to use minimal LLM tools while working on the project.

CLEAN code

Clean code refers to different concepts in software engineering, but here, I mean CLEAN code: consistent naming, consistent break lines between code logic, consistent indentation, etc. To be completely honest, I am not a perfectionist when it comes to writing code. I could spell variables wrong and call it a day, maybe have some inconsistency in indentations, and yeah, who really cares how many empty lines I have between each separate logic of my code?

However, my partner was the exact opposite of me. She cared about everything I did not care about, and actually, it was nice. It was nice to complement each other in this way. I wrote the code quickly, tested it, and handed it over to her to make it CLEAN. At the end of the project, we did not only have working code, but also code that is very elegant. As I mentioned before, I am not that person who cares about these small details, but this experience showed me how important it is to put more effort into them.

Intuition, and making sense of every line of code

I love software engineering for so many reasons, and one of them is how malleable software is. It is nothing like actual engineering: you can't decide to change the design of a bridge during construction, and you cannot really decide to "experiment" with different designs and then CTRL+Z to go back to your original one. But this is not true in software engineering or programming in general. While it is not always efficient to do that, it is part of the beauty of software engineering.

However, a lot of experimentation without actually making sense of what you are trying to test can easily become like rolling a dice. Many times, I follow my intuition — I experiment, see the result, and if something goes drastically wrong, I simply CTRL+Z and try to think again.

My partner, however, did not seem to believe in this approach. She made sure we understand what we are intending to implement before actually implementing it. And to be honest, her approach may be more aligned with what “engineering” actually is, so it adds up to the list of things this project taught me. Although my intuition ended up being right, her dedication to understanding what my intuition told me definitely made the project easier to finish.

Building with a partner

I think this is the first time I really got to work with a partner on a project that involves coding and building. I think this is a crucial thing to learn: how to think as partners. It is not enough to have equal distribution of work, and it is not enough to work separately on different parts of the project and merge them together. I think this is also a crucial part of being a good engineer: to know how to think with the other person and actually collaborate. You need to discuss ideas, point out different caveats in the other person’s suggestions and in your suggestions, and try to find a middle ground between your style of working and their own style.