Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
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
That's a relief because I thought I'd stumbled into LinkedIn Lunatics for a hot second.
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.
I really wish LinkedIn would add an anonymous cringe emoji. I would use it on like 90% of the content on that site.
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.
Bet you $50 we later learn this guy was orchestrating a supply chain attack.
What if instead of continuous integration we had continuous Disintegration, where you code while listening to The Cure on repeat
A typo in the first paragraph of the article in a wiki wont make the 5th paragraph tear down the entire wiki.
you'd be surprised how complex MediaWiki syntax is nowadays, there are many ways to break things on a wiki
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.
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.
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’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.
As a SOC auditor you programmers are going to make me scream at the exceptions you guys cause.
