3 ms·

> Rigidly defined development environments breed fragile systems. They are enticing, for often rapid onboarding of new developers. However, not having the churn

> Rigidly defined development environments breed fragile systems. They are enticing, for often rapid onboarding of new developers. However, not having the churn of letting new people onboard their setup to the system loses on an anti fragile mechanism. > This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction. > Which is not to say that a cloud environment should not be used. Just don't homogenize the setup. IMO, there is a good middle ground. I agree with you on stuff like editor/ide and base OS. But I think there can be great advantages to having everyone do development in docker/VM such that the environment matches prod.

taeric 4y ago
I think letting people do this is awesome. I think standardizing on it would be a huge mistake. In particular, I think local deployment is important. And having freedom in all local deploys leads to finding the small details that matter. Especially since you probably do not own the full prod tech stack, you are behooved by having proof that you can change it. And, by all means, make the best attempt you can. I am arguing that somewhat purposely breaking it in a regular basis with each new developer makes you more resilient if you have to do a change in prod someday. And you will, someday.
- pbalau 4y ago
  > I think letting people do this is awesome. I think standardizing on it would be a huge mistake. There is a hidden issue with not standardizing. Most people either don't care about local vs container (matching prod) development OR are terrible not equipped to make an informed choice. Thus, as a devops, I have to support both methods. This is a huge drain on my resources, especially since devopsing is just part of what I need to do. The root cause of this is the myth that all software engineers will understand source control, will understand databases, will understand how systems interact with each other and on top of it, will understand the business so they can actually do the work required. This is how you end up with "it works on my machine". This is how you end up with "but it works in repl, therefore your prod environment is broken". Standardizing doesn't mean this is the only way of doing things. It means, this is the standard way of doing things and if you get stuck, you get support. It means this is the way we consider to be most efficient of doing this stuff. You are still free to do things your way if you chose to, but if you get stuck, it's on you to get unstuck.
  - taeric 4y ago
    I don't view that as a hidden issue. I view that as the cost. And agreed that conforming to what others are doing will, by definition, get you more support. I just think there is hidden value in that diversity. It sucks, as it can't be forced/codified. I will further agree that too many will chase the "long game" of "if we support diverse environments, we will have a more robust product," at the expense of short term health. And often that is a false dichotomy, in that often the best long term choice for a team is also the best short term tradeoff. Surviving is important.

taeric 4y ago

I think letting people do this is awesome. I think standardizing on it would be a huge mistake. In particular, I think local deployment is important. And having freedom in all local deploys leads to finding the small details that matter. Especially since you probably do not own the full prod tech stack, you are behooved by having proof that you can change it. And, by all means, make the best attempt you can. I am arguing that somewhat purposely breaking it in a regular basis with each new developer makes you more resilient if you have to do a change in prod someday. And you will, someday.

pbalau 4y ago
> I think letting people do this is awesome. I think standardizing on it would be a huge mistake. There is a hidden issue with not standardizing. Most people either don't care about local vs container (matching prod) development OR are terrible not equipped to make an informed choice. Thus, as a devops, I have to support both methods. This is a huge drain on my resources, especially since devopsing is just part of what I need to do. The root cause of this is the myth that all software engineers will understand source control, will understand databases, will understand how systems interact with each other and on top of it, will understand the business so they can actually do the work required. This is how you end up with "it works on my machine". This is how you end up with "but it works in repl, therefore your prod environment is broken". Standardizing doesn't mean this is the only way of doing things. It means, this is the standard way of doing things and if you get stuck, you get support. It means this is the way we consider to be most efficient of doing this stuff. You are still free to do things your way if you chose to, but if you get stuck, it's on you to get unstuck.
- taeric 4y ago
  I don't view that as a hidden issue. I view that as the cost. And agreed that conforming to what others are doing will, by definition, get you more support. I just think there is hidden value in that diversity. It sucks, as it can't be forced/codified. I will further agree that too many will chase the "long game" of "if we support diverse environments, we will have a more robust product," at the expense of short term health. And often that is a false dichotomy, in that often the best long term choice for a team is also the best short term tradeoff. Surviving is important.