Early in my career I had this illusion that working only with senior devs would make everything better. But the first time this happened was not what I had expected. Every single bit of grunt work was engineered away. In theory that sounds like it might be nice, but rather than write a little repetitive but clear code, everything got a processor or an engine or something, and with some generic computer science name instead of using nouns and verbs from the domain. To figure out what a piece of code did, even generically, you had to decipher it to know what.
All of the code did something but none of the code said anything. It was horrible.
I very quickly embraced the notion that software wants a mix of developers of different skill levels, so that any task that must be done can find an author who will remain engaged, and not have to create baroque code to get themselves to do the work.
We already have to deal with this in current state of Class Oriented Programming. Every class does something, none of them say anything about how the program work at run-time as a whole. So bad naming (cleverly bad) just adds on so much trouble in. Good naming from the domain helps, but it can not carry the program that far since it only addresses things at low level. At the architecture level, the class hierarchy still in control.
e.g. http://www.cs.unc.edu/~stotts/GOF/hires/chap1fso.htm
"An object-oriented program's run-time structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program's run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa."
Someone I read about code maintenance and/or quality years ago asserted that if the code uses different concepts than the domain the software is designed for, then you have intentionally built an impedance mismatch into your project and you're gonna have a bad time.
I haven't read enough about DDD to know if he was just a precursor or onto something else, but it does seem to map well to my least comfortable work situations.
This reminds me of a chapter from Clean Code by Robert C. Martin where he suggests using names from the "solution domain space" ie. CS terminology, because names are succinct and more precise which is preferred over long names that are tied to some specific domain for which the software is being developed for, which might require expertise that is disparate. The author suggests to use terminology from the "problem domain space" when "there is no 'programmer-eese'" name for it.
My team had a discussion about this and some argued that this might alienate programmers who are novices, and might be easier to use "Enlgish" but I think that if the problem space for your software is niche enough then a new team member, or a novice will have to learn terminology either way. In my opinion, programming terminologies are more precise and transferable to other programming jobs and problems in general, so is a more sustainable and relevant way of learning. It might be tough at first, and I agree the attitude of the senior dev would make a huge difference, but as long as the senior dev takes the initial confusion of the novice as a good teaching moment, and explains it patiently and clearly I think it can be more valuable in the long term.
It's entirely possible that the anecdote I mentioned in a sibling reply is just an early Uncle Bob comment from ages ago.
The Pattern Language approach to code didn't have to turn into naming everything after patterns (and then arguing endlessly about the ones that are ambiguously differentiated). It could have just been a field guide to spotting them. I recall reading a few good papers about how 75% of that book is just idiomatic functional programming code. I am blissfully unaware of anyone in the FP space getting suckered into actually naming anything after the official names.
I attended a workshop a couple years back, run by a person who was 1 degree of separation away from the Gang Of Four and he asserted that book was a Masters or PhD thesis for the youngest author and the other people were essentially editors. This was all news to me. I suspect if I had known this I would have pushed back a lot sooner, instead of getting sucked in too. A decade of OOAD ruined by someone's college project...
While the GoF book has perhaps not aged well and led to a lot of misguided ideas, it also did something that was a good idea and could have been developed further: a common nomenclature for things we’d all seen and needed to be able to describe to peers. To my thinking, the reuse of patterns to solve specific problems is along the path to turning programming into a discipline of software engineering
I told my last mentee to “read ‘Refactoring’ twice instead”.
GoF tells you What. ‘Refactoring’ tells you Why, and gives some pointers on How. In any field, if you know the why and the how of something, and the what doesn’t work itself out? Then you’re in the wrong field.
(He’s gotten promoted twice since we parted ways. He’ll be just fine.)
As someone that has been building software for nearly 20 years, this is my number one priority - making it simple for the next developer to understand.
It annoys me when I have to do some hackerrank crap as an interview, as it's nothing like how I work - having a hard time limit to come up with some algorithm. Or some question about what Python will do if you write it in an obscure and horrible way. I write far better code than I did fresh out of universty, but I am a lot slower at that sort of stuff as I make a point of avoiding it in my work.
The "hackerrank crap" gets into my head too. It's part of why I've been procrastinating on looking for a new job. I need to sort myself out.
Instead of solving the problem, a corner of my brain is thinking "all I want to know right now is: is there a greater than 0 chance that this sort of code appears in a PR and if so, we are done."
All of the code did something but none of the code said anything. It was horrible.
I very quickly embraced the notion that software wants a mix of developers of different skill levels, so that any task that must be done can find an author who will remain engaged, and not have to create baroque code to get themselves to do the work.