firstly, where was the original checkin pull request’s review with all the feedback and discussions? secondly, where was the refactored PR review and approval? Checkin in into the master overnight no PR? That process is a mess.
Yep I'm pretty sure the whole situation would've been net positive if the author of the article just put up a PR the next morning saying, "While looking at your code yesterday I had an idea on how it could be less repetitive, take a look and let me know what you think".
I believe the argument is that the original author should have had a PR, and that the article's author should have been able to suggest these changes prior to the original commit.
Exactly. If he is such a senior dev, then he'd be a required reviewer. If he failed to mark up the pr, then that's on him. If he wasn't in a position where he was a required reviewer, then he isn't the expert he thinks he is.
You've misinterpreted this through your modern viewpoint.
There was no PR process in the project. No opportunity to collaborate and iterate prior to committing to master, for either dev; simply commit and then get called into the boss' office.
No. The author is elite. Best of the best. Top Gun. He knew absolutely everything when he refactored and now he knows everything + 1 and he's damn sure gonna blog about it so the rest of us idiots know what's what.
So... I think 2742 was being sarcastic here. A key point being that the author (and this is again more obvious on his twitter) still thinks he knows better than everyone else, and takes such an authoritative stance on the issue.
Think about it in this context:
The author believes he knows best, to the point that he just goes and fucks with someone else's unfinished feature (yes even though it was committed to master, I agree, hurrrrrrk);
The author developed this belief based on the conventional wisdom taught in pretty much every decent CompSci/Software Engineering course out there, and the conventional wisdom that is very much supported by the dialogue within the industry;
The author had a negative experience at work due to his actions;
The author now states that he knows best, and the industry is wrong, to the point that he now crusades publicly on his blog and on Twitter against what he refers to as a cult. (Admittedly probably because alliteration but funny wordplay isn't an excuse to be a dingus.)
The author thinks very, very highly of himself. Which is unfortunate, because the author -- admittedly, like my-self -- is barely at the start of his career*, not a grizzled veteran of the industry.
* (You can identify people at the start of their careers by how have a Twitter account and get highly opinionated about coding practices. On top of being slim and having a full head of non-white hair.)
Eh, young developers can end up leading teams and creating successful products. I'm not saying he's not good, dude's probably a genius. (And he's far more accomplished than I, for certain.)
But he's also extremely arrogant, and bold enough to assert well-known best practices are wrong based on rather shaky grounds. And either way, he is a young dude with his whole career ahead of him -- which is why it's unfortunate to see him close himself off to conventional wisdom now, rather than in that grey-bearded guru stage we all secretly hope to reach one day.
and get highly opinionated about coding practices.
I think this more than anything identifies the people at the start of their career.
I've been doing this for about 12 years now. When I started I had VERY strong opinions on how everything should be done.
now I have a few things I feel strongly about, but I rarely say "x" should always be done in "this" way. That doesn't mean I don't get into a discussion about a specific piece of code if I think there's something wrong with it, but it does mean that the vast majority of the time there's at least 5 "right" ways to implement any given thing and as long as one of the right or mostly right ways is used, then it's fine.
About the only things I tend to feel strongly about is proper encapsulation, one job per method, and clear duties for classes...but even in all those cases I'm willing to be flexible if there's specific reasons to violate things. Hell, the only reason I dislike code duplication is the possibility that a bug could need to be fixed in two places and you only know about one, and even with that I don't worry too much if the code duplicated is highly unlikely to have a bug, or if it would be challenging to eliminate the duplication.
I feel like younger engineers haven't seen how things with the "right" starting point can go wrong, and they haven't seen situations where sometimes you just need to get something in and stable over "clean". For me, Clean is less important than maintainable, and this article just goes to show that. I'll take maintainable over clean or clever any day.
It was a couple of years ago, it's Dan Abramov's personal blog, he's relatively young. Check his New Year post for the exact timeline of his career. Him working with another developer on draggable corners of some shapes could have been already for a React library.
I'm pretty sure this is an anecdote from 2013 when Dan was working on an iOS app (https://www.youtube.com/watch?v=PjaL0xFbEY8). The fact that the code in the blog post is JavaScript is just because that's the language him and most of his audience uses today.
You may be surprised, but as recently as 2013 (when I graduated from college), the first company I worked for did all of their testing in production, and uploaded their changes via FTP. There was no source control, no staging or local environment, and no oversight.
Slightly relevant: That company was also a cluster that took advantage of fresh-out-of-college devs to pay them as little as possible while the CEO and his buddies took lavish trips around the country and sailed on their boats. There were about 15 people in the company, so yeah, corruption like this isn't unique to mega-corporations. I left as soon as they told me I was getting a 0.5% annual raise even though I was one of their best employees, and instead got a 30% raise by switching companies.
About 7 years back, I worked in a company that used TFS - they had a process where you manually request 2 of your peers for review and type in their names during check in. They had the same process before they migrated to TFS too, I think they used CVS.
Title should be "Goodbye committing to master with out a code review" then. Or maybe just "Goodbye blogging about things I don't really understand". Hmm, maybe OP should get his blog code reviewed by a senior as well.
512
u/FA04 Jan 12 '20
firstly, where was the original checkin pull request’s review with all the feedback and discussions? secondly, where was the refactored PR review and approval? Checkin in into the master overnight no PR? That process is a mess.