www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The process described in the linked article could be a good thing for

reply max haughton <maxhaton gmail.com> writes:
https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work

We need step 1 (and then the others), but step 1 in particular is 
something we're missing.

Suggestions as to how to implement this are appreciated.
May 24 2022
parent reply forkit <forkit gmail.com> writes:
On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:

 https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work

 We need step 1 (and then the others), but step 1 in particular 
 is something we're missing.

 Suggestions as to how to implement this are appreciated.


ummm..divide and conquer.

to get a unified view of a business, for example, you divide it 
into its components (sales, marketing, customer-service, 
logistics, I.T, finance...etc).

Then you ensure there is management, and competent management, in 
those areas.

Then you bring that management together, and try to get the big 
picture.

You replace those management who are unable to assist in this 
process ;-)
May 24 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 24 May 2022 at 22:44:36 UTC, forkit wrote:

 On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:

 https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work

 We need step 1 (and then the others), but step 1 in particular 
 is something we're missing.

 Suggestions as to how to implement this are appreciated.


 ummm..divide and conquer.

 to get a unified view of a business, for example, you divide it 
 into its components (sales, marketing, customer-service, 
 logistics, I.T, finance...etc).

 Then you ensure there is management, and competent management, 
 in those areas.

 Then you bring that management together, and try to get the big 
 picture.

 You replace those management who are unable to assist in this 
 process ;-)


We don't have people enough to need to do that, what I mean is 
that we need to build systems on servers rather than brains to 
keep track of what people are doing and observe the effects.

If we take Boyd's OODA loop as an abstraction to target we 
currently are struggling with step one and two: Observation is 
somewhat informal but not impossible, orientation is very hard 
because we can't easily keep track of what's happening in way 
that's accessible to either external readers or would-be 
volunteers.
May 24 2022
next sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:

 On Tuesday, 24 May 2022 at 22:44:36 UTC, forkit wrote:

 On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:

 https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work

 We need step 1 (and then the others), but step 1 in 
 particular is something we're missing.

 Suggestions as to how to implement this are appreciated.


 ummm..divide and conquer.

 to get a unified view of a business, for example, you divide 
 it into its components (sales, marketing, customer-service, 
 logistics, I.T, finance...etc).

 Then you ensure there is management, and competent management, 
 in those areas.

 Then you bring that management together, and try to get the 
 big picture.

 You replace those management who are unable to assist in this 
 process ;-)


 We don't have people enough to need to do that, what I mean is 
 that we need to build systems on servers rather than brains to 
 keep track of what people are doing and observe the effects.

 If we take Boyd's OODA loop as an abstraction to target we 
 currently are struggling with step one and two: Observation is 
 somewhat informal but not impossible, orientation is very hard 
 because we can't easily keep track of what's happening in way 
 that's accessible to either external readers or would-be 
 volunteers.


You put too much faith in 'systems on servers' ;-)

There are six git repositories, and one issues repository.

At the very least, there should be a (separate) human in charge 
of managing each, and also attracting, organising, and 
delegating, to other talented humans, within each repository.

To the extent that the 'systems on servers' do not meet the needs 
of those managing each repository, that is a matter for them to 
attend to.

Managing is the key to success, not 'systems on servers'.

If there's failure in the D community, it is failure of managing.
May 24 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:

 If we take Boyd's OODA loop as an abstraction to target ....
 ...


Boyd's loop is targetted towards decision makers (i.e. 
management) - ie. humans.

If you're saying D does not have the humans to put into 
management positions, then D does not have the humans to make 
decisions, and thus, pursuing Boyd's loop (or any other form of 
managing).. is kinda pointless ;-)
May 24 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Wednesday, 25 May 2022 at 03:16:05 UTC, forkit wrote:

 On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:

 If we take Boyd's OODA loop as an abstraction to target ....
 ...


 Boyd's loop is targetted towards decision makers (i.e. 
 management) - ie. humans.


