Then the non-pros never have the opportunity to learn from the pros and the pros never get a break which leads to employee morale and retention issues + tacit knowledge loss.
Pros get burnt out being constantly called on to crank out new features under pressure and never get to leverage their deep understanding in the maintenance phase.
Non-pros have no upward mobility (career progression) and get burnt out struggling to understand and maintain unfamiliar code without any guidance.
I've experienced a different situation where I was one of two pros – pillar may be more appropriate – in a team of around 15 devs – and wasn't recognized as such. I was working 70h/week on average (I never was paid for those overtime hours and my actual hourly wage was under the minimal wage), taking in charge every and any issue that may pop up, I was a reference when it came to knowing how our system worked and people would come ask me questions about the inner working of some part even when they had designed it ! I left disgruntled, and the other piller followed course because I wasn't here anymore to buffer the conflict he had with the CTO. In spite of the new hire and organizational restructuration to fill the gap, what should have taken 2 weeks to implement (a few hours to a few day in the redesign I had reimplemented at home in the weekend following my departure), took them 6 months. They had to distribute overtime hours to every dev, and in the end I received a call from the guy in charge of HR who told me the company was considering rehiring me at the condition I should behave ! Dude was fired eventually and replaced by a manager from the holding company.
As for pros needing training by other pros, I think it's more a question of culture. Once I was tasked with adapting a microservice to also run as a library, the challenge being we used JSON fields and now also had to store them in a mysql database that did not support them natively. I wrote an adapter that could have been released as a separate library because it was that generic, it took me 1 day of work, a 15 files long PR. But because it used a postwalk traversal on tiny json data triggered lazily upon accessing the specific field, cached in the ORM object for repeated access, it smelt funny to the CTO who proceeded to ditch my work away, spend the 3 following days adapting 350 files to try to get a highly specific solution then gave up, and decided in the end we'll have two separate versions of that system, in concurrent use, one as a lib and one as a microservice, hence multiplying by two the time it took to do changes to that highly repetitive codebase because "it was simpler that way".
You don't need to train pros, they have been training on their own since they are twelve.
Reasonable argument, I like it, however would add a bit of salt:
I've seen several times so far that people maintaining things are actually doing a much better job, while those who were granted honor of doing a new thing because hey they are "pros". And once they did the prototype, they are _considered_ even more "pros", because hey, they wrote it. The people who rethought and rewrote the thing later were real makers, but didn't get the appreciation of "pros".
The worst thing is that "pros" status keeps working for itself, even while delivering worse job. I wouldn't have a problem if the system could fix itself over time.
I've been on both sides of this fence. As a maintainer, you have all the time in the world to understand the system, as it is, and improve it. You have the benefits of hindsight.
As a producer of the mvp, a lot of times there is 'exploratory code' where you're not actually sure how it will work yet; or scale. So you bang out a few approaches and pick the best one for the constraints you have. And basically never touch it again.
In one case, I was working on the mvp and the team who would be maintaining it where the one's doing code review. The code turned out way better than either of us would have come up alone. It ended up being one of the coolest projects in the company and some internal secret-sauce for making money. For example, I remember one code review where they asked to add a configurable callback in. I was like 'why?' and they answered, "we're already being asked if it can do X, if you add a callback here, here and here, we can already start building that feature so you can focus on the core."
Yes, but when a "pro" takes too long to deliver something, then that thing is considered hard, because even the "pro" cannot make it quickly.
Re. scaling -- probably, agree, just I never seen myself (working in distributed systems). On my personal experience it was always more-less clear, depending on what software/database/data types we intended to use. So before implementing an MVP, I could roughly answer what price/scalability it would have. But I can see it might have, especially in fields of statistics/ML/new algorithms. E.g. "try using SIMD for this new sorting algorithm" -- only tests could show if it's any better.
But in that areas, usually managers shouldn't judge by outcome anyway, but rather by how fast they make and test hypotheses.
Wow, that blog post post was a breath of fresh air. Can you believe it was written almost six years ago? She is really seeing into the future. Unbelievable.
Maintenance benefits from "pro" skills as much as creation does; you can break something just as easily with maintenance work as with new features if you're not good at it.
To me that's a wrong way to look at software maintenance.
What do you think leads to a better result?
- I create software that I _want_ to maintain and _will_ maintain.
- I create software that I think someone else wants to maintain, I leave the project after.
At least in open source, some of the most praised and successful software was built _and_ maintained by the same people at least for a substantial amount of time.
Thinking about it, this pattern of "I, the rock star will build it, you the code monkey will maintain it." Is a red flag.
