Merge then review

agilob@programming.dev to Programmer Humor@programming.dev – 721 points –

Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.

144

Having a hard time determining whether this is sarcasm or not. Then I see the phrase "JavaScript Engineer" and become doubly confused.

I don't think it's satire, this guy is actively defending this on Linkedin: https://i.imgur.com/SlJPG85.png

I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage.

-- Kurt von Hammerstein

LinkedIn is Facebook for that last type.

That's a relief because I thought I'd stumbled into LinkedIn Lunatics for a hot second.

Linkedin is for lunatics. Just a bunch of goobers giving digital handjobs to each other.

That could still be trolling. But LinkedIn is so full of utter garbage like this that it’s believable

I don't think so. I just made a screenshot of one random convo he's having about this, but there's loads more in a similar fashion.

And all of his other posts besides this one seem legit on the surface.

So it would be pretty weird if he randomly has a very bad take, and then just claims "Lol this was a troll post, gotcha!"... That's pretty much the 4chan defense when you get called out - "Haha guys, I'm actually not r-worded, I'm just trolling!"

Wow, of course he's pretending the response is a misrepresentation of his opinion instead of defending it in good faith.

Having to go through the process of merging hurts morale and slows performance. Give everyone on your team the right to force push to master.

Yes, especially the newbies who don't know what they're doing.

Keep everyone awake and on their toes.

You're not truly part of the team until you cause a massive outage.

New employees are responsible of at least 75℅ of documentation clarification and process overhaul.

I'm totally on board with process overhaul. Ours was stupid when I started, I said it was stupid, and nothing changed. If someone else comes in and can say it's stupid more convincingly than me, that's great.

I honestly wouldn't see this as a problem. But if you break something it's up to you to fix it. But we also don't do CI. We release features in batches after they have been tested and seen to be working.

I don't know if sarcasm because there are actually maniacs like that in this world

I really wish LinkedIn would add an anonymous cringe emoji. I would use it on like 90% of the content on that site.

The best thing you can do with that shithole of a site is ignore it as best as possible. Don’t give them any engagement. They’re no better than rage-baiters on Reddit and TikTok

I'm having a hard time figuring out whether this guy is a fucking moron or a fucking idiot.

pete's a fucking genius

Exactly, this is how you pay off your mortgage

Amateur. You want real performance? Code in prod. Literally could not be better for collaboration to have the whole team working directly from production servers. Best part? You get INSTANT feedback.

I just commit directly to master with auto-deploy like a real cowboy, yee-haw!

Why review at all when the users will do this for you? Merge, deploy and move on. If it's broken they'll tell you.

I'm definitely going to start doing this at work. We don't want our embedded firmware for medical devices to get stale.

What does "stale code" even mean in this context?

Does that mean it falls behind stable? Just merge stable into your branch; problem solved.

Or is this just some coded language for "people aren't adopting my ideas fast enough". Stop bitching and get good.

My old boss (at a sturtup with some ten ppl) loved to do this. When you’re done with your work, merge to master. Boss-man would then revert the commits if he didn’t like the result. Since the branches all were merged, no-one knew what was actually in prod. Fun times.

If somebody actually did that it would be grounds for removing their privileges to merge into master. THIS, THIS is why the JavaScript ecosystem has gotten so bad, people with mentalities similar to his.

'i help JavaScript engineers become framework architects by getting them forcibly reassigned.'

Better yet just edit files live on prod from Notepad (not plus plus) over Samba for "xtreme moral" boost

The amount of times where I had to fix things in live production servers is not a small number. Then again, we are only humans. Backup often and you are golden.

This is why I include those preservative libraries in my projects. My code doesn't go stale for a whole three weeks longer.

I dunno but xtreme programming sounds like something straight outta Musk's wettest teenage day dreams.

Imagine if you will: You have a red button and a green button. You are allowed 10 seconds to review the code before rejecting or accepting & merging. Think fast.

Developers: "Move fast and break things."

Things: break

Developers: surprised Pikachu face

Except instead it’s: Developers: fuck ops, they stuck at their job

This is satire, right? Surely no one would put their name on that publicly?

Like someone working in a kitchen boasting about a life hack of not wasting time with hygiene.

Wash your hands after cooking, never let food products sit stale

never chew before swallowing either. the food can still get stale in your mouth

Bet you $50 we later learn this guy was orchestrating a supply chain attack.

What in the shit is "xtreme programming"?

it's NewGame+ for when you 100% programming

I've been doing this for twenty five years and I'm nowhere near 100%. In fact I think my percent might be going down.

It's when you write everything in l33t WITH CAPSLOCK ON.

I guess that makes COBOL the most Xtreme programming language.

It's agile based around rapid prototyping. You build a thing, then you do it again, but better

It's not a new idea... But I've never heard of anyone doing it professionally

Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.

Pair programming? Then the code is already reviewed.

Yes, that's part of the point. Dumping all at once into a merge and asking people to comprehend it all isn't particularly realistic.

