Well, I have kids. One can dream though.

Babysitters. Slumber parties. Summer camp for the kids. Ship them to relatives for a day with their cousins (and make sure to reciprocate).

They're practically going to be few and far between, but taking a day for yourself (or for just you & your spouse) while they're still young doesn't have to be a dream!

[Disclaimer: Post may not apply if they're still babies. If so, then yeah, you're screwed. ;-) ]

This is why I'am not sure if I want kids.

Aye. It's nice when they start going to school, a few hours of quiet in the middle of the day. :)

Kids like breakfast.

I always thought of production ready to be stable, of all things. Feature complete is not a part of it.

Basically, if you can live with the shortcomings a release has (bugs, performance, lack of features) you can use it in production as long as it's stable (and secure).

I wouldn't consider pegging a CPU until restart to be 'stable'.

This bug's been driving us mad because we can't reliably repro it on our machines at Docker, and it only happens to a small subset of users, but is very annoying when it goes trigger. It seems to be related to the OSX version involved, but there's not enough bug reports to reliably hone in on it.

The other aspect that it may be is a long-running Docker.app -- since as developers we are frequently killing and restarting the application, it could happen after a period of time. I've now got two laptops that I work on, and one of them has no Homebrew or developer tools installed outside of containers, and runs the stable version of Docker.app that's just been released. If this can trigger the bug, we will hunt it down and fix it :-) In the meanwhile, if anyone can trigger it and get a backtrace of the com.docker process, that would be most helpful. Bug reports can go on https://github.com/docker/for-mac/issues

But this release aside, I was more commenting on the whole concept of production ready.

True. So that gives us one issue then?

"Aside from that Mrs Lincoln, how was the play?"

Most of the comments I've read here assumes these two things are equal:

1. A good programmer 2. A good team member

They are not.

How to spot someone that fits in your team is much harder than to spot someone with talent.

Also, as someone pointed out you need to keep track of both hits and misses to assess your skill. I would guess it's easier to track someone if they're successful as opposed to someone who either is not successful or not successful publicly.