What was that device, an early cellular modem or 802.11 wireless bridge? The thing ontop of the briefcase looks like a head visor with an antenna. Google search keywords are just noise.
How many times did I push at 2am so I could go home, get to the freeway entrance, realized I fucked something up, sighed, and turned around to go back and fix it…
(This was like 1999, we didn’t have access to Perforce from home).
After a year or so I realized I should just develop the willpower to check it in after sleeping on it.
That's actually not that rare when I work later than usual. Some stupid problem my brain is too fried to solve. Eventually I give up, feeling defeat for the whole evening and solve the problem in 10 mins the next morning. Get enough sleep, people.
However, much research shows the hand banging against the wall period is required for you to achieve the morning breakthrough.
The sleeping break is where your neurons form new connections based their activity yesterday. The “thinking hard” and the frustration is a required part of the morning epiphany.
“No, wait, it’s not what you think! There’s a continuous integration system, a commit would’ve triggered a new build! It might have paged the oncall! Babe! The test suite has been flaky lately!”
I would lose max 3 hrs of work that I already know how to re do. I can live with that. I don’t want to publish too much unfinished/unpolished work. There is always the chance someone might need the branch.
Even if drafts under development, I like to publish something that reaches the standard of my “best” me, not my “Friday evening” me
Because someone else might need to work on something on or from my branches. And I don’t want garbage in my history. There are cases I might not be able to squash merge, so all my history will be in the project history. I want each commit to be clean. It is not a lot of effort, and forces me to increase code quality, because I review my code more often.
Rules for all projects I manage: never rebase published branches and always publish clean code (even implementation is unfinished).
From experience following these simple rules make the whole project management easier and more effective
On one occasion i had to take over a task from a colleague while he was on his day off. He did not push his changes. I am sure he had backups but when i asked him to push his changes he had to drive home to do it.
You should be pushing feature branches as you work on them, so if you have a crash or something, your work isn’t lost. Builds should be triggered from pull requests on the main branch, if triggered by anything. You should never push directly to main. At least that’s my preference.
Our ci/cd pipelines build also feature branches. I do push often, clean code. I don’t push when I am tired enough that I can’t trust my judgment that the code I am pushing is over my personal quality threshold. I add meaningful, concise commit messages. These are my rules.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.