|> Your team (and manager) sees you're working That's one of the greatest corporate flaws and my biggest personal failure that I fail, and refuse, to adapt to. When I work in a team I often try to empower lacking teammates by taking a challanging task, do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution. While working on it they have to understand how the solution a…
> do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution
once I realized that the hardest part is actually _finishing_
I noticed the same rush when consistently journalling and keeping track of my habits. There is something commit-like about checking in on yourself, even if it's not even remotely code-related. I also think it builds a well-maintained framework that you can attach other (especially time management) chores to. (Well, I'm already at my desk for journalling, let's also write down other tasks I need to do today/tomorrow a…
I think what you are pointing out is really really important. All of this "get SOME work done every day" is really really good, but (atleast in my experience) you have to separate your feelings from likes or stars on social media. Do it for yourself. Do it because you like to do it. Do it because you can develop your inner strength with it. Sure, github stars and a great commit history might give you a dopamine rush,…
For some of us, setting habits is hard-to-impossible. Finding a source of "a dopamine rush" that's correlated with the work at hand is how we get by.
>Your git commit streak looks good Do people unironically care about this shit? What the fuck man. Stop it. Now.
Do I care? No Does my manager? No, but what if they leave and I have a new manager right before performance reviews? I’d hope they don’t care about it, but I assume they’ll see it. May as well make it look nice. Does the random recruiter looking at your resume care? At some point in your career you might be able to afford to not care about this. Most people don’t have that luxury.
If people invested as much time improving their abilities as they did gaming the system, they might find the problem solves itself.
IMHO "every day" is far too frequent, and this ADHD-ish attitude is one of the reasons why the quality of average software has gone down the drain. Developers need to step back, think more deeply, and not worry about being pressured into "shipping code" that barely works. The dopamine rush of your code being shipped This frequent overstimulation leads to less ability for long-term attention. When I taught programming…
You're conflating shipping with release. Of course, many tasks take more than a day to do well. That doesn't mean you can't break it up into atomic parts and ship each part every day (behind a feature flag). I personally find the hubris of disappearing into a branch for many days without any feedback incredibly offputting. If you're working on a team, your team should be able to see your daily progress.
A day is barely enough time to have even a first go at a more serious problem. Why would you push failed starts into the main branch? And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?
I find the reasons why he's advocating that interesting. It's got for his mental health, it looks good to recruiters, it makes the work more incremental (wat?), and it gives him a dopamine hit. Notably absent are reasons that would benefit the project or product. To me checking something in every day does not look impressive. It looks like someone had nothing to do worth talking about and went around the neighborhood…
"Mental health", motivation ("dopamine hit") and even incremental work all benefit the project, by helping them work consistently, and keep them focused - as opposed to coasting and doing not much, and/or getting burned out further. Some people have large inertia when it comes to doing things with delayed gratification (if at all), and ideas like this help.
> This has nothing to do with streaks or dopamine rushes or pleasing managers. This is about getting stuff done. To me, a developer who can't figure out ways to be productive by contributing tiny commits spread over time is a developer who is wasting space in a team. This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights b…
If you're regularly unable to make even a single line change as an IC, your team will probably not be at a loss. Some of my biggest breakthroughs have been far away from a computer, but I can easily understand where the OP is coming from: give yourself a chance to make tangible contribution each day, and maybe it snowballs into something more. Maybe it doesn't and that's ok, but at least give yourself the chance for…
Equalling "tangible contributions" to "git commits" is insanely reductionist. It works maybe if everything your org does - tickets, documentation, manuals, analyses, meeting transcripts, research notes, everything - lives in git, but otherwise, you're just asking to lower the quality of your org's organization and work culture for the sake of hitting made up KPIs.
You're conflating shipping with release. Of course, many tasks take more than a day to do well. That doesn't mean you can't break it up into atomic parts and ship each part every day (behind a feature flag). I personally find the hubris of disappearing into a branch for many days without any feedback incredibly offputting. If you're working on a team, your team should be able to see your daily progress.
A day is barely enough time to have even a first go at a more serious problem. Why would you push failed starts into the main branch? And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?
You might not finish a serious problem, but there isn't any problem where you can't check something in.
> And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?
1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.
2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
3. The lift from merge conflicts / integration work is less.