Not to brag but I just merged this. Felt so good.
removed documentation
package-lock.json?Deleted the test suite since it was failing
That’s worth bragging about
Beautiful… Tomorrow someone runs in and asking for the consumer-service-aggregator-constructor-mapper that apparently everything relies on
But was this a reversion of the previous commit…?
Fuck yeah - towards the end of last year I did a similar cruft pass through a ton of my teams repos. I think I ended up deleting upwards of 60k lines combined. Feels good, man. 😎
Those are rookie numbers
Tell me you commit your dependencies without telling me you commit your dependencies.
“updated package-lock.json”
lgtm 🚀
Looks good. Approve
Only one dude reviewed it. In one minute.
Make sure to send all the code minified to make it small and easier to review.
Minified?
Tell me you’re not a web developer without telling me you’re not a web developer
Backend
ctrl+h
\s+
enter
LGTM 👍
These are rookie numbers. Any commit less than 100k lines changed is.
Because my company works on archaic infrastructure, should PRs be as small as possible with sub-issues sorted into smaller PRs?
PRs should be exactly as big (or small) as task requires. It’s task that needs to be split into smaller task, if it makes sense to split of course.
Small PR are easy to review and parse. Work gets broken down in to small, shippable changes. If you couple that with feature flags, you can get to a point where shipping a release is as easy as building whatever the latest commit is on Main and pushing it out the door.
Automate that, do it every week or two.
Easy to say if your code doesn’t matter. If you work for regulated industries (FAA, FDA) you can’t ship it out the door.
I have been working on automating our tests for years. Manual testing still finds a lot of things despite passing all the automated tests. I’m now convinced anyone who says “automate that” doesn’t care about quality, humans are too good at finding things.
I completely agree. Not mentioned in my spiel is the constant human QA effort, each ticket merged gets checked, releases get a week of testing before release to the public.
Also, yeah. I’m iOS frontend. I make pixels dance. Either I leave security to Keychain or I hope (read: confirm) backend is sanitising inputs.
I completely agree, but every week or two is too long. At one point we had ours running builds + automated regression testing => release twice or more a day. Along with automatic change logs and monitoring, It was so nice. Tiny updates are always better to test and know exactly what/where/how a failure or positive change occurs when the cadence is that fast. The devs loved it, the QA loved it, and as a DevOps, I loved it. We were even able to do AB testing and rolling updates.
It only got worse when management changed hands and some people decided on going agile in a “Scrum-but” method and it’s been a drag that sprints are 3 weeks long. Now releases take longer, have larger impact for better or worse, and regression testing is much more complex and I have to be more involved in releasing new code. The faster cadence meant it happened so often it was fully automated and I didn’t even know when most went out unless I was watching a dashboard.
Mobile app users get annoyed if you push too many updates. So you gotta pace yourself.
I err on the side of splitting because of what Scratch just said. If I give my colleague 2k lines to review it’ll get slapped with a LGTM and passed. If I send them 100 lines they’ll actually look at it.
LGTM= let’s go to the moon?
Looks good to me, are you getting the rocket?
This took me a month to make. Moving from docker swarm to kubernetes.
“Containers are platform independent, and can run on anything” - yes… But…
If you’re organisation is small/flexible enough, maybe look into using some kind of stacked diff system. We used graphite at my previous company and it’s amazing for working with these kinds of things where you have a million little things to fix and they’re all kind of dependent on each other.
I’m slowly pushing my team to git. It’s stupid that we can’t work when the server goes offline
It can be quite overwhelming if nobody knows how to use git.
I know software teams that went back to share code on teams folders after having used git…
Please get a git course for all the developers
I mean, I dabble in got on my own. But I’ve never managed a git for a team.
Thankfully I’ve set up Forgejo to abstract some of the details away.
I desperately want to get my team out of the 80s, but I’m not the manager so sometimes my pushing goes nowhere
Oh I know that feeling. But when you get the hang of it you will never go back
It’s not the size of the PR that counts!
