This article talks about two main things. Accepting "help" applies more broadly than engineering or software.
And I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.
This mostly sounds like the project owner doesn't have experience, or perhaps more importantly time, to manage the project and 3rd party contributions. Nothing is wrong with that, of course - but the framing here, I take issue with.
Placing the codebase on GitHub would allow folks to work and make contributions in the form of a Pull Request, which the OP can reject with explanation if it does not go in the direction they desire. They can even setup a roadmap and tickets (issues) to help guide eager-to-help offers.
For anyone wanting to take the project in a direction OP doesn't want - they can fork it and do just that.
So no, don't beware of offers to "help" - be aware of your time commitments and that not everyone's goals will always align with yours. That's just how open source works...
What I read sounds like the project owner can clearly articulate the projects purpose (a point about free speech and big tech v lightness and about enabling).
And the proposed contributions are reasonably contrary to them as he sees it.
Experience, time... I think the response in this case was perfectly reasonable so I don't know how to remark on this.
Hosting the code (someplace) and discussing issues may be separate good suggestions, all in the context of the projects purpose.
I think the confusion is coming from it being a social network which requires them to ask people for “help” to prove out their ideas — you can’t have a network without users.
Having people helping to prove the idea is one small step away from having people helping to implement the idea and, IMHO, is where the confusion is coming from. They want to implement the idea without help but can’t because the idea itself can’t work without help and helpful people are, unfortunately, helpful.
By the point of “It is being so wrapped up in yourself and your own goals that you cannot accept the fact that your goals are not more important that those of everyone around you.” I couldn’t help but think of the expression “Pot…Kettle…Black.”
I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
If you think there was hypocrisy then I think you lost the thread - the point is not accepting help from people who are more interested in their own vision of the project than yours (as the originator of that project). Hence why they don't accept offers of volunteer help.
The author is not being hypocritical. They can accept that their goals are not more important than the person emailing them. But (in the author’s view) their goals are incompatible. This project can only achieve one set of goals. If they try for both, it’s likely neither. So, the project goes as-is.
I can think that my hunger isn’t more important than my family’s, but if someone offers to help eat the sandwich I just made reply “go make your own”.
> I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
You might be surprised at the number that do think it's double or close to it.
In reality it's often negative productivity. The current engineers have to lose time training the newcomers and the newcomers might not even be versed or skilled in any part of it at all.
I recently forked a project to make some significant changes to make it more useful for my needs. The direction I took the fork is different from needs of the original author. My version is definitely much more useful for other people but wouldn't be any help to the goals of original project.
But I'm very thankful that the original author just posted his code to Github to make this possible.
Yeah, I'm confused as to why the author wouldn't make their source code available with a message that says "I am not looking to accept pull requests or help with this project, but I'm providing the code in case it's useful to anyone in their own pursuits."
That seems like it would make everyone happy, wouldn't it?
Haha, you'd think. You can disable issues, but not pull requests, which has been a pain point for the last... forever[0]. Best you can do is setup workflows to automatically close and lock every pull request (and optionally, add an exception for a single pull request that says in all caps "DO NOT OPEN PULL REQUESTS"). It's as painful as it sounds.
You can be open to contributions and help while still wanting to maintain a certain direction for a project (rather than it becoming a democracy, or a "must solve all use cases"-type of project). Actually, I think that's how most projects are run.
Yes, but that puts the onus on the maintainer to actively reject contributions that they don't like. It doesn't help that often people will implement something without even asking if its right for the direction of the project and then come with the expectation that upstream will accept it. You could say that thats on them for having the wrong expectation but that doesn't change that it isn't fun to tell people "no".
Still, forgoing all contributions for that or even keeping the source closed is throwing out the baby with the bathwater. Even if you don't want any features being contributed at all there is value in accepting patches for bugfixes.
It gets even less fun when they won't take no for an answer and want to argue with you about it: it sucks up time and energy you may not want, or even have, to give. It becomes unnecessary noise and distraction, which is a huge problem if your life is already busy.
I am being sarcastic. I think it’s more nuanced than the author thinks and he’s projecting.
Other people have egos but he probably does too for wanting the project to be an extension of himself.
It’s okay to want that, but other people aren’t bad and selfish for not conforming to your will. Sometimes you just don’t see things eye to eye and need to move on.
Not if the most obvious forks would starve out adoption of the original, more niche project. That would make the original dev unhappy.
His stated purpose is for his project to proliferate and teach people to host their own social networks. It's very unlikely that this would compete effectively against larger social networks based on his stuff, that ask less of the user and offer significantly larger networks.
> But I'm very thankful that the original author just posted his code to Github to make this possible.
That does not make forking possible. There are many projects on GitHub that are not open source. One should be thankful for the author for licensing their software using an open source license.
I think you can still fork it if it's not free software, but it needs to be a private fork. I think that, unless they say they are distributing their software on certain conditions, just copyright alone wouldn't prevent you from modifying the code for personal usage.
> just copyright alone wouldn't prevent you from modifying the code for personal usage.
This is correct. Copyright prevents you from distributing the protected work. It doesn't prevent you from taking it and doing whatever else you want with it.
(I'm ignoring the DMCA anti-circumvention clause here because that's a whole different issue and rarely actually comes into play)
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
The maintainer does not owe their time to anyone
The maintainer must treat everyone with respect
Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
1.) Maintainers are the keepers of the project principles
2.) The goal of the software.
3.) The scope that defines problems that the software will try to fix and those it will not.
4.) The style of the project: which programming practices are used, which language.
5. The culture by which the project is managed.
6. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed.
The author seems to propose it is impossible for large teams to be productive. They even go so far as to claim most potential team mates have malice intent to “sabotage the project”.
Amazon is an example of an organization that does this well (i used to work there). Small teams are responsible for their own project(s). Project(s) can be composed to form higher level project(s). It’s certainly not impossible, and id rather put in effort to manage team(s) than to place an increasingly insurmountable amount of pressure on myself.
Perhaps the reason the author’s project has “few users” is that there are competing alternatives that have authors who understand how to leverage team work to deliver more value to users, and users go where they perceive value.
Also, if you worked for an organization that actually hired (and retained) people with malice intent, i dont think team size was the real issue. In that sense i do agree with the author that you should screen anyone and ensure your goals align before agreeing to invest time in trying to work together. If someone is offering to add a feature you dont think fits in the project, i have a hard time characterizing that as “malice intent”, though!
This story sounds quite a lot like a few experiences I had.
Years ago (more than I'd like to admit), I took to playing Travian with friends and coworkers. Travian is an RTS, where 'Realtime' really means 'Real-Time'! If you attack the town next to you, just a few squares away, it can take 5 hours for your troops to arrive and the battle to ensue.
It was the perfect game; you could play it casually, in between stuff at work during the day, or on break, or in the evening.
My friends started getting really into it and spending a lot more time on it. I did not want to spend more time playing it, but it was a fun game. The makers of Travian did something interesting, though - they would dump one database table with city data every night for people to do interesting things with. My friends were using a bunch of these tools already, but I perceived some opportunity to build tools which didn't yet exist - like a tool which let you discover inactive accounts to pillage. I starting building more and more tools, eventually starting to write a bot to play the game for me, by automatically raiding inactive accounts and automatically building up my current towns to avoid appearing inactive. My goal in doing this wasn't to play the game per se, but to learn and get better at programming.
So I made the mistake of mentioning all this to another friend who was playing Travian. He was interested. I told him if I ever finished, he could try out the bot, but in the meantime he could use the rest of my tools.
Well, he got impatient waiting for the bot (which btw, I never finished, but I did learn some cool stuff from the experience). He decided he was going to 'help' me, by group calling me with another programmer friend of his who first of all quizzed me on how I was building it, and telling me I was doing it the wrong way and that I needed to use different languages, frameworks, messaging layers, etc. Yeah, so now that I am way further in my career, that guy was dead wrong and an idiot who was trying to overcomplicate everything. But the point was - he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project.
This actually really strained my relationship with my friend. Huge dick move, and one that took me a long time to forgive him for. Stay out of my personal projects! To me, it felt along the lines of hearing about an argument with my wife, and then unbidden forcing me to take a call with a relationship coach who told me I was a bad husband.
> "My primary goal for Xnet is to prove that--contrary to everything everyone else says--one does not need a huge, expensive server on a super-fast Internet connection to host a social network with tens of thousands of users"
I don't think "everyone else" believes that. In fact I believe a "social network with tens of thousands of users" can probably be served off a bash script running on a Raspberry pi over SQLite.
I mean, that basically describes a telnetable bulletin board system, and those definitely run off an RPi.
This is a common problem with tech-adjacent types: believing that technology is the solution to all problems, including social ones. If someone isn't using your preferred social networking solution, the problem isn't necessarily that you're not using the latest whizbang language and hardware....... maybe you just haven't given them anything to do on your network. Put another way: the telephone arguably didn't catch on as a utility with obvious use until after the 1878 Tariffville Crash[1]. If you want to start a new network, you need a social nucleation point... whether that's you writing interesting stories, composing music, making artwork, whatever... SOMETHING that people can participate in and interact with in some fashion. Without that you've just got a communications device with no one in particular to reach for any reason.
Software projects need a "Director" - much like a Film Director.
This person has ultimate control over what the software should be.
I'm always surprised to find software that is a really cohesive and appears to be the implementation of a clean and consistent vision, because software projects have so many people pulling it in so many directions.
This is, IMO, why MacOS is such a simple and clean and consistent implementation and Windows is just spaghetti soup. I don't know the truth of how these projects are run but I imagine at Apple there is someone at the top with a really clear vision of what MacOS should be.
I'm sure that somebody has thought this through more fully than myself, but the impression I have is that for software, the benevolent dictator model works best. Python and Javascript occupy adjacent places in the programming language firmament, but the Python language (with van Rossum having fairly tight control over it), although bloating somewhat over time, has still ended up quite a lot more elegant than Javascript.
Ironically, Guido got dethroned precisely because python became too popular and “you can’t please all of the people all of the time” so he just walked away.
Now they have committee meetings to decide if an idea is good enough to form a committee to discuss if a committee should be formed to discuss the idea — though, probably not exactly like that…
Modern python is not more elegant than modern JS, I disagree (I’ve been coding in both for over 15 years).
Python has a good degree of elegance to it, and it does have less warts due to its less stringent backwards compatibility requirements. But JS is very elegant, and better at it than python thanks to python’s shitty lambdas vs js anonymous functions.
There’s nothing elegant about continuously accreting features.
If JavaScript were limited to The Good Parts I could say it’s elegant. As it stands I’d describe it as more akin to Frankenstein’s monster but riddled with tumors.
Maybe a silly question, but if js is such a complete language, why are there so many js frameworks being developed all the time, all seemingly with the goal of making it easier to do fairly basic tasks with js?
Elegance and completeness are two different things. But to answer your question anyway, I would say a framework's goals are more specific than the language's.
For example, Python serves both the data science community and the embedded community. The two have wildly different goals, and thus, different frameworks to achieve "fairly basic tasks [for their domain]".
JS serves so many different communities/domains, which is why there are so many frameworks. Larger audience, with even more different needs. The fact it can serve so many different audiences is a testament to its elegance.
Apple came up with Swift. Apple's pulled off multiple changes in processor architecture (68k/PPC/Intel/Apple Silicon). They are pretty much the poster child for 'my way or the highway', for vision that shows no interest in compromising with the weight of accumulated expectation.
They're consistently willing to throw everything away and make up a new thing and force everybody to do that (and re-buy all their stuff). I don't know the specifics of how, organizationally, they do it.
They're a proof that this way of doing things can be successful, and profitable.
You aren't totally wrong, but the dozens of different dongles I bought over the decades using Apple gear are a nuisance. The amount of display adapters alone...
Am I missing something? There is no lesson learned here. No offer of help was accepted and nothing went wrong. Why beware? He hasn't even tried it. Hell I can't even really parse if there ever was an offer to help, just some suggestions.
That's basically what the article is saying, though, isn't it? The author wasn't deceived by an offer and didn't suffer a setback, they're just commenting on the fact that offers of help always carry some kind of cost. In this case the cost was compromising on their goals for the project. It goes in the same basket as any other unsolicited opinion on the internet, including this one.
The author wasn't deceived, in fact no one even tried to deceive him. Rather, a guy offering to help clearly communicated his intentions, so that the author was able to make an informed decision to decline that help.
From the very limited information presented, it's not clear to me why the author would judge this offer to be a selfish act, or why this anecdote would support his conclusion to "beware offers of help".
If the person who offered helped had technical chops to scale such project. Why they would approach existing project owner instead of building it themselves?
My explanation is they did not have what is needed like tech skills or they were after taking over existing users.
Idea of scaling something up as author noted usually comes with idea that money will eventually follow. Post author is not money driven so it might be that person offering was also different in that way.
Because said user was invested in this community, and reinventing the wheel further is sometimes not beneficial. Some people are really good at specialized tasks, but might not be good at other tasks. Really good backend engineer, not so great at frontend. Perhaps they don’t have the necessary marketing skills required for growth of their own. There are too many unknowns in this story, and it isn’t fair to paint the person harshly like that.
The author has been burned by this in the past many times. You try to include people who say they want to help.. but when alignment is off it winds up just hurting the project.
I've encountered this with dozens of contributors myself.
Such projects have phases of development. If too many people get involved too early, you easily create a "too many cooks in the kitchen" situation.
But once the long-term architecture is largely defined and implemented, there's usually enough inertia and established compartmentalization of modules that more developers can participate without ruining the soup.
No? They're not forcing, or even encouraging, people to help them. People just... Want to. It's not narcissistic to say "Oh... Well I was planning to work on this myself, you can help if you want, but I have my own vision that I don't want to diverge from"
This is terrible anti-social advice. Getting projects to work is about organizing people to work together. Unless your DJB, software is a team sport. If it is a one person project it will fail.
Now when somebody offers to help, be welcoming because it's amazing. But also remember that most of the time their desire to help won't translate in to something useful. That's ok, eventually people will show up who are helpful. Keep being open.
Also, what the hell is somebody doing making a social network if they don't like people.... WTF!?
On the contrary, the right way is to ask first before making large changes that might not even be wanted. For obvious fixes sure, shoot first. For anything more complex it is inconsiderate to put the maintainer into a position where they have to choose between comprimising their project or hurting your feelings.
I think the author is taking a bit of the wrong lesson from his experience.
One of the challenges of coordinating a group of people is getting everyone to buy into the same vision. Fact is that other people see the world differently and may have different goals. Here the author is attributing that to narcissism and maliciousness when most of the time it isn't that.
So yes, as you add more people it gets more challenging to get everyone rowing in the same direction. This is why setting a clear direction and clear communication is key, but the increase in communication overhead as the team grows is always going to be difficult. In this case, as others have said, he could've just open-sourced his code so the people who had a different idea were free to run with it.
Definitely read Mythical Man-Month, which describes how adding more people may delay a project due to communication overhead ("why did the Tower of Babel fail?").
I was thinking this article would be an example of that, but actually while Mythical Man-Month mostly assumes that new team members would share the same visions and goals, this article takes a more adversarial view where new team members are assumed to come with their own agenda. I believe it's a form of cookie licking[1].
It’s not narcissism. Don’t use terms you’ve researched on Wikipedia to diagnose other people. If that’s narcissism, then what’s creating a project that is the unique extension of your own values?
I’ll answer: both are legitimate ways to approach the world, that may involve an acceptable and perhaps at times level of selfishness.
Sometimes things don’t work with other people because you don’t see things the same way. They are not Wrong and Bad.
I like that I can scan down the comments on HN and usually find one that says what I wanted to say.
Damn straight. It's not narcissism to have ideas and be excited about them and to suggest that a team or a founder pursue those ideas, whether or not that jibes with someone else's original vision.
The OP doesn't tell us what the reaction was of the person who offered him help, when he re-explained his vision. Was the reaction something like "oh, okay, I didn't realize you felt so strongly about that?" Was it "I'm a narcissist and I don't care what you want?" I think the OP might be a little insecure about negotiating with other people-- which is fine-- but what not fine is to turn that into universal advice for other people about not talking to strangers.
I read it clearly as someone who does not want to work with other people and deal with their bs. That’s fine, I get it. But at least be mature about that and own it.
There’s a reason why there’s a profession in software—management—that often exclusively involves dealing with other people. In fact, good management is critical to the success of any large project. But it’s not an easy job.
Anyone have a link to the post the author referenced here? "A couple of weeks ago, someone else <posted> his desire to help code Xnet, and he included his vision of the direction it should go" (emphasis added)
The way this story was presented makes me curious to see the dialog (if there was any) between the author and the guy who offered to help.
Sometimes my 5 year old wants to build her block tower just the way she wants, and she says no thank you if someone offers to help. Other times she accepts help and then the tower takes a different form. Both ways are OK.
166 comments
[ 3.5 ms ] story [ 283 ms ] threadAnd I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.
Placing the codebase on GitHub would allow folks to work and make contributions in the form of a Pull Request, which the OP can reject with explanation if it does not go in the direction they desire. They can even setup a roadmap and tickets (issues) to help guide eager-to-help offers.
For anyone wanting to take the project in a direction OP doesn't want - they can fork it and do just that.
So no, don't beware of offers to "help" - be aware of your time commitments and that not everyone's goals will always align with yours. That's just how open source works...
Just instead say you're not interested in doing OSS and want to keep the project private. You're not obligated to do anything.
Often that alone - going through pull requests is time consuming enough to drain you.
Experience, time... I think the response in this case was perfectly reasonable so I don't know how to remark on this.
Hosting the code (someplace) and discussing issues may be separate good suggestions, all in the context of the projects purpose.
Having people helping to prove the idea is one small step away from having people helping to implement the idea and, IMHO, is where the confusion is coming from. They want to implement the idea without help but can’t because the idea itself can’t work without help and helpful people are, unfortunately, helpful.
Totally wrong message being learned here.
I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
I can think that my hunger isn’t more important than my family’s, but if someone offers to help eat the sandwich I just made reply “go make your own”.
Just say no. Done deal.
You might be surprised at the number that do think it's double or close to it.
In reality it's often negative productivity. The current engineers have to lose time training the newcomers and the newcomers might not even be versed or skilled in any part of it at all.
But I'm very thankful that the original author just posted his code to Github to make this possible.
That seems like it would make everyone happy, wouldn't it?
Clone it. Fork it. Star it. That’s it.
[0]: https://github.com/github/dmca/pulls
Still, forgoing all contributions for that or even keeping the source closed is throwing out the baby with the bathwater. Even if you don't want any features being contributed at all there is value in accepting patches for bugfixes.
It gets even less fun when they won't take no for an answer and want to argue with you about it: it sucks up time and energy you may not want, or even have, to give. It becomes unnecessary noise and distraction, which is a huge problem if your life is already busy.
Other people have egos but he probably does too for wanting the project to be an extension of himself.
It’s okay to want that, but other people aren’t bad and selfish for not conforming to your will. Sometimes you just don’t see things eye to eye and need to move on.
His stated purpose is for his project to proliferate and teach people to host their own social networks. It's very unlikely that this would compete effectively against larger social networks based on his stuff, that ask less of the user and offer significantly larger networks.
> But I'm very thankful that the original author just posted his code to Github to make this possible.
That does not make forking possible. There are many projects on GitHub that are not open source. One should be thankful for the author for licensing their software using an open source license.
Note that this doesn’t extend any of the other rights associated with open source.
This is correct. Copyright prevents you from distributing the protected work. It doesn't prevent you from taking it and doing whatever else you want with it.
(I'm ignoring the DMCA anti-circumvention clause here because that's a whole different issue and rarely actually comes into play)
""" Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
The maintainer does not owe their time to anyone The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
1.) Maintainers are the keepers of the project principles
2.) The goal of the software.
3.) The scope that defines problems that the software will try to fix and those it will not.
4.) The style of the project: which programming practices are used, which language.
5. The culture by which the project is managed.
6. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed.
"""
Amazon is an example of an organization that does this well (i used to work there). Small teams are responsible for their own project(s). Project(s) can be composed to form higher level project(s). It’s certainly not impossible, and id rather put in effort to manage team(s) than to place an increasingly insurmountable amount of pressure on myself.
Perhaps the reason the author’s project has “few users” is that there are competing alternatives that have authors who understand how to leverage team work to deliver more value to users, and users go where they perceive value.
Also, if you worked for an organization that actually hired (and retained) people with malice intent, i dont think team size was the real issue. In that sense i do agree with the author that you should screen anyone and ensure your goals align before agreeing to invest time in trying to work together. If someone is offering to add a feature you dont think fits in the project, i have a hard time characterizing that as “malice intent”, though!
Not productive, efficient.
It was the perfect game; you could play it casually, in between stuff at work during the day, or on break, or in the evening.
My friends started getting really into it and spending a lot more time on it. I did not want to spend more time playing it, but it was a fun game. The makers of Travian did something interesting, though - they would dump one database table with city data every night for people to do interesting things with. My friends were using a bunch of these tools already, but I perceived some opportunity to build tools which didn't yet exist - like a tool which let you discover inactive accounts to pillage. I starting building more and more tools, eventually starting to write a bot to play the game for me, by automatically raiding inactive accounts and automatically building up my current towns to avoid appearing inactive. My goal in doing this wasn't to play the game per se, but to learn and get better at programming.
So I made the mistake of mentioning all this to another friend who was playing Travian. He was interested. I told him if I ever finished, he could try out the bot, but in the meantime he could use the rest of my tools.
Well, he got impatient waiting for the bot (which btw, I never finished, but I did learn some cool stuff from the experience). He decided he was going to 'help' me, by group calling me with another programmer friend of his who first of all quizzed me on how I was building it, and telling me I was doing it the wrong way and that I needed to use different languages, frameworks, messaging layers, etc. Yeah, so now that I am way further in my career, that guy was dead wrong and an idiot who was trying to overcomplicate everything. But the point was - he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project.
This actually really strained my relationship with my friend. Huge dick move, and one that took me a long time to forgive him for. Stay out of my personal projects! To me, it felt along the lines of hearing about an argument with my wife, and then unbidden forcing me to take a call with a relationship coach who told me I was a bad husband.
Maybe that’s just the way he approaches problems. Not necessarily helpful to you, maybe legitimately annoying, but why assume the worst?
But that surely would have been the result, had I taken his advice verbatim.
I don't think "everyone else" believes that. In fact I believe a "social network with tens of thousands of users" can probably be served off a bash script running on a Raspberry pi over SQLite.
This is a common problem with tech-adjacent types: believing that technology is the solution to all problems, including social ones. If someone isn't using your preferred social networking solution, the problem isn't necessarily that you're not using the latest whizbang language and hardware....... maybe you just haven't given them anything to do on your network. Put another way: the telephone arguably didn't catch on as a utility with obvious use until after the 1878 Tariffville Crash[1]. If you want to start a new network, you need a social nucleation point... whether that's you writing interesting stories, composing music, making artwork, whatever... SOMETHING that people can participate in and interact with in some fashion. Without that you've just got a communications device with no one in particular to reach for any reason.
-- [1] https://en.wikipedia.org/wiki/1878_Tariffville_train_crash
I wonder what the best ways of discovering (and perhaps verifying) alignment-or-not could be.
This person has ultimate control over what the software should be.
I'm always surprised to find software that is a really cohesive and appears to be the implementation of a clean and consistent vision, because software projects have so many people pulling it in so many directions.
This is, IMO, why MacOS is such a simple and clean and consistent implementation and Windows is just spaghetti soup. I don't know the truth of how these projects are run but I imagine at Apple there is someone at the top with a really clear vision of what MacOS should be.
Now they have committee meetings to decide if an idea is good enough to form a committee to discuss if a committee should be formed to discuss the idea — though, probably not exactly like that…
Python has a good degree of elegance to it, and it does have less warts due to its less stringent backwards compatibility requirements. But JS is very elegant, and better at it than python thanks to python’s shitty lambdas vs js anonymous functions.
If JavaScript were limited to The Good Parts I could say it’s elegant. As it stands I’d describe it as more akin to Frankenstein’s monster but riddled with tumors.
You responded to an opinion which compared the relative elegance of two scripting languages with your own opinion.
I also provided an opinion.
For example, Python serves both the data science community and the embedded community. The two have wildly different goals, and thus, different frameworks to achieve "fairly basic tasks [for their domain]".
JS serves so many different communities/domains, which is why there are so many frameworks. Larger audience, with even more different needs. The fact it can serve so many different audiences is a testament to its elegance.
They're consistently willing to throw everything away and make up a new thing and force everybody to do that (and re-buy all their stuff). I don't know the specifics of how, organizationally, they do it.
They're a proof that this way of doing things can be successful, and profitable.
I’ve found my Apple products have a far longer longevity than similar products.
I’ve never found like I need to re-buy something because of a product change…
From the very limited information presented, it's not clear to me why the author would judge this offer to be a selfish act, or why this anecdote would support his conclusion to "beware offers of help".
My explanation is they did not have what is needed like tech skills or they were after taking over existing users.
Idea of scaling something up as author noted usually comes with idea that money will eventually follow. Post author is not money driven so it might be that person offering was also different in that way.
I've encountered this with dozens of contributors myself.
But once the long-term architecture is largely defined and implemented, there's usually enough inertia and established compartmentalization of modules that more developers can participate without ruining the soup.
it would be narcissistic to say "...and this vision is MY vision, nobody else has a vision like mine" which I don't hear the author saying
The tone of TFA doesn't make that likely.
> Welcome to a place where advertisers don’t call the shots.
> Where your data isn’t packaged up and sold.
> Where you – not algorithms – decide what you see.
> Where you can directly edit misleading content.
Sounds pretty bad.
> Where bad actors are kicked out and kept out.
Strong echo chamber vibes.
> Where you actually like spending time.
> Welcome to social media the way it should be.
> Welcome to WT.Social.
> Register [to even be able to see any of it at all]
Yeah I can see why this would not catch on.
Now when somebody offers to help, be welcoming because it's amazing. But also remember that most of the time their desire to help won't translate in to something useful. That's ok, eventually people will show up who are helpful. Keep being open.
Also, what the hell is somebody doing making a social network if they don't like people.... WTF!?
Having other people help your project might be bad for your ego, but it's also a great way to grow as a developer.
There’s a mindset shift between “senior engineer” and “tech lead” that OP seems to be struggling with…
One of the challenges of coordinating a group of people is getting everyone to buy into the same vision. Fact is that other people see the world differently and may have different goals. Here the author is attributing that to narcissism and maliciousness when most of the time it isn't that.
So yes, as you add more people it gets more challenging to get everyone rowing in the same direction. This is why setting a clear direction and clear communication is key, but the increase in communication overhead as the team grows is always going to be difficult. In this case, as others have said, he could've just open-sourced his code so the people who had a different idea were free to run with it.
I was thinking this article would be an example of that, but actually while Mythical Man-Month mostly assumes that new team members would share the same visions and goals, this article takes a more adversarial view where new team members are assumed to come with their own agenda. I believe it's a form of cookie licking[1].
[1] https://devblogs.microsoft.com/oldnewthing/20091201-00/?p=15...
I’ll answer: both are legitimate ways to approach the world, that may involve an acceptable and perhaps at times level of selfishness.
Sometimes things don’t work with other people because you don’t see things the same way. They are not Wrong and Bad.
Damn straight. It's not narcissism to have ideas and be excited about them and to suggest that a team or a founder pursue those ideas, whether or not that jibes with someone else's original vision.
The OP doesn't tell us what the reaction was of the person who offered him help, when he re-explained his vision. Was the reaction something like "oh, okay, I didn't realize you felt so strongly about that?" Was it "I'm a narcissist and I don't care what you want?" I think the OP might be a little insecure about negotiating with other people-- which is fine-- but what not fine is to turn that into universal advice for other people about not talking to strangers.
There’s a reason why there’s a profession in software—management—that often exclusively involves dealing with other people. In fact, good management is critical to the success of any large project. But it’s not an easy job.
I wouldn't say 'beware', rather, just say 'fork it and have fun'.
Obviously you have to be a bit selective over who can contribute to a small project.
The way this story was presented makes me curious to see the dialog (if there was any) between the author and the guy who offered to help.