From:  Steve Fink <>
Date:  19 May 2016 05:02:03 Hong Kong Time

Re: componentization and specialization, was Re: Clang-format


On 05/18/2016 01:38 PM, Bill McCloskey wrote:
> I think we're starting to conflate separate concepts. I absolutely 
> believe that code should be modular. SpiderMonkey is a great example: 
> we're much more productive because of how well separated it is from 
> the rest of the browser. On the other hand, *people* should not be 
> modular. You don't need to be ignorant of one area in order to be an 
> expert at another.

The ignorance itself doesn't help, sure. But I still assert that there 
are benefits to having fewer things in your head, to have your focus 
wholly consumed by a more limited scope for the most part. It's not for 
everybody, but imagine if we suddenly needed to hire a Sparc64 expert 
and we made it part of our hiring criteria that they had to be willing 
to chase bugs through CSS code if they happened to be triggered by their 
work. We would drastically limit our hiring options, cutting out some 
very qualified people. (Or say we didn't factor that into account when 
hiring, but then expected it of them when they started working. I would 
imagine that would feel pretty unfair and frustrating.)

> I find that when I first learn a piece of code, it takes forever to 
> learn the basic invariants and high-level abstractions. But once you 
> learn those things, it goes much quicker. When you see a function 
> call, you can guess what it does rather than having to look at the 
> definition. When you debug a problem, you know the point where things 
> go wrong because you know how the data is supposed to look (and not 
> look). And the great thing about this sort of high-level knowledge is 
> that it stays with you for a long time. I forgot most of what I knew 
> about the JS engine a while ago, but it's still easy for me to look up 
> specific things that I need to know or to debug issues that relate to 
> SpiderMonkey.
> I don't think there's any reason why a JS engine developer couldn't 
> learn this high-level stuff about other parts of Gecko or Firefox 
> while still being a great JS engineer. Yes, it takes some time. But it 
> pays huge dividends. When test failures happen, you'll find it a lot 
> easier to understand what's going wrong and who would be the best 
> person to investigate. It saves tons of time in the long run.

You're arguing the advantages of being a generalist. I agree; I think of 
myself as a generalist too, and I'm no stranger to some of the weirder 
corners of the Gecko codebase. But that doesn't address whether being a 
specialist can also have advantages.

> I suspect one reason that SpiderMonkey developers have such a dim view 
> of the rest of Gecko is that they usually only look at it when dealing 
> with test failures that are standing in the way of landing something. 
> That's going to be a pretty frustrating experience no matter what the 
> overall quality of Gecko is. And tests tend not to be our best code.

I don't think we need to argue this point, since I don't think there's 
any disagreement. Though I suppose I deserve to have it brought up, 
given that I complained about the difficulty of minimizing test cases. I 
would challenge the assertion that SM devs have a dim view of the rest 
of Gecko -- you may be right, or you may be partially right, but it's 
certainly not universally true. I have a dim view of certain aspects and 
areas of Gecko. And of SpiderMonkey, which I tend to be more critical of 
given its amount of focused developer attention compared to the wider 
Gecko. (It's actually a little weird for me to even separate them, 
actually; I think of SpiderMonkey as part of Gecko. But it *is* a more 
idiosyncratic corner than most, hence the original thread.)

> On Wed, May 18, 2016 at 11:14 AM, Steve Fink  > wrote:
>     On a related note, I think we're also organizationally weak about
>     taking advantage of ideas and new approaches. Specifically, you
>     can come up with all the great ideas you want, as long as you're
>     going to personally implement them. Anything that would best be
>     done by someone else or a collaboration of multiple people
>     requires strong salesmanship, which is not always the forté of the
>     person coming up with the idea. But I've rambled on too long
>     already, so I'm not going to get into that.
> Working with people in other areas is a great way to earn their 
> respect. Once they respect you, they'll be much more likely to work 
> with you on your ideas. Or you might not even need their help because 
> you can do the work yourself. Either way, having more experience in 
> other areas makes it easier to try out new things.

Good points, and I'd like to work out my thoughts on this more, but I 
already regret derailing this thread in that direction. If I can scrape 
together enough coherent thoughts on this, I'll start a new thread... 
somewhere. (Not having a good place is part of the problem, actually.)