this is kind of unproductive. The job of the manager should be to push the envelope of the team as a whole. As such if he already has a high performing team, he should be as hands off as possible, focusing on other crucial areas. If not, his job is to create small proof-of-concepts of ideas and let the team take them forward.

> One thing I can suggest that has helped me on my current project, is to do a morning standup

I've found that this is the only sane way that works if you're trying to manage a team of 15-20 people.

15-20 people is 2-3 teams in any sane organization.

:) I'm the founder. I understand what you mean. Really. Appreciate it. For the record, the photo is not of our office, it is of a hackathon. We don't have spanking fancy office actually. There are a lot of people I know who like open office culture and few who don't. Frankly that has nothing to do with having best engineers. I do have an opinion about building company culture a certain way which may not be exactly in resonance with popular opinion about it; I try to practice it but never preach. Everyone is free to pick what they think is best culture for their company and REALLY there is no such thing as the right culture.

There are some excellent suggestions and workarounds here and looks like you've been using them in production for some time. Thanks for sharing.

Please enlighten us with your professional wisdom and do point out which parts of the article are amateur.

As I said, if it is really as obvious as you say it is, please point me to a single mention in official documentation that databases should not be containerized.

Why would documentation about docker include basic fundamental knowledge about deploying services in production? This isn't docker knowledge, this is service based architecture 101. Why is it docker's responsibility to teach you general software engineering concepts?

point me to a single mention in the official docs that say EVERY service should be containerized

>> Why bother to put your database inside a container if the way you ran your databases before worked just fine?

For the same reason you'd bother putting anything in a container at all. The purpose of docker -as advertised by docker- is to containerize EVERY service. Unless you can point me to a single mention in official documentation that databases are an exception. Till date, I haven't found any and thus this blog.

>> afternoon briefing on in a meeting room and then kinda wing it on implementation

I don't know where did you get that impression from. The article clearly states we ran docker in PRODUCTION for 6 months. The article wasn't written after a docker trial over a weekend.

>> How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

Pretty much everyone who's commented here and have had docker experience in production, agrees that a docker documentation sucks. Maintainers of the dockers project have already conceded that this is an issue so I don't why you're saying this.

That you're making this claim is an almost comically ironic indicator to me that you are exactly what was described.

>> written by your typical one trick pony, technology averse client services agency.

You can be forgiven to have that perception. Sorry, but that's not true.

>> They are the last to adopt new things

Are you actually complaining about this? Well it just shows your immaturity as an engineer and your lack of understanding of how tech startups are run. This is something my very first manager drilled into me on my first job a decade ago, as should yours have - not to use any v1.0 software for ANY CLIENT PROJECT, but only for your hobby projects. Wait atleast for a v1.1

>> as they tend to be the lowest on the talent chain as meeting estimates

Please don't embarrass yourself. There are comments on this thread from the maintainers of both docker and kubernetes projects as well as people who have been running docker in production for much longer than us. None of them think that this article is stupid. Now, if you think you're more talented than us and all of them combined, just tell us why?

Your comments would be much more useful if you could say something like - "They are so stupid because they couldn't figure out X which was as easy as doing Y."

Anytime you want to go toe to toe let me know. Being cheaper and more predictable is so different from actually having to make the best possible product.