HN user

johnb

897 karma

Founder/CEO https://hecate.co/ Former VP Eng 99designs & Eng Manager Envato

Posts19
Comments63
View on HN
99designs.com 10y ago

Book Club for Tech Leads

johnb
17pts0
99designs.com 11y ago

Giving Our Beanstalkd Queue a Unix Interface With Go

johnb
18pts0
jrb.tumblr.com 13y ago

Django Forms in Rails

johnb
5pts0
thiskindofagility.com 13y ago

Show HN: We built a random Arrested Development episode chooser

johnb
4pts0
jrb.tumblr.com 13y ago

Git pull --rebase until it hurts

johnb
156pts67
v-e-n-u-e.com 13y ago

Mountain Lab: An Interview With Scott McGuire

johnb
1pts1
wds12.charliegleason.com 13y ago

You are a developer, the Internet is your friend. (web dev howto for designers)

johnb
6pts1
goodfil.ms 13y ago

Show HN: All films for rental on iTunes (in 61 stores) by price/popularity/genre

johnb
44pts27
goodfil.ms 13y ago

The Minimum Viable Rails Stack, Now Reddit Frontpage Approved

johnb
136pts41
jrb.tumblr.com 13y ago

Scaling Rails talk at Melbourne Ruby Meetup

johnb
4pts0
uptodateapp.com 13y ago

Uptodateapp: service to help stay on top of the rubygems your app depends on

johnb
7pts2
goodfil.ms 13y ago

Goodfilms Goes Mobile

johnb
108pts38
agilebench.com 14y ago

Agile Bloggers You Should Be Reading

johnb
3pts1
goodfil.ms 14y ago

Netflix Quietly Smothers 3rd Party App Ecosystem

johnb
213pts88
blog.goodfil.ms 14y ago

Comparing quality of films in the iTunes & Netflix libraries

johnb
79pts37
blog.goodfil.ms 14y ago

Comparing taste in films using pairwise vector comparisons

johnb
37pts16
www.slideshare.net 15y ago

Envato + Dev Ops

johnb
4pts0
www.slideshare.net 16y ago

Lean Manufacturing and Thought Experiments (Ingite Presentation Slides)

johnb
3pts0
blogactionday.org 17y ago

Blog Action Day - our startup's NFP side project

johnb
5pts1

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.

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.