On Friday, 29 March 2019 at 13:57:57 UTC, Andrei Alexandrescu wrote:

>> Or a team of subordinate apprentice/junior engineers (who have demonstrated sufficient potential) working under the mentorship of a master who is willing to make an investment.
>
> This is a lot more difficult to set up than it seems.
>
> One reason is that surprisingly few of the contributors come here to learn, to acquire knowledge.
[...]
> I think it has to do with a simple reality - I was trying to mentor people who didn't want to be mentored.
>
> So I think it would be difficult to establish a master/mentee dynamics.

I understand (as my head hangs in disappointment).  I've observed it for myself, and may even be guilty of it in a few instances.

This is why I added the word "subordinate" to my sentence before I submitted it.  The apprentice would have to agree to subordination as part of the up-front agreement.

It's not just knowledge the apprentice is seeking.  (S)he may be also be seeking credentials and experience.  The credentials include the trophy of accomplishment and the privilege to use the master's name as a reference in their future prospects.  Insubordination results in being fired and losing those credentials, not to mention the time and effort spent, and the opportunity to expand their knowledge.

The master would have to be selective, just like an employer, to find the right people for the apprenticeships, and there would have to be some up-front agreement with conditions and expectations.

I don't have any experience with this kind of thing, so perhaps I don't know what I'm talking about.  It's just a shame that people are willing to take out a loan for 10s of thousands of dollars for an education built around contrived assignments, when there's an opportunity here to do real meaningful work, led by some of the most reputable names in the field, that doesn't cost anything.  What am I missing?

Mike

On 3/29/19 11:12 AM, FeepingCreature wrote:
> On Friday, 29 March 2019 at 13:57:57 UTC, Andrei Alexandrescu wrote:
>> Here, my reviews were more often than not met with hostility.
>>
>> As a pattern, a reviewer would be more willing to write the code once and then defend it in its current state, rather than improve it through review. In a few extreme cases, people flat out told me they'll abandon the PR if I don't take it as it is.
> 
> Where I work, we're trying our best to do design reviews before starting large implementations and to seek reviewer feedback throughout the process. We do this because it seems clear that after the code is already written and after several days' to weeks' worth of effort has gone into a feature, the cost to making fundamental design changes is as great as it's going to get, and developer attachment to the existing code as well as frustration with the reviewer is high, especially when the reviewer asks for fundamental design changes.

There are few more productive moments at Facebook than those when five solid engineers get in a room and pound out a design.

Keywords being "five", "solid", and "room". The moral equivalent for us would be a virtual room - a forum or a discussion around a github pull request. The problem is access and numbers.

Consider a Gedankenexperiment whereby Facebook opened a room to the public, capacity 12, and offered it to any passer-by willing to discuss design with a couple of Facebook engineers.

Now, one of two things may happen. One is, the notion is very successful and people would clamor to get into the room. Natural dynamics would lead to some form of selection at the door that would allow only the best of the best enter.

Another is, the notion is only mildly intriguing. So there's a few folks inside, and nobody waiting outside. People come and go because they don't see a huge emulation at the door creating incentive to prove their worth inside. Now there would be competition, but just against the two Facebook engineers who are perceived as the benchmark against which everyone needs to compare. (Remember, nobody is at the door to put pressure.) Anyone can enter and stay for any period of time, and their voice will be as loud as anyone else's in the room.  So they'd want to outdo the Facebook engineers, and if they riposte, anyone can throw their hands in the air and leave.

Look at what happens in Rust. People get over each other to add quality to the language, because if they don't, the next guy has a better proposal, idea, or code. There's a crowd at the door, putting pressure on the folks within. Folks don't go around telling Niko Matsakis he's a chowderhead who could learn a thing or two.

