Comment by trevor-e
9 months ago
I cringe thinking about PR comments I left early in my career.
"akshually this should try to follow more SOLID principles"
But, coming from a formal engineering background, I thought this is what it meant to be a professional software engineer. Little did I know these "principles" were just the musings of a consultant lol. Turns out most folks have good intentions and want a standardized way to write code, but for some reason it always results in code that looks like the Enterprise FizzBuzz meme repo.
For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems.
I wonder if that's because in a lot of cases (depending on the domain) the space of possible valid/working solutions is near infinite, and if you don't have hard requirements that are backed up by measurements you're free to concieve of any valid system structure and justify it as 'better' without that ever being something that can be observed and measured.
> For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems.
The secondary problem is that book authors have become extremely good at inventing pseudo-evidence to support their claims. It most commonly takes the form of “I talked to X companies with Y total number of employees over Z years and therefore I know what works best”.
If you cut out all of the grandstanding, it’s nothing more than “just trust me” but in a world of social proof it sounds like it’s undeniable.
> a world of social proof
Which results in the idea of 'good practice', 'best practice' and 'bad practice', and nobody wants to be seen as the person doing things that are considered bad practice, because that would imply that you're a bad developer.
And I almost always hesitate to use the term 'engineer' because as far as I know engineering is considered to be a practice/process that uses measurements and results to drive decision-making, unlike various areas in software. Can you imagine if the same kind of thinking was applied in civil engineering? "This new material has a lot of stars on GitHub and everyone is saying the old materials are bad practice."*
* Which is a thing of course (see: Asbestos) but only in the places with measurable observable outputs.
1 reply →
Yet we have the evidence out there. The only problem is that it is just the negatives — it tells you what to avoid and not what you should do.
Other than with civil engineering where each bridge failure will be studied by the whole community, in programming most people shrug it off as "software error there is nothing we can do" and move on.
If we truly want to progress in terms of code quality we need to anchor our guiding principles in the lessons learned from failed projects and check all new positive principles against those.
The mark of a good engineer is knowing when this sort of handwaving is actually meaningful and helpful. Formality for its own sake is anti-pattern, but who am I telling?