D contributors are indeed human


 If you're saying D does not have the humans to put into 
 management positions, then D does not have the humans to make 
 decisions, and thus, pursuing Boyd's loop (or any other form of 
 managing).. is kinda pointless ;-)


I'm saying we have enough humans to do stuff we are just not good 
at keep them pointing at the right stuff, for reasons similar to 
those described in the linked article.

In a project like D naively aiming to manage people will just 
piss people off, we need to make progress observable and make it 
obvious where actually needs work and what other people are 
trying to do. Being able to measure some notion of progress, even 
if fuzzy, is good way of getting more of that thing: In a very 
simple sense, which types of D outreach bring the most traffic to 
dlang.org? How many people have downloaded the nightly build on 
github etc. (hint: not many).

Managing programmers is a full time job even if you're paying 
them to work for you. I think a lot of these nicely packaged 
ideas like OODA are bullshit, I just think there is obviously 
progress we can make either for individuals or for D as a 
directed programming language in the rough concept of the loop. 
The specifics don't really matter.

This concept has an added benefit in allowing people new to 
contributing to find something to do without having to actively 
seek out people they may not know exist yet. Similarly we have no 
data on whether people try and fail to contribute, get stuck, 
etc: sticking a little survey somewhere is better than nothing.
May 24 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 25 May 2022 at 03:44:08 UTC, max haughton wrote:

 ...
 I'm saying we have enough humans to do stuff we are just not 
 good at keep them pointing at the right stuff, for reasons 
 similar to those described in the linked article.


You need better managers then.


 In a project like D naively aiming to manage people will just 
 piss people off, we need to make progress observable and make 
 it obvious where actually needs work and what other people are 
 trying to do. Being able to measure some notion of progress, 
 even if fuzzy, is good way of getting more of that thing: ...


This is why you need managers. Not to 'manage people', but to 
manage these issues.


 Managing programmers is a full time job even if you're paying 
 them to work for you.


One does not manage programmers ;-)


 This concept has an added benefit in allowing people new to 
 contributing to find something to do without having to actively 
 seek out people they may not know exist yet. Similarly we have 
 no data on whether people try and fail to contribute, get 
 stuck, etc: sticking a little survey somewhere is better than 
 nothing.


Again, this is why you need someone managing this. It won't 
happen otherwise.

Try asking the most important questions first.

Who is managing this repository, and that repository?

At the moment, I don't know. Do you? Is it Walter? Does he do it 
all?

I cannot currently go to a manager and say, hey, I think these 
areas need to be improved, and here are some ideas on how it 
might be done.

Just having the idea and spraying it around the NG won't make 
much difference to anything.

If D wants to set itself up for a new phase, it will need good 
managers, not just good programmers.
May 25 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 25 May 2022 at 08:44:47 UTC, forkit wrote:


Perhaps D needs a formal, 'engineering services' team?

(with the emphasis on 'team', as opposed to 'person')

case study:

https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-innovating-on-open-source/DevOps%20at%20Microsoft%20-%20.NET.pdf



 May 25 2022



 next sibling parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 25 May 2022 at 09:09:40 UTC, forkit wrote:


I think this says it all ;-)

https://wiki.dlang.org/?title=Special:Search&search=Vision%2F



 May 25 2022



  parent  max haughton <maxhaton gmail.com>  writes:


On Wednesday, 25 May 2022 at 09:20:12 UTC, forkit wrote:

 On Wednesday, 25 May 2022 at 09:09:40 UTC, forkit wrote:


 I think this says it all ;-)

 https://wiki.dlang.org/?title=Special:Search&search=Vision%2F


And yes I do agree that we have been ridiculously slow when it 
comes to producing vision documents. Part of this I think is 
Michael being a perfectionist but more generally there is a 
framing issue in that I think a vision statement has to be a 
quasi-living document tracked in git and published loudly 
somewhere rather than a wiki page.

