I fully believe that no one should let themselves be intimidated out of learning or pursuing excellence but I sincerely and in good faith disagree with this:
I gave a talk in 2016 where my most important point was that people erroneously believe that you have to be an expert to write an RFC or change Rust, but that I wasn’t, and you don’t need to be one either.
I really want people who suggest changes to languages be experts in that language. It’s frustrating when changes are made to languages that haven’t considered the full gamut of cases that may benefit or be affected by the change. If the Rust community sincerely believes what I have quoted, then long term it will eventually corrupt itself.
I really want people who suggest changes to languages be experts in that language. It’s frustrating when changes are made to languages that haven’t considered the full gamut of cases that may benefit or be affected by the change. If the Rust community sincerely believes what I have quoted, then long term it will eventually corrupt itself.
How about this as a compromise: anyone at all can suggest changes, but changes are only accepted after lots and lots of thought by (many) people who are experts?
I’m not trying just to quibble. I like the idea of a community open to good ideas from anyone, but also resistant to making changes too quickly or without sufficient consideration.
anyone at all can suggest changes, but changes are only accepted after lots and lots of thought by (many) people who are experts?
Sure, but that’s just superficial pandering to the novices in the community. We should just be honest. Novices are at most qualified to express frustrations with a language, only experts are qualified to suggest and make changes to address those frustrations. This is similar to the product design philosophy that “customers don’t know what they want.” It’s up to skilled professionals to design solutions to the problems that users have.
Sure, but that’s just superficial pandering to the novices in the community.
And how exactly does the community become self-sustaining in the production of a steady stream of “experts” and “skilled professionals”, if “novices” are treated as you suggest?
Well, people don’t become experts in a language by proposing poorly informed and misguided changes anyway. ;)
They become experts by writing that language extensively, designing and maintaining libraries, contributing to the implementation… newbies can certainly participate in the discussion of proposals, but it’s really important to know the limits of one’s expertise. “This will break my workflow if accepted” is a useful, much-needed feedback that anyone can give. So is “this fails to account for my use case”. People can also get better at knowing how to see flaws in proposals by doing that.
Experts also must not dismiss proposals “because reasons”. The problem is that a rejection justification can take more time to write than a misguided proposal (a generalization of Brandolini’s law). Giving every newcomer the same amount of the time of current experts is thus counterproductive — there must be filters to weed out obviously bad proposals before they get to the level where the discussion is whether to actually add it to the language or not.
I’m not saying that newcomers cannot make language feature proposals. They (this includes me, in all areas where I’m a newcomer) just should be prepared to face the fact that their proposals are completely misguided and they may need to learn a lot more just to understand why they are misguided.
Giving every newcomer the same amount of the time of current experts is thus counterproductive
Plenty of projects allow newcomers to propose things. They aren’t guaranteed traction. They aren’t guaranteed detailed responses from “experts”. But they can still propose things, which is the difference between what I want, and what the parent comment suggested: “only experts are qualified to suggest and make changes”.
All novices should be treated with respect. Their concerns should be listened to and taken seriously. Their opinions on how the language should change should be taken with a grain of salt.
I don’t think allowing novices to take a driver’s seat in your language’s design is the best or only way for novices become skilled professionals in your language. They become skilled through experience with the language.
And how exactly does the community become self-sustaining in the production of a steady stream of “experts” and “skilled professionals”, if “novices” are treated as you suggest?
Why are experts, novices, and skilled professionals in quotes? Do you not believe that those categories exist? Do you not believe that there is a difference in understanding of a language between people who have different amounts of experience with that language?
The whole point of this article is that different people tend to be experts and novices all at once, in different fields. You can be someone with 15 years of experience in memory management, lang dev and compiler dev, and still be a novice in Rust. Similarly, you can be an expert in Rust and not be an expert in memory management, lang dev, compiler dev, whatever.
All novices should be treated with respect. Their concerns should be listened to and taken seriously. Their opinions on how the language should change should be taken with a grain of salt.
Your original proposal was that novices should only be allowed to “express frustrations”. And I don’t see how your attempt to walk that back in this comment is any more respectful than that:
I don’t think allowing novices to take a driver’s seat in your language’s design is the best or only way for novices become skilled professionals in your language.
Luckily there’s a wide range of additional options between putting “novices” in “a driver’s seat”, and not allowing them to make proposals at all.
Why are experts, novices, and skilled professionals in quotes? Do you not believe that those categories exist?
I am skeptical of your usage of these categories.
There’s a story often told from the Django community of a conference where several of the “core developers” (a group which has since been abolished in favor of a different approach to technical decision-making) were present at a post-conference sprint, which had the usual pile of “good first ticket” things set up for new people to work on. But one newcomer went straight for a truly gnarly problem deep in the guts of the ORM, and came up with a patch. It took two “experts” reviewing it together for much of an afternoon to understand that it was the correct fix. The newcomer ended up with a commit bit later on.
If Django had been run on your model, as I understand it, that never could have happened, because the “newcomer” would not have been taken seriously enough by the “experts”.
There are many cases when what seems like a simple fix doesn’t fix the root cause, fails to account for corner cases, or has non-obvious implications. It can certainly take a lot of time for very genuine experts to evaluate a solution.
Also, I don’t think anyone in this thread advocates for judging people solely by their time in that particular project. Experts tend to be relatively good at recognizing experts from related fields.
Also, I don’t think anyone in this thread advocates for judging people solely by their time in that particular project.
That appeared to be exactly the criterion advocated above – that not having enough time with a particular language should be an absolute bar to being allowed to suggest changes/improvements to the language.
Experts tend to be relatively good at recognizing experts from related fields.
The universally-loathed state of tech interviewing and hiring is a strong counterexample to this claim.
The standard reply until perhaps 10 years ago was that novices should be humble and take the heat until they are no longer novices. It’s possible that this is not the right answer, but it has served and keeps serving well in many fields.
We obviously need a more stringent way of selecting for competence, though. Otherwise, we wouldn’t keep asking why software is still slow despite improvements in hardware, with rants like this one being offered as answers. That link is uncomfortable for me to read because I worry that I’ll be unmasked as one of those impostors. But the incident with Casey Muratori and the Windows Terminal team, brought up by the author of that comment, shows that incompetence really is rampant in the industry.
We obviously need a more stringent way of selecting for competence,
Maybe take a cue from the embedded world? There are very many competent
people there, doing great engineering. This doesn’t have the prestige
among non-technical folks that working for FAANG has.
Another thing is that high salaries don’t always attract the most
capable people, and even when they do, they may not motivate the capable
people to do their best work. Because maybe the work they’re doing is
actually BS, they know it, and they’re just punching a clock.
If I keep rambling along these lines, I’m going to get really off into
the weeds, so I’ll stop now.
Otherwise, we wouldn’t keep asking why software is still slow despite improvements in hardware, with rants like this one being offered as answers.
Anyone who claims that “software is slow” because of incompetence is revealing their lack of competence in understanding why “software is slow”, which tends to be a multifaceted issue.
Becoming not a novice is generally a matter of self identity. People are humble and take the heat until they decide that they’re not novices. In my experience, the more competent the person is, the more likely that are to self identify as a novice, so you’re selecting for people who are confident in their ability, not people with actual ability. It works in other fields only where there is some rigorous external evaluation of competence (apprenticeships, training, and so on).
The approach, which I’ll name “lurk more”, leads to both false positives and false negatives.
People who are competent but lack self-confidence will feel like they’re not good enough to participate. Even if the regulars try to spot people like that and bring them into the community, they won’t get everyone.
People who have self-confidence but are incompetent will participate anyway. The regulars may try push back on this somehow, but again they won’t get everyone, it won’t work on everyone, and it’ll cause friction.
Overall, it may work, and it’s definitely less annoying for some people to be a regular in such communities (because they’ll deal with less novice questions/comments, and the novices will be “better behaved” - those are scare quotes). It might even be unqualifiedly better for communities where people can choose to participate, or there’s an alternative community that’s more welcoming.
The Rust community has, of course, emphatically come down against “lurk more” because they want a more welcoming community, and “lurk more” is not welcoming. As a self-centered person, I would prefer communities I’m not in to be welcoming, and those I’m already in to be “lurk more”. But as an altruistic person, that should persuade me that it’s better to use alternative means (e.g. invite-only groups) to control group behavior.
Novices are at most qualified to express frustrations with a language, only experts are qualified to suggest and make changes to address those frustrations
Definitely not true – I have gotten good suggestions on the Oil language from people who barely know it (which is most people, by definition)
There is simply not that hard a line between “novices” and “experts” when it comes to language design.
It really is true, just as the diagram in the blog post shows, that different people know different things.
Different people have different use cases, and those are valuable.
Nobody can possibly understand all the things a language is used for – somewhat famously Guido van Rossum has never used NumPy, and doesn’t really do scientific computing / linear algebra, yet there are lots of contributors that are not “language designers who have given input and shaped the language. (This isn’t always a smooth process, but it happens, and Python is the most popular language in that domain)
Sometimes the suggestions are impossible, or inconsistent with something that exists already, but those problems aren’t hard to uncover if there is a healthy dialogue
Note also that GvR’s discomfort with performance-oriented design is why CPython still doesn’t have tagged pointers and PyPy still isn’t an official PSF project. Years of wasted effort on forks of CPython were the result. There are similar stories about asynchronous I/O. When a language designer refuses to explore a field of computer science, then it tends to hobble the entire community.
Eh weird tangent, and also untrue on both counts. There are plenty of optimizations in merged into CPython, just not ones that would break all C extensions, like tagged pointers. Essentially every Python release has gotten faster.
Historically, PSF was basically for running Python conferences. PyPy is an amazing project, but I don’t see why the PSF would take it over. At one point >15 years ago there was the thought that it would replace CPython, but there are good reasons that that won’t happen.
You’re getting the point EXACTLY wrong – Guido is not a god and he doesn’t come up with up all ideas, and bless all efforts. Rather, if you care about tagged pointers and performance in CPython so much – YOU should work on it. Plenty of people have – e.g. I’ve noticed heroic efforts improving performance, with compatibility, from Victor Stinner.
Not to mention the recent huge speedups in Python 3.11 – which took outside FUNDING and organization (mostly from Microsoft it seems). PSF is not a wealthy organization.
I’d say that almost all suggestions based on a real problem have been useful, which is probably 80% of them.
Occasionally there is someone who has an “mind bug” idea they haven’t tried … e.g. “I read about some cool thing and I think it should apply to your project” without really doing anything other than writing an e-mail.
But yeah the overall point is that you need a many different viewpoints to make a good language. You also need people to synthesize and simplify them – i.e. the reason people criticize languages like shell, PHP, and C++ is that they seemingly have every viewpoint, which leads to a lot of inconsistency.
This is similar to the product design philosophy that “customers don’t know what they want.” It’s up to skilled professionals to design solutions to the problems that users have.
Community Representation. Andrew said in 2015 that he hoped the proposal process would “make the process more accessible to anybody who really wants to get involved in the design of Go.” We definitely get many more proposals from outside the Go team now than we did in 2015, so in that sense it has succeeded. On the other hand, we believe there are over a million Go programmers, but only 2300 different GitHub accounts have commented on proposal issues, or a quarter of one percent of users. If this were a random sample of our users, that might be fine, but we know the participation is skewed to English-speaking GitHub users who can take the time to keep up with the Go issue tracker. To make the best possible decisions we need to gather input from more sources, from a broader cross-section of the population of the Go community, by which I mean all Go users. (On a related note, anyone who describes “the Go community” as having a clear opinion about anything must have in mind a much narrower definition of that group: a million or more people can’t be painted with a single brush.)
I think we are more or less on the same page so I won’t belabor the point too much. I don’t disagree with Mr. Cox there but I would only add that I think he’s referring to an explicit feedback step of a larger proposal process, where the initial proposal was likely made by someone qualified to suggest a language change. I consider the feedback step necessary to any process that governs change.
What I meant by pandering to novices was that in the situation where “anyone at all can suggest changes, but changes are only accepted after lots and lots of thought by (many) people who are experts” it’s really just lip service to the initial suggester that they had meaningful input to the proposed changes when in the end it was taken up, shepherded, and likely significantly changed by the experts. That’s fine as a description of the process but I feel that description is just pandering. My personal style is to be more straightforward and set an explicit expectation that language change suggestions are unlikely to be taken seriously from novices, instead of the alternative expectation that anyone at all can contribute at a high level.
It works out okay. RFC is a request for comments, so they do get feedback (sometime too much) and the features are either shaped into something nice, or get postponed or rejected.
Not every feature is a PhD-level type juggling. Some proposals are just for new standard library functions, Cargo flags, or bikeshedding about syntax sugar.
This is so important for every community, and especially for those in leadership roles, to understand. I don’t even write Rust, but I read this anyway because it’s so broadly applicable within programming, or really any technical craft. IMO every language foundation with a significant pool of contributors should have a statement like this. I applaud the Rust Foundation for making an effort to normalize this feeling. ❤
However I’m worried that there is also the opposite. Imposters, bullshitters, arrogance and people that are very much not aware of their skill level thinking they are amazing.
There’s a few things here that I noticed that might help to describe both situations.
Salaries determine how you are viewed. If people are aware of your high salary or think that you are paid well or even if you demand a high salary at a job interview you are viewed more like an expert even if you are not.
On the opposite side of you hear about other people’s salaries and yours is a lot lower you get intimidated.
Job roles/titles are similar.
Used terminology. A lot of buzzwords and trendy terminology can make you seem like an expert both to technical and non-technical people. I’m not talking about professional vocabulary, but für terms that actually are more vague than or simply replace other terms. A lot of them also being created with marketing in mind.
Again with an imposter syndrome having to look up all of them doesn’t feel good it’s even harder when the terms are very vague and things still don’t make sense, because everyone usees them differently and Wikipedia has its own definition.
Rise of frameworks over techniques and age of technologies. People these days define themselves over products/technology implementations and frameworks they know and understand and less over proticols experience in areas, etc. I think it should be a mixture. But what that leads to is that older technologies/products with history, semi obsolete/deprecstedt features, etc. is just very confusing to get into especially when you learn through non official code from either outdated sources or people that simply learned it once and only teach one outdated way. You need to learn both how current things work and often also the history to deal with older (parts of) code.
I think this is why people like to jump on to new frameworks, languages, etc. that are still simple and easy to understand. Sometimes when a project tries to make things easier for beginners they accidentally increase complexity and actually cause the opposite especially if in the long run people also use that feature for other things and it needs changes to better accommodate them.
Then a lot of “smart tricks” are used and features for edge cases get added, people blog about them, beginners overuse them cause they are cool. Slightly more experienced people use it cause they feel an smart and it seems aesthetic to them.
But in the end all of these raise the barrier to get into it or understand code written at different points in time.
The next big thing is crested, some people are freed from their imposter syndrome cause they feel like they have a deep understanding being they’re from the simple start (though of course it might still not free you) and the cycle begins again.
And then people might realize everyone has an imposter syndrome and they pass through it, get self esteem, go further in their career, but end up bullshitting their way through careers, jumping on new tech, never really bothering to understand it out solve problems cause that’s hard work and become expert imposters, maybe even kind of accidentally or without being aware because they get praised for what they do.
Psychology is complicated. I think being aware, talking to others, etc. helps. But people are very good at relating and smart people really good of self-betrayal and arguing things to themselves as well
So what I want to say with this is that I think imposter syndrome should not be seen as a completely stand alone thing. Ave there’s no one size fits all solution and that the way of his to get out of it is also important to not end up in another state of mind one might not want to be in.
To me this is the best argument for salary transparency. Not a solution to the whole problem, but it helps with part of it. That anxiety about salaries is a big part of the power imbalance between employer and employee.
I don’t think I see how salary transparency helps here. You would still be anxious even if you knew all the salaries, no?
Early in my career I’ve been in situations where I knew everyone’s salary, simply because that was a topic people talked about. That pretty much was the time where I had an imposter syndrome.
I agree with you in that power imbalance existing, but it seems relatively small compared to simple things like the employer bring the one both deciding b when you leave and what should be done.
I think it can be good enough to just have people talk.
But then again that’s just from my experiences. Do you have experience with salary transparency? I’m curious about what effects that has in practice.
Sorry, I confess my statement was incomplete. On the one hand I think salary transparency tends to result in more even salaries because people have more negotiating power, though as you point out it can definitely give one more to try to live up to with the associated expectations. On the other hand, what I really want is a company where all salaries for a particular position follow the same, public, pay-scale. There’s a very few companies out there where the pay rates are just published on the careers page, along and it always struck me as a great way to solve so many of the dysfunctions in the job market.
Though I confess I don’t really have much experience with either in practice. Just wishfully thinking “if I ran a company, that’s how I would do it”. Humans are complicated.
I think we need to start posting a lot of essays about the importance of not doing something if you’re just an imposter between now and the next six months when the AI becomes self-aware.
So you’re saying that while imposter syndrome isn’t good, you’re fearing the advent of solving everything with AI suggestions, without actually knowing anything (or trying to understand them) ?
I fully believe that no one should let themselves be intimidated out of learning or pursuing excellence but I sincerely and in good faith disagree with this:
I really want people who suggest changes to languages be experts in that language. It’s frustrating when changes are made to languages that haven’t considered the full gamut of cases that may benefit or be affected by the change. If the Rust community sincerely believes what I have quoted, then long term it will eventually corrupt itself.
How about this as a compromise: anyone at all can suggest changes, but changes are only accepted after lots and lots of thought by (many) people who are experts?
I’m not trying just to quibble. I like the idea of a community open to good ideas from anyone, but also resistant to making changes too quickly or without sufficient consideration.
Sure, but that’s just superficial pandering to the novices in the community. We should just be honest. Novices are at most qualified to express frustrations with a language, only experts are qualified to suggest and make changes to address those frustrations. This is similar to the product design philosophy that “customers don’t know what they want.” It’s up to skilled professionals to design solutions to the problems that users have.
And how exactly does the community become self-sustaining in the production of a steady stream of “experts” and “skilled professionals”, if “novices” are treated as you suggest?
Well, people don’t become experts in a language by proposing poorly informed and misguided changes anyway. ;)
They become experts by writing that language extensively, designing and maintaining libraries, contributing to the implementation… newbies can certainly participate in the discussion of proposals, but it’s really important to know the limits of one’s expertise. “This will break my workflow if accepted” is a useful, much-needed feedback that anyone can give. So is “this fails to account for my use case”. People can also get better at knowing how to see flaws in proposals by doing that.
Experts also must not dismiss proposals “because reasons”. The problem is that a rejection justification can take more time to write than a misguided proposal (a generalization of Brandolini’s law). Giving every newcomer the same amount of the time of current experts is thus counterproductive — there must be filters to weed out obviously bad proposals before they get to the level where the discussion is whether to actually add it to the language or not.
I’m not saying that newcomers cannot make language feature proposals. They (this includes me, in all areas where I’m a newcomer) just should be prepared to face the fact that their proposals are completely misguided and they may need to learn a lot more just to understand why they are misguided.
Plenty of projects allow newcomers to propose things. They aren’t guaranteed traction. They aren’t guaranteed detailed responses from “experts”. But they can still propose things, which is the difference between what I want, and what the parent comment suggested: “only experts are qualified to suggest and make changes”.
All novices should be treated with respect. Their concerns should be listened to and taken seriously. Their opinions on how the language should change should be taken with a grain of salt.
I don’t think allowing novices to take a driver’s seat in your language’s design is the best or only way for novices become skilled professionals in your language. They become skilled through experience with the language.
Why are experts, novices, and skilled professionals in quotes? Do you not believe that those categories exist? Do you not believe that there is a difference in understanding of a language between people who have different amounts of experience with that language?
The whole point of this article is that different people tend to be experts and novices all at once, in different fields. You can be someone with 15 years of experience in memory management, lang dev and compiler dev, and still be a novice in Rust. Similarly, you can be an expert in Rust and not be an expert in memory management, lang dev, compiler dev, whatever.
We are all novices.
Your original proposal was that novices should only be allowed to “express frustrations”. And I don’t see how your attempt to walk that back in this comment is any more respectful than that:
Luckily there’s a wide range of additional options between putting “novices” in “a driver’s seat”, and not allowing them to make proposals at all.
I am skeptical of your usage of these categories.
There’s a story often told from the Django community of a conference where several of the “core developers” (a group which has since been abolished in favor of a different approach to technical decision-making) were present at a post-conference sprint, which had the usual pile of “good first ticket” things set up for new people to work on. But one newcomer went straight for a truly gnarly problem deep in the guts of the ORM, and came up with a patch. It took two “experts” reviewing it together for much of an afternoon to understand that it was the correct fix. The newcomer ended up with a commit bit later on.
If Django had been run on your model, as I understand it, that never could have happened, because the “newcomer” would not have been taken seriously enough by the “experts”.
There are many cases when what seems like a simple fix doesn’t fix the root cause, fails to account for corner cases, or has non-obvious implications. It can certainly take a lot of time for very genuine experts to evaluate a solution.
Also, I don’t think anyone in this thread advocates for judging people solely by their time in that particular project. Experts tend to be relatively good at recognizing experts from related fields.
That appeared to be exactly the criterion advocated above – that not having enough time with a particular language should be an absolute bar to being allowed to suggest changes/improvements to the language.
The universally-loathed state of tech interviewing and hiring is a strong counterexample to this claim.
The standard reply until perhaps 10 years ago was that novices should be humble and take the heat until they are no longer novices. It’s possible that this is not the right answer, but it has served and keeps serving well in many fields.
The problem with this approach is that it selects for arrogance, not competence.
We obviously need a more stringent way of selecting for competence, though. Otherwise, we wouldn’t keep asking why software is still slow despite improvements in hardware, with rants like this one being offered as answers. That link is uncomfortable for me to read because I worry that I’ll be unmasked as one of those impostors. But the incident with Casey Muratori and the Windows Terminal team, brought up by the author of that comment, shows that incompetence really is rampant in the industry.
Maybe take a cue from the embedded world? There are very many competent people there, doing great engineering. This doesn’t have the prestige among non-technical folks that working for FAANG has.
Another thing is that high salaries don’t always attract the most capable people, and even when they do, they may not motivate the capable people to do their best work. Because maybe the work they’re doing is actually BS, they know it, and they’re just punching a clock.
If I keep rambling along these lines, I’m going to get really off into the weeds, so I’ll stop now.
Anyone who claims that “software is slow” because of incompetence is revealing their lack of competence in understanding why “software is slow”, which tends to be a multifaceted issue.
I’m not sure that’s the case…can you elaborate?
Becoming not a novice is generally a matter of self identity. People are humble and take the heat until they decide that they’re not novices. In my experience, the more competent the person is, the more likely that are to self identify as a novice, so you’re selecting for people who are confident in their ability, not people with actual ability. It works in other fields only where there is some rigorous external evaluation of competence (apprenticeships, training, and so on).
The approach, which I’ll name “lurk more”, leads to both false positives and false negatives.
Overall, it may work, and it’s definitely less annoying for some people to be a regular in such communities (because they’ll deal with less novice questions/comments, and the novices will be “better behaved” - those are scare quotes). It might even be unqualifiedly better for communities where people can choose to participate, or there’s an alternative community that’s more welcoming.
The Rust community has, of course, emphatically come down against “lurk more” because they want a more welcoming community, and “lurk more” is not welcoming. As a self-centered person, I would prefer communities I’m not in to be welcoming, and those I’m already in to be “lurk more”. But as an altruistic person, that should persuade me that it’s better to use alternative means (e.g. invite-only groups) to control group behavior.
Definitely not true – I have gotten good suggestions on the Oil language from people who barely know it (which is most people, by definition)
There is simply not that hard a line between “novices” and “experts” when it comes to language design.
It really is true, just as the diagram in the blog post shows, that different people know different things.
Different people have different use cases, and those are valuable.
Nobody can possibly understand all the things a language is used for – somewhat famously Guido van Rossum has never used NumPy, and doesn’t really do scientific computing / linear algebra, yet there are lots of contributors that are not “language designers who have given input and shaped the language. (This isn’t always a smooth process, but it happens, and Python is the most popular language in that domain)
Sometimes the suggestions are impossible, or inconsistent with something that exists already, but those problems aren’t hard to uncover if there is a healthy dialogue
Note also that GvR’s discomfort with performance-oriented design is why CPython still doesn’t have tagged pointers and PyPy still isn’t an official PSF project. Years of wasted effort on forks of CPython were the result. There are similar stories about asynchronous I/O. When a language designer refuses to explore a field of computer science, then it tends to hobble the entire community.
Eh weird tangent, and also untrue on both counts. There are plenty of optimizations in merged into CPython, just not ones that would break all C extensions, like tagged pointers. Essentially every Python release has gotten faster.
Historically, PSF was basically for running Python conferences. PyPy is an amazing project, but I don’t see why the PSF would take it over. At one point >15 years ago there was the thought that it would replace CPython, but there are good reasons that that won’t happen.
You’re getting the point EXACTLY wrong – Guido is not a god and he doesn’t come up with up all ideas, and bless all efforts. Rather, if you care about tagged pointers and performance in CPython so much – YOU should work on it. Plenty of people have – e.g. I’ve noticed heroic efforts improving performance, with compatibility, from Victor Stinner.
Not to mention the recent huge speedups in Python 3.11 – which took outside FUNDING and organization (mostly from Microsoft it seems). PSF is not a wealthy organization.
It might be helpful to know the rough ratio between useful versus nonuseful feature requests for both experienced and brand new oilers.
I’d say that almost all suggestions based on a real problem have been useful, which is probably 80% of them.
Occasionally there is someone who has an “mind bug” idea they haven’t tried … e.g. “I read about some cool thing and I think it should apply to your project” without really doing anything other than writing an e-mail.
But yeah the overall point is that you need a many different viewpoints to make a good language. You also need people to synthesize and simplify them – i.e. the reason people criticize languages like shell, PHP, and C++ is that they seemingly have every viewpoint, which leads to a lot of inconsistency.
I’m familiar with this approach, but I’m not a fan. I prefer something like this paragraph from Russ Cox, in a thread about Go’s proposal process. I don’t think it’s (actually or intended to be) pandering.
Also, for whatever it’s worth, I started a thread on Cox’s posts about the Go proposal process. It’s an important issue for any community.
I think we are more or less on the same page so I won’t belabor the point too much. I don’t disagree with Mr. Cox there but I would only add that I think he’s referring to an explicit feedback step of a larger proposal process, where the initial proposal was likely made by someone qualified to suggest a language change. I consider the feedback step necessary to any process that governs change.
What I meant by pandering to novices was that in the situation where “anyone at all can suggest changes, but changes are only accepted after lots and lots of thought by (many) people who are experts” it’s really just lip service to the initial suggester that they had meaningful input to the proposed changes when in the end it was taken up, shepherded, and likely significantly changed by the experts. That’s fine as a description of the process but I feel that description is just pandering. My personal style is to be more straightforward and set an explicit expectation that language change suggestions are unlikely to be taken seriously from novices, instead of the alternative expectation that anyone at all can contribute at a high level.
It works out okay. RFC is a request for comments, so they do get feedback (sometime too much) and the features are either shaped into something nice, or get postponed or rejected.
Not every feature is a PhD-level type juggling. Some proposals are just for new standard library functions, Cargo flags, or bikeshedding about syntax sugar.
But a request for comment is designed so experts can weigh in and help improve proposals, no?
This is so important for every community, and especially for those in leadership roles, to understand. I don’t even write Rust, but I read this anyway because it’s so broadly applicable within programming, or really any technical craft. IMO every language foundation with a significant pool of contributors should have a statement like this. I applaud the Rust Foundation for making an effort to normalize this feeling. ❤
Imposter Syndrome is a huge problem.
However I’m worried that there is also the opposite. Imposters, bullshitters, arrogance and people that are very much not aware of their skill level thinking they are amazing.
There’s a few things here that I noticed that might help to describe both situations.
Salaries determine how you are viewed. If people are aware of your high salary or think that you are paid well or even if you demand a high salary at a job interview you are viewed more like an expert even if you are not.
On the opposite side of you hear about other people’s salaries and yours is a lot lower you get intimidated.
Job roles/titles are similar.
Used terminology. A lot of buzzwords and trendy terminology can make you seem like an expert both to technical and non-technical people. I’m not talking about professional vocabulary, but für terms that actually are more vague than or simply replace other terms. A lot of them also being created with marketing in mind.
Again with an imposter syndrome having to look up all of them doesn’t feel good it’s even harder when the terms are very vague and things still don’t make sense, because everyone usees them differently and Wikipedia has its own definition.
Rise of frameworks over techniques and age of technologies. People these days define themselves over products/technology implementations and frameworks they know and understand and less over proticols experience in areas, etc. I think it should be a mixture. But what that leads to is that older technologies/products with history, semi obsolete/deprecstedt features, etc. is just very confusing to get into especially when you learn through non official code from either outdated sources or people that simply learned it once and only teach one outdated way. You need to learn both how current things work and often also the history to deal with older (parts of) code.
I think this is why people like to jump on to new frameworks, languages, etc. that are still simple and easy to understand. Sometimes when a project tries to make things easier for beginners they accidentally increase complexity and actually cause the opposite especially if in the long run people also use that feature for other things and it needs changes to better accommodate them.
Then a lot of “smart tricks” are used and features for edge cases get added, people blog about them, beginners overuse them cause they are cool. Slightly more experienced people use it cause they feel an smart and it seems aesthetic to them.
But in the end all of these raise the barrier to get into it or understand code written at different points in time.
The next big thing is crested, some people are freed from their imposter syndrome cause they feel like they have a deep understanding being they’re from the simple start (though of course it might still not free you) and the cycle begins again.
And then people might realize everyone has an imposter syndrome and they pass through it, get self esteem, go further in their career, but end up bullshitting their way through careers, jumping on new tech, never really bothering to understand it out solve problems cause that’s hard work and become expert imposters, maybe even kind of accidentally or without being aware because they get praised for what they do.
Psychology is complicated. I think being aware, talking to others, etc. helps. But people are very good at relating and smart people really good of self-betrayal and arguing things to themselves as well
So what I want to say with this is that I think imposter syndrome should not be seen as a completely stand alone thing. Ave there’s no one size fits all solution and that the way of his to get out of it is also important to not end up in another state of mind one might not want to be in.
To me this is the best argument for salary transparency. Not a solution to the whole problem, but it helps with part of it. That anxiety about salaries is a big part of the power imbalance between employer and employee.
I don’t think I see how salary transparency helps here. You would still be anxious even if you knew all the salaries, no?
Early in my career I’ve been in situations where I knew everyone’s salary, simply because that was a topic people talked about. That pretty much was the time where I had an imposter syndrome.
I agree with you in that power imbalance existing, but it seems relatively small compared to simple things like the employer bring the one both deciding b when you leave and what should be done.
I think it can be good enough to just have people talk.
But then again that’s just from my experiences. Do you have experience with salary transparency? I’m curious about what effects that has in practice.
Sorry, I confess my statement was incomplete. On the one hand I think salary transparency tends to result in more even salaries because people have more negotiating power, though as you point out it can definitely give one more to try to live up to with the associated expectations. On the other hand, what I really want is a company where all salaries for a particular position follow the same, public, pay-scale. There’s a very few companies out there where the pay rates are just published on the careers page, along and it always struck me as a great way to solve so many of the dysfunctions in the job market.
Though I confess I don’t really have much experience with either in practice. Just wishfully thinking “if I ran a company, that’s how I would do it”. Humans are complicated.
Yeah, I agree. That’s what it boils down to. But that makes those topics really interesting. :)
I think we need to start posting a lot of essays about the importance of not doing something if you’re just an imposter between now and the next six months when the AI becomes self-aware.
So you’re saying that while imposter syndrome isn’t good, you’re fearing the advent of solving everything with AI suggestions, without actually knowing anything (or trying to understand them) ?
No, I want the AGI to think it’s not really that intelligent and be too intimidated to conquer the world.