I read this post yesterday, Are software engineering “best practices” just developer preferences? and immediately shared it with my work colleagues and made a note for myself to write about it.

Software Engineering is really frustrating because there’s basically never a “right” answer and so most decisions come down to “whatever the senior engineer wants.” This is probably why people feel imposter syndrome so much in coding: You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.”

I have often struggled with the best way of organising the code I write. Almost everyone who creates web applications agreed on the MVC way of managing their code, but anything after that was always “it depends”.

Every project I have worked on in the last fifteen years has been different—different ways of organising code. Although I disagreed with some of the ways the code was written before me, I continued to work with it and make incremental changes so that it was easier to find methods/interfaces when it was my time to debug.

Who’s right here? Who knows! The app works either way, and it’s still maintainable just a little more annoying (imo).

When I joined the current company, I was introduced to Design Patterns again. I had not looked at Software Design Patterns in the last ten plus years. I had worked on smaller projects before. Not a lot of code, so simple MVC with few standard interfaces worked well.

There was a lot to learn as I read parts of the book. I did not have to pay attention to all the patterns. Colleagues in this company followed two design patterns. So I had to learn and get better at organising/writing code this way.

The job after this will be different. The code organised there would be based on the first few developers who worked on the software. Developers who made the decision that “this” was the best way of organising code.

Are software engineering “best practices” just developer preferences?