I really don't like how GitHub has turned into a social network of sorts. The gamified elements are encouraging people to work for free and MS probably knows this. GitHub should just be a place to host and build code, not to flex your follower or star count. Some examples of gamified elements I find quite toxic:
* Achievements on profiles
* Highlights on profiles
* "Activity overview" which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)
I saw it today in someone who announced a package and in their README had a gif of a mouse clicking to add a "star" to the repo. Like the youtube videos that ask you to "like and subscribe".
"If You institute a revocation of a GitHub star against any entity (including cross-repository and cross-user removals) alleging that the Work or a Contribution incorporated within the Work no longer constitutes a GitHub star, then any patent licenses granted to You under this License for that Work shall terminate immediately as of the date such a revocation is performed."
A startup for which I had applied to a job opening few months ago reached back to me and asked me to check out one of their repos and star it if I thought their project was good. Never heard back from them about the job though
"This dependency tree is sponsored by NordVPN. Staying safe online is an ever growing difficulty and you could be exploited by hackers. NordVPN allows you to change your IP address, making you harder to track, securing your privacy. Check out the link in the API docs to get 20% off for the first two months. Thanks NordVPN!"
Begging for those interactions makes 15 seconds of every video telling me to smash that like, subscribe, bell, comment, share, rewatch 10x for good luck.
Should we limit the # of likes/stars one gets per period of time? Scarcity?
Since it’s always the same comment it is easily compressible and should just be automatically generated and included as part of the pre roll ad. Then it could even be localized for the viewer!
This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened.
Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time.
Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.
Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable.
These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware.
In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.
I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions.
Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.
Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.
> Never promise anything to people using your code. Even if they are paying, unless it is in a contract.
“Never” is a very strong word. What is your recommendation based upon, exactly?
This is my code. It costs me nothing to tell people my future plans with the code. It costs me nothing to tell people that my plans are most probably off. But it will gain people something - they would be able to plan for the future better.
“Politeness costs nothing and gains everything” - is a better theorem (than yours one). I would rather tell it as: politeness usually costs nothing and gains at least something, but that’s just an engineer correcting a salesman’s statement.
Yep. The “this software is distributed as is, with no guarantees…” is essential in any kind of freelance open source development. That sentence does not appear in the BSD licenses and I deem that a mistake.
Every BSD license has this, which is for that purpose:
THIS SOFTWARE IS PROVIDED „AS IS“ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
I don't promise anything, my github is a collection of forks from projects I find interesting, some stuff I rescued from university and technical school projects since 1990, and a few basic utilities I created to make my life easier.
That's it, and I can refer HR departments that enjoy reading github profiles to that pile of code with various levels of quality.
Nothing else and I post all my own code as GPL unless forced otherwise by existing licenses.
1. That’s a great illustration why socialism does not work. When everyone gets a regulated paycheck, everyone thinks they are underpaid. No one in the whole country is paid _extremely generously_. So people kinda disappear from their working places, even when they are honestly sitting on a chair assigned.
2. But. Even in a socialist country there is always a bunch of people who love their job more than a paycheck. Let’s call them “real professionals”. They just love to get things done.
3. When a real professional comes to a capitalist country he sees that there is a huge demand for their services and no real competition. Cause a lot of capable people virtually disappear whenever they damn well please unless they are paid _extremely generously_ for their work. For example:
4. Our customer was complaining that they have too many problems with our software. I was sent to look into that. When I arrived their CTO demonstratively unscrewed the plate with the name of our company from the door of the room I was assigned to. Shrug. Working. Issue #1, issue #2, … issue #23. Sound customers hear while connecting through our switch goes up, then down, then up, then down… Investigation revealed that one department under the CTO bought their voice files from one vendor, the other department under the CTO bought their files from another vendor. One bunch was twice as loud as another.
Now, neither vendor was going to do anything about that unless they are paid extremely well for the additional job. Neither department was going to do anything about their files unless they are paid extremely well for their work (actually they were demanding each other blood, but you can consider it just a kind of currency). I scratched my head. It is definitely not our job, we just connect a source to a destination. But. Actually our software can see which department a voice file comes from. I am going to give you an option: based on a voice file source you will be able to adjust the volume by a configured amount. And this configuration can be changed in real time, so basically you will have a volume knob you can adjust while software runs.
It took 15 minutes to code and a week of QA, which does not count since it is always a week of QA. Anyway in a week issue #23 was gone. Next.
In four months the CTO told me that in 15 years in the tech industry he never saw a company as aggressive as ours. The definition “aggressive” gave me a pause. Nothing we did seemed “aggressive” to me. We humbly listened to the problems and did our best to help, without sorting “our problem” or “not our problem”. It’s kind of opposite to “aggressive”, no?
5. A customer from that F..<something> list of big companies that is often thrown around but I could not remember it exactly told me once that when something happens, they pray (as in pray to God) that it was our company fault. Or, if not - that we were able to find a workaround.
—-
So of cause, go ahead - disappear unless you are paid extremely well for your work. Even if that work is dropping a line warning people that your plans have changed. Such a widespread attitude gets me paid extremely well. Kinda ironic, no?
Despite your high school level of understanding of what is socialism and capitalism that seems to be formed from nothing more than knowledge from watching TV news, very happy for you that you make money from it.
Still, if you want to force me to do absolutely anything on a project I maintain myself and for fun, feel free to pay me extremely well. My employer does so and gets my work, the price doubles for anything done on my free time.
> understanding of what is socialism and capitalism that seems to be formed from nothing more than knowledge from watching TV news
Lol. I have a “living experience” both in socialism and in dismantling it, which is an extremely painful experience in itself. My points 1 and 2 are from hands-on observation.
And my naming something a good thing is not the same as me forcing you to do that good thing. Yes, a named a politeness a good thing, but this declaration while obviously true can’t force you to be polite. Confusing these two things is a logical slippage. Frankly, I never observed such a slippage in good professionals.
The social aspect to GitHub is very much not front and center, so it seems very innocuous. How are badges toxic?
It certainly seems like a waste of their development time. I looks at these badges for a moment and think "neat" but nothing else. And profiles I just ignore, especially the ones people Myspace-ify...
Badges are toxic because they divert a subset of people away from their current open source workflow to focus on getting badges. In reality, the incentive of a lot of these badges is for GitHub's best interest and not necessarily a project's. This is insidious.
To finish my badge collection, I need:
* Merged a pull request without a review - 100% toxic.
* Answer 32 discussions - this is a strong incentive to enable GitHub Discussions on a project, which is the wrong move
* Create a repository and get 4096 stars - diverting focus from the projects I maintain (although I'm a core contributor to a project which meets this requirement, I didn't create it)
* Coauthor 38 more commits on merged pull requests - this'll happen over time. Not a 'bad' thing, but not something I want to take time to achieve.
I'm with the grandparent poster in that I see a badge/achievement/whatever and think "neat," but I don't feel a visceral compulsion to collect the whole set.
It seems there are people who do feel that way. I wonder if the folks who set up the badge system are all of the first type, and didn't realize that some people would be thrown completely off the rails by it.
> Merged a pull request without a review - 100% toxic.
There's a case where this is not just ok, but healthy (especially on smaller teams) - if you're comfortable doing trunk-based development then you can use a PR to "snapshot" a set of changes and either invite commentary or just have a link to share as an FYI around the change, without the awkwardness of linking to an unnamed commit sequence.
I would say this is never healthy, even for a team of 2 people. These days merging code without at least asking for a review should be anathema for devs. Even a 'rubber stamping' review at least signifies a shared awareness of changes.
If you don't care about code reviews, why care about a PR process? don't protect the branch and just make your commits. The notion of a pull request is you're requesting someone pull in your changes. But you don't want them to review those changes?!
Last month we had ~25 code contributors and ~2.32 million users. About 100,000 users per code contributor.
As a user-facing app, rather than 'open source infrastructure', we receive a very large number of support queries from end-users. A significant number of these will be users who are entirely non-technical, or don't speak English at all (looking at my last support efforts, ~20% were non-English + resolved via screenshots, videos + Google Translate).
I'd much rather have our community triage via one of: Forum, Discord, Reddit, StackExchange, Google Play, Mailing List, Twitter, or Facebook Messenger and leave GitHub for code/documentation-level discussions.
Opening up GitHub discussions adds another level of distraction to GitHub notifications, and provides little benefit in return given the existing established support channels.
EDIT: I do have GitHub discussions on other repos, but they're not always suitable.
Yes, this is a good summary of how I feel about discussions too. Non-technical users are going to be more comfortable using non-Github platforms anyway, and for technical users issues or chat are probably a better fit in 95% of cases. Not worth opening an entirely separate forum for.
SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails.
If anyone is skeptical about the email workflow, here's a write-up from another skeptic:
What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.
Fair point. Codeberg.org is more GitHub-like and has fewer gamification elements, for what it's worth, but many platforms which aim, more or less, to be GitHub clones, often include these elements without much critical analysis.
No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational.
The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
> This exchange positions SourceHut as "Github, but without gamification elements"
No, it doesn't, and it's dishonest to try to make that move—just as it is dishonest to manufacture quotes (that are, in this case, designed to provide the opportunity for that attempt).
"Github but just without the gamification elements" does not appear anywhere outside of your own comments and is, in fact, much stronger than what was claimed in the original comment you responded to; the person to whom you responded and to whom you were being needlessly confrontational pointed to SourceHut as an option for people who dislike gamification and are looking for a provider that is just "a place to host and build code". There was no claim about the suitability of SourceHut for anyone who doesn't meet that description, let alone anyone who requires/seeks/prefers(/whatever) "Github, but without gamification elements".
Please stop manufacturing quotes, and please stop defending their use by pleading that "[t]he quotation paraphrases". That word sequence alone is a dense contradiction. Making up false quotes is especially troublesome when they are freely mixed into discussions where a person has otherwise already previously made use of genuine quotes (such as the way you did when quoting the creator's remarks that "SourceHut is not GitHub/GitLab/Gitea[...]"). To do so is pernicious, and the entire practice is against HN's rules.
Thanks for letting me know about the quote rule! While "pernicious" is IMO overdramatized, avoiding that shorthand is a sensible-enough community practice for a venue where people often skim and get heated about things; I won't repeat it.
I still think you're reading a lot into this thread that is not there, and ratcheting this up to the level of accusations of dishonesty is a pretty interesting/illuminating choice. However, I don't actually have a dog in the fight; consider all points ceded.
Not interested in deflection, and not interested in passive aggressive quips like "is a pretty interesting/illuminating choice", either.
> I still think you're reading a lot into this thread that is not there
To reiterate the background for this discussion: a participant in this thread went a step further than what you're saying here and literally* wrote things in that weren't really there.
How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.
Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems).
A pull request, literally, need only be moving code from one repo to another.
The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means.
That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics.
E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git).
Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them.
Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
I do not believe it's nitpicking. I was supporting the post you replied to (https://news.ycombinator.com/item?id=33313036), which claimed that git indeed does not have review tools, and that the review tools/flows are and should be external to git. You claimed otherwise, and I argued that you were incorrect in that claim.
Isn't that what discussion board is for? I agree that this particular topic is not life-and-death important, but still worth discussing, IMHO. If you think otherwise, just walk away, you do not owe anybody anything.
It isn't picking nits, git does patch management, there is nothing and shouldn't be for review.
It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling.
(Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things.
Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.
Yep, many people forget GitHub was trying to be Facebook but for coders from the very start. Back in late 2000s when FB was the hottest startup everyone was trying to do "the Facebook of X" knockoffs.
Missing from all these is a social network of "our friends and adjacent social circles". And perhaps, on top of it, a service aggregating output of all the ones you listed, so as a user, I can have (for a lack of better term) "people-first" mode of interaction. By this I mean, I want it to answer the question, "what have X been up to recently?", where X is a scope I can alter - from "all my friends" to "a particular group" to "particular friend".
I.e. what Facebook used to be, before the "great social network unbundling".
This paper is about how gamification affects behavior, not about it being some sort of social platform. Every platform was "social X" around the time github started up. Lots of sites have social elements and it never amounted to them being called social X either. Sure you can use those features in some sort of gamesmanship, but generally it's not used that way and so few people care that it's laughable.
> "social coding"
Social coding is not Github's primary function and it's hasn't been promoted in earnest, this way because it's secondary at best. Ostensibly, it's hosted git. That's the naming, the function, and most developers think of it as such. The vast majority of users are either corporate developers who work for some company and can't care less about the "social" aspects of it or insular developers with projects that never see the light of day.
Notably, this paper only sourced public repositories, where many people use it as an element of their work portfolio. This doesn't speak to "all of github".
Git is absolutely trivial to use in a fully decentralized fashion. GitHub and GitLabs success shows how much people don't want to run their own servers.
You're under the impression that the few people in this thread complaining about the social aspects on Github is a greater force than the massive amount of people USING their social aspects?
Actually yeah. The stuff we're discussing here matters. The behavior of developers is being shaped by these designs in absolutely harmful ways. I would know, I've been down that rabbit hole myself with video games and other "gamefied" apps.
Look at the article:
> We find that the unannounced removal of daily activity streak counters from the user interface (from user profile pages) was followed by significant changes in behavior.
> Long-running streaks of activity were abandoned and became less common.
> Weekend activity decreased and days in which developers made a single contribution became less common.
> Focusing on a set of software developers that were publicly pursuing a goal to make contributions for 100 days in a row, we find that some of these developers abandon this quest following the removal of the public streak counter.
Look at this bullshit. People doing work just to maintain their streaks. People making literally one contribution just to keep it up. That's fucked up and needs to be fixed. Nobody deserves this operant conditioning stuff.
There's fixes that can be made (and Github is aware of), without turning Github into cgit. I don't want that and pretty much nobody wants that - those who do, already use cgit.
Conceptually, I like that Github has social aspects to it. But Github needs to be more careful about what they emphasise. IMHO the existing mechanisms they have reward rather toxic behaviour.
IMO this is the main thing GitHub has over GitLab. Most platforms which support GitHub also support GitLab, GitLab has equivalents for many of GitHub's features like actions, and GitLab even has comparable free tier storage (as they've decided not to delete inactive free projects [1])
If someone just wants to host and build code there are many alternatives (like Sourcehut). The only reason GitHub is so dominant is because of its already huge following and exploration / networking which relies on said following.
There have been a lot of red flags with GitLab recently. This (aborted) plan to delete projects was one of them, but the recent limits on CI they impose on open-source projects get in the way quickly compared to GitHub: 2,000 minutes per month.
Personally I am planning to move to GitHub soon. The CI limit is very small for an active project testing across a few different Python versions, I am reaching it just with a couple pushes per day.
Consider sinking capital or asking for donations for your own CI then - sure you might get something for "free", but if you aren't paying anything then you might just be the product.
Serious downsides to being the product include:
* No means of production - whatever profit you hoped to have can simply be taken away from you.
* No control over your likeness, IP
* Limited legal protections
* Finding yourself being sold in ways you find unethical.
I'd reconsider your planned move, unless I guess you really just don't care about your project longevity...
GitHub's just a tool to me. I can put my project any number of places, including my own server, any time I want. Why would I pay for compute ("means of production") or contend with a lower limit when I can get it for free from GitHub?
I don't know what you mean by "taken away from you" or "control over likeness" or even "legal protections". Code is intangible, it can be multiple places. If you're referring to Copilot, my code can already be taken whether I use GitHub as my base of operations or not, because it is public and GitHub feels the thing is "fair use"...
You throw around big words that apply to other industries, but what specifically do you think I lose with software?
Tools are not made all equal, and there's this fallacy that just because it is a tool it is probably OK and as easy to use as abuse.
To borrow from the medical industry - yes, opiate drugs are absolutely useful _in specific cases of extreme acute pain_, but that doesn't make them good tools for dealing with a headache.
A tool can be bad, even if it can be used well, likewise a tool can be good even if it can be used for bad.
"Code is intangible, it can be multiple places" - you should study law, especially wrt existing legal precedents. If this were true, things like software patents would not be a problem, and I would evaluate how much you really can lay claim to your code, especially now Microsoft has played their hand here...
In a world where digital media and electronics remain an important part of every industry, and large rich tech companies exist, these are absolutely concerns, this is not some idle ideological patter. Your IP matters, (F)OSS has IP as well, that's part of why any of this matters.
if i may be so bold, this is an encroaching effort from multiple large players, FAANG included. its a pretty ham-fisted, transparent attempt to get the kids excited about code in much the same way your spanish teacher tried to pump the kids up to learn with a fiesta.
The idea is to increase the number of programmers, decrease the median pay rate of the average programmer, and recapture the excess capital lost from the past 60 years of nerd-shaming that led us to consume more code and tech than we produce.
the only people whining about code not being fun and pushing gamification are the very people who shouldnt be doing it.
Parent thinks there is a fix amount of code needed in the world, and the only reason (some) programmers earn a lot of money is that a relatively small number of people produce that code. They ignore that the cast majority of code generates demand for more code.
Exactly! A successful software project creates a building block. A basic human desire is a) to modify the successful design to perform some other task, and/or 2) to use an existing building block to build something bigger and more complex.
my first "wtf" was seeing the "pull shark" badge... really? I do like that they give you the option to disable showing your achievements in the settings.
The badges are just not that compelling. Feels like an "everyone gets an award" thing. You shouldn't get an award for making a PR.. Show an award when your repo reaches 10,000 stars or something.
FWIW I don't notice it in my usage of GitHub... but yet I've still noticed it because projects I've been involved in which happen to use GitHub end up with people showing up who clearly just want the badges or who explicitly admit they are wasting my time trying to get a "contributor" status on the project so their icon shows up somewhere and while at the end of the day the problem can of course be blamed on these people who fall for this stuff, GitHub knows what they are doing as these features have no legitimate use case other than to gamify their platform.
If you don't like how GitHub has become a social network of sorts, you really won't like how LinkedIn is apparently the new Facebook.
I have even seen a number of creepy screenshots from horny single men on LinkedIn sending unsolicited messages to women they think are attractive, trying to use it as a dating website.
GitHub and linkedin are both owned by MS and trying really hard to be social networks, so the follow on social consequences of mass adoption seem almost inevitable.
Star count has some interesting side effects. On one hand, it incentivizes people to produce something popular — and by proxy something useful. On the other hand it can be cause addictive behaviors.
What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations.
Star counts on a repo are both essential for devs who need to assess a range of libraries/products for possible use in their own product (as indirect indicators of support, community, etc), and yet also toxic for anyone trying to build a new library/product in an established niche (everyone ignores repos with low star counts).
Clearly if I was serious about marketing/promoting my library then asking people to star the repo would be high on the list of asks. Sadly I am not that person.
On the other hand, having starring a repo made into a game will skew the stars' usability in gauging a project's popularity or quality. Maybe the "most starred repo for X" is just made by someone who's really into collecting badges or marketing.
I think it is fine. If you lack consciousness to notice when you are, as you suggest, tricked to working for free, you have much worse issues. I started my programming due to a social network need in the first place.
Don’t blame the users for wanting to change a predatory system. They’ve already identified the problem — telling them to simply ignore it is dismissing their humanity. We’re not machines and need to work inside those constraints
I'm going to buck the comment trend thus far and state that I enjoy the gamified experience.
Getting an achievement in recognition of the open source work that I've done feels great, and honestly it's more positive recognition then I would normally receive for that same effort.
I also appreciate the activity chart and graph, since they double as a way to monitor my productivity and therefore my energy. If I've felt that I had a bad week and the charts contradict this, then it's easier to stop myself from feeling down on myself.
I am just a social mammal, after all; and a life long gamer. This works for me, but maybe not everyone.
The obvious concern is not that some existing legit users mightn't enjoy it; it's that the gamification will pollute the platform by incentivizing an influx of low-grade users, attention-seeking or annoying behavior, garbage commits, pointless chatter, non-issue issues, profiles stuffed with links to add SEO juice to low-grade profiles on social-media/LI/etc.; (the repo equivalent of "Follow, Like and Subscribe!"). How badly depends on how much github incentivize it.
I guess we'll know if/when github has gone the way of FB/YT/IG is if/when people pay for fake/compensated followers to star a repo. I don't think we're there yet.
Maybe a more constructive way to have this discussion is to subdivide github's social features into those that are good vs those that are open to be abused.
I also enjoyed it, but I was only coding on my own stuff back then for fun to pass time without having or thinking about a job. I can't imagine doing this on non-solo projects with other people's opinions involved.
At the same time I'm glad it's gone as it seemed to cause more harm than good for other developers.
As a very casual coder who wants 'in' to more coding, I really enjoy the gamification. I wish the mobile app had more of it, really has helped me progress and feel like I'm accomplishing something. I know they're just green dots but really helps me stay on track and keep practicing.
Martin from GitHub here. I think we’d consider this very much ‘by design’ in removing the streak counter so I’m glad it had the desired affect. Coding 100 days straight with no breaks isn’t good for anyone.
Martin thanks for jumping in, the thing I'd love most is when I'm logged in and go to github.com, just take me to my repository list. I'd pay money for that.
The commit graph should at lest have a disclaimer of some kind. Plus I think the lines of code added/removed are a better indicator than number of commits. Perhaps with some heuristic to detect whether a lot of lines were being changed similarly, such as if code was changed by a wizard or from a find and replace.
A colleague once showed me a tool to produce back dated commits in bogus git repos so you can draw pictures on your commit graph. You should know that people are gaming the gamification.
> Coding 100 days straight with no breaks isn’t good for anyone.
Why? I've done that and it has been amazing for me. I don't want other people telling me what's good or not. Absolute statements like this is just social malaise and not based in objectivity in the slightest.
The current social bandwagon can be summarized as: “Work is bad. Hard work is toxic. Perseverance is not healthy”.
HN is just reflecting r/antiwork ethics.
Complete and utter social non-sense. People have just stopped thinking for themselves.
> Absolute statements like this is just social malaise
> Complete and utter social non-sense. People have just stopped thinking for themselves.
Yes, absolute statements are a problem - including your comment. There's context around antiwork, there's context around grind culture - everything can be taken to an unhealthy extreme.
Gamifying non stop daily “contributions” does not seem healthy to me.
I work 5 days per week. I may not commit every day. Typically I will, except when I'm ill, or my close family is seriously ill, or there's a funeral, wedding, holiday, etc. So, life gets in the way, I guess.
If you're compelled to work all the time, every day, for months on end, good for you I guess. But I wouldn't skip my life to satisfy any KPI.
I will, however, persevere. I work hard. I do not give up easily. I learn something new all the time. I try to get better every day. I do my best to contribute to my family, my company, my society, and humanity at large.
However, life, I've realized, is long. My priorities have shifted over time. In the past, the value I've created in my work has not always ended up where I'd like.
If you have all this figured out 100%, then yes, go for it! Don't stop! The rest of us are still figuring it out.
Oh, also, I don't work with GitHub at all. Imagine that.
Right on, this is the spirit. Committing yourself to a goal, like learning piano or not missing a single day at the gym is a great “gamification” motivation. That doesn’t mean you have to miss a funeral or have a complete mental breakdown.
> People have just stopped thinking for themselves.
I see the opposite. People are thinking for themselves and are looking at empirical evidence like TFA to boot.
Edit: your other comment about needing targets makes me suspect you'd benefit from using a personal task manager that can clearly and tangibly visualize progress if you aren't using one already.
I learnt early to task things out, in my head/notes.
Graphical representation seems like a crutch to me.
Specifically regarding 100 days of coding - with truly zero breaks yes this is ridiculous. Defined as design instead, it's not - I work best in periods of long productivity, but I also require time to focus on different activities, else I suffer in ways that affect my performance. If you can't write code, that's fine, maybe look at the problem a different way or build that tool which helps you succeed in your 100 day goal.
That's the opposite of poor work ethic, IMO, and that's exactly what is required (mental breaks) in order to succeed, at least in my experience.
It's fairly factual, just because you have a way you might like to work or think is best doesn't mean it's the only one. People are very different, perhaps there is some psychological profile which behaves differently than another, regardless just as there are extroverts and introverts, people don't all work best in one way.
I suspect most people can benefit from breaks, and the studies seem to back this up. Perhaps you are the special one - not the other way around.
Someone commented about running challenges. Similar. I need a target to achieve and a reason to motivate myself. Frankly speaking, I’m terrible at writing code but I do it for fun.
Well one might start to excessively think like a computer!
For example, most humans can account for the imprecise nature of language and understand that "for anyone" doesn't necessarily mean every individual human on earth, but rather a sizeable portion of people. And "isn't good" is speaking relative to the poster's ideas rather than them claiming to have determined an absolute measure of the term "good".
-
But a computer struggles with such fuzzy constraints and falls back to the most literal interpretation of any statement.
At which point the GPT-3 model the computer is running might regurgitate some overreaction by jumping from someone essentially saying: "everything in moderation" to interpreting it as an attack on hard work and good work ethics.
This is an unfair attack. Choosing "for anyone" instead of another phrase does indeed carry meaning. You're both finding more meaning than is justified. A little wobble in imprecision from martin led to a bigger one in systemvoltage, led to a bigger one in you.
(A better ending sentence from martin might've been "We don't want to incentivize 100-day streaks." But that has its own, orthogonal downsides--oh, GitHub's in the business of setting incentives? Uh oh... So all in all, I think I understand his choice of phrasing.)
This would be unfair if they didn't springboard into:
> The current social bandwagon can be summarized as: “Work is bad. Hard work is toxic. Perseverance is not healthy”. HN is just reflecting r/antiwork ethics. Complete and utter social non-sense. People have just stopped thinking for themselves.
This is generally not even-keeled behavior.
"Everything in moderation" dates back to 6 BC. This was clearly an reinterpretation of that basic idea. No reason to hop into a tirade into the death of hard work or something.
I’m just generally fed up of antiwork culture here. We are teaching youngsters to never persevere and push themselves to the limit, ensuring they’ll never realize their full potential and spiraling downwards in a low quality life of lethargy and resentment towards those who succeed.
I thought this is “Hacker News”. The tone here has slid significantly in last 5 years. Folks like Martin apologizing indirectly.
> We are teaching youngsters to never persevere and push themselves to the limit, ensuring they’ll never realize their full potential and spiraling downwards in a low quality life of lethargy and resentment towards those who succeed.
I think you vastly misunderstand the entire point of antiwork. Its not saying go sit on a couch all day. Its to recognize you have a life outside of work and its okay if work isn't your driving factor in life.
You can learn to persevere and push yourself many many ways. Work is not the only way. Not excelling at your job does not mean you are lethargic and resentful.
Success is measured many different ways, by many different people. You seem to measure it by how hard you work, that's great. Doesn't mean everyone has too.
How? If I do what is asked of me and no more, then go spend my free time with my family, or go hiking, or do a million other fun, fulling things I could enjoy. How is that destructive?
I meant what you’re saying is normal and great; but that’s not the antiwork culture and does not describe it accurately. I have an extremely cynical view of it and I’m convinced that’s people don’t have the best intentions. Not a single comment on HN in last few years encourage hard work and mentally exhausting yourself. Your brain is far more capable than the current zeitgeist tells you. We are raising a generation that will revel in lethargy and smoking weed all day.
> Not a single comment on HN in last few years encourage hard work and mentally exhausting yourself.
I am astounded that not pushing yourself to mental exhaustion is what you consider anti-work. If I'm not willing to abuse my own body for the good of a company I'm destined to be lethargic and smoke weed all day? What the hell kind of scale is that?
Pushing yourself to mental exhaustion, is stupid and pointless. It's been thoroughly studied, by the time you've hit mental exhaustion you are not doing anywhere near your best work. Hell I've seen it myself. I noticed my code quality and code output fell drastically the more exhausted I became. I can not stress enough how much better you are not doing that.
Looking through your own post history I see clear signs of trying to work while exhuasted.
> it takes me forever to make anything with code. Like hours to do something simple.
This was literally me until I learned to not push myself so hard. I had the exact same problem and it turns out for me at least trying to learn programming while exhausted did me no favors. I worked all day came home and tried to learn and struggled the exact same way you are. It wasn't until I was able to learn more during the day while not exhausted that it really started to click with me.
You more then anyone need to really reconsider what I posted earlier. Please for you own health.
I have been programming for decades, and I have never had a time of outstanding productivity without times of times of much less activity. Creative activity, for many people, is non-linear and not a recipe based activity. Sure, writing the fourth app in a framework, you can crank it out, but coming up with a great framework for the type of applications rhat your business and technical environment requires something else, a metaphorical walk around the park, while the various possible pieces od solitions kind of simulate themselves in your muttering only half conscious imagination. The sort of solutions that achieve the agile manifesto imperative to maximize work not done. You find interfaces that simplify the problem space so much that so much possible code becomes unneeded.
I find too many people mistaking velocity for progress to be an almost insolvable organization problem. if you want to end up with mega lines of code that are all part of a useless of incomprehensible solution that is certainly a job, but might fail as a life's contribution.
I am no longer an eager youth, but when i was, the thing that hooked me to push on past limits, was my excitement and joy about solving real problems, at scale, with software, with a simple yet powerful idea. It was not any history of frequent commits or risong to rhe 95th %ile or the barren useless of a streak. It was having an idea born out of real needs and made simple enough to need almost no comlexity to implement. Having that novel simplicity go into production and be used was motivation for a lifetime of work.
I certainly have periods of stillness and more restful learning than prodigious output, but they are, for me at least, completely necessary. they may be fairly lethargic as well.
I'm a believer in code everyday. It doesn't need to be more than a few seconds long for it to count. Leave an editor open and add a function if that's all you have today.
Could you explain why you believe daily code contributions are beneficial? If one can only feel inclined to add a simple function then it could be indicative of burnout, and thus time off is needed, not a gamified-obligation to write code.
It builds a habit and moves you closer to your overall goal. It's similar to a common suggestion for writers who want to write a book: open an editor and write at least one sentence per day. Or doing at least one push-up every day.
No more zero days, so to speak.
Starting is often the hardest part. An easy task makes it harder for you to talk yourself out of it. It also keeps the ball rolling.
I think the OP meant "code" in its purest sense - writing something for themselves, not necessarily pushing the contributions to GitHub as a part of gamification.
You don't have to do it if you're disciplined. I struggle with it and I find tiny daily habits useful.
Habits have context. I do gardening and I have a habit of checking my garden beds for weeds and diseases every day. I don't do it in winter when it's freezing and nothing is growing. I'll pick it up again in spring.
You don't have to game the system you've created. The habits are for you, not the other way around.
If you have nothing to fix you obviously don't need a productivity hack. It's called being done and you should either retire or move on to something else.
It helps me avoid procrastination. "Don't break the chain" is the only productivity hack that has actually worked. Even if you only need to do the bare minimum it helps you to get started (which is the hardest part for professional procrastinators), so it seldom stops there.
There are many entire fields of software achievement that have not been realized yet that are just "take this common idea/technique from field X and apply it to software." Limiting your own intellectual exposure to only currently existing software methods seems like it will cause you to miss possibilities for orders of magnitude improvement from time to time. Assuming you are including quantum field theory, cladistics, chemical engineering, history of societies, mathematics and linguistics as part of that non-sense. We live in an epoch of more learning than anyone can absorb, so there are fortunes to be made in moving learnings around.
I worked as a contractor/freelancer for ages, and coming back into fulltime employee work I was appalled that this was actually considered to be relevant to my impact on the job site. Some of our clients used gitlab, which to github looked like a long stretch of zero activity.
I'm sad that we as an industry use such simplistic and error prone metrics. The closer I get to the hiring side of things, the sadder I get.
I develop software for a living, and I do a very different kind of software dev for myself, as a hobby, in my free time. Its a creative outlet of sorts. On my personal github, I have lots of activity, and its disjunct from my job stuff.
Its not really a great idea, in my opinion, to say "you have a hobby, so you probably dont have a job".
The commenter you're replying to can chime in here for an accurate response- but I assume what he's referring to is that a company usually assigns you a fresh, internal GH account. My past three jobs have all done this, which makes it even harder to demonstrate the work I've been doing to employers... Especially when after leaving a company my GH profile is terminated.
I feel like companies don't use Github as much as individuals. I've seen Azure DevOps used a lot, Gitlab right behind that, Bitbucket as a third option, however I've yet to work for company using Github organizations. And I don't blame them tbh, Github for organizations, has less feafures, but costs a ton more than other alternatives. Other thing i've notices is that sometimes, bigger companies have special deals with Microsoft, that for example include some Azure DevOps features for free.
I know of at least three huge, multi-national corporations using Github extensively - either via separate, protected orgs and repos directly on github.com, or a separate Github Enterprise instances on their own domains.
Do the non-programming vice presidents at these companies know that you don't need a 3rd party host to use Git? That literally a networked file share is enough (assuming a decent VPN)?
Oh, what am I saying, they're mid-level management. Of course a bloated paid solution involving a 3rd party vendor wins over simplicity. Otherwise they'd be out of jobs!
I've always maintained: if you put a number next to someone's name, then that person will try everything to try and increase that number. GitHub is no different than any other social media platform, and has various metrics (Stars, Followers, Contributions, etc) that people relentlessly try to game.
Yeah but Hackernews' karma score doesn't really mean anything to me. I mean it's great if one of my posts gets to the frontpage and all, but for me it's a useless metric. The only purpose it serves is optics into how well a post performs, but that's about it.
I used to not be able to: I set my bar to #000000, which is the same color as the text. And unless I'm imagining things, somewhere along the way it changed to #222222
I can set the topbar to #222222, but then everything else shows up in an annoying low-contrast shadow
You can't, period. There used to be a comment-level counter years ago, but it was removed as part of an experiment to see if not having it improves overall discussion quality. Apparently the experiment concluded positively, since the counter hasn't been brought back.
Yup I always cringe a little bit when I see developers on their repos or social media asking for follows or stars to their repo. If it's good people will do that anyways.
It seems like it can be a resume builder for some people though. I've seen resumes where people list their open-source repos and display "Over 500 stars on github" as one of the line-items.
As a maintainer for quite popular Go repo (20k+ stars) I find really annoyed by the amount of trivial PRs (started at start of 2022 or some time like that). Especially then some random dude starts to "improve" tests by checking errors etc and submit multiple different PRs where each PR "fixes" only one file.
this crap makes my life harder as I do this stuff from my spare time. Doing comprehensive review takes me 30min to 1h sometime more couple of hours to provide alternatives with examples etc.
I have not seen almost no rise of useful PRs that add features or fix bugs since that change in early 2022. Only rise of trivial nononse PRs.
A good idea is to create a file called CONTRIBUTING, and then inside put 5 of your top bullet points for what you expect form a PR. I thought it was dumb at first, but people actually used them to my surprise. Hope it works out for you! Also it helps if you don't tag your repos for the hackathon things.
As a maintainer for two less popular repos (3K & 5K stars), I'm very happy to get small PRs with incremental changes. Many of our large contributors have started this way.
We have a robust test and linting suite on both, so we often don't need much human engagement for reviews — code looks reasonable, tests pass, smash "Merge".
Out of interest — do you find they're not actually improving the code? Or it's just not worth the time to review it?
I don't maintain a repo of that size but I have to say this sounds more reasonable. I guess it totally depends on the project. I guess tons of PRs could be annoying _but_ if they are actually useful PRs, then it would be nice to have smaller, more manageable PRs, no?
For example: In Go you have `x.Close()` / `err := x.Close()` that returns an error and if someone starts to check/assert those usages in tests which you have ignored in test code. I think they are pushing the limits. No - these do not add value. No new use-cases are being checked, no improvement to coverage etc.
or typo check tests.
I do not reject these PRs. I review these and merge but I feel annoyed.
This non-sense started somewhere around start of 2022. Before that I rarely ever see PRs like that.
Them doing it and you getting annoyed sounds like a bad equilibrium!
I'd echo the sibling comment re adding what is / isn't appreciated into a CONTRIBUTING.md. My guess is people are doing it to get their feet wet with the repo, being helpful on the margin, and would not do it if they thought it was unhelpful on the margin.
I find a lot of typos in documentation and I never create a PR lest people think I am one of those people. They really do make things worse for everyone.
Honestly these are my favorite PRs to receive for my open source side projects. They are easy to review and approve. The smaller the PR the less time consuming it is for me to deal with them. Big PRs that add complex new features are also appreciated of course. But setting apart time to review them is often hard given other responsibilities that I have. And often I personally don't even need the feature that's being added.
Honestly this is baffling to me — who doesn't appreciate PRs fixing typos? Does even the parent commenter agree with this, assuming they're actual typos?
I both try and make these PRs, and appreciate others doing it! That's how things get better.
Again — disagree — the cost of reviewing diffs is superlinear in their size, with a tiny intercept of the manual steps of opening the PR and clicking "Merge".
Maybe this is too extreme but I cannot remember seeing a PR too small, and I've merged thousands.
How many stars were you at when this began to happen? I maintain a repo with 8k stars and so far we've not gotten a single PR that felt like it was in bad faith - even with the hacktober fest tag.
It's very much interesting how gamification tickles the monkey parts of the brains of me and even the smartest people I know. We even know it's "stupid" or "useless" and still strive to make the number go up.
Frankly, thats terrifying, now that I think about it. What a powerful tool.
Same reason why obese people keep eating junk food and smokers have a hard time stopping, we're still monkeys, if you know which buttons you have to press you can make us do really unproductive/negative things
We're still competing for food, attention, mates, &c. it's just that technology made it so convoluted and "unnatural" that we somehow don't even make the link anymore
I never understand people chasing daily commits to GitHub. You can push whatever git history you want to GitHub. I can rewrite all my commits so they are evenly distributed across however days I want to show up green on GitHub.
Gamification works until it doesn’t. Ask the most addicted gamers that exhausted games they’ve played endlessly. It burns something out in your brain and you can never truly return to said game.
Whatever. The burn out from gamification is of no consequence simply because the economy knows there are fresh bodies to take the place of the torched.
I just recently made my github activities private, also blocked part of the github UI (for example achievements, profile avatars), and removed all my stars from repositories and instead made a 'repos' bookmarks folder to put interesting projects in. (I do the same for many platforms, in the sense of bookmarking stuff instead of using platform-built-in features to 'save' something - what an illusionary save as well...).
I don't want to be locked in, I also don't want to be manipulated by shiny virtual crap. Activities also is such a poor metric. On many days I have simply one commit, because it's a night of programming followed by one push to the repo... friend of mine wrote a script that makes one-line changes to a file and pushes regularly, so his activity chart looks great... (his first idea was to have it spell something out)
The trend with github seems obvious, it'll be a linkedin dev-hiring social media crap-platform people stay on for visibility and many developers eventually won't know how to use git outside of it... (and we hear the cries of "I'd like to contribute but it's not on github..." and some projects will see it as a feature of being not on github to keep those kind of people away).
So many things are going to sh*t... and people like it, which is the worst. sourcehut.org is a nice alternative (I have an account). I also wish more people would just host their own gitea instances.
"GitHub removed two counters from developer profiles that tracked their current and all-time longest streaks of uninterrupted daily contributions"
Those the least significant aspect of gamification on GitHub. Stars, visits, downloads and maybe forks are what developers are interested in. And - strangely - the article seems to ignore them.
"GitHub has gamification elements in the form of badges for projects."
What, that stupid shark and cat icons? They're just embarrassing and I don't even remember what they mean. I found out I can turn them off and they were gone for good.
As someone completely oblivious to gamification on GitHub what is the primary motivation? Is this some form of social validation, like resume padding, or do people contribute to this behavior for some other quality. What goal does this fulfill?
Release endorphins in the brain to make people contribute more to opensource than they otherwise would. It doesn't work on everyone and is extremely effective on a small group of people with most people being somewhere in between.
It's basically an attempt at hacking brains to get more work for free.
Same, that said, we should want the people with addictive tendencies to be protected, because it's the right ting to do.
There is also a selfish argument to be had for why you should be against features targeting addictive behaviour even if your are immune yourself. Take games as an example, modern AAA games have been completely ruined by design chasing addicts for money.
Gamification is significantly more widespread and influential than commonly thought. We’re aware of it in our own corners of life and work, but less aware of how it’s being used on, e.g., truck drivers, gig economy workers, school students, video game players, and more.
The wall of contributions (with different degrees of green) is also pretty ill conceived, with a 1000 lines of code commit having the same value (one contribution) than opening an issue.
I'm not discarding the study or the many anecdotes I heard, but I'm still chuckling because as someone who loves gamification and achievements in game, I was always completely ignoring this on Github. Which would be more apt if I was a 9-to-5 programmer but I only ever had one job that primarily used Github (after they introduced this stuff, I'm pretty sure except that graph there was nothing pre 2013), but the majority of my activity is just fun projects and open source work.
Ranking output of a task by bulk quantity without any measurement is not a good idea. Maybe some people didn't get the memo that taking software development advice from Josef Stalin isn't the greatest concept.
"They urge caution: gamification can steer the behavior of software developers in unexpected and unwanted directions"
What do you mean unexpected and unwanted? It is the stated purpose of gamification to steer the behavior of the user. And I'm sure that in Github they worked very hard to create the incentives for exactly the type of behaviors they found.
Yes, gamification can be great for encouraging the desired behavior. The question is whether the behavior desired by microsoft is aligned with devs interests.
TIL (actually YIL) that you can turn off the stupid badges. I could have figured it out, anyway, by simply going through the settings, but I didn't.
GH is a place that I can store and share my work. It isn't a social media outlet. In fact, this here venue is about the only place I engage folks, nowadays.
Has anyone written (or detected) software/scripts to game the gamification? 24/48h delay/scheduled git push so you can have a healthy work life balance while feigning to employers that you are a code machine.
This paper is cheerless — gamification for good should be celebrated!
If we can make contributing to open source projects as exciting as playing Factorio or watching TikTok, that's a huge benefit to society.
And even if we don't care about the benefits to society, it's also much better for the developers — they can be part of a community, know they're making an impact on the world, potentially get a better job through their passion.
Is there a potential downside, that people build fewer human connections, spend less time with their family, delay finding a partner — sure. But is it more of a risk than with video games or their job? I can't see how we can draw that conclusion.
So let's give contributors more status, and if that means more badges on GitHub, great.
> If we can make contributing to open source projects as exciting as playing Factorio or watching TikTok, that's a huge benefit to society.
If you suck at Factorio or waste time on TikTok, it doesn't really affect anyone else other than yourself and your direct friends/family. If you're contributing to OSS to earn points based solely on participation and not quality/value, you're having a negative effect on the signal-to-noise ratio and quality of the OSS community. That is NOT a huge benefit to society. Simple participation isn't inherently beneficial if that participation is just a source of noise.
I speak as someone who has had to sift through and reject pull requests and issues from incompetent developers. I'd rather they not be encouraged to waste my time.
If any "incompetent developers" are reading this, come and contribute at Xarray or PRQL — you will be part of an exciting project, and we'll mentor you to become competent developers. Your contributions will be appreciated by the devs and the users alike.
coding, specially for open-source projects does not even gets close on how much cognition you have to burn vs. watching TikTok…
i would have someone coding with me excited by seeking knowledge rather than trying to reach level 75 on Github…
not even mentioning what is gamification? are levels based on dark patterns on video-games, created with the intention of making players waste more time or get more addicted?
and then what is the end point of having someone full of badges and trophies on their profile?
to compare oneself with others and feel bad? have benefits over others that a hierarchical system has?
append: i am not typing levels were created specifically for a dark-pattern introduction but nowadays, even if the game is not free, these practices are done to make players addicted.
and i can not feel how someone really interested into get better at coding, would care
If someone told me they're striving to achieve 100 days in a row of contributing, my first thoughts would be "egocentrism" and "dishonesty". Helping isn't about you helping. And if you're aiming for 100 days in a row, I'm pretty sure you're pushing changes you could've pushed during the week on Saturday and Sunday to keep up the streak. Somebody could've reviewed it two days earlier, but you kept them waiting until Monday, just for style points.
The article discusses gamification, but really a lot of the general incentives for open source are to bolster the resume of the developer by showing they work on important, credible things.
Gamification transforms that generally open-ended benefit into KPIs of various sorts -- rather than present overall value as a contributor, you get badges for _how_ you develop.
I’m not really sure that that’s true for most FOSS contributions. I think (anecdotally) most maintainers of even smaller FOSS projects are driven by solving a particular problem they’re facing, not because it generates status. I think most developers who are contributing to FOSS projects because it makes them seem credible are not usually contributing much to those projects (as they’re rarely core maintainers).
To clarify, and not by way of disagreement: you're speaking to what motivates folks and claiming it is altruism. I agree. I was talking about the incentive structure as it is, which is much less about altruism and more "what is the benefit folks involved."
The key here is whether it's "contributing" or "contributing to ___." If someone's goal is, say, to ensure that every day they make at least a few lines of incremental progress on their [game/book/project/set of open source projects they want to contribute to] etc., and even/especially if they publicize that goal to create some external accountability, that can be a really powerful tool - as long as it doesn't get ahead of one's well-being, etc. But having a streak just for having a streak's sake is unhealthy at best.
I hear you, and don't disagree re: potentially questionable weekend commits, but also know from experience (and having read many books on productivity and motivation) that tracking behavior and using "don't break the streak" as a motivator can be effective.
> Potentially, the people responsible for deciding your salary.
Yikes, yeah I forget some people have that type of workplace that isn't necessarily result driven. If that is the case and does get someone escorted at least there's a chance they'll end up somewhere more engaging.
I don't understand how it is possible to lie to myself. It requires you to suspend disbelief and say to yourself that something did or didn't happen, that's something I cannot fathom.
Lying to yourself doesn't necessarily require suspension of belief entirely, but convincing yourself whatever you are doing is worth you doing it. Since it's hard (probably impossible) to know the object truth of if something is " right" or not. Then it becomes fairly easy to justify anything, im sure you've done this even if you don't know exactly how to admit it or don't think you're doing it consciouly.
But you can also be motivated by a streak and do work you wouldn't have otherwise done.
Personally I find streaks are powerful motivators. If this were going to affect my work negatively it would probably be something like "not resting adequately."
Yeah but what if the streak that motivated you was now "improved" - your annual bonus now depended on keeping that streak.
You would be foolish to not have a little dry powder in your stashes. Maybe get a week or so ahead and commit fixes from 5 days back, so that if you hit a gnarly bug today you have five days to fix it for real and your streak is not affected.
There is no simple metric for "doing quality work" and any management that is not "i will sit down and read the code and understand it" is not real management.
And this does not scale. And so quality, creative work does not scale. Hence clusters. And senior staff engineers.
Oh and btw, staff engineers are the executives in software lead companies. any non-coding layers on top should be viewed as financiers - with some interesting organisational implications
I got an Apple Watch in mid 2021. I was a casual runner before then. By the first week, I was watching the 3 rings on the watch, and by the second week I had a streak going. I hit my rings every day for a week. Then 2. Then 3.
The only way to close the 'move' ring goal - 730 calories/day - for me was to run. I could brisk walk some days, but between work and other commitments, running was the only 'fast' way to close the circle. I went to the gym more, or ran around the town near the office.
And then I got to 4 weeks. Then 2 months, and so on. After several months, I didn't want to break the streak. But it gets hard - bad weather, feeling sick, personal commitments. I was doing... weird stuff just to hit the goals.
I got to 1 year. Then... even a bit more. I intentionally stopped on day 400.
I done a couple of small streaks since then, almost accidentally, but am not going to try for a long streak again like that. It started to consume too much mental space, and became a distraction. If I get to the point where I have less going on in life, perhaps that will be a new goal again. I've already proved I can do it, but I've now proved I can stop too.
Before all this, I had set up a goal of 'run min 2 miles every day for a month', and did that too, but my schedule (and weather) doesn't always allow for longer commitments.
But... I also didn't tell anyone about any of these until after I'd hit them. No, not true - I would tell folks in the office sometimes about "oh, I hit day 264 today" and show my watch, but usually only if/when the topic of exercise or apple watches came up.
If someone told me they're striving to achieve 100 days in a row of lying for profit, my first thoughts would be "egocentrism" and "dishonesty". But it's actually just called marketing apparently and it's a job.
To me it leans more in the ego direction if they were using a social network platform to track the running activity so that it can be compared to their friend's activity.
I feel this is really about wether you are doing something for genuine self improvement or to gain social status. It's the latter we tend not to like because when wanting to gain social status you tend to shortcut and "cheat" the self improvement part. However it's not always easy to distinguish the two.
If your code commits are, like running: regular chunks of interchangeable, repetitive, rote, menial labor that an untrained child can do, where the only benefit expected by anybody is your own personal exertion, and making it a static, mechanical routine with no novel output is the very goal for the majority of practitioners?
Then of course nobody would criticize you for aiming for a “streak”.
I might be missing something, since I don't use github that much: Are you implying there's no way you can imagine that someone could cook up something useful enough to commit to a feature branch under development during a day's work?
Maybe if they're working on rocket control firmware or something that's true, but it's not hard to imagine being able to make a small fix/upgrade/refactor to some sort of app every day
(gamification) an expression of paternalism from the C_suite, who believe coders are basically ungrown children, and encouraging that for their own benefit IMHO