It's most interesting what happens with Walter. He is one of the best hackers (in the Paul Graham sense) I've ever known, and that says a lot; I know quite a few, and I could also hack my way out of a paper bag. Walter is literally the guy who could write a line of code where most others would need one hundred. Yet he is hardly revered in our community, and his views on doing software are routinely debated and often derided. His inability to debate is part of it (he's a hacker, not a politician), but I think the lion's share goes to the "Facebook room" thought experiment above. Not enough people at the door.

> And this, to pivot to another debate we had recently, is exactly why it's a counterproductive approach to do DIP reviews only at the end.

Yes, that would be helpful. One problem we have there is proposals that cannot be improved via review.

Years ago, I had the hots for a girl so I did what many silly guys do - I friended her. She confessed she had aspirations for writing. Being likely inclined as well and wanting to please, I enthusiastically proffered interest in her endeavor. So she gave me a manuscript to read.

It was... bad. Not just bad, fractally bad - from the overall arc down to grammar and punctuation. Wanting to say something nice about it, I went for advice to my uncle, a published author (his obituary is online - Nicuta Tanase). He said, kid, just mention a couple of things that are objective and would improve things.

And so I did, not realizing I was creating a larger problem for myself. Because a week later, she came with another draft in hand, saying: "I fixed it! Now it's good for publishing... right?"

Needless to say, that didn't go well for my dating life.

Now on Hacker News:

https://news.ycombinator.com/newest

On Friday, 29 March 2019 at 16:26:06 UTC, Andrei Alexandrescu wrote:
> Years ago, I had the hots for a girl so I did what many silly guys do - I friended her. She confessed she had aspirations for writing. Being likely inclined as well and wanting to please, I enthusiastically proffered interest in her endeavor. So she gave me a manuscript to read.

I don't think this comparison is appropriate, and honestly, I think it's a little disrespectful to contributors.

Like, contributors aren't trying to get a date. They don't want to be teased, they don't want to play social games, they don't want things to be dramatic or fun or romantic. They want to submit a change, and they want it to be straightforward.

Also, they're mostly volunteers, helping on their free time out of passion. Comparing them to a girl hamstringing you for writing advice seems extremely condescending.

> It was... bad. Not just bad, fractally bad - from the overall arc down to grammar and punctuation. Wanting to say something nice about it, I went for advice to my uncle, a published author (his obituary is online - Nicuta Tanase). He said, kid, just mention a couple of things that are objective and would improve things.
>
> And so I did, not realizing I was creating a larger problem for myself. Because a week later, she came with another draft in hand, saying: "I fixed it! Now it's good for publishing... right?"

That doesn't mean early reviews aren't valuable.

Like, I get that some people get sore when you tell them that a submission they've spent a lot of effort on just isn't good enough, and sometimes they will be unreasonable no matter what you say.

(and, as I've said before, the community has a tendency to jump to "Oh, W&A are being stubborn and ignoring The Will of The People again" every time you make a design decision someone doesn't like)

But the response to that is *more* communication, not less. If someone's PR is too bad to be merged, you're not going to help anyone by letting the person work on code that has no chance to be accepted. Same thing for DIPs.

Saying "This would be much easier if the community was bigger and people fought for my attention" is just wishful thinking. You don't solve a communication problem by becoming a cult icon, you solve it by communicating better, and earlier.

> Look at what happens in Rust. People get over each other to add quality to the language, because if they don't, the next guy has a better proposal, idea, or code. There's a crowd at the door, putting pressure on the folks within. Folks don't go around telling Niko Matsakis he's a chowderhead who could learn a thing or two.

Seriously, I'm worried that the takeway you're getting from all this is "the community is unreasonable, unlike Rust's community which has a healthy respect for the maintainers". It's not just that. The D community is has a ton of people whose experience writing a PR is "I spent two weeks writing that code, got a comment from Walter six months later that asked to clarify what X did, I added some documentation, and I haven't had any news for a year".

If you look at the open PRs on rust, all PRs in page 3 are less than two weeks old. By comparison, some PRs in page 3 of dmd are from May 2018, almost a year ago!

I realize that the D team has way less resources than Mozilla to dedicate to following PRs, but acting like the only problem is that PR authors are capricious is just disingenuous.

On Friday, 29 March 2019 at 13:05:31 UTC, Andrei Alexandrescu wrote:
> This allows user code to add things like serialization, factories and other introspection-based utilities automatically upon import.

You mean something like this?

    // someFile.proto
    syntax = "proto2";

    message SomeType {
      required int32 x = 1;
      required int32 y = 2;
      optional string label = 3;
    }

    message AnotherType {
      required SomeType xy = 1;
      required int32 z = 2;
    }


    // foobar.d
    import "someFile.proto" : SomeType, AnotherType;

Because that would be seriously awesome.

On 3/29/2019 8:38 AM, Mike Franklin wrote:
> It's just a shame that people are willing to take out a loan for 10s of thousands of dollars for an education built around contrived assignments, when there's an opportunity here to do real meaningful work, led by some of the most reputable names in the field, that doesn't cost anything.  What am I missing?

One thing I really enjoy is working with people who are better at it than I am. It's the fastest, most effective way to up your game, and besides, it's fun.

On Friday, 29 March 2019 at 16:26:06 UTC, Andrei Alexandrescu wrote:
> It's most interesting what happens with Walter. He is one of the best hackers (in the Paul Graham sense) I've ever known

Walter is a brilliant programmer whose historic experience is exceedingly valuable. You're also an excellent programmer and a good writer who brings very valuable higher-thought discipline to library design.

Where you guys are weak is project management. A project manager needs to set clear expectations, facilitate communication among the team, prioritize work based on real world requirements, and motivate the team to do that work, striking the right balance between autonomy and direction to maintain morale while meeting requirements.

I'm sure facebook has some good managers who keep that room of engineers focused on the big picture and willing to come back to work week after week. D needs a good manager too. They make a real difference.

I betcha if we got a good manager, contributors would be a lot happier working in a shared direction and the manpower problems the PR queue sees now would evaporate. And best of all, it'd let you and Walter go back to doing the awesome work you really excel at, instead of arguing with the community so much.

On Fri, Mar 29, 2019 at 07:45:35PM -0400, Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 29 March 2019 at 16:26:06 UTC, Andrei Alexandrescu wrote:
> > It's most interesting what happens with Walter.
[...]
> Walter is a brilliant programmer whose historic experience is exceedingly valuable. You're also an excellent programmer and a good writer who brings very valuable higher-thought discipline to library design.
> 
> Where you guys are weak is project management. A project manager needs to set clear expectations, facilitate communication among the team, prioritize work based on real world requirements, and motivate the team to do that work, striking the right balance between autonomy and direction to maintain morale while meeting requirements.

+1.

I spent the last hour writing a whole bunch of stuff to respond to this, but decided instead to distill it all to just two things:

(1) It's clear that Walter & Andrei excel at technical expertise, but lack in the people skills department.  This has been shown time and again in the way various interactions with different people panned out over the years.  (Please don't take this as an insult or a personal attack, because I don't intend it that way, and I also recognize myself to be belong to the same category. We techie types simply aren't good at people skills, that's all there is to it.)

(2) OTOH, people skills are exactly what's needed to foster a healthy, thriving community around D.  It's unrealistic to expect a volunteer-run open source project to operate the same way as a company that pays its employees to do assigned work.  A volunteer project *can* produce work of equivalent quality, but the lack of monetary compensation must be replaced by a different kind of "currency": an equivalent amount of inspirational leadership. I.e., inspire the people enough and they'll go out of their way to do whatever you want, pay or no pay. And a big part of this is effective communication of the high-level goals of the project and what's expected of would-be contributions. Fail to do that, and be prepared for the same reaction you might get if you gave an employee a sudden big pay cut while still expecting the same amount (and quality) of work as before.

The lack of manpower, etc., are not a cause of our problems; it's a symptom of our lack of proper leadership (in the social sense -- clearly, W&A have excellent technical leadership; but that's not what's missing here).  I don't blame Walter and Andrei for this -- we techie types just aren't good at this sort of stuff.  We need a manager who is.

tl;dr: Walter & Andrei shouldn't be expected to bear the brunt of the social aspect of community building. That's not their forte, and even if they could do it, it'd be a waste of their technical talents.  We need a proper manager who can do a good job with the community-related / people-related stuff, and leave W&A to do what they're best at doing.


> I'm sure facebook has some good managers who keep that room of engineers focused on the big picture and willing to come back to work week after week. D needs a good manager too. They make a real difference.
> 
> I betcha if we got a good manager, contributors would be a lot happier working in a shared direction and the manpower problems the PR queue sees now would evaporate. And best of all, it'd let you and Walter go back to doing the awesome work you really excel at, instead of arguing with the community so much.

Yes and yes.  It's about time we acknowledge where our weaknesses lie, and take real steps at fixing the problem, instead of continuing to lie to ourselves with the fantasy that social problems can be cured by technical expertise.  We techie types all wish it were so, but sadly the real world simply doesn't work that way.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Friday, 29 March 2019 at 16:26:06 UTC, Andrei Alexandrescu wrote:
> Look at what happens in Rust. People get over each other to add quality to the language, because if they don't, the next guy has a better proposal, idea, or code. There's a crowd at the door, putting pressure on the folks within. Folks don't go around telling Niko Matsakis he's a chowderhead who could learn a thing or two.

There's a saying, keep your eyes on your own plate. You really want to compare to rust? How about starting with the fact D doesn't even provide a 64-bit binary on Windows for their compiler. That's the sort of trivial problems D has yet to even solve. You best look at your own plate first before even considering to compare to others.

On Friday, 29 March 2019 at 13:57:57 UTC, Andrei Alexandrescu wrote:
> This is a lot more difficult to set up than it seems.
>
> One reason is that surprisingly few of the contributors come here to learn, to acquire knowledge. Most come to dispense. I spent long times reviewing pull requests in our community, calibrated to the reviews standards at Facebook (however controversial, they have an impressive software engineering force).

Therein lies your problem, you are attempting to fit a square peg in a round hole.
You are not dealing with well paid highly qualified engineers whose job it is to do what needs to be done.
For the most part you are dealing with an intermittent army of volunteers of a range of abilities for whom this is a hobby.

> There, the code review process is locked in a virtuous circle: you get good reviews that help you improve, and you'd be motivated to give good reviews to improve others'.
>
> Here, my reviews were more often than not met with hostility.

I can't speak for your phobos reviews, but most of the interactions I've had with you on dmd were not at all useful.

> As a pattern, [an author] would be more willing to write the code once and then defend it in its current state, rather than improve it through review. In a few extreme cases, people flat out told me they'll abandon the PR if I don't take it as it is.

Been there
https://github.com/dlang/dmd/pull/8557#pullrequestreview-149952733
done that
https://github.com/dlang/dmd/pull/8557#issuecomment-416798558

> Larger disagreements on matters of architecture and design were often taken as personal offenses.

With responses like that I can see why.

> I'd wake up in the morning for days, then weeks and months, with one thought: "I have so many things to do today, and I like none of them." The irony! Here I was, independent, working for myself on whatever I dreamed of. Yet this was worse than the worst jobs I've ever had. How did I get into this situation? I think it has to do with a simple reality - I was trying to mentor people who didn't want to be mentored.

Probably, chances are most of them wanted to get shit done...

> So I think it would be difficult to establish a master/mentee dynamics.

... but there are definitely those out there looking for experience, looking to become better programmers (GSoC students are a good source).