Readit Newsneo2006 commented on Reorient GitHub pull requests around changesets mitchellh.com/writing/git... · Posted by u/jamesog
I'm gonna rephrase my previous point. What you say makes sense, but only if you understand that it takes away time, money and energies and after knowing it, and the impact of all this time drag you determine it's worth it.
Might apply to huge products making millions $ every day. Sure, delivering a bug will be expensive.
Might apply when you can't trust your colleagues (not skilled, reasonable or experienced enough).
Might apply if your code is niche but mission critical (maybe some safety system on a car or a dangerous tool, or surgery equipment).
Of course I agree with all you said.
But you're writing some Java/TS web app which isn't raking much money, or has still to be launched, or your biggest focus is time to market to beat competitors and you're wasting time on code reviews the author hasn't requested?
In this scenario (my current client) I want to have a team I can trust and gets stuff done. This does not imply that CRs don't happen or design isn't discussed, but it happens when it brings value or it is needed. And I like it that way, where we can build stuff, rather discussing how to build it.
If we want to include the cost of a code review into the equation we should also include the cost of fixing a big that made it to production which is in most of the cases higher then code review. Skill is not a factor here, I work and worked with some of the best engineers in the world and everyone write buggy code sometimes. Software engineering is a complex practice.
If you are writing some prototyping code or some code that will never make it to production or in a very early stage of a startup, sure I can understand your point.
neo2006 commented on Reorient GitHub pull requests around changesets mitchellh.com/writing/git... · Posted by u/jamesog
I don’t mind code reviews so I’m not really defending who you’re replying to. There is another way to think about this tho and I actually have found this practice to be light years more effective than code reviews. Where I work we have a practice where before you start doing a ton of work on your card/ticket you should find someone on your team, explain the problem to them, and show them how you’re going to do the work. This gives your teammates an opportunity to give you feedback before anyone has done anything, and you can both poke holes in design decisions before anyone has done anything they feel strongly about. If you do this process 95% of code reviews are pretty much worthless.
I fully agree, we also do this and this is the design review I alluded to.
That said, I think both have different purpose. The design review is more about the approach and the high-level implementation. The code review is about the implementation details.
Also, a great aspect often overlooked around code review is that it's a great teaching tool if used right. Asking question go a long way and make both the reviewer and the reviewee learn.
Code review is often looked to as a senior watching over what juniors are doing. In my experience it should be done for all levels and even juniors should review seniors PR as they can bring novel perspective and at least learn from the code by reviewing it.
neo2006 commented on Reorient GitHub pull requests around changesets mitchellh.com/writing/git... · Posted by u/jamesog
I often stack PRs to emulate the practice described by Mitchell but it's not ideal as if you need to change an underlying PR l, you need to rebase all of the dependent PRs.
neo2006 commented on Reorient GitHub pull requests around changesets mitchellh.com/writing/git... · Posted by u/jamesog
Jm2c, but by far the best place I've ever worked (my current client) we don't do code reviews at all unless the author wants feedback.
PRs are good ways to defend your code base from bad code, and they were born in open source where you literally have no clue who the contributor is, but years of experience left me convinced that I don't want such a system where there's constant need to overview each other's work.
I want to work with a team where there is high respect and trust. A team where I know I won't like or love all the decisions others make, but I trust their judgement. Maybe they did indeed hack an ugly solution cheating the type system and automated controls. So what? What matters is if they have done so for good reasons (stuff was super urgent, a proper solution was just not worth the effort as the feature/fix was really not important for the business).
This made development speed skyrocket and I'm no longer bound to infinite code reviews as if we were sending rockets on Mars.
I also want to say, code quality is high, but this stems both from working with great individuals that can be trusted and from much higher interaction speed.
I don't see code review as an overwatch but a good communication tool and a way to think about problems collectively. Code review reduce bugs because it permit to have people think about the problem from multiple angles. About decisions, I think important design decisions need to be taken prior to the code review steps ,and also reviewed.
I'm not sure what context you worked in that gave you that opinion about code review being a sign of distrust and I think the problem lay within the culture in those places not the code review practice it self.
neo2006 commented on Do-nothing scripting: the key to gradual automation (2019) blog.danslimmon.com/2019/... · Posted by u/jabo
This is the way. I wish this were taught in computer science class, development bootcamps, operations team onboarding, anywhere there is a procedure that is even slightly complicated to automate. It is the absolute best solution there is.
* Documentation of the entire procedure is contained in one place. No need to go sifting through 20 different sources of documentation. This lowers the human emotional barrier to "just get it done", as people will always avoid things they aren't comfortable/familiar with, or don't have all the steps to. This central point of documentation also enables rapidly improving the process by letting people see all the steps in one place, which makes it easier to fix/collapse/remove steps.
* Automation in small pieces over time avoids the trap of "a project" where one or more engineers have to be dedicated to this one task for a long period of time. Most things shouldn't be automated unless there is demonstrably greater value in the cost of automating them than the cost of not doing so. Automating only the most valuable/costly pieces first gives immediate gains without sinking too much into the entire thing.
* One unified "method" to encapsulate any kind of process means your organization can ramp up on processes easier, reducing overall organizational cost.
* In the absence of any other similar process, you are guaranteed to save time and money.
I would say that the only potential downside is if someone decides to "engineer" this method, making it more and more and more complicated, until it loses its value. KISS is a requirement for it to be sustainable.
If you are going through writing the do-nothing script anyway why not do a do-something script and remove the error prone human out of the loop, it also can serve as documentation and if you are disciplined enough to never make a change other then trough the automation you can have the benefit of source controlling it and have documentation with historical context
neo2006 commented on I ruin developers’ lives with my code reviews and I'm sorry habr.com/en/post/440736/... · Posted by u/aracena
Have you ever written some text, and re-read it, and it sounded just right, and had someone else read it, and they said "what does this mean"? Sometimes the words you write are sufficient to trigger in your own head the thoughts you've already had, but not enough to make someone else think those same thoughts.
Code can be like that, too. You write code, and it's enough to convince you that it does what you think it does. But someone else reading it can sometimes see the holes that you don't see.
Assuming that person X writes bug-free code is bad, whether X is "you", "me", or "that co-worker".
I don't have to be better than the PR author. I just have to be decently good, and be a different person. That's enough.
And of course I'm looking for bugs. That's the absolute first thing to look for!
Now, true, if I can help the author be able to see their own bugs (asking questions, maybe), then that's probably better than me just lecturing them. Teach them how to think so that they can see it themselves next time.
I'm not saying that you will never find bugs in someone PRs I'm just saying it shouldn't be your first intention, your first intention should be to understand it and be convinced by it. Finding bugs will be a side effect of that.
If you reading the code to execute it in your head and find all the weird combination that could trigger a core dump, you should probably check if the author wrote tests for those use cases instead and comment about missing tests.
Genuine interest in others work can go a long way compared to imagining how would you solve it like the article author said.
The way war usually works, is the side that feels it has something to loose, sues for peace by making concessions. However the international backing of Hamas has ensured them that they have nothing to loose, and everything to gain, by attacking the Jewish state.
Also, most of the people in Gaza are not Hamas members and are regular civilians. What Natanyahu is doing is basically analog to the following:
A killer take a member of your family as a hostage (Hamas in this case is the killer) so you decide to kill a member of their family every hour until they release your beloved one. Do you think that this is acceptable or are you trying to make it acceptable?