Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
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
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.
Wow, of course he's pretending the response is a misrepresentation of his opinion instead of defending it in good faith.
I think the latter makes clear that this is a joke account, doesn’t it?
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.
Oops boss just did a git push --mirror
I really wish LinkedIn would add an anonymous cringe emoji. I would use it on like 90% of the content on that site.
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
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.
🫠
No integration is as continuous as editing in prod.
I miss when internet services was literally down because it was being developed in place
Do we have a Linked In Lunatics sub on Lemmy?
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.
Bet you $50 we later learn this guy was orchestrating a supply chain attack.
I help JavaScript engineers become framework A...
ssholes.
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.
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!
LinkedIn "influencers" are insufferable, dear god
this made my heart rate go up a little bit in a way that doesn't feel good
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.
Something like that happened to me yesterday. I reviewed one PR, then some Important Guy came in and said:
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.
If coders are good AND know the project
Those are some pretty big ifs.
Let the users do the testing
Oh hey a fellow game dev, how long you been in the industry?
I mean this is basically a wiki, isn't it.
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.
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
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.
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"
Test it? Meh. Just ship it.
It compiles = it goes to prod!
This explains what is going on a facebook.
The subtle Linux-flex in the screenshot.
As a SOC auditor you programmers are going to make me scream at the exceptions you guys cause.
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
Developers: "Move fast and break things."
Things: break
Developers: surprised Pikachu face
I wonder how many programmers out there have intentionally set out to subtly sabotage the system. Anyone doing that, good luck to you.
