I have no idea and no idea how I can figure that out.
I’m going to be unlazy for once and spend some more time on this so that it only sends the updated changes instead of the entire list. Will think about it some more.
1 Like
Sending the changes seems like a better option than worrying about timing when you don’t know how often to send changes is too often.
I was told early on by our hotshot consultant to just avoid rebase because when it causes problems they’re really bad to untangle. So I’ve never used it or advocate that devs more junior than me use it. I’d rather deal with ugly commit histories personally.
We have pull requests as our snapshot of a new feature or bug fix into the develop branch (which eventually gets pushed through the test/staging environments to master).
I’ve just never worked at a place where history was that important. Keeping devs who have no idea what git reflog or git reset --hard does (including me since if I ever learn it I just forget it) has always been a bigger priority in those shops. It’s hard to help them when I’m the lead and I have no clue on that stuff. But I do know merge flows very very well.
So yeah at your FAANG or similar I can see a completely different scenario.
Rebase is horrible and should only be used in a catastrophe
If you worked in the non-tech company corporate world you might feel different. We’re like a MASH hospital in a war zone compared to say Mayo Clinic or something. Whole different set of priorities, standards and expertise levels.
rebase is my only workflow
git fetch
git rebase
TF are you using if not git
Ive used submodules for this and didnt run into many problems, weird.
Re: rebase, for fixing local stuff it’s fine i guess… i just view history as holy.
In my last job maintaining and organizing our repos was one of my main and only jobs and i had only found 1 or 2 scenarios where I had to rebase. When do you use it?
Agree there’s different kinds of history and i was more thinking about rebasing public stuff being a nono
For my local stuff who cares, it just gets squashed anyway.
I was surprised to see 2p2’s avice has solved all the leetcode problems, written 100 of the questions, and is ranked #2 in their contest things.
Is that the same poster who won a lot of money betting on Trump and made a ton in btc?
The one and only.
I occasionally do a mock interview there to stay sharp. I highly recommend leisurely practice > cramming when interviewing.
For all you lucky duckies out there who work with nothing but rock stars who can git rebase and git reflog and force revert w/o getting themselves into trouble - this is from a buddy of mine whose company does a lot of offshoring:
I told him obviously the devs are just asserting that the now date from the code will equal a new now date they create in the test. Which is the worst thing ever because it means the test will only fail some small fraction of the time.
Jesus christ - just pulled up the method, all it does is return new Date().toUTCString() but has a huge comment that reads “This section of the code to convert current Date() into [our company]-specific time-zone has been removed temporarily due to inconsistencies in the behaviour for different browsers with different time-zones and locales. This work will be resumed shortly.”
This is what we have to deal with out in the non tech world. And I think his company even has “technologies” in the name. We’re like MASH surgeons - just stop the bleeding and stitch them up.
1 Like
Honestly think there’s a decent amount of “engineers” who just write super long pointless comments on code to avoid doing real work. Especially unit tests.
The comments are one thing - but a unit test that fails intermittently due to bad design is an unpardonable sin.
If I was the CICD engineer and that dev wasn’t offshore - I’d tell the dev that every time that test fails I’m going to smash one of their Star Wars figurines.
“For all you lucky duckies out there who work with nothing but rock stars”
The bar for my coworkers is pretty high.
- Everybody contributes regularly.
- Management is better than the devs and adds value.
- There are no difficult personalities.
- We all do useful work which gets used by customers.
- Everybody can understand pretty complicated code with no documentation.
- There are no crazy policies.
- Politics is non-existent at my level.
- There is pressure to produce long term but not short term.
- Other teams are always happy to help.
There exists at least one low drama, productive job.
No comments at all? Not that I like making comments, I just thought people wanted them.
+1 comments suck, get rid of them. Write more expressive code.
Exception is if you have to write weird code to avert some obscure issue.
1 Like
+1 Only if it’s something counter intuitive that I think I’ll be scratching my head over if I come back and see in 6 months.
Also security checks in infrastructure code - I comment the shit out of those.
And stuff like we do a batch delete every night on our users in Cognito who don’t complete the signup process. It would be fairly easy to screw up and accidentally delete all the real users with I believe no real way to recover them. Or at least it would be a nightmare. So I’ve got three independent checks that look for unconfirmed users only - and big comments that yes they’re redundant but never ever delete them.