you are supposed to have written the tests and to have written your code with pair programming,

I commented out the tests because they were failing, pipelines were green so I merged. Now it's running on prod. What do you do?

Fire you for destroying the tests. It's intentional sabotage.

Give you public kudos for moving fast and breaking things. We need more fearless cowboys like you around here

You lost me at "pair programming". Having tests for what you can test is fine. But there's code that simply can't be tested, or at least not easily at which point you are just wasting time. Open source mantra is always great in my opinion... release early, release often. In addition to that have a test version of your software before you push it to production if there's sensitive data. That's usually good enough to catch issues.

And he's right, reviewing changes before merge just takes time and resources away from project while the master branch keeps moving. Merge, if there are issues, whoever submitted the change is obliged to fix it. You can always checkout earlier version.

I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there's a conflict but the automerge keeps drift to a minimum so it's less common and fixed sooner.

better than merging poorly tested/reviewed code.

and yeah, a small team of superstars doesn't need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.

it also leads to plenty of good conversations about the best way to implement, so overall it's a win.

Well, Git was designed to branch out, not be a single repo with bunch of users. So one team can have a local repo, that in turn gets merged into big one, etc. Structure matters as you say. Small experienced teams move fast. Big teams require a lot of management and supervision. I still think it's better to split people up into small teams and give individual tasks, or let them pick tasks that need to be done.

At my company we're so agile that we directly deploy branches from developers' local machines to customers for A/B testing.

Call it “container orchestration” and charge an extra 20% to the customer

As one of our most important customers, we've greenlit you for our cutting edge early access. Most people need to wait weeks for the features you get today!

We’ve been doing that the wrong way, offering a discount if they were willing to try the early features.

This is the big money reasoning that I should suggest to the bosses.

LinkedIn "influencers" are insufferable, dear god

If you’re working in a context where it’s okay to make mistakes so long as they get fixed later, you’re not working on anything important.

Honestly that's okay. That's how most of the games industry works and you know what? I sleep very well knowing that none of my code is actively hurting people. I do likely have some code in some defense simulator from my work on squad but so be it. Overall I make toys. Works of art and as long as the bugs are caught it really doesn't matter when. As long as it's before release. Even then you can just work at Bethesda and just never fix them no matter what.

Kinda acceptable if you have a slow release cadence. Everything needs to be reviewed and fixed/accepted (with defect/US raised) before production though.

Needs to be in a smaller team with decent Devs too though!

It’s insane to me that gitflow won over TBD and Continuous Integration to the point that this is now considered an extreme position. Not all projects are open source with many remote collaborators.

this made my heart rate go up a little bit in a way that doesn't feel good

Nothing improves morale like the on-call having to unfuck production for the third time that hour because mUh VeLoCiTy decided code review and testing in CI was too slow.

Techbros are fucking cultists.

What if instead of continuous integration we had continuous Disintegration, where you code while listening to The Cure on repeat

Something like that happened to me yesterday. I reviewed one PR, then some Important Guy came in and said:

  • it is nice you reviewed my work, but we need to push this to production right now.
  • just fix these things, I described you how. Just copy/paste these snippets
  • these are cosmetics, I don't care
  • "cosmetics", huh? Your shit may just crash
  • gfy and push this to production right now
  • well, ok

Of course, lack of these "cosmetics" caused crash in production. It's my fault of course.

Am not sure I disagree but I don't agree completely. It's insane to merge things that go to production without testing. However at the same time I don't like continuous integration one bit. Open source mantra is great in my opinion. Release early, release often. If code chews some important data, have a test version of it that needs to run some time before it gets pushed to production.

Delaying merge of someone's code means branches get further and further apart. At the same time code in main branch gets fixed and tested the most. I would merge often but only full features. None of the half-done stuff. Let humans test it a bit before it reaches target audience. That is usually good enough to catch most bugs. Those that do happen to leak into production are easily fixed since you have fast development cycle and deployment pipeline. And backup frequently.

I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production

have the author address issues after the merge.

Hahahahahahaha. Sorry, you've merged, next ticket, PM needs shiny results for execs this QBR!

This is how bug backlogs grow.

This exactly. By the time they notice a problem you are three tickets down and on to the next sprint.

Yeah, I see your point. Maybe my employers are different, it's never been an issue explaining why the ticket isn't closed just because the PR is merged

This only works if the merge is being done to staging builds that are continuously tested by a QA team before they go to production, with carefully planned production milestone releases. I work for an emergency management SaaS company. If we just merged all lightly reviewed code into production without thorough QA testing, there’s the possibility that our software would fail in production. This could cause aircraft in major airports to crash into each other on the runway, or a university to respond poorly to a live shooter situation, or the deletion of customer data about COVID vaccine efforts, etc

