The Brendan Eich interview was really interesting, because it talked about bridging research and software engineering, specifically with regard to memory safety in C++ and debugging tools.
I think he was talking about manual annotations on C++. It seems clear that this interest morphed into sponsoring of Rust. I think Rust was a side project since 2006 and it was "announced" around 2010 (?).
And Mozilla also sponsored the "rr" reversible Debugger, which is also some very impressive engineering. (Sadly it seems to get less attention than Rust!)
Anyway, for PL nerds, I recommend reading this interview.
I think this work on software engineering tools is great, but as a Firefox user of 15+ years, it would be hard for me to argue that Firefox received sufficient attention. It does feel like the situation where the engineers work on the tools for too long and then management cancels both projects (which I've seen happen in my career).
There's an inherent complexity in the problem being solved.
And there is an "accidental complexity" in the implementation of the solution.
Throwing away everything, people typically believe that they can avoid handling a lot of the "inherent complexity." But typically there is a good reason why the inherent complexity was addressed in the previous version of the program, and there's a big chance that the new "from the scratch" designers will have to relearn and rediscover all that, instead of transforming the already existing knowledge that is encoded in the previous version.
For anybody interested in the topic, I recommend the number of case studies presented in:
"In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters"
See about new rewrite of Wordstar simply not having the printer drivers that the previous had, and also other features people already expected, leading to Wordstar's demise.
Or what Zawinski's names "Cascade of Attention-Deficit Teenagers" (search the internet for that, the link here wouldn't work!)
"I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short."
"It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?"
Or an interview with Jamie Zawinski from Siebel's "Coders at Work."
... "even phrasing it that way makes it sounds like there’s someone
who’s actually in charge making that decision, which isn’t true at all. All
of this stuff just sort of happens. And one of the things that happens is
everything get rewritten all the time and nothing’s ever finished. If
you’re one of those developers, that’s fine because there’s always
something to play around with if your hobby is messing around with
your computer rather than it being a means to an end — being a tool
you use to get whatever you’re actually interested in done."
If one is able to cover all the complexity, and it is not destructive to the goal, the rewrite is OK. Otherwise, one should be critical to the ideas of rewrites as they could be potentially secretly motivated by simple (jwz again): "rewriting everything from scratch is fun (because "this time it will be done right", ha ha)"
Personally, my favorite book about old coders is Coders At Work (https://www.amazon.com/Coders-Work-Reflections-Craft-Program...). It's a bunch of interviews with programmers who have created programming languages and lots of the fundamental software we all rely on. It showed me what the journey to being a great programmer can look like.
To me, senior is a corporate term. Great programmers build great things. Senior developers get promoted. I sometimes ask young programmers this: Do you care about the craft or the career? I think being a great programmer will make a person money. There aren't that many truly great programmers. But if they're impatient or they don't think they can be great, they can probably be senior.
Becoming senior is easy: Just help your boss accomplish their goals. Pay attention and develop skills that will help you do this no matter where you are and what you're working on. If you over-specialize in a specific organization or person's need, you become the expert beginner and you can't leave or you will struggle.
Some of the things that help a person be senior can also make them great. But the path to being great is a very different and personal one (at least that's the impression I got from Coders At Work. I make no claims for myself.) Jeff Dean is undoubtedly a great programmer and was also the most senior developer at Google for a long time. They made new levels just for him. So they can overlap. If someone is lucky and their job is great, the things that make them senior can also make them great. If their job sucks and management is terrible, they'll have to choose every day between doing something great or doing something to get promoted (being senior.)
My favorite article on the journey of a software engineer is this one: https://medium.com/@webseanhickey/the-evolution-of-a-softwar... . To me it's the story of someone who started off trying to be senior but then started to become great.
In the reply to another comment, I also mentioned Coders at Work. I found that it provided some great insight into the early days of some fascinating companies from a technical perspective.
(Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Location 6269). Kindle Edition: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... )
Seibel: When do you think was the last time that you programmed?
Allen: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue....
Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?
Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities.
Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional programming* and its builtins allow pervasive mutable state.
: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...* Its impossible to support FP without generics. Even the most basic higher order functions require type variables.
* Its impossible to support FP without generics. Even the most basic higher order functions require type variables.
Coders At Work (https://www.amazon.com/Coders-Work-Reflections-Craft-Program...)Founders At Work (https://www.amazon.com/Founders-Work-Stories-Startups-Early/...)Architecture of Open Source Systems (https://www.amazon.com/Architecture-Open-Source-Applications...)Architecture of Open Source Systems - Vol 2 (https://www.amazon.com/Architecture-Open-Source-Applications...)
Founders At Work (https://www.amazon.com/Founders-Work-Stories-Startups-Early/...)Architecture of Open Source Systems (https://www.amazon.com/Architecture-Open-Source-Applications...)Architecture of Open Source Systems - Vol 2 (https://www.amazon.com/Architecture-Open-Source-Applications...)
Architecture of Open Source Systems (https://www.amazon.com/Architecture-Open-Source-Applications...)Architecture of Open Source Systems - Vol 2 (https://www.amazon.com/Architecture-Open-Source-Applications...)
Architecture of Open Source Systems - Vol 2 (https://www.amazon.com/Architecture-Open-Source-Applications...)