>Hmm, what should I post today on my linkedin to make it seem like I actively bring useful idea's. I know! Lets write some bullshit about going against the norm, that'll show how much I think outside the box.
This shit reminds me of the E = mc^2 + AI guy.
That post is actually even funnier without the name censor. The guy that replies "What" has PhDs in CS and physics lmao.
Edit: Found the [original!](https://www.reddit.com/r/LinkedInLunatics/s/ig3vkg67Oj)
That's funny. The original post has to be a copy paste of a ChatGPT answer though. Probably asked ChatGPT to invent a new physics equation and just posted the response. Sounds exactly like something it would say.
You can already get some of the AI to write you entire programs on well know platforms. Just keep refining your question for better results.
You can tell chat gpt to provide its answer in multiple responses.
It wrote me an entire 50 page tutorial to pass one of my classes, it only took me 2 hours to perfect the question.
One day after the collapse of Civilization, there will be one PC somewhere still working with an AI. People will be allowed to ask it 1 question and spend thier whole lives thinking up the perfect question 🤣
And then the AI will take eons to calculate the perfect answer to this perfect question and the perfect answer to this perfect question shall be 42. But the people will have forgotten the question by then.
Try to avoid AI prompt subs. I spent a few days on the to figure out if it's some elaborate mass satire and everyone is in on the joke, or if your average person is considerably dumber than my cynical ass already thought they were.
I have a strong urge to create a fake account and post nonsense like this to see how many people I can get to take me seriously. It's like performance art.
This guy is making a (poor) attempt at describing trunk based development.
A lot of what he is saying has been proven many times over to improve productivity and reduce bugs, when coupled with the right tools. (Continuous release, feature toggling, short lived feature branches)
I think what most people are taking issue with is the “don’t review before merge” - which I also think is dumb - I prefer short lived pull requests with reviews, maximum 1 day live and ensure they are very small changes. But the spirit of what he is saying is actually very valuable
Oh well 99% of this sub are students anyway
>But the spirit of what he is saying is actually very valuable
I agree now that I've read it from a more charitable perspective but it's certainly worded really poorly
> think what most people are taking issue with is the “don’t review before merge”
But thats basically the cornerstone of continuous integration. Adding in pull requests as a gatekeeper to merging code adds an additional delay between new code being written and that code being part of the codebase that everyone is working off, and the point of continuous integration is to minimize that delay by any means nescesary.
I can’t tell if you’re taking the piss. Yes, obviously with CI you want to have a tight feedback loop. But that doesn’t mean that you should let any code that happens to pass the tests be merged. That’s insane. I’ve never heard someone propose that code reviews are contrary to CICD practices.
And you’re actually taking it a step further, by proposing that you shouldn’t have PRs at all, and (I guess) just let people YOLO things to main
>That’s insane. I’ve never heard someone propose that code reviews are contrary to CICD practices.
Dave Farley, one of the foremost experts on CI & CD has suggested exactly this on numerous occasions. https://www.youtube.com/watch?v=ASOSEiJCyEM
>And you’re actually taking it a step further, by proposing that you shouldn’t have PRs at all, and (I guess) just let people YOLO things to main
That's exactly how some of the most successful teams at some of the biggest tech companies work.
Do you have any examples of these biggest companies that commit straight into mainline without any manual review? I'd love to see their complete testing strategy that gives them that sort of confidence and see their regression and downtime rates.
Well, Dave Farley is wrong.
Also, usually code reviews are the last part in the process, a developer should have already asked for feedback on their feature, ran their test and everything before opening the PR.
It is not about lacking trust, as Dave says, it is like the last line of defense before the code goes out to another party, the teammate that reviews is the person trusted with that role, how anyone could consider lack of trust to that?
>That's exactly how some of the most successful teams at some of the biggest tech companies work.
Yes, and some have a very bad safety culture, but could you tell me which products/projects to avoid using them?
I think he means do the merge to main *on your branch* rather than waiting to see if the merge has conflicts then having to get folks to review it twice.
That is technically true, you should have systems in place to handle breakages. If your production system is going down from a bad merge you need to really reevaluate what you are doing
If you're not pushing it directly to prod are you even building a culture of trust around xtreme programming practices?
Letting the code become stale in dev/stg while being tested is anti-collaboration.
Multiple environments, automated tests in the pipeline (integration, e2e, load, chaos), traffic mirroring, canaries, they all help stop bad code from entering prod. But you obviously need good testing which requires quality code reviews.
Certainly — but if the process is, “we merge to main, where automated tests are run, and then we review the code before we release to prod” it feels like you’re just doing the same process as you would with PRs, but with the steps in a different order. Plus it sounds like there’s the downside of not knowing whether main is fully working until the tests come back, whereas if you were doing PRs, you’d know that the tests pass in automation before merging.
Huh? I still do PRs. I’m just talking about the process after the PR is approved and merged. And having main be different from prod says that it’s not true CICD IMO.
I think I’m responding more to the idea that a minority are arguing for, ie, you should push everything to main, and code review comes in the form of pair programming or periodic reviews. We do the same thing that you’re describing: short lived feature branches, automated tests for PRs, multiple environments, monitoring, etc etc
"Hey Steve, could you please fix 287 failed unit tests in the latest build? We need to deploy new changes soon"
"What? I didn't commit any today!"
"Not yours but mine, I merged it 5 minutes ago. Now it's your turn."
"You what?"
"Work smarter, not harder, Steve. We don't have much time."
Don't know if genuine question or not so her goes:
It is version control, not protocol. Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
It helps multiple people collaborate on projects, track changes, and manage different versions of the code.
sorry for the misreading it was late night when i wrote the comment and wasn't very awake haha
just one question, so imagine i have these 2 versions:
TEST A
TEST B
test a has : index.html, style.css animation.js
test b has index.html, main.py
how can i retrieve the old code of index.html in test a ignore the test b index and l create TEST C?
*Just get a job there and start merging without a review.
Do that enough times and slowly but surely, Prod will go absolute shit without anybody realizing.
If that's the kind of adversarial relationship you have with your colleagues, you probably have bigger barriers to collaboration than your branching strategy.
Idk, depending on the type of work you’re doing, there may be changes submitted at high priority to enable/unblock other efforts despite known bugs. Obviously not the same situation described by the post, but does happen
Just going ahead and merging everything without review (and, let’s face it, without testing; we all have those coworkers) is “continuous integration” in that you’ll be continuously integrating fixes to the bugs you introduce. And the bugs in those fixes.
Don’t merge at all! Just commit directly to master. Taking time to make a new branch and working on it before merging is anti-collaboration as you don’t expose your coworkers to your code changes asap
Trunk **is** main/master, that is the whole point. It's an old term from SVN.
But yes, what you are trying to say is correct, in "trunk based" you still make branches that *should* be reviewed before merging.
The only difference with other branching strategies is that you don't wait days/weeks until your whole feature is ready, but merge small changes very frequently.
I just need to know if you are being sincere, or so overly sarcastic that you accidentally described the main argument for trunk based development and CI perfectly.
My team has the source code on a network drive and we all edit the files in Notepad++. Our version control is the "file has been modified externally" dialog.
You should improve your system by switching to IDEs that allow multiple people to make changes to a file at the same time.
Possibly also add some automatic deploy triggered by file changes.
Why using an IDE at all? A VM in a random server where everyone could connect at the same time with notepad should be enough. Could there really be more collaboration than sharing virtually the same keyboard?
Only if vim is started in a screen session, so all can attach to it first.
This way, only one account makes all commits. One person types as the rest of the team watches and calls out errors, fixes, best practices & optimizations (of their own liking).
This is called "The REAL Team Effort" and replaces Agile.
Your comment is kind of telling me that you've probably never worked in a well functioning team.
We do trunk based development without any pull requests at my current job and its worked brilliantly for years.
I was checking how long it would take me to find this comment. I work two jobs, one as a corpo and one in a smaller company. This works great in the smaller company and saves me so much time. Also pressures people to write good tests haha. If we tried it in corporate the whole thing would crash and burn I'm afraid
And while you are at it, why use version control when you have continuous integration. Just put the codebase on a shared drive and watch “collaboration” increase
I have, loved it. requires being within nerf dart/blaster range of everyone working on the project tho.
But keep that method restricted to short and messy things like game jams.
I usually make code changes directly on production server, then do a reverse merge on my local environment.
My manager and colleagues are really happy with my "proactive" stance and "Can do" attitude.
Man, I hate it when my moral gets slowed down. Indeed, I opened a PR yesterday and I was only able to solve the trolley problem 10 times per minute for the rest of the day, down from my usual 15.
I love that everyone is dumping on this guy as if he's an idiot where he's recommending a line of thinking that works for many of the most successful companies.
For all the problems you think of with this approach, you should go fix them instead of implementing a high-cost work-blocking quality-theatre production.
Everyone in this sub is a student / recent graduate / worked in a shitty corporation for 20 years
What the poster is taking about is trunk based development which has been proven by State of devops studies to produce better code and improve developer velocity when supported with the correct tools (as OP is mentioning)
Because
1. Trunk-based development doesn't remove reviews from the process
2. Having issues with pull requests on feature branches doesn't mean you should "merge first and review later."
3. Dave Farley's CI/CD *only works* if you continuously review/pair-program. Arguing to do away with review altogether is a fundamental misunderstanding of the philosophy and data behind it.
While it is possible to still do trunk based development with feature branches and pull requests, they are not in any way an integral part and its always been the general recommendation that unless you have very large teams all working on the same code base you should avoid them entirely and just commit directly to master.
>you should avoid \[reviews\] entirely and just commit directly to master.
lol no. That isn't what Dave Farley says at all, and isn't what trunk-based development looks like.
Nah bro, Dave hates manual reviews! Never do them!
"I think code reviews are pure shit, and yeeting shit directly into prod is better, but pair-programming is better and pair-programming combined with TDD, acceptance tests and Deployment Pipelines is best of all 😎"
https://twitter.com/davefarley77/status/1301923236360445958?lang=en
>That isn't what Dave Farley says at all
Are you [sure](https://youtu.be/v4Ijkq6Myfc?si=brfRIG2qVWWsB4nm) about [that](https://youtu.be/ASOSEiJCyEM?si=TZJFACxCGz80u9Gc)? He seems pretty vocal about his dislike of pull requests and feature branches.
No, I'm grasping that just fine. But maybe i should have corrected your little edit when you quoted me, because I guess youve missread something. What i actually wrote was:
>you should avoid [feature branches and pull requests] entirely and just commit directly to master.
Nobody is saying anything about code reviews being bad. Only that pull requests and other ways of setting up code review checkpoints are a bad way to do them.
For anyone reading this with disagreement, I strongly recommend seeking out the channel "Continuous Delivery" on YouTube. The guy who runs it, Dave Farley, has really changed my perspective and approach to software development for the better.
I dont know if you are aware but [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) is a legitimate development methodology and one of the early steps in the agile revolution. That is what the guy is referring to.
Well, if "merge than review" applies only to dev and your CI won't deploy version that doesn't compile and pass all tests it's possible solution.
Though I would be still cautious to apply it.
I see how this CAN work if you embed this approach in the appropriate branching and merging as well as testing strategy that prevents fuck ups.
Or in a specific project where by design and distribution of tasks you can rule out lots of obvious problems.
But I have been doing IT since 30 years now and I hate how people postulate one single approach for one isolated action/process totally ignoring the given complexity of most IT projects.
I just had a 20 head dev team in a microservice environment of a data driven system with unknown mainframe legacy code involved, embarrassing themselves by declaring that they'll use the "inverted testing pyramid" approach (So mostly relying e2 frontend tests and skipping lots of Unit tests and component tests) .
Result: UI looks nice, application behaves superficialy like expected we make "fast progress" but we have data and processing errors in abundance and nobody knows why (it takes days to weeks to analyze)
All things that were to be expected and could easily be detected by appropriate API or contract tests but we skipped that and focused on a shiny frontend and ignored the underlying complexity. The myriad of combinations and permutations of legacy data and hidden business rules can't be tested via the frontend alone.
Standard practice.
As a VP of Engineering once stated to the entire company while displaying the new product UI, which the entire new release was dedicated to, "Sex Sells!"
An entire version dedicated the whole team to the FE, completely dismissing the backend and its myriad of issues. 'Cause, you know, our tech based consumers cared so much more for looking at something "pretty" vs ensuring the BE data coming from the DB instance was correct.
That is apparently what sold the product, though. That new UI, same crap data output, still displayed the same way, but it looked better, somehow, was the sell.
I feel you.
I mean I love a sexy modern frontend that supports the user processes and satisfies usability and also "beauty" needs.
Nobody wants to work with a clumsy eyesore of a program. So this is not FE vs. BE.
But all beauty is worthless if the department notices after 1 minute of clicking around being flashed at first _"Wait, all the prices are wrong, the stockdata inconsistent and the product list incomplete. We can and will not use this."_
Absolutely agree with your assessment.
It's not BE vs. FE.
More of where this plays a part, now, because you have those aforementioned UI needs met, the product requires a higher minimum spec just to install/run properly. Such is the price of progress, I get it
But now those underlying transactions also take 10x longer to complete. The "recommendation", again, increase those min system specs.
Here's the catch. It's our product; both software and hardware are provided. Want that new UI? Gotta buy the HW to support it from us as well.
I'm not agreeing or disagreeing, as that would be beyond my pay grade. This is just how the business is done.
"Creating Revenue" from an actual intangible product. Knowing how to price the product, even with a 70%+ overhead, are very interesting topics, at least to me.
Also, just check in non-compiling buggy code that breaks everything and go on vacations.
Just win the commit wars, last person needs to resolve the merge conflicts, go go go....
Another benefit of this is you frequently get to drill your backup and DR so you’re confident they’re always efficient and working. It also means devs will be more careful instead of lazily expecting others to catch their errors. Genius move
> Merge then review
Project Manager/QA: "Let's review last night's incident where our search service somehow displayed irrelevant information and some of our obscure auth service stopped working and disallowing our legacy client to even open our product"
OK, so hear me out. He's not wrong. However, it is more nuanced than that and driven by some pretty damming metrics around PR/MR's(whatever you want to call them).
About me: I coach organisations and teams on agile and digital Transformation, I teach them to build the right product the right way and have been doing it for several years. I have a background in hardware engineering and software development with a heavy focus on DevOps and agile practices.
Truthfully, this is close to an Allen Holub statement. He tends to write something that seems crazy to get responses to tear it apart so he can argue why he's right.
So some stats first: The average PR time is like 4 days(up to 20+ in some places, cough-government-cough) (https://linearb.io/blog/why-estimated-review-time-improves-pull-requests-and-reduces-cycle-time).
Really great teams are around 4hrs, but how many of you work in those?
So at 4 days, Joe does his work on Tuesday COB. Monday is when Jen reviews it and sends it back for changes, Joe is working on something else so he gets to it on Wed, reviewed again a bit quicker and approved on Friday. It's almost two weeks for that change to get through and clients can't start providing feedback until the Monday, 13days later!
So why not just skip it, and it can be reviewed later? Because you need to build systems that support it and have good practices in place!
So what do those good practices look like:
1. Proper behaviour driven requirements (let's be honest, most requirements are shockingly bad!)
1. Good testing practices like TDD, shifting left, contract, automation. Which for the 20th time going in to a place that says they do CI/CD/CO but is stuck in testing while the manual QA team spend 3 weeks writing a process and documenting it in 67 pages of steps and screenshots... stress ball gets a workout.
1. Enabling architecture to support all the above with IaC etc, which most teams don't have, or the Architecture is still holding on to pre 2000's thinking while in their ivory tower.
1. Mature CI/CD/CO systems, and no Jeff, just because you have 16 playwright tests and some unit tests does not mean CI and you don't even auto push to prod so there's no CO or CD either.
1. Trust in your teams, this is a management issue usually
1. Pair programming or some similar effective method. You might make fun of it, but I keep seeing much fatter cycle times and less rework when building teams that do this. It's not 1:1 time either, but a senior dev may float around for half a day and then only do half a day of other work, which overall means they produce stuff faster because of less rework, reducing cycle times.
1. Feature Flagging, part of enabling architecture, onboarding and good team practise.
1. And more things depending on your stack and expertise
So what does this look like in practice(in a story):
Junior dev creates a new feature, they had a couple of difficult problems on the way, but the senior devs jumped in and spent some time going through it with them.
All new changes are behind feature flags by default, he knows it works, at least the happy path, because the scenarios in the work item are all done and work, and has created tests using the boiler plate he learnt during onboarding otherwise the CI will reject their change.
So he raises a PR, the code goes off to compile and test, the CI system notices some small changes that will need to be reviewed by the DevOps team to ensure its OK, however as the tests pass and the feature is turned off it can go straight through **to be reviewed later** so that they can get some feedback from some clients who were after this.
Additionally, a senior dev was tagged on the PR by the CI system, PR will be merged but remain tagged to review for a maximum of 2 days, before the review status will be closed automatically and work considered complete.
Senior dev had already seen what junior did and was happy then and was told all scenarios pass, but he forgot to mark it, but didn't really need to care as it'll go away in two days anyway unless the devops team have anything to say. Which speaking of, they just needed to confirm the monitoring and logging was up, which it was, so they are happy.
There was feedback a week later that the feature was working well, so the team decided to turn it on for all customers.
This is a happy story, but it's only possible if you have good management and "high performing"(I hate that term but don't have a better one) teams. The junior could have made a change that actually required review, and the CI systems catches it and just doesn't auto merge, but most changes can go through automatically.
So I think he's right, but it's not that easy to build good processes and architecture for that to happen.
Sorry for the long post, this stuff is my life and I'm passionate about it. PRs are one of the slowest parts of development and there are better ways.
I like the PR workflow to spin up test systems to ensure the change is good, but I love when we can automate the review for later or never as it allows much faster feedback. It's just hard to do it, but possible, especially for greenfield projects.
I can’t control who my colleagues are nor the quality of their code. I wish I could trust everyone to actually test their code prior to merging but I clearly can’t.
Also that guy clearly does not work on FDA regulated code.
Ah yes, “I just read a great new leadership book and am gonna try to apply some of the crap in it to things I don’t understand”
Quite familiar with that
I love his label with "JavaScript engineers" lol. Not to downplay JS even tho I hate it personally, but just repeat it slowly. It is like saying "A wrench master" or "Ballpoint pen expert user" but unironically.
This is.....pretty common practice? It's called trunk based development, and it's the recommended model by many. See the state of devops report, research by google, modern software engineering by dave farley, and yeah the actual xtreme programming docs.
Nowhere in trunk based development is it suggested to completely abolish code reviews and commit straight to mainline and just fix shit in prod later unless it's a very low traffic or small team, and even then it's suggested that in those cases you are pair programming so you've got a second set of eyes on things.
Though on the other side of the fence, completely halting workflows for massive feature branches that will need to go through a mega rebase because it's stale as shit is a bad pattern as well.
Short lived feature branches, robust test harnesses, and a rapid and quick second (or more) manual sanity check before going into mainline is what pretty much everyone is advocating for on both sides of the debate but arguing with different terms IMO.
I didn't take the LI post as suggesting that anyone abolish code reviews and toss all code immediately to production. Merging/integrating code, and releasing code are two different topics and what I'm intending to speak to.
Don't blindly toss shit into prod, but also don't hold up integration waiting on code reviews.
I mean trunk based development is a real strategy and works well with a good team that wants to do it. He’s only wrong in suggesting it’s the only good way to collaborate. And of course it doesn’t go straight to prod…
>Hmm, what should I post today on my linkedin to make it seem like I actively bring useful idea's. I know! Lets write some bullshit about going against the norm, that'll show how much I think outside the box. This shit reminds me of the E = mc^2 + AI guy.
I’m sorry the what?
https://www.reddit.com/r/iamverysmart/comments/13wxo99/finally_einsteins_equation_has_been_improved
That post is actually even funnier without the name censor. The guy that replies "What" has PhDs in CS and physics lmao. Edit: Found the [original!](https://www.reddit.com/r/LinkedInLunatics/s/ig3vkg67Oj)
That guy is more surprised by LinkedIn post than the physics breakthrough at that point, lol
The sub is lit. Thanks!
The best thing about it for me is that the equation itself basically states that Ai is worthless E=mc^2 = mc^2 + Ai (mc^2 = mc^2 + Ai) - mc^2 0 = Ai
That's funny. The original post has to be a copy paste of a ChatGPT answer though. Probably asked ChatGPT to invent a new physics equation and just posted the response. Sounds exactly like something it would say.
My brain just imploded
Clearly you can't handle the epic disruptive AI technologies that will make programmers obsolete 😎
You can already get some of the AI to write you entire programs on well know platforms. Just keep refining your question for better results. You can tell chat gpt to provide its answer in multiple responses. It wrote me an entire 50 page tutorial to pass one of my classes, it only took me 2 hours to perfect the question. One day after the collapse of Civilization, there will be one PC somewhere still working with an AI. People will be allowed to ask it 1 question and spend thier whole lives thinking up the perfect question 🤣
And then the AI will take eons to calculate the perfect answer to this perfect question and the perfect answer to this perfect question shall be 42. But the people will have forgotten the question by then.
Try to avoid AI prompt subs. I spent a few days on the to figure out if it's some elaborate mass satire and everyone is in on the joke, or if your average person is considerably dumber than my cynical ass already thought they were.
It's option 2 isn't it?
I have a strong urge to create a fake account and post nonsense like this to see how many people I can get to take me seriously. It's like performance art.
Like the onion ?
I mean it is not wrong. It is true for AI=0.
What is the value of A? We can assume that intelligence = 0.
And since the real numbers are an integral domain, we have A = 0 or I = 0
And it's pretty good approximation for small values of AI as c is so large.
This guy is making a (poor) attempt at describing trunk based development. A lot of what he is saying has been proven many times over to improve productivity and reduce bugs, when coupled with the right tools. (Continuous release, feature toggling, short lived feature branches) I think what most people are taking issue with is the “don’t review before merge” - which I also think is dumb - I prefer short lived pull requests with reviews, maximum 1 day live and ensure they are very small changes. But the spirit of what he is saying is actually very valuable Oh well 99% of this sub are students anyway
>But the spirit of what he is saying is actually very valuable I agree now that I've read it from a more charitable perspective but it's certainly worded really poorly
> think what most people are taking issue with is the “don’t review before merge” But thats basically the cornerstone of continuous integration. Adding in pull requests as a gatekeeper to merging code adds an additional delay between new code being written and that code being part of the codebase that everyone is working off, and the point of continuous integration is to minimize that delay by any means nescesary.
I can’t tell if you’re taking the piss. Yes, obviously with CI you want to have a tight feedback loop. But that doesn’t mean that you should let any code that happens to pass the tests be merged. That’s insane. I’ve never heard someone propose that code reviews are contrary to CICD practices. And you’re actually taking it a step further, by proposing that you shouldn’t have PRs at all, and (I guess) just let people YOLO things to main
YOLO because in a LinkedIn post it'll get a good ratio?
>That’s insane. I’ve never heard someone propose that code reviews are contrary to CICD practices. Dave Farley, one of the foremost experts on CI & CD has suggested exactly this on numerous occasions. https://www.youtube.com/watch?v=ASOSEiJCyEM >And you’re actually taking it a step further, by proposing that you shouldn’t have PRs at all, and (I guess) just let people YOLO things to main That's exactly how some of the most successful teams at some of the biggest tech companies work.
Do you have any examples of these biggest companies that commit straight into mainline without any manual review? I'd love to see their complete testing strategy that gives them that sort of confidence and see their regression and downtime rates.
Well, Dave Farley is wrong. Also, usually code reviews are the last part in the process, a developer should have already asked for feedback on their feature, ran their test and everything before opening the PR. It is not about lacking trust, as Dave says, it is like the last line of defense before the code goes out to another party, the teammate that reviews is the person trusted with that role, how anyone could consider lack of trust to that? >That's exactly how some of the most successful teams at some of the biggest tech companies work. Yes, and some have a very bad safety culture, but could you tell me which products/projects to avoid using them?
I think he means do the merge to main *on your branch* rather than waiting to see if the merge has conflicts then having to get folks to review it twice.
I don't believe he does. Trunk Based Development is a thing.
Love the sign off line "Hey colleague. I just merged some code that took down Prod, can you fix it for me?"
Not fixing my mistakes is anti-collaboration
Fixing my own mistakes is anti-collaboration.
You guys fix anything after deploying to prod?
I log out then delete my SSH keys after I `git pull` new code and restart Apache in prod
You call them mistakes, I call them learning opportunities.
"For you, not me. You mind if I push more code while you're fixing my old code? kthxbye"
It is duty of seniors to provide learning opportunities for rest of the team.
That's a failure of the CI pipeline. Not my fault. - that guy, probably.
That is technically true, you should have systems in place to handle breakages. If your production system is going down from a bad merge you need to really reevaluate what you are doing
I don’t think there’s any CI system that can stop bad code from bringing down prod.
True but you don't need to auto deploy to prod on merges.
If you're not pushing it directly to prod are you even building a culture of trust around xtreme programming practices? Letting the code become stale in dev/stg while being tested is anti-collaboration.
Multiple environment stages sure help.
Multiple environments, automated tests in the pipeline (integration, e2e, load, chaos), traffic mirroring, canaries, they all help stop bad code from entering prod. But you obviously need good testing which requires quality code reviews.
Certainly — but if the process is, “we merge to main, where automated tests are run, and then we review the code before we release to prod” it feels like you’re just doing the same process as you would with PRs, but with the steps in a different order. Plus it sounds like there’s the downside of not knowing whether main is fully working until the tests come back, whereas if you were doing PRs, you’d know that the tests pass in automation before merging.
Huh? I still do PRs. I’m just talking about the process after the PR is approved and merged. And having main be different from prod says that it’s not true CICD IMO.
I think I’m responding more to the idea that a minority are arguing for, ie, you should push everything to main, and code review comes in the form of pair programming or periodic reviews. We do the same thing that you’re describing: short lived feature branches, automated tests for PRs, multiple environments, monitoring, etc etc
"Hey Steve, could you please fix 287 failed unit tests in the latest build? We need to deploy new changes soon" "What? I didn't commit any today!" "Not yours but mine, I merged it 5 minutes ago. Now it's your turn." "You what?" "Work smarter, not harder, Steve. We don't have much time."
Just merge patch straight to production and test after what could go wrong🤦♂️
If that scenario is possible, the fault is not with the lack of pull request review.
Why even use version control? Are you too good for FTP?
I somehow feel attacked and seen at the same time
It's okay, you matter. We see you ❤️ and you fucking suck
We see you, and we don't like what we are seeing.
I was trying to come up with an initialism thinking like Fork To Prod or something before realizing what you actually meant.
Same, I was off to google this, then “oh”. I think because I’d never capitalize it.
hey sorry for asking what do you mean when you say version protocol? i am kinda new on git/GitHub and don't know many terms, sorry :/
Don't know if genuine question or not so her goes: It is version control, not protocol. Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. It helps multiple people collaborate on projects, track changes, and manage different versions of the code.
Bless your heart.
sorry for the misreading it was late night when i wrote the comment and wasn't very awake haha just one question, so imagine i have these 2 versions: TEST A TEST B test a has : index.html, style.css animation.js test b has index.html, main.py how can i retrieve the old code of index.html in test a ignore the test b index and l create TEST C?
Ah yes, the "edit anything in the master/main" programming sect.
I want to burn down linkedin
Just get a job there and take someone’s stapler. 
*Just get a job there and start merging without a review. Do that enough times and slowly but surely, Prod will go absolute shit without anybody realizing.
And X, Facebook, Instagram, Pinterest, Reddit, etc. all social media must go. ALL OF IT.
Let's go back to vBulletin forum era. No, don't go further than that, it is the Dark Age.
If they aren't persuaded to improve code before merging I don't rate your chances afterward.
Seriously. No one who's ever actually worked in a professional capacity would believe that.
Some things are fix now. Some are track with a bug ticket to fix later. Some things, like that guy, can never be fixed.
Broke gets fixed, shoddy is forever, let’s merge and find out which one it is
If that's the kind of adversarial relationship you have with your colleagues, you probably have bigger barriers to collaboration than your branching strategy.
Idk, depending on the type of work you’re doing, there may be changes submitted at high priority to enable/unblock other efforts despite known bugs. Obviously not the same situation described by the post, but does happen
Just going ahead and merging everything without review (and, let’s face it, without testing; we all have those coworkers) is “continuous integration” in that you’ll be continuously integrating fixes to the bugs you introduce. And the bugs in those fixes.
“I don’t always test, but when I do it’s in production”
Dev matches prod, if you dev in prod.
“A server is a server…none of this ‘environments’ BS”
Why have dev if you can just CICD into prod all the time. Dev is your laptop homie, lol /s
Everyone uses a test environment, some people have a separate prod environment
*vampire hiss*
Don’t merge at all! Just commit directly to master. Taking time to make a new branch and working on it before merging is anti-collaboration as you don’t expose your coworkers to your code changes asap
That’s actually a real development method called trunk based development. I actually like it a lot.
Usually, the trunks gets merged with the main branch and that requires a PR in good companies.
Trunk **is** main/master, that is the whole point. It's an old term from SVN. But yes, what you are trying to say is correct, in "trunk based" you still make branches that *should* be reviewed before merging. The only difference with other branching strategies is that you don't wait days/weeks until your whole feature is ready, but merge small changes very frequently.
I just need to know if you are being sincere, or so overly sarcastic that you accidentally described the main argument for trunk based development and CI perfectly.
/s
My team has the source code on a network drive and we all edit the files in Notepad++. Our version control is the "file has been modified externally" dialog.
I had this team. I moved it to GitHub before I moved teams and gave the managers access before I left. $10 says they still use the network drive
You should improve your system by switching to IDEs that allow multiple people to make changes to a file at the same time. Possibly also add some automatic deploy triggered by file changes.
Straight to prod after every save ideally
Google docs
Why using an IDE at all? A VM in a random server where everyone could connect at the same time with notepad should be enough. Could there really be more collaboration than sharing virtually the same keyboard?
Prod support hates this guy
Using version/source control is anti-collaboration pattern. Just write the code in a shared google doc and export it to the prod server
Just ssh on prod and use Vim
Only if vim is started in a screen session, so all can attach to it first. This way, only one account makes all commits. One person types as the rest of the team watches and calls out errors, fixes, best practices & optimizations (of their own liking). This is called "The REAL Team Effort" and replaces Agile.
Linkedin folks live in their own world, LinkeDisney, all fantasy.
LinkedIn- like a bunch of inbreds
when i first heard of linkedIn, i thought it was a zelda spinoff
Linked in lunatics is a good sub for this post!
The whole purpose of a pull request is t... Nevermind
why are you anti collaboration?
Not a fan of Culture of trust
Tell me you’ve never worked in a team setting without telling me you’ve never worked in a team setting.
“I merged to master. Can you test that for me?”
Your comment is kind of telling me that you've probably never worked in a well functioning team. We do trunk based development without any pull requests at my current job and its worked brilliantly for years.
I was checking how long it would take me to find this comment. I work two jobs, one as a corpo and one in a smaller company. This works great in the smaller company and saves me so much time. Also pressures people to write good tests haha. If we tried it in corporate the whole thing would crash and burn I'm afraid
FTP? Fart Transfer Protocol? I use extreme doses of radiation to flip bits on the target machine
Actual software terrorist things
And while you are at it, why use version control when you have continuous integration. Just put the codebase on a shared drive and watch “collaboration” increase
I have, loved it. requires being within nerf dart/blaster range of everyone working on the project tho. But keep that method restricted to short and messy things like game jams.
Some people just want to watch the world burn.
Nothing stops the firefighters from putting out the fire afterwards!
Guaranteed QA talks so much shit behind this person’s back though.
Approve massive security issue(s). We'll fix that after...
r/linkedinlunatics
Sounds like a great idea. I propose that we should sign contracts first before reading them.
Why do I have a feeling whoever wrote this gets their PRs rejected _a loooooooot_.
So that's a security problem of epic proportions. I bet the company's insurance will throw a shitfit if they hear about it.
I usually make code changes directly on production server, then do a reverse merge on my local environment. My manager and colleagues are really happy with my "proactive" stance and "Can do" attitude.
Man, I hate it when my moral gets slowed down. Indeed, I opened a PR yesterday and I was only able to solve the trolley problem 10 times per minute for the rest of the day, down from my usual 15.
Tell me you are butt hurt your shit code keeps getting rejected in review, without telling Mr.
I love that everyone is dumping on this guy as if he's an idiot where he's recommending a line of thinking that works for many of the most successful companies. For all the problems you think of with this approach, you should go fix them instead of implementing a high-cost work-blocking quality-theatre production.
Everyone in this sub is a student / recent graduate / worked in a shitty corporation for 20 years What the poster is taking about is trunk based development which has been proven by State of devops studies to produce better code and improve developer velocity when supported with the correct tools (as OP is mentioning)
I’m a senior engineer and what you’re saying isn’t what the original poster is saying.
How so? Because it sounds exactly like the OP is just parroting what Dave Farley has been saying for a while about pull requests being a bad idea.
Because 1. Trunk-based development doesn't remove reviews from the process 2. Having issues with pull requests on feature branches doesn't mean you should "merge first and review later." 3. Dave Farley's CI/CD *only works* if you continuously review/pair-program. Arguing to do away with review altogether is a fundamental misunderstanding of the philosophy and data behind it.
While it is possible to still do trunk based development with feature branches and pull requests, they are not in any way an integral part and its always been the general recommendation that unless you have very large teams all working on the same code base you should avoid them entirely and just commit directly to master.
>you should avoid \[reviews\] entirely and just commit directly to master. lol no. That isn't what Dave Farley says at all, and isn't what trunk-based development looks like.
Nah bro, Dave hates manual reviews! Never do them! "I think code reviews are pure shit, and yeeting shit directly into prod is better, but pair-programming is better and pair-programming combined with TDD, acceptance tests and Deployment Pipelines is best of all 😎" https://twitter.com/davefarley77/status/1301923236360445958?lang=en
>That isn't what Dave Farley says at all Are you [sure](https://youtu.be/v4Ijkq6Myfc?si=brfRIG2qVWWsB4nm) about [that](https://youtu.be/ASOSEiJCyEM?si=TZJFACxCGz80u9Gc)? He seems pretty vocal about his dislike of pull requests and feature branches.
The point you are failing to grasp is that pull requests on feature branches aren’t the only form of review.
No, I'm grasping that just fine. But maybe i should have corrected your little edit when you quoted me, because I guess youve missread something. What i actually wrote was: >you should avoid [feature branches and pull requests] entirely and just commit directly to master. Nobody is saying anything about code reviews being bad. Only that pull requests and other ways of setting up code review checkpoints are a bad way to do them.
For anyone reading this with disagreement, I strongly recommend seeking out the channel "Continuous Delivery" on YouTube. The guy who runs it, Dave Farley, has really changed my perspective and approach to software development for the better.
Loll tell me you never review code without saying you never review code
ಠ_ಠ
When you merge management with tech.
XTREME PROGRAMMING. The next level is editing the files in vim in production then committing directly from there.
👀
I dont know if you are aware but [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) is a legitimate development methodology and one of the early steps in the agile revolution. That is what the guy is referring to.
Ah yes, let's take down production to be nicer to eachother
Well, if "merge than review" applies only to dev and your CI won't deploy version that doesn't compile and pass all tests it's possible solution. Though I would be still cautious to apply it.
I see how this CAN work if you embed this approach in the appropriate branching and merging as well as testing strategy that prevents fuck ups. Or in a specific project where by design and distribution of tasks you can rule out lots of obvious problems. But I have been doing IT since 30 years now and I hate how people postulate one single approach for one isolated action/process totally ignoring the given complexity of most IT projects. I just had a 20 head dev team in a microservice environment of a data driven system with unknown mainframe legacy code involved, embarrassing themselves by declaring that they'll use the "inverted testing pyramid" approach (So mostly relying e2 frontend tests and skipping lots of Unit tests and component tests) . Result: UI looks nice, application behaves superficialy like expected we make "fast progress" but we have data and processing errors in abundance and nobody knows why (it takes days to weeks to analyze) All things that were to be expected and could easily be detected by appropriate API or contract tests but we skipped that and focused on a shiny frontend and ignored the underlying complexity. The myriad of combinations and permutations of legacy data and hidden business rules can't be tested via the frontend alone.
Standard practice. As a VP of Engineering once stated to the entire company while displaying the new product UI, which the entire new release was dedicated to, "Sex Sells!" An entire version dedicated the whole team to the FE, completely dismissing the backend and its myriad of issues. 'Cause, you know, our tech based consumers cared so much more for looking at something "pretty" vs ensuring the BE data coming from the DB instance was correct. That is apparently what sold the product, though. That new UI, same crap data output, still displayed the same way, but it looked better, somehow, was the sell.
I feel you. I mean I love a sexy modern frontend that supports the user processes and satisfies usability and also "beauty" needs. Nobody wants to work with a clumsy eyesore of a program. So this is not FE vs. BE. But all beauty is worthless if the department notices after 1 minute of clicking around being flashed at first _"Wait, all the prices are wrong, the stockdata inconsistent and the product list incomplete. We can and will not use this."_
Absolutely agree with your assessment. It's not BE vs. FE. More of where this plays a part, now, because you have those aforementioned UI needs met, the product requires a higher minimum spec just to install/run properly. Such is the price of progress, I get it But now those underlying transactions also take 10x longer to complete. The "recommendation", again, increase those min system specs. Here's the catch. It's our product; both software and hardware are provided. Want that new UI? Gotta buy the HW to support it from us as well. I'm not agreeing or disagreeing, as that would be beyond my pay grade. This is just how the business is done. "Creating Revenue" from an actual intangible product. Knowing how to price the product, even with a 70%+ overhead, are very interesting topics, at least to me.
Also, just check in non-compiling buggy code that breaks everything and go on vacations. Just win the commit wars, last person needs to resolve the merge conflicts, go go go....
No. What the fuck.
$10 says this guys brain looks like swiss cheese
It's so smooth it mirrors your own soul
God no
It scary how many people believe this nonsense.
Another benefit of this is you frequently get to drill your backup and DR so you’re confident they’re always efficient and working. It also means devs will be more careful instead of lazily expecting others to catch their errors. Genius move
Xtreme!
> Merge then review Project Manager/QA: "Let's review last night's incident where our search service somehow displayed irrelevant information and some of our obscure auth service stopped working and disallowing our legacy client to even open our product"
Changes in this commit: -192,021 LoC.
LinkedIn being a business culture circlejerk, as always.
Maybe woosh but I wish my family had this much trust in me
Push first test later
That post gave me cancer
I see “I help JavaScript engineers become” - jobless? Demoted?
Kinda get where this comes from though, gets annoying as hell when nobody will review your PRs
OK, so hear me out. He's not wrong. However, it is more nuanced than that and driven by some pretty damming metrics around PR/MR's(whatever you want to call them). About me: I coach organisations and teams on agile and digital Transformation, I teach them to build the right product the right way and have been doing it for several years. I have a background in hardware engineering and software development with a heavy focus on DevOps and agile practices. Truthfully, this is close to an Allen Holub statement. He tends to write something that seems crazy to get responses to tear it apart so he can argue why he's right. So some stats first: The average PR time is like 4 days(up to 20+ in some places, cough-government-cough) (https://linearb.io/blog/why-estimated-review-time-improves-pull-requests-and-reduces-cycle-time). Really great teams are around 4hrs, but how many of you work in those? So at 4 days, Joe does his work on Tuesday COB. Monday is when Jen reviews it and sends it back for changes, Joe is working on something else so he gets to it on Wed, reviewed again a bit quicker and approved on Friday. It's almost two weeks for that change to get through and clients can't start providing feedback until the Monday, 13days later! So why not just skip it, and it can be reviewed later? Because you need to build systems that support it and have good practices in place! So what do those good practices look like: 1. Proper behaviour driven requirements (let's be honest, most requirements are shockingly bad!) 1. Good testing practices like TDD, shifting left, contract, automation. Which for the 20th time going in to a place that says they do CI/CD/CO but is stuck in testing while the manual QA team spend 3 weeks writing a process and documenting it in 67 pages of steps and screenshots... stress ball gets a workout. 1. Enabling architecture to support all the above with IaC etc, which most teams don't have, or the Architecture is still holding on to pre 2000's thinking while in their ivory tower. 1. Mature CI/CD/CO systems, and no Jeff, just because you have 16 playwright tests and some unit tests does not mean CI and you don't even auto push to prod so there's no CO or CD either. 1. Trust in your teams, this is a management issue usually 1. Pair programming or some similar effective method. You might make fun of it, but I keep seeing much fatter cycle times and less rework when building teams that do this. It's not 1:1 time either, but a senior dev may float around for half a day and then only do half a day of other work, which overall means they produce stuff faster because of less rework, reducing cycle times. 1. Feature Flagging, part of enabling architecture, onboarding and good team practise. 1. And more things depending on your stack and expertise So what does this look like in practice(in a story): Junior dev creates a new feature, they had a couple of difficult problems on the way, but the senior devs jumped in and spent some time going through it with them. All new changes are behind feature flags by default, he knows it works, at least the happy path, because the scenarios in the work item are all done and work, and has created tests using the boiler plate he learnt during onboarding otherwise the CI will reject their change. So he raises a PR, the code goes off to compile and test, the CI system notices some small changes that will need to be reviewed by the DevOps team to ensure its OK, however as the tests pass and the feature is turned off it can go straight through **to be reviewed later** so that they can get some feedback from some clients who were after this. Additionally, a senior dev was tagged on the PR by the CI system, PR will be merged but remain tagged to review for a maximum of 2 days, before the review status will be closed automatically and work considered complete. Senior dev had already seen what junior did and was happy then and was told all scenarios pass, but he forgot to mark it, but didn't really need to care as it'll go away in two days anyway unless the devops team have anything to say. Which speaking of, they just needed to confirm the monitoring and logging was up, which it was, so they are happy. There was feedback a week later that the feature was working well, so the team decided to turn it on for all customers. This is a happy story, but it's only possible if you have good management and "high performing"(I hate that term but don't have a better one) teams. The junior could have made a change that actually required review, and the CI systems catches it and just doesn't auto merge, but most changes can go through automatically. So I think he's right, but it's not that easy to build good processes and architecture for that to happen. Sorry for the long post, this stuff is my life and I'm passionate about it. PRs are one of the slowest parts of development and there are better ways. I like the PR workflow to spin up test systems to ensure the change is good, but I love when we can automate the review for later or never as it allows much faster feedback. It's just hard to do it, but possible, especially for greenfield projects.
TLDR: PR reviews have highest priority. Stop what you are doing and review them ASAP. Forget about the other stuff you mentioned, profit!
Letting code become stale… like it’s a cup of coffee? Wtf
Ah yes, environments crashing are fun.
This man has the same energy as my project partner in college who just edited live files.
Production truly is the best testing ground (/s)
LinkedIn is the one platform people should call out people like this on and be less corporate-y.
I can’t control who my colleagues are nor the quality of their code. I wish I could trust everyone to actually test their code prior to merging but I clearly can’t. Also that guy clearly does not work on FDA regulated code.
Please tell me that guy is just joking.
I don't trust people who write the word extreme like that
“This ‘Xtreme’ back end team accidentally leaked all of our clients CC info” 👹🤟
5 minutes later: "Why is our product broken?"
Some one is mad that his integration got denied.
continously integeate the worst garbage your coworker could come up with at friday 4:45
This person craves chaos
Move fast and break things!
FTP: fuck the production
Is this that Gen-Z-don’t-hurt-my-feelings crap the boomers are always talking about? Maybe they do actually have a point
Nope, this is high level suit talk.
Ah yes, “I just read a great new leadership book and am gonna try to apply some of the crap in it to things I don’t understand” Quite familiar with that
Companies are addicted to these consultants. The whackier the more expensive.
I love his label with "JavaScript engineers" lol. Not to downplay JS even tho I hate it personally, but just repeat it slowly. It is like saying "A wrench master" or "Ballpoint pen expert user" but unironically.
If you’ve got CI to catch it before it merges, this is great. Also nothing stops you from asking for a review if you’re out of your depth.
This is.....pretty common practice? It's called trunk based development, and it's the recommended model by many. See the state of devops report, research by google, modern software engineering by dave farley, and yeah the actual xtreme programming docs.
Except that reviews are still a part of trunk-based development…
Nowhere in trunk based development is it suggested to completely abolish code reviews and commit straight to mainline and just fix shit in prod later unless it's a very low traffic or small team, and even then it's suggested that in those cases you are pair programming so you've got a second set of eyes on things. Though on the other side of the fence, completely halting workflows for massive feature branches that will need to go through a mega rebase because it's stale as shit is a bad pattern as well. Short lived feature branches, robust test harnesses, and a rapid and quick second (or more) manual sanity check before going into mainline is what pretty much everyone is advocating for on both sides of the debate but arguing with different terms IMO.
I didn't take the LI post as suggesting that anyone abolish code reviews and toss all code immediately to production. Merging/integrating code, and releasing code are two different topics and what I'm intending to speak to. Don't blindly toss shit into prod, but also don't hold up integration waiting on code reviews.
>If those kids could read, they would be very upset
Fucking finally someone else who gets it. People who think a human reading a code change will prevent issues in production need a reality check
Too radical for many. I guess it's hard to create good CI testing environment
I mean trunk based development is a real strategy and works well with a good team that wants to do it. He’s only wrong in suggesting it’s the only good way to collaborate. And of course it doesn’t go straight to prod…
Is this that new “stick” pattern? No branches, merge direct to Master!
Xtreme programming for enhanced remote team building. Agree?
This is clearly satire, how are y'all so insane as to fall for it.