You've got some reasonable points and I don't just want to completely gang-tackle you here, but there is a part of your argument that I think is sufficiently incorrect in a sufficiently harmful way that I'm going to sort of keep at you about it, in what I hope is an open-minded or at least respectful way.

Some people like the book "Coders at Work" (I do), some do not, but almost anyone would agree that the people interviewed are absolute luminaries [0].

There are 15 chapters comprising 15 interviews. You have to get to #6, arguably #7 before you find someone who at the time of writing wasn't both a world-renowned hacker and currently or at one time a demonstrably successful engineering leader. The first 5 being: jwz, Brad Fitzpatrick, Douglas Crockford, Brendan Eich, Joshua Bloch. It starts to get a little blurry in the second half because it's so thick with CS academics (who in a different way also do engineering management), but you've still got VP-types who still code like Peter Norvig. The ~50% who aren't demonstrated engineering leaders are super hard-core CS researchers like Donald Knuth. The book doesn't even interview Cliff Click, or John Carmack, or talk about the fact that Larry Page and Sergey Brin wrote the first version of Google themselves and continued maintaining parts of it well into hyper-growth. Eric Schmidt wrote `lex`. When Jack Dorsey was recruiting me for Square over lunch he made an incredibly eloquent argument about why he uses OCaml rather than Haskell for his personal hacking.

At the time I was an L7 EM, my L9 boss didn't have much time to write code, but asked probing questions about everything from the merits of various binary classifiers given imbalanced underlying Bernoulli distributions to the algebraic properties of the data structures we were using for distributed systems convergence.

I don't dispute that plenty of successful leaders in technical organizations have become rusty as hackers when they hit the mega-seniority, but the idea that some L6/L7 manager shouldn't be able to lift some of their team's serious code off the ground, let alone some undergraduate dynamic-programming interview question as was the original point of my original post is simply contradicted by a mountain of evidence both generally-available and anecdotal to numerous people in this thread.

You can get ahead as a mid-level EM without knowing the frib-frobs from that whatsits, but God-willing I'll never work for one again. That's a visibility game, it's a popularity game, it's a schedule-too-many-meetings game, it's a post-too-much-on-the-internal thing game. Fuck that game.

[0] https://www.oreilly.com/library/view/coders-at-work/97814302...

At Apple? Maybe not. But elsewhere?

Maybe no articles written about them but books or chapters ([0], [1]) written by them.

In the spotlight? You betcha, i think watching talks by Brian Cantrill is highly entertaining. Rich Rickeys' talks are highly regarded on HN (making a mental note to watch them). Carmack talking at Quakecon for hours about many different things.

(edit) formatting and links

[0] https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

[1] https://www.amazon.com/Masterminds-Programming-Conversations...

Yeah I wondered about the origin too. One thing I did during quarantine was re-read some old books on my bookshelf, including 2009's Coders at Work:

https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

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).

It's about even more than that: it's about the complexity.

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:

https://www.amazon.com/Search-Stupidity-Twenty-Marketing-Dis...

"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."

https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

... "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)"

Yes. The article is a bit tautological. It's not defining seniority in terms of time spent. He actually says this at the end. Instead he's defining a "senior developer" as someone who has a necessary mix of the qualities he talks about. It would be more accurate to say "These are the traits your manager will tell you to develop to get promoted."

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.

All the guys from "Coders at work" [1]: - Jamie Zawinski - Brad Fitzpatrick - Douglas Crockford - Brendan Eich - Joshua Bloch - Joe Armstrong - Symon Peyton Jones - Peter Norvig - Guy Steele - Dan Ingalls - L Peter Deutsch - Ken Thompson - Fran Allen - Bernie Cossel - Donald Knuth [1] https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

You might enjoy Steven Levy's Hackers: Heroes of the Computer Revolution[1]. It's not too focused on specific people or companies, although you'll encounter some well known people like Bill Gates, Steve Jobs, and Richard Stallman in the book. It's an interesting read because it gives you a great background that helps you understand how we ended up with the tech culture and environment we have today.

In the reply to another comment, I also mentioned Coders at Work[2]. I found that it provided some great insight into the early days of some fascinating companies from a technical perspective.

[1] https://www.amazon.com/Hackers-Computer-Revolution-Steven-Le... [2] https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

I know you didn't ask for books but here are some interesting ones. The first two cover individuals and the last two cover the works of others.

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...)

Oh wow, I was just reading about this yesterday in Coders At Work[0]. Douglas Crockford[1] worked on this at a company that was trying to do some distributing computing work in the 90s-00s. They originally based it off the JVM but SUN had issues with that so they turned it more in to what he described as a scripting language "which is what we have today."

[0]: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... [1]: http://javascript.crockford.com/

There are two excellent books that will answer most of your questions. The second book is harder to obtain (more expensive), as it is older. Each of the interviews are pretty detailed, down to nitty-gritty, often mundane details about the craft of programming.

