4 ms·

>people who model stormwater for a living. >They are not software engineers. These aren't programs designed around security issues, or scalability issues, main

>people who model stormwater for a living. >They are not software engineers. These aren't programs designed around security issues, or scalability issues, maintainability issues, or even following processes like pull requests. That's been the obvious problem for a while now. These are the people whom software engineers need to be cheerfully working for. Any less-effective hierarchy and they'll just have to continue making progress on their own terms.

gwbas1c 2y ago
> These are the people whom software engineers need to be cheerfully working for. Nope: We are equals with very different goals. I (a software engineer) happen to work on a product, with customers. Modeling stormwater is part of the product. Within my company, the people who do modeling are roughly equal to me. In the past, I've built products for customers where the products do not provide programming / scripting tools. > That's been the obvious problem for a while now. A script that someone runs on their desktop to achieve a narrowly-defined task, such as running a model, does not need to handle the same concerns that I, as a software engineer, need to handle. To be quite honest, it could be awful spaghetti code, but if no one else will ever touch it once the model is complete, there is no need for things like code reviews, ect.
- bob1029 2y ago
  > We are equals with very different goals. I think it would do most developers a lot of good if they were to pretend like they were a servant class to the customer & team for a period of time. They will hopefully learn that a contest of egos is not enjoyable at scale over long timeframes. A happy customer provides a much bigger dopamine rush than getting some smart-ass jab in on your coworkers. A job done right and seeing the recipient legitimately happy about what's been done for them should be the #1 goal of a person who identifies as being a fucking genius with computers. Most people suck at this and you should be helping them out, not competing with them in some bullshit heirarchy that only exists in your own head.
  - fuzzfactor 2y ago
    >pretend like they were a servant class This is what I like to do, and it really is worth putting in the effort so that you end up really liking to do it. I've been on both sides of the coin, building engineering labs for petroleum or chemical engineers who are going to spend more expert effort on the data than it took the labs to creatively collect what was needed. Then more often eventually building and adding capabilities to chemical labs where I have some leading data insight for the clients myself. Either way fresh engineers and chemists often have to really start from scratch if they want to become industrial workers, and that's going to take more than a year right there. It's the same amount of work in the lab, but the engineers' output is the product of the engineering outfit, while OTOH the data itself is the product of an analytical lab.
- fuzzfactor 2y ago
  You have some good points, sounds like you are in a well product-focused organization. Technical contributors work way better together when they are equals in key disciplines. I think when software is done right it can be a lot more organized than many other technical efforts or engineering tasks too. I also think it's a good idea to tailor the organization differently when software is the actual salable product versus when it is a component of a fairly dissimilar revenue source.

gwbas1c 2y ago

> These are the people whom software engineers need to be cheerfully working for. Nope: We are equals with very different goals. I (a software engineer) happen to work on a product, with customers. Modeling stormwater is part of the product. Within my company, the people who do modeling are roughly equal to me. In the past, I've built products for customers where the products do not provide programming / scripting tools. > That's been the obvious problem for a while now. A script that someone runs on their desktop to achieve a narrowly-defined task, such as running a model, does not need to handle the same concerns that I, as a software engineer, need to handle. To be quite honest, it could be awful spaghetti code, but if no one else will ever touch it once the model is complete, there is no need for things like code reviews, ect.

bob1029 2y ago
> We are equals with very different goals. I think it would do most developers a lot of good if they were to pretend like they were a servant class to the customer & team for a period of time. They will hopefully learn that a contest of egos is not enjoyable at scale over long timeframes. A happy customer provides a much bigger dopamine rush than getting some smart-ass jab in on your coworkers. A job done right and seeing the recipient legitimately happy about what's been done for them should be the #1 goal of a person who identifies as being a fucking genius with computers. Most people suck at this and you should be helping them out, not competing with them in some bullshit heirarchy that only exists in your own head.
- fuzzfactor 2y ago
  >pretend like they were a servant class This is what I like to do, and it really is worth putting in the effort so that you end up really liking to do it. I've been on both sides of the coin, building engineering labs for petroleum or chemical engineers who are going to spend more expert effort on the data than it took the labs to creatively collect what was needed. Then more often eventually building and adding capabilities to chemical labs where I have some leading data insight for the clients myself. Either way fresh engineers and chemists often have to really start from scratch if they want to become industrial workers, and that's going to take more than a year right there. It's the same amount of work in the lab, but the engineers' output is the product of the engineering outfit, while OTOH the data itself is the product of an analytical lab.
fuzzfactor 2y ago
You have some good points, sounds like you are in a well product-focused organization. Technical contributors work way better together when they are equals in key disciplines. I think when software is done right it can be a lot more organized than many other technical efforts or engineering tasks too. I also think it's a good idea to tailor the organization differently when software is the actual salable product versus when it is a component of a fairly dissimilar revenue source.