Hacker News Reader

Comment by smitty1e | Hacker News Reader

1. I've never upped my game enough to contribute to a project, much less put something on github. So, to the vast swath of people who are cooler than I: thank you.

2. TFA really gets at the classic issue of working vs. managing. Technical people tend toward being better at the former. Context switching between doing the work and managing the work is hard. Punting the management and diving into the work almost seems an escape.

3. The code itself makes this point to us. We can define an integer, and there it is. But when we need a list of integers? Look at how the management required just exploded.

4. Management sucks, but a management vacuum is a void, indeed. Let us be thankful for managers who don't suck.

View on HN

(I've been in the situation he describes, unfortunately)

I agree a lot of that article feels like two things (but i'm not going to remove all nuance - there are clearly other issues):

1. The issue of being forced to be a manager when you want to be an individual contributor, and even worse, feels like being forced to be a TLM when you want to be an individual contributor.

2. Even if you take away the aspects of #1, it feels like a lack of notion that individuals don't build software past a certain point. I mean that in the sense that, IMHO, past a certain point, all software becomes team built (or fails), whether you are the manager or not. High level software engineering is a team sport, not an individual one. That is true even outside of management - it's also about technically mentoring and growing the team that builds your software so you can rely on them instead of you (which is not just a manager task).

Every person you mentor into someone capable of doing the kind of work you want done is going to increase productivity on the software a lot more than you trying to do it yourself. Over time, they will also be able to build your team.

Over time and scale, if you don't have a team to rely on, and actually start relying on them, you will just feel crushed. Utterly utterly crushed.

There is no path out of it that involves getting better yourself. You simply cannot scale past a certain point and there is no way out of it.

> High level software engineering is a team sport, not an individual one.

#Truth

Floating out there in the cloud, you have to be a DBA, a network engineer, a browser jockey, a middleware dev, a sysadmin, a security specialist, an architect. . .

. . .and that's without being handed someone else's effort that is probably not in the desirable state for reasons you'll never know.

It's blatantly obvious to even the most casual observer that anybody claiming to know "all that stuff" is having you on.

That the internet works AT ALL is somewhat amazing when you ponder it.

It's not for everyone, but there's a way out: accept existential "futility", as Antirez puts it.

Let your project be less than it could be.

In my experience, this doesn't actually work. You basically have to close up shop.

Otherwise, the negative vitriol/etc of people who won't accept that is amazingly overwhelming.

Put another way, imagine, in a housing thread on HN, any time someone says "yeah, but i'm just happy to have my town stay the way it is. We don't want growth, we are happy, and we should be allowed to have that choice", what the response is.

While different situations for sure, it's the same type of response you get when you say "yeah, i'm happy with my open source project the way it is, sorry".

> You basically have to close up shop.

If you can't come to peace with that possibility, this approach isn't for you. Having to close up isn't an inevitability, but grappling with that prospect is an essential exercise.

It's truly not easy for ordinary humans to withstand the vitriol of a furious userbase. So, remove yourself from the channels where that vitriol gushes and roils.

The key is avoid making promises you can't keep -- either explicitly or implicitly. Putting a project on Github, home of "social coding", makes it hard to tune out the din. So... maybe don't keep your project on Github.

"If you can't come to peace with that possibility, this approach isn't for you."

Sure, but i mean in the sense that what you suggest is not a viable method for a lot of projects, unless, as you say, they also disconnect completely from the world.

That is not the same as existential futility - it is going off grid.

I vehemently disagree with this false dichotomy that either a project must strive endlessly or exile itself. Gradations are possible, and the way you achieve them is by strategically choosing the terms of engagement.

Embracing existential futility puts you in a state of mind to accept the consequences of subsequent concrete actions which limit future prospects of glory.

You can vehemently disagree.

" Gradations are possible, and the way you achieve them is by strategically choosing the terms of engagement."

In my experience, you are simply wrong. You don't get to actually make this happen. You may want it to happen, and i agree it would be very nice. But it is also unrealistic, in the same way lots of polarizing things are but shouldn't be. So you may not like that dichotomy, but in my experience, it is the practical effect.

I'd love to see your examples of projects that are both fairly successful and choose somewhere along the gradient you have in mind.

There are projects out there on GitHub that have issues disabled entirely. It's fairly simple to not accept user feedback, and still distribute source code and binaries without support. It's more difficult with larger projects that require big reports, but it's certainly possible to not give out direct contact information (use forums or built-in bug reporter, etc)

> I've never upped my game enough to contribute to a project, much less put something on github.

Well, if you want to, just find a project you like and search their bug tracker. Usually there's a lot of shit that's trivial which no one could find time for.

You know, the stuff that people will be like "OpenOffice's About Page hasn't been disableable for over fifteen years. This bug report is untouched!" Or whatever. You can fix it in five and be happy.

'Just' read the source of something you like:

https://blog.codinghorror.com/learn-to-read-the-source-luke/

Or not – you're not obligated to contribute!

I'm hoping that finishing the excellent https://shop.jcoglan.com/building-git/ will give me enough git-fu to start making some modest contributions.

Reply on news.ycombinator.com