Excellent perspective. Organisations are similar to individual human minds in structure, but scaled. They will make mistakes, just like people do, but also correct themselves over the long haul so that they can survive.
A more stark example is that of Newton. A true philosopher, by hacker news standards he'd be considered a misguided madman, since he spent 2/3rd of his life on "unproductive" topics such as religion and alchemy. However, the "productive" 1/3rd cannot be separated from the rest.
One must remember that the word "scientist" was coined merely in 1834...the word isn't 100 year old even. Newton saw himself as a philosopher, he studied the ancients intently, etc. The same applies to many of his contemporaries as well.
My overall point is, one shouldn't judge a person too harshly for any particular piece, while ignoring their larger contributions and efforts.
VSCode/IDEs and Vim need not be mutually exclusive. I tend to rely on vim emulation within my vscode, chrome and in other applications. Usually, all I need are the basic vim modalities with the nicer amenities provided by modern editors.
The well known “Vim mode paradox”: if you like the Vim mode provided by another editor, it means you don’t know Vim well enough to justify using Vim nor Vim mode. Vim modes don’t approach even 10% of the Vim features you need to reach the bare minimum of efficient editing.
Trying it out again now, this isn't Vim, it's an entirely different product. It doesn't have command editing mode q: nor q/. It doesn't use Vim's regexes and doesn't support \v (which is probably good, Vim's regexes are very bad, but it's still not Vim). There is limited support for windowing, I mean not really support at all, because this is a better windowing system that Vim (:h CTRL-W_J). Although I am surprised `ctrl-w +` works. Of course no support for Vim plugins like surround.vim. Vim out of the box is not a usable editor. H and L seem to be busted and scroll the screen.
Still trying it, no `:norm`, no `:g`, multiple cursors in VSCode are so much more powerful than this, and already do 90% of what you want to do in Vim in the first place.
Read about Admiral Rickover. He built the first practical nuclear submarine in the world, for the US navy, in record time of 3 years. He cleared bureaucratic hurdles, played the politics when needed, kept tight control, delved deep into the technicalities of the project, recruited and trained a large number of people into the program, and ultimately made the project successful.
Dig deeper into any other large scale projects, you'll find great engineering management. The Manhattan project is another example (It should be categorised mostly under engineering management & not scientific management, according to some of the members in the team).
I think there is a huge difference between managers who can get a project over the finish line and ones who can get multiple large projects over the finish line. I'm not saying that Admiral Rickover didn't/couldnt do that but many managers are effective at cracking the whip and making X happen but at the expense of their teams health which leads to burnout and turnover.
I'd also say military management is significantly different than civilian. If my manager tells me to jump I'm not going to say how high. I'm going to say why are you asking me to move its early and i havnt had coffee yet.
Rickover was near the top echelons of US navy for ~60 years, as far as I know. Definitely, he knows a thing or two about burnout and turnover. He executed many, many sophisticated projects throughout his life. That's why he had such a long & successful career. I'd recommend reading his book - The never-ending challenge of Engineering. In my readings, this has been the best book on Engineering management.
Secondly, about burnout and turnover. Let's discuss from an empirical standpoint. The number one proximal cause of turnover is lack of "commitment". There are longitudinal empircal studies which demonstrate this. Job satisfaction is important as well; however commitment dominates every other factor.
Hence, it is important for managers to generate commitment, one way or another. I believe from these aspects, Rickover truly understood engineers and technical folks... In fact, he went against the US military books, and emphasised Individual initiative and judgement, regardless of what the rulebooks said. In a way, Rickover was able to work around the navy rules to create sufficient commitment to get complicated jobs done.
I for one consider social methods part of the problem solving process.
Knowing who knows what, and who can help, and asking for help the right way is key to getting better at problem solving.
Perhaps it is the school system that discourages problem solving through social means, and people feel guilty about taking help.
However, consider this perspective. What if the ones who could put together people into functional groups could be considered great problem solvers? Consider any of the great American enterprises, there are people at the top who figured out how to put people together to get things done.
I recommend you dig deeper into Buddhism to grasp how flexible & responsive the religious leaders are to scientific advancements.
A book from Matthieu Ricard, an ex western scientist who later became a Buddhist monk and Dalai Lama's interpreter, wrote a book with a western quantum scientist [Quantum and the Lotus](https://www.amazon.com/Quantum-Lotus-Journey-Frontiers-Buddh...). What is notable is how the exemplary practitioners are highly knowledgeable in scientific and philosophical subjects.
Moreover, you can see that both Dalai lama and the other top leaders of Tibetan Buddhism proactively collaborate with scientists on experiments and discussions to learn more.
I have a question for experienced/skilled FOSS maintainers.
Are there any good ways to convert those who comment/suggest into contributors? I feel like instead of simply dismissing suggestions with "you get what you paid for", there must be a better way to handle the situation. Or perhaps I'm too naive on the topic
this is really hard. i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.
most of the time when i d̶r̶o̶p̶/contribute a suggestion as a user then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and contribute a patch.
and for those who don't know how, most likely the idea they had is more complex than they would be able to do as a first project, even if they were willing to learn. they are better off contributing in other areas that match their skill-level or enable them to learn. but how to motivate them to work on something that does not relate to their suggestion? maybe by arguing that if they help with those beginner tasks over there, then someone else can find the time to work on their idea, but it feels risky to make that kind of promise.
so i would rather focus on those who say they want to contribute something but don't know what because they feel they don't have the skill. those are hopefully motivated to learn. point them to issues that are suitable for people starting out.
and for anyone else: thank you for the suggestion. patches for this idea are welcome. (and optionally) feel free to ask for pointers how to get started.
I am a CS student, three years away from being a software engineer.
Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
That demotivates me a little about starting simple bug fixing PRs for big projects.
> I am a CS student, three years away from being a software engineer.
Three years away from having a degree. If you routinely do software engineering, you're a software engineering (possibly s/engineer/develop/ for a similar claim.)
> Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
You are a saint! I would _love_ for people to read through my code looking for bugs and oddities.
Just remember that some FOSS projects are coded well, while others are coded horrendously.
> I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
>
> Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
If you are considering writing a PR, get in touch with developers in a chatroom, or even over email, to coordinate this. They are likely to respond favorably to offers of PRs, and tell you things like "Don't do it now, we have a refactor coming up" or "base yourself off of this branch". And even if they say "not interested, don't bother" - you've still gotten useful information from them.
first of all, don't give up. being ignored or overlooked is part of the FOSS experience. not every developer is available all the time, some only work during holidays or whenever the mood strikes them. some would prefer to ignore rather than reject someone, or (especially on popular projects) they may be so busy that they simply didn't see your submission.
when you fix a problem consider first of all, to do it for yourself. for your experience, or to solve a problem that you actually have.
fixing a problem and then finding out that it is already fixed, or that someone elses later fix was accepted ignoring yours, is also a common experience. there is nothing malicious about it. communication is just not perfect, and for some things, it may just be easier for the known and trusted developers to fix a problem themselves rather than to take the effort to review your contribution, even though taking care of your contribution would give them the opportunity to invite a new contributor. not every project has inviting new contributors on their radar.
my suggestion would be to look at projects that have an explicit policy of being welcoming to new contributors. they will either say on their site or in the documentation, or they have issues that are marked "good for beginners" "or good for a first contribution" or something similar.
work on such issues. join the community, their mailinglists, chat rooms, or whatever they use, and talk to other developers there. get to know the people, help other new contributors, make friends. later when one of your submissions is ignored or overlooked again, those new friends will be able to help you get attention to it. or they may know why it was ignored.
Fwiw, dont be afraid to jump right in. Your patch might get rejected, but that happens to experienced people all the time too, and is no big deal.
PRs that get ignored is really demotivating. It can depend on which project a lot. If you're new to the project informally (and politely) chatting about your patch on project's irc/discord can help ensure you are not missing any social conventions.
> i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.
That is true, but there are also other issues, such as:
- Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature.
They might not accept the change, leading to further things below:
- Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended.
- Needing to maintain your own fork of the project.
- If making multiple patches, making them to not interfere with each other.
I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain).
> most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch.
I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list:
0. It already has this feature, or this capability can be easily done by the existing features.
1. Yes, I will likely add it soon (and may be working on it already).
2. Yes, but it is not a high priority; it may be added later.
3. Yes, but more work will be needed before it is added.
4. Probably; more work will be needed, and/or design decisions must be made, before it is added.
5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added.
6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable.
7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though.
8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it.
9. No, it is probably too complicated and not very helpful anyways.
10. No, it is probably impossible. Forking it probably won't help.
11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc.
In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc.
sorry, i slightly edited my text to clarify that i was talking from the user perspective and didn't mean to imply that i just drop/reject suggestions as a project owner. for that, your list of responses is very good.
The internet is full of crazy people. "You get what you pay for" is usually used on people who are obnoxious and super entitled. Its not generally (at least in my experience) used on people who are making good faith suggestions. Its used on people who want you to be their personal slave. I generally have only ever used "you get what you pay for" or "i would be happy to provide a full refund" to extremely rude people, as a slightly more polite version of "fuck off".
People who make good faith suggestions can sometimes be converted, but you also have to respect that some people don't have the inclination or time but can still make good suggestions. Sort of similar to how on an internet forum most people are lurkers and that is ok. Good faith suggestions are really valuable to open source projects.
I tend to use the human potential framework. As a human being, I have a potential capacity to do sophisticated things or to merely operate at the level of an animal. Developing capabilities & skills is what differentiates me from an animal. This always fires me up.
Second thing that helps is, defining "huge" within the right context. Your project looks large from a self-centered point of view. Think about human flight - took 2000 years, multiple generations to figure out. Go into the history of various inventions, they all took lots and lots effort. Once this context is understood, you'll find that whatever you're doing is not necessarily such a "huge" task. Such perspective helps too.
Third, the characteristic of good goals is this:
Good goal = Difficult + Specific
The whole point of good goal is it helps you extract more effort from yourself. In a way, you set goals so that you can do more. If your goal demands more of you, it means the goal is doing its magic! So why'd you become discouraged when a goal demands more of yourself? By stretching yourself, you'll become more capable.
In buddhism at least, developing compassion is seen from a skill-building perspective as far as I know. Most human capabilities have to be amplified through deliberate study from our ancestry, accumulated wisdom and constant practice.
The key idea is that we can "develop" various attributes to a degree which is orders of magnitude larger than the next animal. To me, doing that is meaningful.
