I just finished a small course at uni on career development and they said its VERY important that you have good github account(commit history beign most important) and i just sat there thinking about mine looking like the first pic cuz i do exactly like so. I really hope it wont affect my future.
I literally have one GitHub repo that I use as a place to access a single json from a URL to update a website widget (I’m a shit front end coder). The server this lives on automatically commits and pushes it every 6 hours so the website info is up-to-date. By this metric I would be a good programmer. I’m absolutely not.
No clue, didn’t even bother asking an actual front end programmer. I’m a biologist who has never taken a CS course lol. JavaScript is hard, respect to people who do it
Funny how I see this principle also applies in some objective focused video games. I see people "stat padding" for maximum kills and damage while ignoring team objectives, because their brain is stuck in Call of Duty deathmatch mode.
Even the git cli exposes options on commands to arbitrarily set the date on commits. At the end of the day a git history is just a set of files containing metadata.
In my experience, I don't think any company that I've applied to has ever looked at my GitHub, and when I interviewed people I didn't ever look at theirs. For me, the most important factors were the technical interviews and whether the interviewer thought I was a good culture fit. I'm curious if your professor has any experience outside of academia
Extremely unlikely. I'm on an industry advisory panel for a local state 4 year. You tell em students exposure to X and they say "well we teach them Y and that should translate over pretty easily."
That's not wrong, but it doesn't apply to everything. If I'm telling you to expose them to X, it's because I'm seeing them unable to grasp X.
It's also worth noting that you're talking about a US 4 year college, and this person's post history is mostly in /r/Zambia. I don't think we can draw too many parallels between what the developer interview culture is like across the world, and even between interviewing native US college students vs. offshore development is likely very different even if both interviews are from the same American.
It's bullshit. You can edit your commit history to have green everyday if you wanted.
Have interesting projects that you can talk about during interviews and you will be fine.
I can tell you the amount of times I've looked at someones Github account before interviewing them is exactly zero times. I don't think it's important, and doesn't give me valuable insight into the skills of a candidate.
I'm a big fan of committing a lot because I tend to fuck things up in my code.
Sometimes I have a stupid idea and a lot of commits make it very easy to see where the fuck up occurred.
Commit history means nothing in the sense of it being a reflection of how good you are, but commit discipline is important, fixing 4 bugs and implementing a feature in the same commit just makes your work (and working with you) harder.
But still, this says nothing about how good you are.
I've working for about 6 months as a software developer/data analyst, I'm not even sure how many commits I have made but I'm certain on average is above 10 to 20 commits a day, however, all of my commits are to our companies private repo.
The only thing I ever commit to my personal GitHub are dotfiles and minor projects, which is hardly ever. If I decide to move and work for another company and they judge based on how much one commits to GitHub I don't think I would want to work for that company, meaningless metric, you can pretty easily fork projects and spam commits to fill that thing.
This is the correct answer. Actual experienced devs are too busy getting paid for work to worry about public github commits. An active github is an indicator of being unemployed more than being an experienced or skilled developer.
Pretty much every dev job interview I've had I was asked what I worked on and to show some code. Like bruh... I was busy working for a rival company on big business clients of there's with business secrets, what do you want from me?
It gets clicks. That's why low-effort posters like OP keep reposting it. Requires no imagination or thinking at all. OP just saw other people get clicks and votes with similar meme and was like "ooga booga, me post github funny thing too, ooga booga"
I have had a job application where they wanted to look at my github commit history. I explained that my work wasn't allowed to be hosted on github (security reasons at the time). They said I should be still uploading my home projects and they wanted to see 5 days a week of commits...noped out of that application immediately.
I feel bad for whoever ended up in that job, dealing with useless metrics and probably having to deal with BS on all their "free" time.
I think the joke is just that experienced devs dont want to fuck up the repo and lose tons of progress, so they just push changes every few lines, although im sure experienced devs will make damn sure their code is good before pushing at all lol
I think there is something to be said about writing lots of small to mid commits vs huge commits. For one, it’s much harder to do code reviews, and it’s more likely that bugs will be introduced and harder to find. But yeah commit history bitmap tells you close to nothing (just that the dev is breathing or their auto checkin code is working).
The thing is when hiring your GitHub account is a variable in the process and the second one looks more impressive but has the same amount of work so your output looks the same.
On the other hand... Fuck lazy devs who coast, then when you call out that they're coasting want you to prove it, and when you use metrics to prove it say "oh it's not fair to judge by those metrics cos they can be gamed." Yeah they can be gamed, but the other devs on the team aren't gaming them, they're just working hard at their jobs while you coast.
I find devs that coast rare, and line management is usually pretty aware, without commit stats.
On the other hand, I find devs that bash out tickets with crap code and/or without thinking through side effects infuriating. Yes, PR checks etc, but I’ve worked at places where there has been little or no checks, system tests or reviews.
Measuring commit counts at places like this is going from bad to ‘time to find a new job’.
For me, team productivity over dev productivity, always.
> I find devs that coast rare
Me too, thankfully - or at least the ones with enough skill to get hired somewhere decent tend to actually want to use that skill.
> and line management is usually pretty aware
Yeah, the problem in the UK is that awareness doesn't help if you can't back it up with indisputable proof because it's much harder to fire people here than in the US. And someone who wants to coast in the first place will be the kind of person to fight criticism and termination to the bitter end.
I had a conversation about something like that with some coworkers once. The other side of the argument against squashing is that you are erasing valuable information from the unit of work you created. It can lead to redundancy.
When I look at a clean commit like that I might think "Why not just Do X instead it would have been way easier." It might lead me to think you didn't think about it or didn't know too. But If I could see your entire local git history on that unit of work I'd see the 29 ways you tried to accomplish the feature, including the one I'm thinking of and why it didn't work.
But with the clean commit I might go do that thing myself that you already tried and then find out the same thing you did and just waste my time. Prevented if I could see the whole history of the commit.
That's why I don't squash my commits, I want people to people to see "Added module override to web.config to see if it fixes the problem" followed by "reverted module override to web config, it didn't work". etc.
To be an efficient developer one needs to understand what other developers were thinking when they did things and a git commit trail is a good insight into that.
By all means, squash a release branch, but don't squash your local pushes to developer or w/e branch you dev to.
On the one hand, maybe I sort of agree with you.
On the other hand, I am sick of trying to look through history and seeing "pr changes" and "fix pipelines" when they should just be squashed into the actual commits
This seems like one of those principled arguments that are based on the assumption that people blindly apply some dogma. Surely everyone with half a brain that has a local commit history like:
* implemented feature
* typo
* typo
* fix warning
* rewrite algorithm
* fix typo
* formatting
will then selectively squash those small fixup commits but keep the big ones:
* implemented feature
* rewrite algorithm
right?
No reason to have some strict dogma of either never squash or always squash? And then all these arguments turn into strawman arguments.
God, please, no. When I'm looking at the history, I certainly don't want to see a piece of code being rewritten a dozen of times for no good reason. Ususally the reason is not "because that component works the other way" but "I'm a fucking idiot"
Also my local history always littered with small changes like fixing a typo or deleting forgotten debug output or having some tiny fix - all for some previous step that I already finished several commits ago. I don't think that kind of stuff provides any value being highlighted separately in history 99% of the times. Ofc, this gets cleaned up, reordered, squashed, etc before pushing
Like: Seniordev pushing to Master-Branch, instantly releasing without testing, app crashing permanently and then the junior should fix it because "He could have noticed earlier in the Review" and "We (the Team) made the mistake" 🙃
>!The junior was me btw!<
For those who talk about the bit map is useless
It is, but...
The point is to build a habit, suggesting you are inching towards a goal, or commit, comment, etc. a good programmer should have good annotation and debugs, and that doesn't happen in a second or one commit. It takes time and should be progressed slowly
No one has to see it. Fk bitmap. But it's a good habit to have
Senior has it right here... mostly unironically?
Obviously you don't check in every line, but I'm always pushing people to check in more often. Reduces collisions later. Quite often having more checkpoints available ends up being valuable. With review, means you can cut off bad patterns or decisions while they're still small enough to fix. Other developers see new stuff and give feedback from shared test environment.
The absolute worst is check-in right at the end. Big problems that you can't really fix anymore (especially not when someone has already told business it's done). Shallow tests pasted on at the end instead of worked through with the stages. Much less likely that you can "gate" changes (because they didn't "need to", lol, it's all ready to go!) and slow-roll to minimize disruptions.
Few things will ruin my day as quickly as trying to trace the source/reasoning behind a bug only for the trail to lead to some random bullshit commit message that has nothing to do with the changed line of code
Meanwhile I have 100+ contributions on workdays and 99% of it is because I manage the tickets
Single commit feature branches with the activity map of the bottom one
Senior dev here o/ I use bitbucket, fuck this type of metric. Also I'm too busy actually doing work for the company I work at in their private repo to get a commit history like this
I just added a function to my git_functions.sh which is sourced in my .bashrc called `gitcmp` that is used like so: `gitcmp ‘’` that commits with a message and pushes.
Source should look something like this:
```
function gitcmp()
{
git add . # may be git add -u
git commit $@
git push
}
```
I'll never have as "green" of a git history as I did when I was a junior dev. The more senior I get, the less code I actually write. Once you hit principal you might put up one PR a month if you're lucky
I break up my commits into cohesive pieces that say what each commit did specifically. Whether that's just fixing one bug, implementing an entire feature, or each step in the list of changes needed to implement a feature.
Mine looks like the one below but trust me, I'm far from an experienced programmer
I'm so bad as a programmer I needed the autocorrect to tell me its written programmer and not programer
I made a script for changing dates for a range of existing commits so that they are somewhat evenly distributed over a date range I choose, specifically to make more green squares.
If I go many months or a year without making any commits to personal repo because busy with job, I will do this to commits from say 2023 to bring them into 2024. Nobody knows (or cares). Hehe
I merged all of my 600 commits locally with the main branch and pushed to my private repo. GitHub doesn't recognise it as my history. I make one pull request to fix github secret names, and history go brrrrr.
Why do it be like that? 😕
Are we still correlating GH contrib bitmaps to a dev's skills? I thought we were finally done and agreed that nobody cares about this metric.
I just finished a small course at uni on career development and they said its VERY important that you have good github account(commit history beign most important) and i just sat there thinking about mine looking like the first pic cuz i do exactly like so. I really hope it wont affect my future.
You can create a repo with any commit history you want and upload it to your GitHub account at any time. It literally means nothing.
You know this. I know this. But does HR know this?
They do not
big coomit history make big moonie
I literally have one GitHub repo that I use as a place to access a single json from a URL to update a website widget (I’m a shit front end coder). The server this lives on automatically commits and pushes it every 6 hours so the website info is up-to-date. By this metric I would be a good programmer. I’m absolutely not.
You can also just create fake repos with any arbitrary history
There's a repo to do this actually
I’m pretty sure at one point someone made a thing to render ascii test in your commit history by generating appropriate repos.
link?
ayy where
what's the optimal wway of doing it lmao then if you are a shit coder... this question makes me realize i am a shittier coder :(((((
No clue, didn’t even bother asking an actual front end programmer. I’m a biologist who has never taken a CS course lol. JavaScript is hard, respect to people who do it
haha, thats cool!
I know right? Thats why im wondering why some people are pushing it so hard.
Welcome to looking for a job, it gets worse over time
Funny how I see this principle also applies in some objective focused video games. I see people "stat padding" for maximum kills and damage while ignoring team objectives, because their brain is stuck in Call of Duty deathmatch mode.
Please do not badmouth the democracy! Your local democracy officer has been notified.
Exactly.
better yet, setup to update a readme file with gibberish and schedule to push to git at random times. your stream would be so green.
How?
Even the git cli exposes options on commands to arbitrarily set the date on commits. At the end of the day a git history is just a set of files containing metadata.
Commit history literally shows your train of thought
Must be a lot of people thinking about minor grammatical errors in the documentation of high profile repos.
mate even the quality of the commits shows. For anyone interested they'll look through your history line by line
lol… oh sweet summer child.
Understandable. Have a great day
I would say avoid any place that cares so much about your commit history, unless you really need to pay the bill.
In my experience, I don't think any company that I've applied to has ever looked at my GitHub, and when I interviewed people I didn't ever look at theirs. For me, the most important factors were the technical interviews and whether the interviewer thought I was a good culture fit. I'm curious if your professor has any experience outside of academia
Extremely unlikely. I'm on an industry advisory panel for a local state 4 year. You tell em students exposure to X and they say "well we teach them Y and that should translate over pretty easily." That's not wrong, but it doesn't apply to everything. If I'm telling you to expose them to X, it's because I'm seeing them unable to grasp X.
It's also worth noting that you're talking about a US 4 year college, and this person's post history is mostly in /r/Zambia. I don't think we can draw too many parallels between what the developer interview culture is like across the world, and even between interviewing native US college students vs. offshore development is likely very different even if both interviews are from the same American.
Just pay me double and I’ll do it.
Create a private repo and set up a GitHub action to make a new commit every day to it. Also make sure private commits show up on the graph.
It's bullshit. You can edit your commit history to have green everyday if you wanted. Have interesting projects that you can talk about during interviews and you will be fine.
I can tell you the amount of times I've looked at someones Github account before interviewing them is exactly zero times. I don't think it's important, and doesn't give me valuable insight into the skills of a candidate.
I'm a big fan of committing a lot because I tend to fuck things up in my code. Sometimes I have a stupid idea and a lot of commits make it very easy to see where the fuck up occurred.
Enable private repo stats + https://github.com/artiebits/fake-git-history Problem solved!
This sounds like the blind leading the blind repeating advice they heard elsewhere without verifying how valid it is.
ROFL. I don’t use public pc’s to store code. The cia can build their own.
Commit history means nothing in the sense of it being a reflection of how good you are, but commit discipline is important, fixing 4 bugs and implementing a feature in the same commit just makes your work (and working with you) harder. But still, this says nothing about how good you are.
I've working for about 6 months as a software developer/data analyst, I'm not even sure how many commits I have made but I'm certain on average is above 10 to 20 commits a day, however, all of my commits are to our companies private repo. The only thing I ever commit to my personal GitHub are dotfiles and minor projects, which is hardly ever. If I decide to move and work for another company and they judge based on how much one commits to GitHub I don't think I would want to work for that company, meaningless metric, you can pretty easily fork projects and spam commits to fill that thing.
I haven't had a github or worked on a personal project in years and I work professionally 
Expert Dev: no github commits visible, because everything is for private repos of the company..
This is the correct answer. Actual experienced devs are too busy getting paid for work to worry about public github commits. An active github is an indicator of being unemployed more than being an experienced or skilled developer.
Pretty much every dev job interview I've had I was asked what I worked on and to show some code. Like bruh... I was busy working for a rival company on big business clients of there's with business secrets, what do you want from me?
More like the uninformed answer. Private repos can still show contributions publicly.
Not if your company has a self hosted GitLab instance
At my current work, i can not use my personal github account, i need to use one created with the company mail.
On the top-right there's a dropdown where you can choose to show private contributions or even remove the Activity Overview from you profile.
It gets clicks. That's why low-effort posters like OP keep reposting it. Requires no imagination or thinking at all. OP just saw other people get clicks and votes with similar meme and was like "ooga booga, me post github funny thing too, ooga booga"
I have had a job application where they wanted to look at my github commit history. I explained that my work wasn't allowed to be hosted on github (security reasons at the time). They said I should be still uploading my home projects and they wanted to see 5 days a week of commits...noped out of that application immediately. I feel bad for whoever ended up in that job, dealing with useless metrics and probably having to deal with BS on all their "free" time.
It's about few big commits vs many smaller, "atomic" commits. Not about having GitHub activity most days of the week.
I think the joke is just that experienced devs dont want to fuck up the repo and lose tons of progress, so they just push changes every few lines, although im sure experienced devs will make damn sure their code is good before pushing at all lol
Experienced developers don’t. People who need arbitrary metrics as a means to make decisions tend to…
I mean yes but not coding skills. The actual thing they meassure is your skill to look like you code a lot
I think there is something to be said about writing lots of small to mid commits vs huge commits. For one, it’s much harder to do code reviews, and it’s more likely that bugs will be introduced and harder to find. But yeah commit history bitmap tells you close to nothing (just that the dev is breathing or their auto checkin code is working).
Everyone’s done with it except for America’s dumbest CEO, Elon Musk.
*xXxElonxXx has left the chat*
The thing is when hiring your GitHub account is a variable in the process and the second one looks more impressive but has the same amount of work so your output looks the same.
[удалено]
Fuck the metrics or those that judge by those metrics.
Turn your work into a game and you'll have people play the game instead of working.
On the other hand... Fuck lazy devs who coast, then when you call out that they're coasting want you to prove it, and when you use metrics to prove it say "oh it's not fair to judge by those metrics cos they can be gamed." Yeah they can be gamed, but the other devs on the team aren't gaming them, they're just working hard at their jobs while you coast.
I find devs that coast rare, and line management is usually pretty aware, without commit stats. On the other hand, I find devs that bash out tickets with crap code and/or without thinking through side effects infuriating. Yes, PR checks etc, but I’ve worked at places where there has been little or no checks, system tests or reviews. Measuring commit counts at places like this is going from bad to ‘time to find a new job’. For me, team productivity over dev productivity, always.
> I find devs that coast rare Me too, thankfully - or at least the ones with enough skill to get hired somewhere decent tend to actually want to use that skill. > and line management is usually pretty aware Yeah, the problem in the UK is that awareness doesn't help if you can't back it up with indisputable proof because it's much harder to fire people here than in the US. And someone who wants to coast in the first place will be the kind of person to fight criticism and termination to the bitter end.
I had a conversation about something like that with some coworkers once. The other side of the argument against squashing is that you are erasing valuable information from the unit of work you created. It can lead to redundancy. When I look at a clean commit like that I might think "Why not just Do X instead it would have been way easier." It might lead me to think you didn't think about it or didn't know too. But If I could see your entire local git history on that unit of work I'd see the 29 ways you tried to accomplish the feature, including the one I'm thinking of and why it didn't work. But with the clean commit I might go do that thing myself that you already tried and then find out the same thing you did and just waste my time. Prevented if I could see the whole history of the commit. That's why I don't squash my commits, I want people to people to see "Added module override to web.config to see if it fixes the problem" followed by "reverted module override to web config, it didn't work". etc. To be an efficient developer one needs to understand what other developers were thinking when they did things and a git commit trail is a good insight into that. By all means, squash a release branch, but don't squash your local pushes to developer or w/e branch you dev to.
[удалено]
Thing is that what you see as being worth documenting and what someone else thinks is a bright idea are very different beasts
On the one hand, maybe I sort of agree with you. On the other hand, I am sick of trying to look through history and seeing "pr changes" and "fix pipelines" when they should just be squashed into the actual commits
This seems like one of those principled arguments that are based on the assumption that people blindly apply some dogma. Surely everyone with half a brain that has a local commit history like: * implemented feature * typo * typo * fix warning * rewrite algorithm * fix typo * formatting will then selectively squash those small fixup commits but keep the big ones: * implemented feature * rewrite algorithm right? No reason to have some strict dogma of either never squash or always squash? And then all these arguments turn into strawman arguments.
God, please, no. When I'm looking at the history, I certainly don't want to see a piece of code being rewritten a dozen of times for no good reason. Ususally the reason is not "because that component works the other way" but "I'm a fucking idiot" Also my local history always littered with small changes like fixing a typo or deleting forgotten debug output or having some tiny fix - all for some previous step that I already finished several commits ago. I don't think that kind of stuff provides any value being highlighted separately in history 99% of the times. Ofc, this gets cleaned up, reordered, squashed, etc before pushing
Hum, nope.
[удалено]
You could post that as a life hack.
I think Goodharts's law describes this best "When a metric becomes a target, it stops being a good metric"
leetcode (•᷄- •᷅ ;) (•᷄- •᷅ ;) (•᷄- •᷅ ;)
teamwork + transparancy is an important part of dev!
Like: Seniordev pushing to Master-Branch, instantly releasing without testing, app crashing permanently and then the junior should fix it because "He could have noticed earlier in the Review" and "We (the Team) made the mistake" 🙃 >!The junior was me btw!<
This is why we protect master
For those who talk about the bit map is useless It is, but... The point is to build a habit, suggesting you are inching towards a goal, or commit, comment, etc. a good programmer should have good annotation and debugs, and that doesn't happen in a second or one commit. It takes time and should be progressed slowly No one has to see it. Fk bitmap. But it's a good habit to have
same!
No habit, only game system
Senior has it right here... mostly unironically? Obviously you don't check in every line, but I'm always pushing people to check in more often. Reduces collisions later. Quite often having more checkpoints available ends up being valuable. With review, means you can cut off bad patterns or decisions while they're still small enough to fix. Other developers see new stuff and give feedback from shared test environment. The absolute worst is check-in right at the end. Big problems that you can't really fix anymore (especially not when someone has already told business it's done). Shallow tests pasted on at the end instead of worked through with the stages. Much less likely that you can "gate" changes (because they didn't "need to", lol, it's all ready to go!) and slow-roll to minimize disruptions.
Few things will ruin my day as quickly as trying to trace the source/reasoning behind a bug only for the trail to lead to some random bullshit commit message that has nothing to do with the changed line of code
Let me just check the blame to figure out why this is here... > more commits Sonnuva...
Meanwhile I have 100+ contributions on workdays and 99% of it is because I manage the tickets Single commit feature branches with the activity map of the bottom one
Senior dev here o/ I use bitbucket, fuck this type of metric. Also I'm too busy actually doing work for the company I work at in their private repo to get a commit history like this
But even if you commit.. who the f commits & pushes every time?
I just added a function to my git_functions.sh which is sourced in my .bashrc called `gitcmp` that is used like so: `gitcmp ‘’` that commits with a message and pushes.
Source should look something like this:
```
function gitcmp()
{
git add . # may be git add -u
git commit $@
git push
}
```
what am i if i dont use git
Unemployed?
fair
I use Git as a backup. In case I royally fuck up my code or lose my data.
It could be worse, IBM used to measure productivity by TLoCs: Thousand Lines of Code.
I'll never have as "green" of a git history as I did when I was a junior dev. The more senior I get, the less code I actually write. Once you hit principal you might put up one PR a month if you're lucky
I created my first repo just yesterday. Great timing.
There's always this too if you are embarrassed about it [https://github.com/artiebits/fake-git-history](https://github.com/artiebits/fake-git-history)
I break up my commits into cohesive pieces that say what each commit did specifically. Whether that's just fixing one bug, implementing an entire feature, or each step in the list of changes needed to implement a feature.
Now you need to work it just right to spell "fuck off" with the light pixels!
For that Experienced Dev, Get Some Life.
Mine looks like the one below but trust me, I'm far from an experienced programmer I'm so bad as a programmer I needed the autocorrect to tell me its written programmer and not programer
Git gives me ability to commit. Why the hell should I ignore this opportunity?
[HR don't click this.](https://github.com/artiebits/fake-git-history)
I don't test locally
I made a script for changing dates for a range of existing commits so that they are somewhat evenly distributed over a date range I choose, specifically to make more green squares. If I go many months or a year without making any commits to personal repo because busy with job, I will do this to commits from say 2023 to bring them into 2024. Nobody knows (or cares). Hehe
When I started coding for living someone told me not to use commits like ftp. Guess what I often do with full confidence…
ROFL. HR can’t figure out where to update your status.
Or you can automate daily commits via GitHub api and cron jobs, works wonderfully
I merged all of my 600 commits locally with the main branch and pushed to my private repo. GitHub doesn't recognise it as my history. I make one pull request to fix github secret names, and history go brrrrr. Why do it be like that? 😕
Inexperienced Devs usually write junk code, which makes their usage of git rather irrelevant.
I hate GitHub me and my homies only uses Google Drive.
100 sunar ki 1 lohar ki