Hi Branden, G. Branden Robinson wrote on Fri, Jan 03, 2020 at 04:35:52PM +1100:
> Right. I've started to adopt the philosophy that _especially_ for > critical stuff, a senior engineer should not be writing an > implementation--he or se should be producing a spec, which junior > engineers then implement. > > A senior should also, of course, participating in code reviews and > helping out with validation and verification. > > But the Thing-Itself-Which-Is-To-Be-Maintained? The senior should not > be directly touching that at all. If there's a stumper of a problem, > the senior should be working alongside the juniors to solve it. But the > keystrokes and commits to resolve the issue should belong to those > juniors. > > This, I believe, is how expertise is built and transmitted in a > collaborative environment. This seems excessively strict to me. Yes, i know rms@ is no longer writing much new code nowadays. But it's not like that in all communities. For example, in OpenBSD, the most senior engineers (like Theo de Raadt, Marc Espie, Mark Kettenis, David Gwynne, Kenneth Westerback, ...) are writing a lot of code all the time. It is not holding back the youngest engineers (like Klemens Nanni, Scott Cheloha, Theo Buehler, Anton Lindqvist, Martijn van Duren, ...) from contributing and growing, often collaborating on exactly the same regions of the code and the same projects, and inspiring them. Heck, for the vast majority of active developers, i wouldn't even be able to decide whether they are "juniors" or "seniors". Of course everybody (including juniors) participates in code review, and the seniors do not behave like rockstar code cowboys. In fact, the seniors are among the most zealous when it comes to reviewing and polishing legacy codebases. So it doesn't have to be the way you describe, even though i agree it is like that in most places. Incidentally, the worst rockstar code cowboy i ever had to deal with in the industy was quite a young man (oops - i almost mentioned the name; he also contributed marginally to some free software projects). So it's more a matter of the attitude of project members and the climate in the project/company than of seniority. Consequently, i wouldn't object at all to Doug writing some come for groff, if he wanted to. ;-) > What is stopping us? > I'm tempted to say "engineering managers" but I suspect that is > painting with too broad a brush. Of course that brush is broad; there are some individual managers who have more and some who have less of a conscience (and of technical competence). But it's not so far off the mark in so far as you *can* regard "management" as the personification of the *structural* effects that are actually causing the problem. As long as society is organized around making profit and around owning personal property rather than around sutainablity and cooperation, many consumers will be forced to look more closely at the price tag than at the quality (if they even manage to get the education to understand what the latter is - chances are their education already taught them to hurry and scramble more than anything else), and producers will suffer from a pressure to get some results (or too often: any results whatsoever) as fast as possible to sell them and start making money. Hom much does spending the last 90% of work to get the last 10% of quality contribute to the success of an *average* company, really, on current markets? The fact that *you* would be willing to buy the considerably more expensive product due to its quality doesn't really matter, on the scale of society as a whole. Anyway, in a project like groff, we do have the freedom to review and polish legacy code, to build unit tests if we want to, and to develop new features in a sustainable way... Yours, Ingo