But underneath the overall vision there is still a vast amount of 
things to organize and measure. The level of granularity I want 
to attack is not initially the big picture stuff, that's not 
where the real development work has issues.



 May 25 2022



prev sibling  parent reply max haughton <maxhaton gmail.com>  writes:


On Wednesday, 25 May 2022 at 09:09:40 UTC, forkit wrote:

 On Wednesday, 25 May 2022 at 08:44:47 UTC, forkit wrote:


 Perhaps D needs a formal, 'engineering services' team?

 (with the emphasis on 'team', as opposed to 'person')

 case study:

 https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-innovating-on-open-source/DevOps%20at%20Microsoft%20-%20.NET.pdf


We have recently starting making a push to get everything under 
one IaC roof when it comes to infrastructure. The whole idea 
behind doing that is to eliminate much of the need for a team at 
all, it's just code.



 May 25 2022



  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 25 May 2022 at 09:27:23 UTC, max haughton wrote:

 ...
 The whole idea behind doing that is to eliminate much of the 
 need for a team at all, it's just code.


Ahh. The holy grail for programmers ;-)

In the end though, it will always come back to leadership, and 
interactions between people; not 'systems on servers'.

"It seems clear that the success of armies, athletic teams, 
business enterprises, universities, religious organizations—any 
collective activity—depends on the leadership of that 
collectivity."

https://www.hoganassessments.com/blog/personality-theory-and-the-nature-of-human-nature/



 May 25 2022



  parent reply max haughton <maxhaton gmail.com>  writes:


On Wednesday, 25 May 2022 at 10:17:38 UTC, forkit wrote:

 On Wednesday, 25 May 2022 at 09:27:23 UTC, max haughton wrote:

 ...
 The whole idea behind doing that is to eliminate much of the 
 need for a team at all, it's just code.


 Ahh. The holy grail for programmers ;-)

 In the end though, it will always come back to leadership, and 
 interactions between people; not 'systems on servers'.


I am specifically talking about building things on servers, 
because that is something we can actually do. Almost everything 
you have mentioned so far just isn't doable in the short term. Or 
actually relevant to what is blocking current progress.

I am happy to coordinate and manage programmers but I just don't 
think it's a realistic model for the D community because the vast 
majority are working for free. The dynamic just isn't the same as 
a company.

Similarly I want incremental progress to be measurable, not to 
impose a grand model onto the process. This is going to be a 
matter of working hard and smart, not a battle of management 
philosophy.



 May 25 2022



  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 25 May 2022 at 10:26:14 UTC, max haughton wrote:

 On Wednesday, 25 May 2022 at 10:17:38 UTC, forkit wrote:

 On Wednesday, 25 May 2022 at 09:27:23 UTC, max haughton wrote:

 ...
 The whole idea behind doing that is to eliminate much of the 
 need for a team at all, it's just code.


 Ahh. The holy grail for programmers ;-)

 In the end though, it will always come back to leadership, and 
 interactions between people; not 'systems on servers'.


 I am specifically talking about building things on servers, 
 because that is something we can actually do. Almost everything 
 you have mentioned so far just isn't doable in the short term. 
 Or actually relevant to what is blocking current progress.

 I am happy to coordinate and manage programmers but I just 
 don't think it's a realistic model for the D community because 
 the vast majority are working for free. The dynamic just isn't 
 the same as a company.

 Similarly I want incremental progress to be measurable, not to 
 impose a grand model onto the process. This is going to be a 
 matter of working hard and smart, not a battle of management 
 philosophy.


Nothing you've talked about will occur, without leadership and 
interactions between people. Better systems don't just suddenly 
appear out of nowhere.

If you're not focused on this, you may be working 'hard', but not 
very 'smart'.

Also, you do not need to 'coordinate and manage' programmers. You 
only need to set a clear agenda, with priorites, and measureable 
goals; which again, requires leadership and interactions between 
people.

You are correct that better systems are needed (as well) - cause 
inviting programmers to contribute, by saying ..there's a bunch 
of bugs in our bug repository, go pick one... is not very 
motivating ;-)

