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, I saw plenty of beginners do this, especially with an IDE, and the addictive nature of being able to edit and run to see the changes immediately lead to many of them falling into an unproductive rapid iteration loop where they were barely even thinking about what they were doing, just making random changes until something seemed to work.
Your team (and manager) sees you're working
Tough problems need time to solve, and you won't see much meanwhile. If needing to put on a show for others is more important than actually working, something is very wrong.
Your git commit streak looks good
Yes, people say this doesn't matter. But I'm sure people like recruiters look at GitHub profiles, and an empty page isn't a great look.
Optimising for metrics never works for those who can see through the illusion, and that's an increasing number of people over time. If I was a recruiter and saw that sort of activity, I wouldn't think of it as more than someone just putting on a show --- especially if the majority of those commits are effectively "thrashing" or "churning".
The satisfaction (and mental benefits) of getting something done
I can personally say that the satisfaction is far bigger the longer you've persevered.
Actually I first thought this person was joking in their blog post. As you already mentioned almost every piece of advice in there is related to how to look good in others eyes.
I would not dare interpreting too much into it but I do not think this is how you achieve satisfaction in your job. In fact I get anxious just thinking about me sitting there and being "oh my, I have not committed in an hour, people must be thinking I'm slacking".
On another note I also think much more goes into what makes a good commit than frequency. It's a topic that has already been widely discussed a lot and will continue to be discussed in the future.
Edit: I suppose this sentiment may also be one of the reasons why I'm increasingly reluctant to work with Gitlab. Their UI changes multiple times per year and I have yet to encounter a UI change that I would actually call an improvement. I value some level of stability in software that is being used by all our developers throughout the day. But someone seems to think their customers need to "see things changing" or they will stop paying for licences.
Some of the main benefits of shipping every day, is:
1. Develop a system where you can turn codepaths on and off with a toggle.
2. Become better at architecture. Learning to split a task into smaller chunks that are easier to reason about, both overall and individually.
3. Learn to do multi phase increment.
4. Develop an automatic deploy/rollback system.
All are good practices, and essential if you need HA. It also gets the velocity into your daily work, so if you need to deploy extra logging, a bugfix ect, you can do it in minuts and not hours/days/weeks.
Can you do all of that and ship on a weekly basis? Absolutely, I just haven't met anyone that do that.
> Can you do all of that and ship on a weekly basis? Absolutely, I just haven't met anyone that do that.
I'd go as far as to claim that you cannot, at least at a level close to a highly available system updated with full CD without any gating or manual intervention.
Weekly deployments implicitly lead to merge trains and large PRs and team members sitting on their ass to approve changes. Each deployment is huge and introduces larger changes which have a larger risk profile. As deployments are a rare occurrence, teams don't have incentives to invest in automated tests or mechanisms to revert changes, which leads you to a brittle system and pressure to be conservative with the changes you do. As deployments are rare, breaking deployments becomes a major issue and a source of pressure.
To understand this, we only need to think about the work that it takes to support frequent deployments. You need to catch breaking changes early, so you feel the need to increase test coverage and invest in TDD or TDD-like development approaches. You also feel the need to have sandbox deployments available and easy to pull off. You feel the need to gate deployments between stages if any automated test set breaks. You feel the need to improve testing so that prod does not break as often. If prod breaks often,you also feel the need to automate how deployments are rolled back and changes are reverted. You also feel the need to improve troubleshooting and observability and alarming to know if and hoe things break, and improve development workflows and testing to the ensure those failures don't happen again.
You get none of this if your project deploys at best 3 or 4 times a month.
Another problem that infrequent deployments causes is team impedance. You need more meetings to prepare for things which would otherwise be automated away. You have meetings for deployments for specific non-prod stages, you have meetings to plan rollback strategies, you have meetings to keep changelogs, you have meetings to finalize release versions, you have meetings to discuss if a change should go on this or that release cycle, etc. bullshit all around.
If your tests only run as part of deploy, you've already lost.
So long as you have a good set of integration tests and the right staging environments to run those tests against, when you ship doesn't matter. I've worked on multiple teams with test suites that give very high confidence what changes are good and are not; most tests were fast and could run before code was merged and block submission. The expensive integration tests ran against a staging environment, and when they started failing it was very quick to identify the range of CLs there and understand what to rollback/fix.
For most of my time there those services only pushed to prod twice a week - sometimes less if the integration tests were failing on the day of one of the deploys. Not every day, not every commit. And yet we had all of those benefits that you claim are impossible. No list of idle people waiting to approve changes, no "huge" deployments, infrastructure for automated tests and more. There are no meetings - those two weekly rollouts are entirely automated infrastructure, and unless an abnormal error rate is detected during the canary proceed entirely without human involvement.
The world didn't fall down. Customers didn't ask us where things were. Oncall appreciated that there weren't constant builds at risk of breaking and falling over - they only had to monitor rollouts twice a week and otherwise could focus on failing tests, logs, and alerts.
> 1. Develop a system where you can turn codepaths on and off with a toggle.
> All are good practices…
I beg to differ on this point actually. It’s very difficult to get right and leads to subtle bugs (or even potential security vulnerabilities). It also pollutes the codebase with conditional statements that aren’t related to the business logic and makes it harder to read. Avoid feature flags.
I think this would be better if it was "Do something every day".
Close a bug, clean up a file, take a pass at a refactor. Set up a new monitor. Build some utility for yourself, or your work flow. Learn something. Play with some new tech and try it out.
> I can personally say that the satisfaction is far bigger the longer you've persevered.
I dont disagree but one can collect small joys along the way to make it easier.
i think it's do something small, manageable, something you can finish soon, to get the feeling you're being productive, while the stuff in the slow-cooker works its magic.
I write a lot of dev ops type stuff so I ship a lot of smaller things as a rule.
But, I have adopted a ship every day rule for myself, which can often keeps me from yak shaving, which is actually a direct combat for my ADHD deep dive tendency. I love what I do and I love to make perfect code, but sometimes that's less than helpful.
One of the ways that ship every day is extremely helpful for me is in helping me with realistic time boxing.
If I'm working on a bigger module or something really complex, I'll note that in the morning and spend 15 minutes adding a new graph to the dash, or knock out a quick bug fix that's been annoying me.
While there's lots of circle jerking about dopamine rush of ADHD, for me, if I had my way, I'd go so deep and ship perfect code once a month or twice a year.
But, we also know there is no such thing as perfect code, but there is a sweet spot that gets quality code into the wild with the least possible amount of time working speculative edge cases.
Looking at my stack and deciding if I'm going to ship my main project today or take a 15-30 minute warm up bug/push thing, has been extremely useful for me and I end up with better small single function commits, and pushing working code with a slot for the edge case. I still do the edge case before we go to prod, but my projects move a touch faster, I don't rabbit hole and my bus factor is quite a bit lower.
> 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.
I think you are too quick to try to claim someone is incompetent or unsuited for a job just because you can't or won't understand a point they make over how many commits they make.
I disagree with you: I think that posting at least one commit per day is an incredible low goal. A commit can be anything, from a major refactoring to fixing a typo. Any developer worth its title is well aware of stuff that needs to be done in a project in spite of not being a high priority. From renaming a function to refactoring a class, from adding a unit test to tweak how a test is setup, there is always, and I mean always, things that need to be done in a project. Even updating a document or adding a comment counts as a commit.
And in the very least, if you feel that touching something in a project is a risky ordeal, your project needs tests.
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 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 but won't be merged.
But then, anyone who knows how incredibly valuable such work is will likely not want to argue whether they are "wasting space in a team" either, and leave on their part when confronted with such claims.
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 it to.
(It also says something to read the OP and not be able to imagine any interpretation other than "they just don't understand how work is done")
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.
- regularly unable: When you're an IC, there's plenty of non-code contributions needed but if it's so fantastically wild that you should regularly contribute code, something might be off.
- not be able to imagine any interpretation: the article literally says it now, but any half charitable reading already covers a productive day of non-code work. There's just still something to be said for making "butt in chair in front of editor" time.
If there's so much "other" taking your time in an organization that this seems onerous, it might be all the more reason to push for that time or question why that is.
> This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights but won't be merged.
I don't think it does. My point was not "do this OR that". My point is that posting a commit a day is a goal that's easily achieved if you do professional work. The work it takes you to fix a typo or add a commit is not something you need to plan around, or have to choose in place of doing requirements analysis.
Only if your job is to write new code/features. I've been involved with critical bugs that took 6 months to figure out the root cause. What are you supposed to commit for those 6 months while staring at core dumps, trying to guess what might be going on?
This goes back to the "ADHD-ish attitude". I've had entire weeks where I didn't commit anything, because I was doing discovery or documentation or some other useful task with an outcome that wasn't code. Should I have deliberately broken my flow state to go put up a commit for a random unrelated typo?
The article does in fact note that documentation is acceptable.
Except it isn't. This is the reason why software is shitty, and most teams are shitty, too.
I write software because I have a vision in my mind, which I want to achieve. Coding up stuff and trying it out helps a lot, but so do phases of quiet introspection and reflection.
> I think that posting at least one commit per day is an incredible low goal. A commit can be anything, from a major refactoring to fixing a typo.
This is an easy goal in some companies / projects, while in others (usually bigger companies / projects) it's unreasonable and will even be counter productive.
You might need hours of execution time in a test cluster, then need code reviews from several peers (who are busy working on prioritized items), and if your commit is later integrated with commits from other organizations and tested as a whole which results in failures, you put extra load on those who are tasked with finding and sorting out the offending commits.
In principle I do absolutely agree with you that ideally it should be encouraged to spontaneously fix and commit, but in practice "it depends". I've found that larger companies / projects have a certain cadence, and trying to deviate from that cadence too much just results in grinding gears on all levels.
> I think that posting at least one commit per day
Notice that the article has been edited.
> Edit: A better title would've been "commit every day that you work". I don't mean you should work on weekends or not take time off, and whatever you work on doesn't need to "ship to prod".
I'm pretty sure parent comment was replying to the original version which, at quick skim, gives the impression that the article was about pushing to prod everyday.
I've worked at startups to do push to pod every day at it's an absolute frenetic nightmare.
Posting a commit everyday is so uncontroversial that I doubt the headline would have made it to the FP of HN. I've also never heard the term "shipping" in software refer to anything other than getting something into prod.
This confusion came from me not thinking too long before writing. My work makes use of feature flags so we incrementally merge features all the time, internally (and can do it quickly). But its still “shipped.”
This right here is the truth. Yes, there's all the of the other stuff -- "requirements", etc -- but in reality, as an IC, we're here to push code and review code. All of the requirements stuff comes on top of that. (In my experience, the people who aren't pushing or reviewing code are _also_ not doing the other stuff either.)
Remember, commenting on PRs counts as activity. That's PR review -- that's doing something, and potentially a _lot_ of something. Big long stretches of empty space on Github is absolutely a red flag, until you get into the highest levels of IC seniority and are mostly in meetings all day.
It is extremely easy to do nothing at all as a software engineer, when there is so much stuff to do any given day. It's easy to get defensive when faced with such privilege.
userbinator speaking out again, loving your posts on "modern" stuff.
Unfortunately, that's how it's like sadly. People just want the "constant CONSTANT CONSTANT UPDATES!!!" without thinking properly, even if they don't need the new features but it's just because the company said so.
Heck, physical books don't even need to get any updates and I can still enjoy picking them up and reading them, just like I can still enjoy launching the old software and using them.
IMHO the software is already feeling like 99% complete, companies just want to abuse the users, get them to use their abusive models, and milk the software in general just because they're lacking any ideas for new "features".
Anyways, feel free to throw pitchforks at me all you want ;)
I just threw a pitchfork at you. It had only one tine, though. It was to the left of your username above, and pointing upward. Heck, it just disappeared into the screen or something.
Wow, your second paragraph hit the nail on the head about the effect that any sort of ML/AI work has on me. Tweaking hyperparameters/prompts/features and running it “one more time” is like sitting down at a slot machine for me. Can burn a day without any real work done iterating towards some unreachable perfect run.
How did "ADHD" enter the conversation out of the blue? If you're thinking this is how "ADHD-ish" experience is, I recommend you to check out /r/ADHD_programmers where people actually with ADD struggle to figure out how to ship consistently, let alone every day!
I left off a key point; your code doesn’t need to ship to production, I just think you should do _something_. Thanks for sharing your thoughts.
> I can personally say that the satisfaction is far bigger the longer you've persevered.
It’s a great feeling to finish something. I find I’m more likely to finish it well if I break it up versus ship it all at once (and my teammates thank me)
I was about to say; if we replace 'ship' with 'commit' I'm in full agreement.
If you're a full time developer I don't know why you wouldn't.
Commits are communication. If we're making them often and correctly, there's that much less fluffing around with reports and status updates and meetings that we need to do.
The merits of CI/CD notwithstanding I definitely do NOT want my reports feeling like they need to deploy every day. That will lead to rushed work and errors on production.
But commit, why not? I don't care if it's in a private branch, behind a feature flag, or even some notes/pseudocode in a comment, commit it. Write an actual decent commit message while you're at it. That way as your manager, I can call up your commit history before our 1:1, and by the time the meeting starts it's already 80% finished because I was able to update myself on what you've been doing.
I don't know about routine skimming of history, but promo committees in big tech look at both commits and code reviews (the comments you left on others' commits).
I work at a FAANG like company, and here it's just annual performance reviews, that include bunch of achievements and then politics. No way anyone is going to check anyone's commit history. There are huge calibration meetings where managers have to stand up for their engineers on who gets what kind of performance rating and who gets promoted, and it's just verbal debates. There's just no way anyone can bring up someone's commit history and have enough time to explain what is going on overall.
And managers have little clue about the actual work that is going on. Definitely not enough clue to understand what commits are about, even if they have had a technical background overall.
> 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.
I agree with you partially because I’ve seen this Rush-Driven Development you describe, but with proper gates in place (hooks, Pull Request checks, culture, etc.), this worry mostly disappears in mature teams.
I’ve worked on teams where there aren’t Code Reviews if you’ve successfully deployed without errors last 3 times. Like, the system has this information stored, so if you’re trusted and the change is not marked as critical, it will deploy automatically after passing all previous automated checks/tests. It works wonders, believe me, and you can still apply other policies, like error budgets and stuff.
I agree some of the other Appearance Driven Development practices sound mostly useless to some, but the reality is that such practices, in my experience, are what made code development explode (in a good way) everywhere. Most people are somewhat social, virtual or in person, so they like to have some notoriety.
me helping a newbie:
"type find...."
him: presses enter
me: "no, don't just press enter, I wasn't done yet, did I say press enter?! oh well, type find dot slash...."
him: presses enter
me: "okay please take your hands off the keyboard! I'll type it for you in the chat."
I once TA’d an intro to unix class where I had to help a lot of students this way.
I would vocalize e.g. “find -name '*png'” as “find space hyphen name space single-quote asterisk png single-quote enter”.
I found that saying it exactly like that had the highest success rate. I never wanted to type it for them because the point of the class was to get familiar with unix and the shell.
My attention span is not nearly enough to push releases everyday, but you also need to basically own the QA team. I've worked in enough places that if I don't have a QA team handy, I assume the worst possible environment. Devs get tunnel vision, we make really dumb UI choices, or account for x, y and z scenarios as issues, and forget a, b and c, which happen when the user uses your software while holding a toaster or whatever.
This is probably why 2 weeks prints are very common, its enough time to get some things out, enough time for QA to test it, and "short enough" that nobody is hounding as to why some feature is taking months. They can at least get it in incremental pieces with 2 week sprints (or whatever you prefer, 1 week, 3 weeks, 4, doesnt matter to me, just be consistent).
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?
> 1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.
If they have the time to do that, they can look at a branch as well.
> 2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
It's also much easier to entirely lose track of what the purpose of a feature was if you only review it in small, incremental chunks. The chunks often make sense individually, but are a convoluted mess when you look at the full picture. Also, a feature branch should still have many small commits on it, and you can easily review those individually as well, but you also get to look at the whole picture before putting everything in. Not to mention, if it needs to be reverted, much much much easier if there's a single PR with 50 commits instead of 50 disparate commits over 3 weeks.
> 3. The lift from merge conflicts / integration work is less.
If you pull everyday from the main branch, there's rarely a problem with merge conflicts and integration work, unless someone else is doing a major refactor. And if they are, there is going to be a problem regardless of whether you commit early or late, you'll still have to keep adjusting to their ongoing refactor (and the possibility of ever reverting will be slim to none).
I mean, sure, if shipping everyday means stuff breaks everyday then its a bad idea--that sounds miserable. But it doesn't have to mean that. I'd rather have a culture of shipping frequently and fixing the occasional mistake instead of shipping slowly and moving at the pace of a snail. Thats assuming "breaking" occasionally is an acceptable risk. Speed does matter, especially with new products. Shipping frequentily often speeds up the feedback loop which speeds up how fast you learn (and how long it takes to build something useful).
There's tons of assumptions in both our comments though, and loads of context thats important. Spend more time on the code for life support systems, healthcare, etc. If its just a bunch of rest API's for a crud app with few consequences if you break stuff, then its okay to live life on the edge.
While I agree everyday is too frequent. Too infrequent release cycles also lead to poorer quality software as the gap between implementing a feature and getting it into user’s hands widens. You generally want that context to be fresh enough in your team’s head that they can quickly fix or improve it.
It doesn't have to be feature work. It can be as simple as a single line bug fix or writing a test. But keeping the pace of doing "something" every day, even if you're burned out or stuck on a hard problem, adds up quickly.
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 actually works (for instance by writing tests), and usually they are happy that they can contribute something bigger than they normally could. I don't mind passing the credit, as long as I know that the person actually made some work and understand the code.
Meanwhile I offer myself for help or pair programming (although I'm not really a fan of the concept per se) to kickstart someone elses tasks, helping with architecture or just the general approach to the problem.
My coworkes like me, it worked wonders when I was running my own company, yet, when working in BigCo I have to constantly explain myself to higher ups that I'm actually present, not slacking and doing my job, because my jira/github profile doesn't shine.
One could say I'm a fool by not building up "portfolio" and paving my way to promotion/raise, but I genuinely think that this brings much bigger value in a long run. :)
this comment resonates with me. I think it’s a common mistake for a lot of folks to forget that programming is a creative task, and creative tasks rarely fit into metrics effectively. I have a bad habit at my place of work for not ticketing things out correctly and pushing larger than average commits.
At one point I just realized that the work in BigCo has very little to do with actual value, and much more politics and PR.
In my last workplace we had two teams working on almost identical applications - large, multistage web forms for insurance. At that time it was a common practice at the office to estimate in units of time. One team was constantly commiting sprints to 300 units and delivering 200, and the other was commiting to 100 and delivering 150. First was quickly disbanded and fired, and the latter was praised for performing beyond expecations.
Maybe for you. I'm terrible at starting projects and the beginning of them, but I love getting all the pieces in place and getting the product/feature to a production-ready state. It's easy and natural for me.
I used to work closely with a "starter" who is great at getting the activation energy to start, and we made a great team. Find yourself a "finisher".
Also, as a senior employee, I found that just general technical and even organizational troubleshooting was difficult to quantify or even justify (in formal management-style terms), and did not really form any kind of "portfolio". Oh well.
These, to me, seem like highly invalid reasons to do something and will definitely backfire.
Ship incomplete features just so your manager sees you’re working? Sounds like a toxic work environment to me.
Fill up your GitHub profile with colors? Seems like a superficial display of smoke and mirrors for those who value such a thing, not for what’s actually beneath the surface of it.
I have the “gift” of ADHD, and I’m quite content with learning something, solving a bug, finding something that can help my team, survive through meetings or just close up tickets every day, without the added stress or cognitive load that I have to ship something besides my usual tasks.
Strive for progress. Learn by doing. But it’s also fine if you don’t on some days. Don’t burn out. Not worth it.
Or don't. The older I get, the more I find the obsession with work and hyper productivity to be pointless.
This might be good advice for young people starting their careers, but even then I would advise prioritizing real life goals over work. Don't buy into the entrepreneur ideals you see on social media. People can be successful without working all day, everyday. Take rests, prioritize your health, and enjoy life first. Work is secondary.
I don't blog, but blogging is something I carry on my todo list for years.
Knowing how important is the cadance to keeping the public engaged I always planned to post at most one post per month, and keeping a steady backlog of articles for at least 6 months in case I won't be able to come up with something new or simply not having time to add something new.
This reflects my own changes. Me at 25 and me at 35 are completely different when it comes to code. I'd rather finish early, spend time with family, and come back tomorrow with a better solution than keep on hammering away on an overnighter to try and hit some arbitrary metric.
> The satisfaction (and mental benefits) of getting something done
I used to think that motivation would come to me if I just waited long enough but I now believe that action breeds motivation. You need to do something no matter how small and your motivation will benefit from it.
Totally agree. I’ll also add that although I am often tempted to work alone, sharing my work or ideas or output with someone else boosts motivation a lot.
Our team is slowing down instead. The quality of the code has become so poor, full of bugs and what not, that we have decided to slow down and instead invest in quality. We currently spend so much time fixing bugs and refactoring spaghetti code to shoehorn the next shiny new feature, that the amount of actually useful features we deliver has decreased. Half-assed features which work on paper but totally unusable for users because we're still at MVP where nothing really works but the PM is happy because he can report to CEO we shipped another cool feature. It's actually quite demotivating to learn that no user actually uses the feature you developed because it's total crap. Yes, we shipped often, but we shipped crap.
Now we focus on writing more tests and doing more design reviews.
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 cutting off leaves from the hedges.
Causing a lot of transactions is a great way to stop people assigning you actual work. I suspect OP forgot to mention that reason. You already look busy without actually being busy. It's like managers scheduling useless meetings. They want to look busy so nobody gives them actual work to make them actually busy.
"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.
It’s actually off putting if you check out a potential employer’s GitHub and it’s filled with obsessive committers, obviously working late hours, weekends, holidays, etc.
Even worse: I've seen profiles that run scripts to generate fake commits for the sole purpose of making their GitHub stats look like they're working. Absolutely asinine, and a huge red flag when hiring.
My personal take is to ship a PR every day, even if its something small. Its been a very good practice that has enabled and taught much over the years.
No, focus on pushing the right solution. If you hold off pushing code that works but does not solve the correct (actual) problem, that's good.
Tracking commit frequency is one step away from tracking lines of code. If this is really the metric of performance, then you are a cog.
My take would be: plan upfront consistently. What do you need to do now to unblock the work later? Does the solution make sense? Is there something more useful? Think lots, talk lots, commit sometimes.
i followed this religiously for a month or two, and found it really beneficial. not necessarily for the product i was building (some of those things i shipped probably shouldn't have been) but for my own motivation.
however, i expanded my definition to mean not just software features, i included writing a new help doc as "shipping". as long as it was something user-visible and for users in general, and not something for one specific user, it counted.
One thing that really helps me is “do nothing time”
When I sit down, it’s tempting to fire up a browser, or Spotify or YouTube or something, then spend time faffing about looking for a good song, no no no, this is really just me avoiding the work.
I sit down, resist that initial temptation and my mind calms, like a storm clearing, and then I let it calm and little more, and then I can start. That do nothing period is only 2-3 minutes but it allows me to slip into flow state quickly. I recommend to others to try…
Several years ago I was doing something that showed your consecutive-days streak. I lost mine at about 300 days because I flew to Europe and the time zone was calculated from the USA, and on the day of my flight I missed a (US timezone) day. I was so sad lol
Totally. Some of us can't afford to stop working for a year or two or however long it takes to properly deal with burnout, so we need metods like this to keep our families from going hungry.
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 and get started with the first one)
I'm not quite sure whether it's really important to keep your github bathroom wall green, but it builds a quite useful habit imo.
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, but so does learning to appreciate the struggle and working through it. It doesn't matter what anybody else thinks about it.
Over the past year/months I built a RISC-V CPU in VHDL. It can barely do anything and if I show it to most people they'd probably think it's super boring. But I love it. I love to work on it. I love to let the LEDs blink the way I wanted to, because I achieved to implement some small thing in hardware and see that it works (imagine my dopamine rush the first time it successfully ran gcc-generated code and blinked an LED on actual hardware. That's boring, innit? But I loved it.). It's often a really hard struggle, because the progress is so little, but I learned to force myself to do it, even if I don't want to/don't feel like it, because I know it will bring me joy in the end, even if I hate it for days/weeks. I sitll do it.
Same with journaling, as you said. It's all about the habits. Find your habit and do it.
This doesn't make sense to me. Sometimes I need to sit down with a problem for a few days before I can even get to writing code. There is nothing to ship because I'm still wrapping my head around the business logic.
On other days I get nothing done because the most productive thing I can do is rest, or tend to personal matters. That doesn't mesh well with hustle culture, but it contributes to my personal happiness and long term productivity.
I think some developers cannot create and refine a mental model of the finished product well enough for it to be worth it for them to spend days doing it.
Also, many managers perceive only writing code as worthwhile.
This. Since 2008 I've worked at one company using a Perforce derivative and three others using Gitolite or GitLab privately, but never GitHub. Maybe commit history matters to recruiters, but I've been on a lot of interview debriefs (discussing whom to hire) and it never came up.
I try to do this, but it's often my own dotfiles or other programs I work on. I have a things.app db of different things I want to do for various projects, most of which are not work related. Just committing a new dotfiles script, fixing an existing one, adding a neovim command to automate something, or deploying a container to my vps that i was curious about -- all of that is shipping imho and i get energy from the creative aspect of it.
As I'm still a coding noob, I don't ship code as much as I want to.
However, I make a simple bullet task list and work on it. Tasks are not necessarily related to coding. It could be a task related to image editing. Initially, I was feeling very bad if I can't finish a task within the time I've set for it.
Now I don't feel bad if I can't finish that task on time. I perceive it as a micro-iteration of the task. The trick is to iterate further, until the task is done.
While rushing to do a task within a specific timeframe, might be productive in the short-term, I don't see it feasible if you push yourself all the time doing it. I imagine it might reflect on the quality of your work and lead to a self-induced burnout.
Shipping for the sake of it, in my opinion, might create some false perception of work being done. In my experience, employers tend to reward that behavior.
So maybe the question here would be: why are you shipping in first place? To show off, to boost dopamine through gamifying yourself, or to deliver a piece of work you'll be proud of before going to bed.
I've experienced being on teams where PRs and commits happen infrequently, resulting in massive PRs and merges/rebases that constantly have conflicts.
The spirit of pushing small incremental changes on a team really helps address that.
This can be sustainable if everyone on the team realizes that every PR is expected to be small and incremental. It shouldn't be a large push every time.
Same here. Every damn time it's only my third idea that is sufficiently correct and maintainable. Unfortunately that means I need to sit and wait before it comes to me.
I could go the analytical road and write down all the requirements, edge cases and just tick them off one bu one but that's throughly exhausting.
At work more often than not I settle on the second iteration, but that is still slow by some people's standards and incurs tech debt.
Laughs at a PostgreSQL schema change backfill jobs that need a few days to complete on i4i.16xlarge.
Or that time I spent $120k USD on testing some upgrade paths on a dataset in elasticsearch from version 2.4 -> 5 -> 6 -> 7 that took about 5-6 days runtime on imports per upgrade step.
There are a lot of people here that seem to be taking the view of "Oh no, it's a toxic to do this. You shouldn't work on the weekend. Why are you doing this just to get attention for your GitHub profile, or what your managers see?"
However, one concept that comes up in research like the book Atomic Habits, is that there's a much better reason to commit code frequently - quantity leads to quality. There's a famous story from the book Art & Fear about a university pottery class. The lecturer decided to grade half the class on the number of pots they produced, and the other half on the quality of a single pot. It turned out that the half of the class focused on quantity ended up producing higher quality pots over time. This is because the group that only had to produce one pot spent the whole time overthinking it rather than actually practicing and mastering their craft.
I think this is a much better reason to be committing code frequently and working on your skills every day. We're in an environment where it's a challenging hiring market, so it's important to set yourself apart from others within the industry. Some people have turned their nose up against "colouring in" their GitHub profile, but there are a number of psychological effects like "don't break the chain" that can be helpful in consistently putting in the effort.
Some commenters have mentioned tasks that simply take a long time, but I don't think the author of the original blog post was arguing against that. Rather, he's advocating that you should be continuously working on and improving your abilities.
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 a doctor told you to poop every day or eat steak every day would you actually do it or would you consider it excessive?
Do you really need those inputs to get outputs that mean something? No.
"ship something every day" is dumb because a day is quite a small piece of time for even small pieces of useful inventive work. Even geniuses don't produce all their things in one day, that would be dumb and geniuses know better.
"ship something every week" would make sense and leave you open to actual proper work still being done in proper time scales.
The dopamine rush of your code being shipped
This frequent overstimulation leads to less ability for long-term attention. When I taught programming, I saw plenty of beginners do this, especially with an IDE, and the addictive nature of being able to edit and run to see the changes immediately lead to many of them falling into an unproductive rapid iteration loop where they were barely even thinking about what they were doing, just making random changes until something seemed to work.
Your team (and manager) sees you're working
Tough problems need time to solve, and you won't see much meanwhile. If needing to put on a show for others is more important than actually working, something is very wrong.
Your git commit streak looks good
Yes, people say this doesn't matter. But I'm sure people like recruiters look at GitHub profiles, and an empty page isn't a great look.
Optimising for metrics never works for those who can see through the illusion, and that's an increasing number of people over time. If I was a recruiter and saw that sort of activity, I wouldn't think of it as more than someone just putting on a show --- especially if the majority of those commits are effectively "thrashing" or "churning".
The satisfaction (and mental benefits) of getting something done
I can personally say that the satisfaction is far bigger the longer you've persevered.
I would not dare interpreting too much into it but I do not think this is how you achieve satisfaction in your job. In fact I get anxious just thinking about me sitting there and being "oh my, I have not committed in an hour, people must be thinking I'm slacking".
On another note I also think much more goes into what makes a good commit than frequency. It's a topic that has already been widely discussed a lot and will continue to be discussed in the future.
Edit: I suppose this sentiment may also be one of the reasons why I'm increasingly reluctant to work with Gitlab. Their UI changes multiple times per year and I have yet to encounter a UI change that I would actually call an improvement. I value some level of stability in software that is being used by all our developers throughout the day. But someone seems to think their customers need to "see things changing" or they will stop paying for licences.
Can you do all of that and ship on a weekly basis? Absolutely, I just haven't met anyone that do that.
I'd go as far as to claim that you cannot, at least at a level close to a highly available system updated with full CD without any gating or manual intervention.
Weekly deployments implicitly lead to merge trains and large PRs and team members sitting on their ass to approve changes. Each deployment is huge and introduces larger changes which have a larger risk profile. As deployments are a rare occurrence, teams don't have incentives to invest in automated tests or mechanisms to revert changes, which leads you to a brittle system and pressure to be conservative with the changes you do. As deployments are rare, breaking deployments becomes a major issue and a source of pressure.
To understand this, we only need to think about the work that it takes to support frequent deployments. You need to catch breaking changes early, so you feel the need to increase test coverage and invest in TDD or TDD-like development approaches. You also feel the need to have sandbox deployments available and easy to pull off. You feel the need to gate deployments between stages if any automated test set breaks. You feel the need to improve testing so that prod does not break as often. If prod breaks often,you also feel the need to automate how deployments are rolled back and changes are reverted. You also feel the need to improve troubleshooting and observability and alarming to know if and hoe things break, and improve development workflows and testing to the ensure those failures don't happen again.
You get none of this if your project deploys at best 3 or 4 times a month.
Another problem that infrequent deployments causes is team impedance. You need more meetings to prepare for things which would otherwise be automated away. You have meetings for deployments for specific non-prod stages, you have meetings to plan rollback strategies, you have meetings to keep changelogs, you have meetings to finalize release versions, you have meetings to discuss if a change should go on this or that release cycle, etc. bullshit all around.
So long as you have a good set of integration tests and the right staging environments to run those tests against, when you ship doesn't matter. I've worked on multiple teams with test suites that give very high confidence what changes are good and are not; most tests were fast and could run before code was merged and block submission. The expensive integration tests ran against a staging environment, and when they started failing it was very quick to identify the range of CLs there and understand what to rollback/fix.
For most of my time there those services only pushed to prod twice a week - sometimes less if the integration tests were failing on the day of one of the deploys. Not every day, not every commit. And yet we had all of those benefits that you claim are impossible. No list of idle people waiting to approve changes, no "huge" deployments, infrastructure for automated tests and more. There are no meetings - those two weekly rollouts are entirely automated infrastructure, and unless an abnormal error rate is detected during the canary proceed entirely without human involvement.
The world didn't fall down. Customers didn't ask us where things were. Oncall appreciated that there weren't constant builds at risk of breaking and falling over - they only had to monitor rollouts twice a week and otherwise could focus on failing tests, logs, and alerts.
I think you got things in reverse.
Deployments happen at each pipeline run. At each pipeline run, you run tests.
Continuous deployment.
> All are good practices…
I beg to differ on this point actually. It’s very difficult to get right and leads to subtle bugs (or even potential security vulnerabilities). It also pollutes the codebase with conditional statements that aren’t related to the business logic and makes it harder to read. Avoid feature flags.
Close a bug, clean up a file, take a pass at a refactor. Set up a new monitor. Build some utility for yourself, or your work flow. Learn something. Play with some new tech and try it out.
> I can personally say that the satisfaction is far bigger the longer you've persevered.
I dont disagree but one can collect small joys along the way to make it easier.
I’m not saying one is better than the other. But having an end in mind will yield more productivity.
But, I have adopted a ship every day rule for myself, which can often keeps me from yak shaving, which is actually a direct combat for my ADHD deep dive tendency. I love what I do and I love to make perfect code, but sometimes that's less than helpful.
One of the ways that ship every day is extremely helpful for me is in helping me with realistic time boxing.
If I'm working on a bigger module or something really complex, I'll note that in the morning and spend 15 minutes adding a new graph to the dash, or knock out a quick bug fix that's been annoying me.
While there's lots of circle jerking about dopamine rush of ADHD, for me, if I had my way, I'd go so deep and ship perfect code once a month or twice a year.
But, we also know there is no such thing as perfect code, but there is a sweet spot that gets quality code into the wild with the least possible amount of time working speculative edge cases.
Looking at my stack and deciding if I'm going to ship my main project today or take a 15-30 minute warm up bug/push thing, has been extremely useful for me and I end up with better small single function commits, and pushing working code with a slot for the edge case. I still do the edge case before we go to prod, but my projects move a touch faster, I don't rabbit hole and my bus factor is quite a bit lower.
I think you are too quick to try to claim someone is incompetent or unsuited for a job just because you can't or won't understand a point they make over how many commits they make.
I disagree with you: I think that posting at least one commit per day is an incredible low goal. A commit can be anything, from a major refactoring to fixing a typo. Any developer worth its title is well aware of stuff that needs to be done in a project in spite of not being a high priority. From renaming a function to refactoring a class, from adding a unit test to tweak how a test is setup, there is always, and I mean always, things that need to be done in a project. Even updating a document or adding a comment counts as a commit.
And in the very least, if you feel that touching something in a project is a risky ordeal, your project needs tests.
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 but won't be merged.
But then, anyone who knows how incredibly valuable such work is will likely not want to argue whether they are "wasting space in a team" either, and leave on their part when confronted with such claims.
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 it to.
(It also says something to read the OP and not be able to imagine any interpretation other than "they just don't understand how work is done")
- regularly unable: When you're an IC, there's plenty of non-code contributions needed but if it's so fantastically wild that you should regularly contribute code, something might be off.
- not be able to imagine any interpretation: the article literally says it now, but any half charitable reading already covers a productive day of non-code work. There's just still something to be said for making "butt in chair in front of editor" time.
If there's so much "other" taking your time in an organization that this seems onerous, it might be all the more reason to push for that time or question why that is.
I don't think it does. My point was not "do this OR that". My point is that posting a commit a day is a goal that's easily achieved if you do professional work. The work it takes you to fix a typo or add a commit is not something you need to plan around, or have to choose in place of doing requirements analysis.
The article does in fact note that documentation is acceptable.
Except it isn't. This is the reason why software is shitty, and most teams are shitty, too.
I write software because I have a vision in my mind, which I want to achieve. Coding up stuff and trying it out helps a lot, but so do phases of quiet introspection and reflection.
This is an easy goal in some companies / projects, while in others (usually bigger companies / projects) it's unreasonable and will even be counter productive.
You might need hours of execution time in a test cluster, then need code reviews from several peers (who are busy working on prioritized items), and if your commit is later integrated with commits from other organizations and tested as a whole which results in failures, you put extra load on those who are tasked with finding and sorting out the offending commits.
In principle I do absolutely agree with you that ideally it should be encouraged to spontaneously fix and commit, but in practice "it depends". I've found that larger companies / projects have a certain cadence, and trying to deviate from that cadence too much just results in grinding gears on all levels.
Notice that the article has been edited.
> Edit: A better title would've been "commit every day that you work". I don't mean you should work on weekends or not take time off, and whatever you work on doesn't need to "ship to prod".
I'm pretty sure parent comment was replying to the original version which, at quick skim, gives the impression that the article was about pushing to prod everyday.
I've worked at startups to do push to pod every day at it's an absolute frenetic nightmare.
Posting a commit everyday is so uncontroversial that I doubt the headline would have made it to the FP of HN. I've also never heard the term "shipping" in software refer to anything other than getting something into prod.
The morale of the story is don’t play speed chess but make move every day.
Remember, commenting on PRs counts as activity. That's PR review -- that's doing something, and potentially a _lot_ of something. Big long stretches of empty space on Github is absolutely a red flag, until you get into the highest levels of IC seniority and are mostly in meetings all day.
It is extremely easy to do nothing at all as a software engineer, when there is so much stuff to do any given day. It's easy to get defensive when faced with such privilege.
Unfortunately, that's how it's like sadly. People just want the "constant CONSTANT CONSTANT UPDATES!!!" without thinking properly, even if they don't need the new features but it's just because the company said so.
Heck, physical books don't even need to get any updates and I can still enjoy picking them up and reading them, just like I can still enjoy launching the old software and using them.
IMHO the software is already feeling like 99% complete, companies just want to abuse the users, get them to use their abusive models, and milk the software in general just because they're lacking any ideas for new "features".
Anyways, feel free to throw pitchforks at me all you want ;)
For developers who are seriously hardcore, sometimes it might be good to lighten up, and enjoy a little daily reward and recognition.
But in the current state of things, the advice sounds closer to embracing the dysfunction, and feeling good about it.
How did "ADHD" enter the conversation out of the blue? If you're thinking this is how "ADHD-ish" experience is, I recommend you to check out /r/ADHD_programmers where people actually with ADD struggle to figure out how to ship consistently, let alone every day!
> I can personally say that the satisfaction is far bigger the longer you've persevered.
It’s a great feeling to finish something. I find I’m more likely to finish it well if I break it up versus ship it all at once (and my teammates thank me)
If you're a full time developer I don't know why you wouldn't.
Commits are communication. If we're making them often and correctly, there's that much less fluffing around with reports and status updates and meetings that we need to do.
The merits of CI/CD notwithstanding I definitely do NOT want my reports feeling like they need to deploy every day. That will lead to rushed work and errors on production.
But commit, why not? I don't care if it's in a private branch, behind a feature flag, or even some notes/pseudocode in a comment, commit it. Write an actual decent commit message while you're at it. That way as your manager, I can call up your commit history before our 1:1, and by the time the meeting starts it's already 80% finished because I was able to update myself on what you've been doing.
And managers have little clue about the actual work that is going on. Definitely not enough clue to understand what commits are about, even if they have had a technical background overall.
I agree with you partially because I’ve seen this Rush-Driven Development you describe, but with proper gates in place (hooks, Pull Request checks, culture, etc.), this worry mostly disappears in mature teams.
I’ve worked on teams where there aren’t Code Reviews if you’ve successfully deployed without errors last 3 times. Like, the system has this information stored, so if you’re trusted and the change is not marked as critical, it will deploy automatically after passing all previous automated checks/tests. It works wonders, believe me, and you can still apply other policies, like error budgets and stuff.
I agree some of the other Appearance Driven Development practices sound mostly useless to some, but the reality is that such practices, in my experience, are what made code development explode (in a good way) everywhere. Most people are somewhat social, virtual or in person, so they like to have some notoriety.
Y. Also:
s/ush/esume
I would vocalize e.g. “find -name '*png'” as “find space hyphen name space single-quote asterisk png single-quote enter”.
I found that saying it exactly like that had the highest success rate. I never wanted to type it for them because the point of the class was to get familiar with unix and the shell.
This is probably why 2 weeks prints are very common, its enough time to get some things out, enough time for QA to test it, and "short enough" that nobody is hounding as to why some feature is taking months. They can at least get it in incremental pieces with 2 week sprints (or whatever you prefer, 1 week, 3 weeks, 4, doesnt matter to me, just be consistent).
Your team (and manager) sees you're working
our industry is not rational.
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.
> 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.
If they have the time to do that, they can look at a branch as well.
> 2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
It's also much easier to entirely lose track of what the purpose of a feature was if you only review it in small, incremental chunks. The chunks often make sense individually, but are a convoluted mess when you look at the full picture. Also, a feature branch should still have many small commits on it, and you can easily review those individually as well, but you also get to look at the whole picture before putting everything in. Not to mention, if it needs to be reverted, much much much easier if there's a single PR with 50 commits instead of 50 disparate commits over 3 weeks.
> 3. The lift from merge conflicts / integration work is less.
If you pull everyday from the main branch, there's rarely a problem with merge conflicts and integration work, unless someone else is doing a major refactor. And if they are, there is going to be a problem regardless of whether you commit early or late, you'll still have to keep adjusting to their ongoing refactor (and the possibility of ever reverting will be slim to none).
There's tons of assumptions in both our comments though, and loads of context thats important. Spend more time on the code for life support systems, healthcare, etc. If its just a bunch of rest API's for a crud app with few consequences if you break stuff, then its okay to live life on the edge.
Adorable.
Then certainly something is very wrong in every single company that exists out there.
Moi aussi. Volume of ejaculate is highly correlated with level of satisfaction.
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 actually works (for instance by writing tests), and usually they are happy that they can contribute something bigger than they normally could. I don't mind passing the credit, as long as I know that the person actually made some work and understand the code. Meanwhile I offer myself for help or pair programming (although I'm not really a fan of the concept per se) to kickstart someone elses tasks, helping with architecture or just the general approach to the problem.
My coworkes like me, it worked wonders when I was running my own company, yet, when working in BigCo I have to constantly explain myself to higher ups that I'm actually present, not slacking and doing my job, because my jira/github profile doesn't shine.
One could say I'm a fool by not building up "portfolio" and paving my way to promotion/raise, but I genuinely think that this brings much bigger value in a long run. :)
once I realized that the hardest part is actually _finishing_
I used to work closely with a "starter" who is great at getting the activation energy to start, and we made a great team. Find yourself a "finisher".
Ship incomplete features just so your manager sees you’re working? Sounds like a toxic work environment to me.
Fill up your GitHub profile with colors? Seems like a superficial display of smoke and mirrors for those who value such a thing, not for what’s actually beneath the surface of it.
I have the “gift” of ADHD, and I’m quite content with learning something, solving a bug, finding something that can help my team, survive through meetings or just close up tickets every day, without the added stress or cognitive load that I have to ship something besides my usual tasks.
Strive for progress. Learn by doing. But it’s also fine if you don’t on some days. Don’t burn out. Not worth it.
This might be good advice for young people starting their careers, but even then I would advise prioritizing real life goals over work. Don't buy into the entrepreneur ideals you see on social media. People can be successful without working all day, everyday. Take rests, prioritize your health, and enjoy life first. Work is secondary.
I used to think that motivation would come to me if I just waited long enough but I now believe that action breeds motivation. You need to do something no matter how small and your motivation will benefit from it.
> whatever you work on doesn't need to "ship to prod"
The author walked that back pretty quickly. My understanding is "ship to prod" is redundant, "shipping" means "ship to end-users (in prod)".
I guess "do your job on the days you're expected to" isn't great clickbait.
Now we focus on writing more tests and doing more design reviews.
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 cutting off leaves from the hedges.
Causing a lot of transactions is a great way to stop people assigning you actual work. I suspect OP forgot to mention that reason. You already look busy without actually being busy. It's like managers scheduling useless meetings. They want to look busy so nobody gives them actual work to make them actually busy.
Tracking commit frequency is one step away from tracking lines of code. If this is really the metric of performance, then you are a cog.
My take would be: plan upfront consistently. What do you need to do now to unblock the work later? Does the solution make sense? Is there something more useful? Think lots, talk lots, commit sometimes.
however, i expanded my definition to mean not just software features, i included writing a new help doc as "shipping". as long as it was something user-visible and for users in general, and not something for one specific user, it counted.
One thing that really helps me is “do nothing time”
When I sit down, it’s tempting to fire up a browser, or Spotify or YouTube or something, then spend time faffing about looking for a good song, no no no, this is really just me avoiding the work.
I sit down, resist that initial temptation and my mind calms, like a storm clearing, and then I let it calm and little more, and then I can start. That do nothing period is only 2-3 minutes but it allows me to slip into flow state quickly. I recommend to others to try…
smh
(I realize this could just be down to timezone differences considering I'm in the US)
B U R N O U T
I'm not quite sure whether it's really important to keep your github bathroom wall green, but it builds a quite useful habit imo.
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, but so does learning to appreciate the struggle and working through it. It doesn't matter what anybody else thinks about it.
Over the past year/months I built a RISC-V CPU in VHDL. It can barely do anything and if I show it to most people they'd probably think it's super boring. But I love it. I love to work on it. I love to let the LEDs blink the way I wanted to, because I achieved to implement some small thing in hardware and see that it works (imagine my dopamine rush the first time it successfully ran gcc-generated code and blinked an LED on actual hardware. That's boring, innit? But I loved it.). It's often a really hard struggle, because the progress is so little, but I learned to force myself to do it, even if I don't want to/don't feel like it, because I know it will bring me joy in the end, even if I hate it for days/weeks. I sitll do it.
Same with journaling, as you said. It's all about the habits. Find your habit and do it.
On other days I get nothing done because the most productive thing I can do is rest, or tend to personal matters. That doesn't mesh well with hustle culture, but it contributes to my personal happiness and long term productivity.
Also, many managers perceive only writing code as worthwhile.
What recruiter is going to see my company's private GitHub repos?
However, I make a simple bullet task list and work on it. Tasks are not necessarily related to coding. It could be a task related to image editing. Initially, I was feeling very bad if I can't finish a task within the time I've set for it.
Now I don't feel bad if I can't finish that task on time. I perceive it as a micro-iteration of the task. The trick is to iterate further, until the task is done.
While rushing to do a task within a specific timeframe, might be productive in the short-term, I don't see it feasible if you push yourself all the time doing it. I imagine it might reflect on the quality of your work and lead to a self-induced burnout.
Shipping for the sake of it, in my opinion, might create some false perception of work being done. In my experience, employers tend to reward that behavior.
So maybe the question here would be: why are you shipping in first place? To show off, to boost dopamine through gamifying yourself, or to deliver a piece of work you'll be proud of before going to bed.
The spirit of pushing small incremental changes on a team really helps address that.
This can be sustainable if everyone on the team realizes that every PR is expected to be small and incremental. It shouldn't be a large push every time.
Most of the time I only start to see the real shape of the solution after a few days of work.
Those iterations each day have value as they propel me toward a solution. But it’s more of an internal type of shipping. I’m shipping to myself.
I could go the analytical road and write down all the requirements, edge cases and just tick them off one bu one but that's throughly exhausting.
At work more often than not I settle on the second iteration, but that is still slow by some people's standards and incurs tech debt.
Or that time I spent $120k USD on testing some upgrade paths on a dataset in elasticsearch from version 2.4 -> 5 -> 6 -> 7 that took about 5-6 days runtime on imports per upgrade step.
However, one concept that comes up in research like the book Atomic Habits, is that there's a much better reason to commit code frequently - quantity leads to quality. There's a famous story from the book Art & Fear about a university pottery class. The lecturer decided to grade half the class on the number of pots they produced, and the other half on the quality of a single pot. It turned out that the half of the class focused on quantity ended up producing higher quality pots over time. This is because the group that only had to produce one pot spent the whole time overthinking it rather than actually practicing and mastering their craft.
I think this is a much better reason to be committing code frequently and working on your skills every day. We're in an environment where it's a challenging hiring market, so it's important to set yourself apart from others within the industry. Some people have turned their nose up against "colouring in" their GitHub profile, but there are a number of psychological effects like "don't break the chain" that can be helpful in consistently putting in the effort.
Some commenters have mentioned tasks that simply take a long time, but I don't think the author of the original blog post was arguing against that. Rather, he's advocating that you should be continuously working on and improving your abilities.
I mean if you want to ship but you believe that wanting to is not a good enough reason, none of these reasons are any more persuasive.
It is a distraction to ship things.
Do people unironically care about this shit? What the fuck man. Stop it. Now.
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.
I get that the market is pretty tight at the moment but strong CV positions have always trumped proverbial internet points.
There should be exceptions though
Do you really need those inputs to get outputs that mean something? No.
"ship something every day" is dumb because a day is quite a small piece of time for even small pieces of useful inventive work. Even geniuses don't produce all their things in one day, that would be dumb and geniuses know better.
"ship something every week" would make sense and leave you open to actual proper work still being done in proper time scales.
Do something every day. Maybe it's getting up on time. Maybe it's exercise. Maybe it's a bug fix.