Skip to main content


Showing posts from September, 2014

Fwd: Great Article on Code Review Consequences of bad reviews Not having time to deal with your review backlog. Delaying a release because your reviews aren't done yet. Posting reviews that are no longer relevant since the code has changed so much in the meantime. Doing poor reviews since you have to rush through them at the last minute. Ideas >>  something around 25% of the original development time should be spent on code reviews .  >> understand how the code fits into the larger context of the application, component or library it is part of. If you don't grasp all the implications of every line of code, then your reviews are not going to be very valuable. >>    empty their review backlog every day.   Fix One Area At A Time >>   If my colleague spends a week adding code willy-nilly across a large project then the patch they post is going to be really hard to review.   >>   creating reviewable code is to  annotat


I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis. Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it. Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners" Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message. Guess that means the iPhone 8 will be back to boxy. And honestly, Apple Watch is not worth " one more thing " --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thin