I know the comment came from a good place and you meant well. The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to address the root cause. Is it because the task is too big, not enough details, is it too early in the project that the requirements haven’t really surfaced organically? You want your team to be autonomous, you want to empower your team to make mistakes and at the same time actively minimize the chance for mistakes by greasing “things” so people around you can be more effective.
There are few things as negative for a team performance as an insecure manager that needs to be making tactical decisions for the team as if developers were little kids.
I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.
I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well.
That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.
I for example seem to almost need this kind of rhythm. Yes it is spiky and sometimes a bit chaotic. But also very intrinsically motivated, which can sometimes lead to high impact solutions.
A good way to deal with this tradeoff is writing more text and less code. Text which is off-base is much more valuable than code that does do wrong things or things in a wrong way.
But I have to say that I work alone or in small teams, which requires less technical coordination.
I've seen places where working on your free time and/or weekends would be totally frowned upon by managers, and the general culture around workers would be that working on weekends is giving up your time for free in an attempt to clib on the other's backs, so that wouldn't be very popular among your colleages.
I have no children. I like my job. I spend my free time doing things that aren't software development.
I theoretically could work outside of work hours, sure, if I were a boring person with no interests.
I think that most people who treat their jobs as their 'calling' and burn themselves out on them ruin the world for both themselves and the rest of us. Races to the bottom everywhere.
It doesn't bother me too much though, since ultimately the selection pressure is such that the brown-nosers end up being abused by their managers whilst the stubborn lot get promoted. YMMV.
My American boss regularly feels proud that he puts in 12-14 hour days. In my opinion, that amount of hours makes sense if I am working on my own business or something that truly benefits humanity (like a vaccine for COVID-19 for example). It is hard to do good work more than 6-7 hours per day anyway and much harder to sustain it for long periods of time
If you have a job that's ultimately pointless, then you want to work as little as possible so that you have time for leisure and/or useful work.
Sure, but people with kids win at life.
Let the DINK make some extra money. You still have it better.
That's a pretty insulting statement for those of us who can't have / don't want children.
It's not a competition. We've chosen different paths than you. Not worse, just different.
Kiss of death seemed melodramatic at best though. Every CEO, CTO, and CFO I've worked with had kids. Guess they were the lucky few who didn't have their professional career ruined by those goblin children?
I get under everyone’s skin here. Just seeing my username is enough to get ppl riled up in HN
That entire first line seems entirely unrelated the the words I typed. Did you respond to the correct person?
What’s dumb is to tell people you’re better than Proust because you popped out some brats.
... That was dripping sarcasm. Please don't down vote.
My best friend since childhood has a kid and I can see that he lives an adventure of which he appreciate every second and I enjoy watching him live it. I don't have kids and I live different sorts of adventures and I can see that he lives them vicariously through me. It's pointless to try to make a tally. Figuring out what makes your mind "tick" the most is how you best "win at life".
And then they could either contribute it back, fork your project or just keep it to themselves, if the license allows it. At any rate, you already helped them...
You'll often get angry irate emails/issues raised demanding you help them or add a new feature or whatever. Some people are just clueless and need help, others are just dicks.
It is often not worth the hassle in my opinion, but then everyone's circumstances and motivations are different and I am glad that a lot of people do think it is worth it.
A much better response would be:
1. Scrutinise end users of the code: demand that governments only use this data if proper due dil has been carried out.
2. Submit code improvements.
3. (maybe) Demand that peer reviewers are more rigorous when checking the way results are generated. The issue with this is that this would also be a strong disincentive for scientist to publish their work.
While the tone of the covid model scrutiny leaves a lot to be desired it is understandable seeing as how the results are affecting the entire world. The situation is unprecedented.
My meta point is that people are:
1. pressuring and blaming the wrong party. 2. doings something which will have an unintended strongly negative consequence (make scientists averse to publishing their code).
Yeah, the code's bad – so what? It wasn't written by programmers. Most simulation code is bad, but if it's been proven correct it doesn't need to be good.
From what I can tell, this is a matter of conflicting conventions in different fields meeting head-on.
This is exactly why scientists don't release their code.
In fact, more applications-focused researchers (those who combine real data with established models, for instance) tend to write higher-level scripts stringing more-engineered tools. In this case, open sourcing the scripts would be both easier and more pointless, since they will be almost the same as what is stated in English, tables, and plots in the paper. Epidemiology is usually this way, in my experience, though the linked repository seems to have some of both flavors.
The underlying misunderstand in that issue thread seems to me to be a disagreement on what the main valuable byproducts of scientific programming are. Professionally programmers will naturally think it's the code, but, traditionally, the code has been seen in academia as only a temporary vehicle for the model and it's parameters, which is the real product. (Also, the "program" might really need to include the lab, its papers, and its institutional knowledge, which is harder to package and open-source.)
Right or wrong, the assumption is that any competent grad student could reproduce the result in a week or so of (admittedly unnecessary) greenfield coding. But this is clearly not ideal, and newer work does strive for more professionalism in coding, open-source-by-default, and therefore faster replication. The project in question clearly predates this trend.
(Of course, a third reason academics don't open source is that some secrecy is required before publication in competitive fields. On a months-long project, you might not want to be committing publicly before publication. But this isn't much of an excuse.)
The only thing more frustrating is when I see people swoop into open source code with "security vulns" that are based on nonsense threat models.
Isn't "faith in science" an oxymoron? If anything, people should default to skepticism for hastily thrown together scientific models.
It's interesting. For me there are at least two classes of open source.
1) Project with a single maintainer, or perhaps a small number of key people, nothing in the way of corporate backing, often worked on in spare time, but which can still be very popular and widely used. I always think back to the example of NDoc, which was a great tool for taking raw XML doc comments from .NET code and turning them into beautiful Javadoc-style HTML documentation. It worked incredibly well for .NET 1.x but the .NET 2 support was never finished because the author, Kevin Downs, received abuse and threats via mail-bomb due to it not being ready "fast enough" for some people. Understandable he decided to quit and, as far as I'm aware, not a peep has been heard from him since in terms of OSS contributions. The way Kevin was treated, and the way other OSS maintainers have been treated by both individuals and corporations, is absolutely despicable and completely unacceptable.
2) Corporate backed OSS projects that are actively evangelised: projects like .NET Core, Node, npm, TypeScript, React, Angular. You might even think of something like Firefox in this category since, although Mozilla is a foundation, it's substantially funded by corporate sponsors (mainly Google?), has full time employees paid to work on the products, etc. Some of these might at times have been considered open source in name only: i.e., source code is absolutely available, but there is little or no way for most people outside of the sponsoring organisation to meaningfully contribute. With these I take a slightly different attitude, and I certainly expect sponsoring organisations to take more responsibility for the projects. If you're actively evangelising people to use a project (and especially if you've succeeded in recruiting large numbers of people to use your project), and you're not giving them much opportunity to contribute, then absolutely you need to take responsibility for making sure the project is supported appropriately. That might even include paid support options.
And I suppose perhaps these represent the extremes of a spectrum (perhaps - I don't claim to have this absolutely right, by any means).
Clearly there are a lot of people who would disagree with me on both sides. E.g., people who think every open source project should be like (2) and that all authors bear an equal responsibility for supporting their code. On the flipside, since I've been flamed on this before, I know there are people who think I'm a walking manifestation of all human evil because I've suggested that any open source project might perhaps fall into category (2).
Fundamentally though I think your point stands: a lot of people behave in a way that's very entitled towards individual maintainers of OSS projects. As you say, depending on your circumstances, often not worth the hassle.
Absolutely, but that is often not the expectation. When I have pointed this out in the past people have gotten hysterically angry demonstrating a degree of entitlement. The mere mention they could do it themselves or submit a pull request has been regarded as a hostile personal insult like declaring war or perhaps worse than making sexually profane and racial commentary about their spouse.
1. Allow others to step in as maintainers and review/approve new features and bug fixes in your stead.
or (if you want to maintain control of your library)
2. Be clear that your library is in maintenance mode, and encourage and bless (by linking from your README) a fork (or forks) that work for those who were using your library but want the extra features that you don't want or have time to implement in your library.
Otherwise your project is actively getting in the way of the community organising development of similar.
If you had to go to the trouble of creating your library in the first place, it means either
A) "the community" had not met your specific need, so why would they start now? Or
B) you did this for fun/learning/visibility/coping with a mania, in which case you still don't owe us any favors.
That said, doing either of the above would be nice and appreciated, but you don't have to donate anything above and beyond what you are have.
While you're technically correct that people don't owe anyone anything, I've often had the experience of using an open source library that was otherwise excellent, except that it had critical bugs that hadn't been patched, or that it hadn't been updated to work with the latest versions of it's dependencies. Popular repositories like this often have tens of high-quality pull-requests fixing these issues, but using them is non-trivial because you'd have to merge everything. These PRs pile up for a few months until someone realises that the repo is unmaintained and forks. At which point you have two versions of the project (often with the same name), and everyone is left to figure out which one they should use.
It would save everyone a lot of bother if maintainers of these repositories took half an hour to update everyone that they didn't have time to maintain the repository and pass the baton on to someone / some people who do.
Instead of having to figure out how an existing piece of code works, update deps and merge a couple of PRs myself, I instead have to recreate the entire functionality from scratch.
In our original world, where you did release the code, I still have the option of creating my own library (with the benefit of seeing your implementation!). So by releasing your code, you've given me strictly more options, and therefore made me better off, or at least no worse off.
Think about this claim: ‘a creator of open source doesn’t owe X anything’. First, using a financial metaphor misses the point. Second, it is often used as a cliche and/or rhetorical device to shut down conversations about ethical considerations. Third, I get it: there are people that expect too much, which can encourage an (over) reaction from someone who shares an open source library.
Many people bristle when someone else uses the word ‘should’ in a sentence. I’d like software developers to be more mindful of what it means to participate in a community.
Who said anything about vetting?
More generally, I wonder about your underlying thought process and expectation. Were you somehow bothered when someone raised an additional related point?
The way we interact with each here other matters.
If the new maintainers cause problems, it's their problem, so the "you" in "you can't win" would of switched between maintainers.
If there's an implicit obligation, it seems to me it's on users, not authors. If you really need something changed you should fork/fix it yourself or talk somebody else into doing it. That right is baked into every major OSS license.
And that's taking into account we're the lucky ones that can work from home and keep getting a salary
Whatever I put outside is more to keep HR happy when they ask for a github link than anything else.
It is all a bit crappy collection from university projects, or tiny stuff I did on side either to learn an algorithm or a quick and dirty solution for something.
The good stuff I rather do it at work.
I had a kid and a fulltime job and going through a divorce. I happened to use it at my job, but everyone kept asking for me to integrate it into new up and coming repos which I didn't have time for. Honestly I felt bad about not caring, but the reality is that I didn't. I had other things on my mind.
Some people are DINKs (dual income, no kids) and get bored so instead of video games they'll make a side project. Some people have totally other circumstances. For me I wanted my spare time to either zone out to some games, or zone in to spending time with my daughter. I had plenty of coding to do at work.