johnb

Yep - jest.

I can see:

> 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

It does in Australia: https://www.amberelectric.com.au/ (disclaimer: I work there)

Tangentially related but in Australia we run a household utility company that operates of that same assumption: https://www.amberelectric.com.au/

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.

A few good ones that haven't been mentioned yet:

* "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...

https://devtomanager.com/ is a good one, especially for those just making (or about to make) the transition.

Kasparov had said that all players are worse in blitz, but that Carlsen gets least worst https://twitter.com/Kasparov63/status/1067826806823297029

Post author here - logging off to go to bed because it's bedtime down under. Will pop by again in the morning.

Thanks for reading and all your comments.

I agree and trying to cover that education gap is what I'm trying to achieve with the post (and the product behind it)

I definitely overstated here sorry. Found the excerpt I was remembering in my copy of code complete "On a project that uses inspections for design and code, the inspections will take up about 10-15 percent of project budget and will typically reduce overall project cost".

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.

Those are all really good points.

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.

> For sure, it's important to keep an eye on the code review culture, though. It's easy for code review to degenerate into nitpicking small things like whitespace, naming, coding conventions - these should be handled by tools instead.

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.

There was an old Tom DeMarco article I'm a fan of: http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf

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!

That's not really true. A better formulation is that there's no way to manage programming productivity cheaply and/or non-intrusively.

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.

I'm not super across the evidence on pair programming so I'd hate to try and have a definitive answer. https://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.... suggests it's pretty good for quality and so-so for utilisation.

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.

Author here. The post is largely written from a point of personal experience and philosophy but that's the one statement I'm comfortable saying has empirical backing.

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.

Hi - author here.

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.

I can recommend Stay Awhile and Listen by David L. Craddock which tells the story of how the original Diablo was made. It's mostly told in interviews, so while it's not a single developer's story a lot of it is first hand.

I think the trademark issue should be OK.

My understanding is that you can have overlap in trademarked names when it's in very different markets, but IANAL

That is some mean-spirited internetting right there.

From the title I was hoping it was a 500 page that git blames the backtrace and tells the user who specifically messed up.

I've been using wercker to test and auto deploy a few sideproject go apps and the process has been really smooth. I'm about to switch one over to their new ssh deploy stuff and will write a blog post about it.

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.

This might seem like a strange submission, but I thought it was worth submitting for all the insights into very hardcore "user centred design"

I don't think that's true. There are plenty of threadsafe gems with C extensions, and plenty of non-threadsafe pure ruby gems that mutate class/class-instance variable willy-nilly.

The whole site? The current iteration is around a year old, things were pretty solidly overhauled when we got our first seed funding.

The graph specifically? Was a Glen (founding dev) & Charlie (designer) working for a few days straight.