897 karma · joined May 31, 2007
> Integration with your test framework and programming language
any indication which languages/frameworks? I've got a fair sized typescript monorepo with a build/test cycle I want more insight into
Our hypothesis is that market signals combined with the right tools (friendly app and home automation) can help households shift demand into less carbon intensive periods.
So far it's working pretty well.
* "IBM's 360 and Early 370 Systems " https://mitpress.mit.edu/books/ibms-360-and-early-370-system...
* "Broad Band: The Untold Story of the Women Who Made the Internet" https://www.goodreads.com/book/show/35953464-broad-band
* "Fire in the Valley: The Making of the Personal Computer" https://www.goodreads.com/book/show/1427580.Fire_in_the_Vall...
Thanks for reading and all your comments.
So assuming the same payoff benefit (big if, but let's go with it) between PR style reviewing and more formal inspections, every engineer should be spending around four or five hours a week performing reviews to hit the sweet spot.
I have a recollection of seeing a study once that found the best balance point of review time vs dev time but haven't found it again. I recall it being somewhere around 20-30% but now that I can't find it I'm questioning my recall.
I agree with this, but think there needs to be some balance. My experience has been that people generally add rules over time while rarely removing them - usually to quell disagreements without regards to the benefit of standardising the answer versus the cost of more rules.
In it he has a pretty interesting insight about late projects. "If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster."
I imagine as our field matures measuring productivity and hitting estimates will get more important once software has finished eating the world. The unlimited (or close to) upside dev projects will be largely behind us and we'll need to hit tighter economic targets. I'm just glad I'm working in the era where I don't need to measure it :D
Glad you like the posts. Thank you!
I agree that the bulk of X vs Y comparisons are emotive and subject to what Alan Kay calls the "pop culture" but that in no way demonstrates that measurement is out of reach. It's just in most contexts we don't care to do the work to measure it out of personal preference or economic reality.
My anecdotal experience with my own teams is relying too much on pairing as a training mechanism, especially between senior and junior, has a couple of issues. The first is tradeoff between training quality and utilisation - it may shorten the training cycle but the payoff isn't high enough for the output constraint on the more senior member. The second is I've sometimes had trouble weaning the junior off always having guidance on tap and it takes them longer to develop confidence to break through certain problems alone.
I link to https://blog.codinghorror.com/code-reviews-just-do-it/ in the post which has an excerpt from code complete:
> … software testing alone has limited effectiveness – the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.
The quality assertions are the most defensible empirically. I wrote the post at the office away from my bookshelf which was the main thing keeping me from including them up front (flicking through my old copy of code complete now). Capers Jones' "Software Defect-Removal Efficiency" (https://ieeexplore.ieee.org/document/488361/) would be the main one on the effectiveness rate of code inspections. I've collected a few other relevant papers over at https://github.com/joho/awesome-code-review
The second two themes around education and culture come more from my personal perspective and experience - largely from running the engineering teams at Envato and 99designs respectively. My feeling is the educational and safety elements of code review have come up online a lot more over the past couple of years - but that's just my anecdotal view.
My understanding is that you can have overlap in trademarked names when it's in very different markets, but IANAL
From the title I was hoping it was a 500 page that git blames the backtrace and tells the user who specifically messed up.
Using them as a plain CI/badge system for libraries is really nice too: I'm using them on https://github.com/joho/godotenv for that and have been really happy with that.
Two thumbs up from me for the service all round.
The graph specifically? Was a Glen (founding dev) & Charlie (designer) working for a few days straight.
We need to save in session when you switch store to change what you see on a specific film page. But then I'm pretty sure we send you to a generic itunes URL per item and you're being redirected by them. Maybe.
Trying to "fix" the severe segmentation problems between the various online streaming services is one of the things we're aiming to fix with Goodfilms. It's so annoying when you want to legally rent content but first you've got to do a mission to figure out where on earth you can get it from.