And you are here why?

It was my first day on the job. This was a wee bit back, and the company I had just joined was having … issues … getting stuff out the door. “ Any day now ” had turned into “ It’ll ship in two weeks ”, and that was a cool 3 months in the past, and eventually, I got called in to help get stuff unstuck. So anyhow, it was my first day on the job, and I was poking around the repos, trying to figure out what was what. After a couple of baffled hours, I figured out that the development process seemed to be  eventual-consistency-git  — everybody developed against their own branch, and cherry picked from each other to get updates. A “release” involved nominating one developer (and their branch!) as the primary, and having everybody else stop work. The primary would then painstakingly merge in all the other branches,  maybe  resulting in something that worked. And yes, this was utterly bat-s**t crazy, but whatever. I put a little bit of order in place, just to ge...

You’d like to believe that the contents of your monorepo are well constrained, you’ve followed  Loose Coupling  principles thoroughly, and it’s  SOLID  as far as the eye can see. And yet,   yet , this happens It isn’t like it’s some  #CowboyDeveloper  deciding to go f**k around in the code-base, and send in  all  the changes to the 17 tickets that he (•) was working on at the same time. I mean of course yes, that happens. In this case though, it was that one change in a library module, that was needed, that trickled up through the code-base, and ended up affecting everything. We’re not perfect. It may have been “ SOLID  as far as the eye can see”, but it turns out that the bug in the library module was actually over the horizon, and yeah, it affected everything. Sigh. I know what  I’m  doing for the next 6 hours… (•) Yes. It’s always  He .

That moment when I realized that we had   isCanceled   and   isCancelled   flags. And getters and setters for both. And methods that made sure that they were in sync. And a background GC process made sure they were in sync, because the “sync” method had a bug(s?) in it somewhere. And instrumentation around all of the above. And reports tracking discrepancies between them. (Incidentally, there was a perfectly logical for pretty much each of the above steps. I’m not saying it was a   good   reason, but it was certainly logical) ( This article also appears on my blog )

Does it go something like this? a)  Checkout the PR b)  Scan through the code, looking for obvious s**t c)  Approve it Thats about it, right? Mind you, if you’re feeling particularly testy,  -b-  above might turn into  “ Scan through the code, and find something to criticize” but that’s  really  about it. /via http://geek-and-poke.com This isn’t really because you’re a bad person. Odds are, you’re in the middle of one of two things Code Reviews Take Time It’s true. And there really isn’t much that you can do about it. That said, a different way of saying this is  There is no short-cut to Quality . You want software that doesn’t suck? Well, that’s going to take time, no way around it. If your tech-lead/PM/ProdMgr doesn’t get it, either help them get it, or find a new job (•). At some point, s**t is going to break, and, well, you don’t want to be in the blast radius… #CowboyDeveloper  Hates Code Reviews This is a wee b...