If there's going to be 'a next phase' for D, it's going to come 
about because of leadership and interactions between people. That 
is the only way it can occur.

So I have to disagree with your assertion, that this is 'not 
relevant to what is blocking current progress'.

If it were me, I 'lead' by saying D3 will be  safe by default. 
Now, let's get to work on it.



 May 25 2022



  parent reply max haughton <maxhaton gmail.com>  writes:


On Wednesday, 25 May 2022 at 23:02:54 UTC, forkit wrote:

 If it were me, I 'lead' by saying D3 will be  safe by default. 
 Now, let's get to work on it.


This is exactly the kind of thing that I am trying to stress 
isn't the scope I'm talking about: You can't coordinate an open 
source project like this, it doesn't work. The overall strategy 
isn't the issue, I want to improve the smaller things underneath 
that. The apparatus for tracking smaller projects simply isn't 
there.

Have you contributed to D? There is a huge amount of stuff at the 
bottom of the stack that needs improving and tracking, the actual 
design of the language is the easy part as far as I'm concerned.

Even ignoring that you're talking about a level of structure that 
is probably impossible unless the D Foundation itself had a 
significant number of full time employees, it's just not what I'm 
talking about.



 May 25 2022



  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 25 May 2022 at 23:32:36 UTC, max haughton wrote:

 On Wednesday, 25 May 2022 at 23:02:54 UTC, forkit wrote:

 If it were me, I 'lead' by saying D3 will be  safe by default. 
 Now, let's get to work on it.


 This is exactly the kind of thing that I am trying to stress 
 isn't the scope I'm talking about: You can't coordinate an open 
 source project like this, it doesn't work. The overall strategy 
 isn't the issue, I want to improve the smaller things 
 underneath that. The apparatus for tracking smaller projects 
 simply isn't there.

 Have you contributed to D? There is a huge amount of stuff at 
 the bottom of the stack that needs improving and tracking, the 
 actual design of the language is the easy part as far as I'm 
 concerned.

 Even ignoring that you're talking about a level of structure 
 that is probably impossible unless the D Foundation itself had 
 a significant number of full time employees, it's just not what 
 I'm talking about.


Well, I agree that we disagree ;-)

You want to advance the D project using 'systems on servers'.

I think it can only advance, through better understanding human 
and social psychology.



 May 25 2022



  parent reply max haughton <maxhaton gmail.com>  writes:


On Thursday, 26 May 2022 at 01:03:00 UTC, forkit wrote:


 I think it can only advance, through better understanding human 
 and social psychology.


I am not saying this can be avoided, I'm saying that this a 
completely different level of abstraction to what I'm trying to 
suggest by linking the article (more specifically the first step).

This is the absolute basics. There's no point in waffling about 
psychology if you have almost no way of judging the effect of any 
changes you make.



 May 25 2022



  parent  forkit <forkit gmail.com>  writes:


On Thursday, 26 May 2022 at 01:27:45 UTC, max haughton wrote:

 On Thursday, 26 May 2022 at 01:03:00 UTC, forkit wrote:


 I think it can only advance, through better understanding 
 human and social psychology.


 I am not saying this can be avoided, I'm saying that this a 
 completely different level of abstraction to what I'm trying to 
 suggest by linking the article (more specifically the first 
 step).

 This is the absolute basics. There's no point in waffling about 
 psychology if you have almost no way of judging the effect of 
 any changes you make.


Umm.. psychology is a science, with plenty of peer-reviewed 
scientific research to back up the claims it makes.

I am unaware of any 
management/leadership/motivation/decision-making (etc) theories 
that don't draw on such research. They all involve humans 
afterall.

If anything I've said is unrelated to your goals fine, ignore it, 
but it's not 'waffling' - it comes from peer-reviewed, scientific 
research.

Good luck with your strategy. I hope it works out ;-)



 May 26 2022