I'm with you. I've worked on a few teams, one of the first was a company where two teams were contributing code changes to the same product. The other team "owned" it and as a result it took ages, sometimes months, to get code changes merged. It meant more time was spent just rebasing (because merging wasn't "clean") than working on the actual feature.

My current role, we just do TDD, pair programming, and trunk-based development. We have a release process that involves manual testing before live deployment. Features that aren't ready for live are turned off by feature flags. It's quick and efficient.

Fundamentally I think the issue is the right tool for the job. Code doesn't need to be managed the same way in a company as it does in an open-source project.

Code doesn't need to be managed the same way in a company as it does in an open-source project.

Open-source projects are usually longer lived more maintainable, more stable, and more useful than any closed source code I've ever worked on for a company. Partially because they're not under contract deadlines which create pressure to "deliver value" by a certain date, but still. Might be helpful for companies to consider adopting practices the open-source community has shown to work, rather than inventing their own.

Get the value to production

Ugh, not this SAFe Agile (tm) cultist bullshit. The "value" is working, bug free code, which you get when you put it through review and QA before it gets to production.

There is no value in spaghetti piled on top of rotten spaghetti. Tech iCal debt is real and if you're just shippin it and plan to fix it later, y'all gonna have a bad time. Nothing more permanent than a temporary workaround.

There's often features and bug fixes worth more than the ones introduced in the PR. I've yet to see bug free code just because it's went through review and QA.

Surely you've seen bugs caught because code went through review and QA though. Those are bugs that would go into production if following the "advice" in this post.

I'm saying identify the bugs through review, and fix them. Just do it in a new PR unless they are critical

This is some poe's law shit. I can't tell if you're serious or just committing to the bit.

Sorry about the confusion. It's not sarcasm. I'm just sick and tired of people blocking my PR because of an argument about wether the function should be called X or Y or Z or D

Ah. Yeah those kind of nitpicks are annoying. We try to specify when comments are blocking or non blocking on reviews.

But I definitely block a lot of reviews over no tests, bad tests, no error handling, failed linting. And the occasional "this doesn't do what the ticket asked for"

As a SOC auditor you programmers are going to make me scream at the exceptions you guys cause.

I wonder how many programmers out there have intentionally set out to subtly sabotage the system. Anyone doing that, good luck to you.

This explains what is going on a facebook.

Probably unpopular opinion, but peer reviews are overrated. If coders are good AND know the project, the only thing you can do in a PR is nitpicking. They are more useful for open source collaborators because you want to double-check their code fits with the current architecture. But people here are reacting as if peer reviews could actually spot bugs that tests can't catch. That happens rarely unless the contributor is junion/not good.

Peer reviews can catch bugs that tests can't catch.

I won't disagree that peer reviews are overrated, but they're a great way to train and onboard less experienced devs (who are just more fun to work with, anyway). Like I'm a platform dev, so I don't have a "home" project - if I had to know every project before I opened a PR for it, I'd get hardly any work done. Review help other knowledge experts weigh in on my changes.

Anyway, one case for being pro

I operate from the presumption that code's first job is to be as easy for a human to understand as possible. It should clearly communicate what it's attempting to do. If your code isn't written so that your colleagues, or you 2 years from now, can read it and understand it, it's bad even if it's whip tight, fits all the AC and has 100% test coverage with a perfect mutation score. That's what I focus on when I review code: does it communicate intent semantically. Code that can be understood is code that can be reused, optimized, altered when use cases change, generalized out into even more reusable code, and provide insights that technically perfect but incomprehensible code can't. I, like you, assume that the coder knows what they were trying to do and how to test for it, so that only gets a cursory glance to spot common errors like missed nullables, inverted conditionals and shit like that. I look at it from the perspective of "If I had to add functionality to this, could I do so easily". Because I'm gonna one of these days.

Nitpicking can be automated by a linter, then reviews can actually sit back and review more important things like high-level design and scalability

as if peer reviews could actually spot bugs that tests can't catch

There can't be bugs if there are no tests to catch them! Ofc you can also automate test coverage standards. But PRs are sometimes the only way to catch bugs, even and especially with senior devs in my experience bc they are lazy and will skip writing tests, or write useless or bare minimum tests just to check off code standards and merge on ahead

If coders are good AND know the project

Those are some pretty big ifs.

Code review can't fix incompence though. I lost count of how many times my boss told me "review that PR well because X is not very good". Also my point is that they are overrated, not that they are useless.

It can work if you have a test zone and only a small amount of people work on a given code base.

Also checks to ensure the code compiles and tests pass before merging, as some quality gateway.

That's nice but it goes against our quality standards and the international quality standards we are charging the client extra for adhering to, the line you're trying to merge into is stability and needs CCB approval for the merge, and the client has specifically requested only showstopper-level bugs be addressed for stability lines. You know what, I have neither the time nor the crayons to properly explain this to you, a consultant that supposedly knows the business. Pack your shit, you're gonna have a wonderful time posting this crap on LinkedIn instead. #gitshiton

2 days before, at Pete Hurrd former job