6 ms·

The problem we solve by religiously sticking to "best practice" is the extreme engineering churn in "Silicon Valley" companies. Not spending 9 months on-boardi

The problem we solve by religiously sticking to "best practice" is the extreme engineering churn in "Silicon Valley" companies. Not spending 9 months on-boarding might be worth extra minutes on deployment, IDK...

HelloNurse 6y ago
On the other hand, after 9 months on-boarding an engineer is likely to operate much more productively than the "best practice" would allow. Even more importantly, the engineer is likely to stick with a truly high tech workplace with much less "churn" than in yet another dime a dozen startup with the same fashionable tech stack as the slightly better competition.
- jiofih 6y ago
  Or dig deeper and deeper into a rabbit hole, and come out almost unemployable 7 years later while the entire industry has moved on.
winrid 6y ago
You don't have to have crazy on boarding. In fact, with systems like Kubernetes it can take me months to finally grasp the whole system... especially if you have your own Kubernetes Operator and custom YAML configuration that maps to Kube's... which I have seen. You can use Fargate for example, which should give you easy to manage and fast deployment times - you just have to figure out the fast build time. For FastComments.com I can do a build in under two minutes. The second you merge to master: 1. E2E testing runs, which is massively parallelized. Each test suite's data gets namespaced so they don't step on each other. 2. The build runs, takes 30 seconds, because it's not a compiled language. Although if it was in Java I don't think it would take very long. 3. Deployment happens, Orcha sends the bundle to all the servers, stops the deamon, extracts it, restarts the systemd daemon. 4. E2E testing runs again against production as a smoke test. This all happens in under a couple minutes. Not a very small app - package.json has 50 dependencies and the E2E test suite has ~40 tests. These tests are complicated - some will open two browsers for example to test the live commenting features...
toast0 6y ago
Deploying faster means you can onboard faster, because part of onboarding is deploying. Deploying faster means you can onboard faster, because you get quicker feedback on your changes, getting insight into code and systems faster. Deploying faster means you can onboard faster, because you have fewer (ideally just one) pending changes to deploy to keep in your mind while working, increasing the amount of changes you can make in a work week. Deploying faster means you can onboard faster, because you spend less time deploying and more time studying the system.

HelloNurse 6y ago

On the other hand, after 9 months on-boarding an engineer is likely to operate much more productively than the "best practice" would allow. Even more importantly, the engineer is likely to stick with a truly high tech workplace with much less "churn" than in yet another dime a dozen startup with the same fashionable tech stack as the slightly better competition.

jiofih 6y ago
Or dig deeper and deeper into a rabbit hole, and come out almost unemployable 7 years later while the entire industry has moved on.

winrid 6y ago

You don't have to have crazy on boarding. In fact, with systems like Kubernetes it can take me months to finally grasp the whole system... especially if you have your own Kubernetes Operator and custom YAML configuration that maps to Kube's... which I have seen. You can use Fargate for example, which should give you easy to manage and fast deployment times - you just have to figure out the fast build time. For FastComments.com I can do a build in under two minutes. The second you merge to master: 1. E2E testing runs, which is massively parallelized. Each test suite's data gets namespaced so they don't step on each other. 2. The build runs, takes 30 seconds, because it's not a compiled language. Although if it was in Java I don't think it would take very long. 3. Deployment happens, Orcha sends the bundle to all the servers, stops the deamon, extracts it, restarts the systemd daemon. 4. E2E testing runs again against production as a smoke test. This all happens in under a couple minutes. Not a very small app - package.json has 50 dependencies and the E2E test suite has ~40 tests. These tests are complicated - some will open two browsers for example to test the live commenting features...

toast0 6y ago

Deploying faster means you can onboard faster, because part of onboarding is deploying. Deploying faster means you can onboard faster, because you get quicker feedback on your changes, getting insight into code and systems faster. Deploying faster means you can onboard faster, because you have fewer (ideally just one) pending changes to deploy to keep in your mind while working, increasing the amount of changes you can make in a work week. Deploying faster means you can onboard faster, because you spend less time deploying and more time studying the system.