http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

http://www.amazon.com/Programmers-at-Work-Susan-Lammers/dp/0...

I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern.

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.

[1]: https://en.wikipedia.org/wiki/Frances_E._Allen

[2]: 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.

Peter Norvig often covers really interesting stuff. A long time ago here on HN I read his article on the probability of there being no set in the card game SET [1]. I had never heard of SET then, but picked it up based on the article. It's a simple game, but has interesting properties. Analytical answers are hard to find for a lot of the cases, so simulation to the rescue. I ended up running more simulations than Peter did, with some interesting results [2].

Also, the interview with Peter Norvig in the book "Coders at Work" [3] is great - one of my favorites in the book (actually, the whole book is great).

[1] http://norvig.com/SET.html

[2] http://henrikwarne.com/2011/09/30/set-probabilities-revisite...

[3] http://www.amazon.com/gp/product/1430219483/

For anyone who hasn't browsed through Peter Seibel's "Coders at Work," one of his subjects is Fran Allen...it's kind of funny because I do agree that learning C has been valuable to the high-level programming I do today (but only because I was forced to learn it in school). But there's always another level below you that can be valuable...Allen says C killed her interest in programming...not because it was hard, but because of, in her opinion, it led engineers to abandon work in compiler optimization (her focus was in high-performance computing):

(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.

Assault is a loaded word to describe a honest observation based on a needless graphic picture you painted. You might not need help to sort out your anger issues. But you certainly need some work on your politeness skills. Here's a tip on the importance of that, politenes is appreciated as much as rudeness is abhorred.

Now onto your claims about open source developers from Brazil, Russia, India, Poland, and China. I'm going to ignore the fact you only backed it up with your imagination, and focus on the interesting part, your assumption. You assumed that all these fellow programmers didn't have access to books, older programmers, nor even computers, in the seventies. Despite of the fact that programmers from these countries have been consistently shipping great software for decades. What really staggers me is that you assume on behalf of all these people that they lack culture, just to prove your point.

Do humanity a favor, and go read a book [0]. Or at least try to leave home so you can talk to people, and finally work on your poor social skills.

[0] http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

Sadly I don't really read quite as much as I used to; but following are the books I read this year (though none of them were released this year).

- Founders at Work: Stories of Startups' Early Days

http://www.amazon.com/Founders-Work-Stories-Startups-Problem...

Excellent book covering interviews with founders of companies that became really big. I thought this book was really insightful and inspirational.

- Coders at Work: Reflections on the Craft of Programming

http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

I just started this book, but already like it - the format is the same as the Founders at Work book but on the developer side of things.

- World Changers: 25 Entrepreneurs Who Changed Business as We Knew It

http://www.amazon.com/World-Changers-Entrepreneurs-Changed-B...

It was a good book, but not as inspirational as the Founders at Work book. Some of the stories are good, but since the majority of the people are not in my sector, the book just wasn't as interesting to me.

- Ready Player One

http://www.amazon.com/Ready-Player-One-Ernest-Cline/dp/03078...

An excellent story that really made me nostalgic to my younger years - definitely recommend this one.

- The Mystic Arts of Erasing All Signs of Death: A Novel

http://www.amazon.com/Mystic-Arts-Erasing-Signs-Death/dp/034...

I have a weak spot for Charlie Huston books - he's not the best author (sorry Charlie), but his books are really easy to approach. This is one of his best ones and is about crime scene cleaners - a nice departure from all the Joe Pitt vampire novels.

- World War Z: An Oral History of the Zombie War

http://www.amazon.com/World-War-Oral-History-Zombie/dp/03073...

It's OK... I read it half way through and then once I got busy I just couldn't get myself to pick it up again. I will finish it eventually.. just not yet.

- Hyperion

http://www.amazon.com/Hyperion-Dan-Simmons/dp/0553283685

A friend recommended this book to me - I could not get past the first chapter.

I don't necessarily know of any one book that meets all of your friends requirements, but...

Tracy Kidder's The Soul of a New Machine might be good for your friend.

http://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/03164...

Another good option might be Code: The Hidden Language of Computer Hardware and Software by Charles Petzold.

http://www.amazon.com/Code-Language-Computer-Hardware-Softwa...

Or, how about Coders at Work?

http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

Another one that I have (but haven't had time to read yet) is Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg. It might have something that your friend would find interesting.

http://www.amazon.com/Dreaming-Code-Programmers-Transcendent...

Another one that may be inspirational, although it's more about personalities than computer science per-se, would be Steven Levy's Hackers: Heroes of the Computer Revolution.

http://www.amazon.com/Hackers-Computer-Revolution-Steven-Lev...

I think Coders at Work and Founders at Work did a pretty good job with this.

http://www.amazon.com/gp/product/1430219483/

http://www.amazon.com/gp/product/1430210788/