johnb

Joined 19 years ago

Karma

897

Submissions

Member since

May 31

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

View on Hacker News

Recent submissions

Comment · 5 years ago

Yep - jest.

Comment · 5 years ago

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

Comment · 6 years ago

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

Comment · 6 years ago

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.

Comment · 6 years ago

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

Comment · 7 years ago

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

Comment · 8 years ago

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

Comment · 8 years ago

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.

Comment · 8 years ago

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

Comment · 8 years ago

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.

Comment · 8 years ago

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.

Comment · 8 years ago

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

Comment · 8 years ago

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!

Comment · 8 years ago

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.

Comment · 8 years ago

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.