6 ms·

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 n

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.

camhart 2y ago
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.
neilv 2y ago
I think the article would come across better, did the field not have such widespread problems right now. 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.
zer00eyz 2y ago
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.
- jethro_tell 2y ago
  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.
- esafak 2y ago
  But then it's a trivial observation; of course you should do something.
  - exe34 2y ago
    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.
MaxLeiter 2y ago
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)
- safety1st 2y ago
  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.
  - mewpmewp2 2y ago
    Managers watch commit histories? Haven't ever heard of something like that.
    - erik_seaberg 2y ago
      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).
      - mewpmewp2 2y ago
        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.
sibeliuss 2y ago
This comment is really quite opinionated! This sounds like your way of working, but there are many ways to work.
ramesh31 2y ago
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.
jamil7 2y ago
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.
begueradj 2y ago
> If needing to put on a show for others is more important than actually working, something is very wrong. Then certainly something is very wrong in every single company that exists out there.
airtonix 2y ago
[dead]
exe34 2y ago
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."
- senkora 2y ago
  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.
  - exe34 2y ago
    ah space might help, I'll try that. i keep having to prefix everything with please don't press enter until I tell you.
intull 2y ago
> ... and this ADHD-ish attitude ... 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!
- deleted 2y ago
  [deleted]
mythhabit 2y ago
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.
- chipdart 2y ago
  > 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.
gfourfour 2y ago
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.
Tommy430 2y ago
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 ;)
- vram22 2y ago
  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.
chipdart 2y ago
> 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.
- moring 2y ago
  > 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.
  - BoorishBears 2y ago
    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")
anbotero 2y ago
> 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.
- vram22 2y ago
  >seen this Rush-Driven Development Y. Also: s/ush/esume
karmarepellent 2y ago
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.
flir 2y ago
I agree with everything you said. But... Your team (and manager) sees you're working our industry is not rational.
richrichie 2y ago
> I can personally say that the satisfaction is far bigger the longer you've persevered. Moi aussi. Volume of ejaculate is highly correlated with level of satisfaction.
morgante 2y ago
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.
- simiones 2y ago
  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?
  - morgante 2y ago
    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.
    - simiones 2y ago
      > 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).
anal_reactor 2y ago
> Optimising for metrics never works for those who can see through the illusion, and that's an increasing number of people over time. Adorable.
giancarlostoro 2y ago
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).

camhart 2y ago

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.

neilv 2y ago

I think the article would come across better, did the field not have such widespread problems right now. 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.

zer00eyz 2y ago

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.

jethro_tell 2y ago
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.
esafak 2y ago
But then it's a trivial observation; of course you should do something.
- exe34 2y ago
  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.

MaxLeiter 2y ago

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)

safety1st 2y ago
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.
- mewpmewp2 2y ago
  Managers watch commit histories? Haven't ever heard of something like that.
  - erik_seaberg 2y ago
    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).
    - mewpmewp2 2y ago
      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.

sibeliuss 2y ago

This comment is really quite opinionated! This sounds like your way of working, but there are many ways to work.

ramesh31 2y ago

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.

jamil7 2y ago

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.

begueradj 2y ago

> If needing to put on a show for others is more important than actually working, something is very wrong. Then certainly something is very wrong in every single company that exists out there.

airtonix 2y ago

[dead]

exe34 2y ago

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."

senkora 2y ago
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.
- exe34 2y ago
  ah space might help, I'll try that. i keep having to prefix everything with please don't press enter until I tell you.

intull 2y ago

> ... and this ADHD-ish attitude ... 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!

deleted 2y ago
[deleted]

mythhabit 2y ago

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.

chipdart 2y ago
> 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.

gfourfour 2y ago

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.

Tommy430 2y ago

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 ;)

vram22 2y ago
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.

chipdart 2y ago

> 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.

moring 2y ago
> 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.
- BoorishBears 2y ago
  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")

anbotero 2y ago

> 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.

vram22 2y ago
>seen this Rush-Driven Development Y. Also: s/ush/esume

karmarepellent 2y ago

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.

flir 2y ago

I agree with everything you said. But... Your team (and manager) sees you're working our industry is not rational.

richrichie 2y ago

> I can personally say that the satisfaction is far bigger the longer you've persevered. Moi aussi. Volume of ejaculate is highly correlated with level of satisfaction.

morgante 2y ago

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.

simiones 2y ago
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?
- morgante 2y ago
  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.
  - simiones 2y ago
    > 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).

anal_reactor 2y ago

> Optimising for metrics never works for those who can see through the illusion, and that's an increasing number of people over time. Adorable.

giancarlostoro 2y ago

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).