I once wrote a library in backbone.js to have a data-synchronized list. It allowed me to provide an array, and it'll keep that array sync'd up to what I saw.
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.
Unfortunately, DINKs are hard to compete with professionally. Old boss used to loudly thank my colleague for doing tickets on the weekends, and too often people seem to assume I want to spend my weekend "brushing up" on some implementation detail for a project I don't care about. Even "why doesn't he come to after work drinks?" Is hard to answer with "because my spouse is _also_ an exhausted wreck at the end of the day and I already barely have any time for them, much less my real friends, much less you lot".
That's terrible. I am a manager and actively discourage people from working late / weekends. I find it's not sustainable. People who do that, regardless of children status are much less predictable in their output. They go through peaks of productivity and then they crash. It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket. Some of our employees with highest productivity have kids. I think your story means you should look for a new job when it is possible for you.
> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket.
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'm sorry, but I don't think that's what they were saying at all. To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. Thus, if the ticket is vague, or if they have a question about a part of the codebase they are less familiar with, they have to spend a lot of time trying to divine the answers themselves when they could just walk over or message their colleague for the answer on a normal work day. Spending three hours rederiving trivial knowledge that other members of your team already know (such as which package something is in, or the exact set of inputs that reliably reproduce a bug), IS spending time on the wrong things.
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.
> To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions.
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.
This is a very commendable default approach. Let me suggest that there are also people who just happen to be that way naturally.
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’ve somehow managed to work in this industry twenty years and never be pressured to work on weekends, except for occasional emergencies or exceptional releases, and I’ve never felt pressured to happy hour with anyone. In SF, no less. I’m also a single co-parent, from the time he was born.
I mean, this isn't necessarily a 'dual income' thing, this is a 'cares exclusively about work' thing.
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.
Nowadays, I don't feel anymore like I need to compete professionally. I've got a decent savings account, half my house is paid off, my family is healthy, and work is interesting. Why would I need to compete with anyone?
Because they're bidding on the same house as you, and can push for slightly more cash at work, presumably. But it's amazing what a paid-off house does for your assertiveness at work.
This seems more in certain cultures than others - American and Japanese from my anecdotal experience. I worked with Europeans (French especially), they don’t seem to wear long hours as a badge of honor.
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
Agreed... I remember a study on “do kids make you happier” and their conclusion was “kids make you happier if you want kids”.. people who didn’t want kids but had them or wanted kids but couldn’t have them were sadder, but people who didn’t want kids and didn’t have them were just as happy. Which I guess makes sense... people are happy when they get what they want!
Sure I could have rephrased it along the lines of "you have the invaluable blessing of children, and surely that's more important than a 15% pay rise?".
Your edit got under my skin way more than your comment did.
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?
Only if you care personally for the kids. Pick up a history book, filled with famous persons who had lot's of kids, but they were raised by family and staff.
Maybe to someone who isn’t ambitious or intelligent but personally, I’d rather write a great book or make great software. I believe, like Proust, that art is how you reach immortality.
What’s dumb is to tell people you’re better than Proust because you popped out some brats.
Although I appreciate the sentiment behind this very romantic comment and I understand that it is mostly addressed at kindred spirits who can relate in parenthood, I think that it's important to nuance the idea a tad bit. The world is already filled with too many people mindlessly following tradition. When in doubt about how to make themselves happier, they don't dig much before reverting to the status quo: having a kid. The promotion of the idea that we're realizing our purpose in life by procreating has undoubtedly caused a lot misery, as a substantial portion of those who experimented with parenthood failed to find what they hoped for and many children ended up suffering for it. Human beings are not just mere biological entities fulfilling some function of nature. We are blessed (or cursed) with complicated minds that make us appreciate a lot more to life than raising children.
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".
Why would you feel bad? The whole point of open source is they could have done it themselves, if they wanted some integration they needed and you didn't.
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...
People often act very entitled about open source I've found.
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.
Some of the commenters in that issue have a very regressive and myopic stance. Raising such a public ruckus will heavily disincentivise scientists from publishing their code in the future. Decisions will still be made, but in the dark. There's a certain amount of self-stroking going on there with people feeling better by putting down code produced by non-professional programmers.
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.
I don't think anyone is saying the code can't be better or even that the results might be wrong (I don't know as I haven't spent much time going through the codebase).
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).
I don’t doubt it, but covid-sim is not the best example of this effect. In this case, people are worried that poorly written simulation code is informing policy decisions that affect billions of people. They are not demanding that it should be fixed, they are demanding that it should not be relied on in its current state.
They're worried that there isn't testing code to prove that it's correct. If it's proven correct in other ways, it doesn't need unit tests.
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.
To be clear, I am not arguing for or against the validity of the claims regarding covid-sim. I am only saying that this is not a good example of the effect where people feel entitled to get open source code that fits their needs.
Dunning-Kruger powered software developers with beliefs that they are in any way qualified to say that mathematical simulations checked by dozens of actual scientists with PhDs are not valid ask that results are ignored because there's no unit tests.
I don't even know where to begin with this, it's so insane. It's extra funny because John Carmack was the one who did a lot of the refactoring of this code. It's also not remotely true that billions of lives have been disrupted on the basis of this code being correct.
This is exactly why scientists don't release their code.
Another reason scientists often don't release code is that code is not considered the valuable artifact produced by research--in more methods-focused fields in particular, it's instead the mathematical model, as embodied in some latex in the published paper. "Reproducing" the results then doesn't consist of trivially rerunning the same code, but in reimplementing it, possibly in a different language. This could maybe be seen as valuable in that the reproduction will surface both implementation errors and logic/modeling errors (though, really, having the source facilitates both).
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.)
Yup. This whole experience was immensely frustrating. First people complain that the code isn't open source and as soon as it is available suddenly there are piles of people swooping in to shit on everything. That's not going to make scientists write better code. It is going to make scientists refuse to open their code.
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.
> People often act very entitled about open source I've found.
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.
I have a very simple Firefox extension that inverts the colors of sites, I wrote it as I needed something that would just give me dark themed web pages when my baby was asleep next to me. You would not believe some of the reviews and requests (ultimatums) I got.
The funniest ones are those who need your thing for their professional work, yet treat you as if you were a fully paid contractor at their beck and call.
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.
I think it's fine to not have time to maintain code you open source. However, if your library ends up gaining a significant user base and you don't have time to maintain it, then I think you have a duty to either:
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.
Vetting a maintainer is non-zero work. But it's also not all that much. Especially if said maintainer has already contributed meaningful PRs against your repository.
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.
Sure it would save everyone a lot of bother, but consider the alternate universe where you didn't release your code at all. There's no original repo, no idling PRs, no forks, no "community".
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.
I think we would benefit if more people think about individualist and communitarian views on ethics.
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.
Generally, writing ‘who said anything about X’ strikes me as unproductive for discussion. At the least, the tone could be improved.
More generally, I wonder about your underlying thought process and expectation. Were you somehow bothered when someone raised an additional related point?
Because people also complain when new maintainers are added and those maintainers cause problems or even abuse the project to insert malware. You can't win.
Well maybe those people don't have a valid complaint, but then that wasn't part of the original post; I was looking for a response from fovc specifically.
If the new maintainers cause problems, it's their problem, so the "you" in "you can't win" would of switched between maintainers.
I really disagree that authors have a general obligation to do anything with their code, at least as far as support is concerned. If somebody signed up formally to be a committer or made some other explicit commitment that's of course a different matter.
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.
Licenses do not codify obligations, they codify legal requirements. Getting someone to replace you if like holding the door open after yourself: no law will force you to do this, but people will still say it’s polite for you to do so.
A bit tangential but it's been very relatable to me lately : 80% of my coworkers : OMG working from home gets you so much done! I've passed this and this certif and also did that side-project. Amazing. And you ? Well, I've tried to manage being a good parent while working with kids at home and god knows that was hard enough.
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.
I find many prolific GH OSS authors to be single, but do code instead of gaming like you said. Or their job lets them OSS some of the code they use at work while on the clock.
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.