4 ms·

People underestimate how much of software engineering is subjective touchy feely decisions. But really it's just a nature of being in a field with so many possi

People underestimate how much of software engineering is subjective touchy feely decisions. But really it's just a nature of being in a field with so many possible options and so few hard constraints. You can write your web app/cli in Java, Go, Rust, JavaScript, Ruby, Python, etc, each of them with reasonable justifications. You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. You can use Postgres, Mongo, SQLite, MySQL, etc. Is there any actual evidence that one stack is better than another? No, not really. It's ultimately up to what your brain decides it likes, and then it fills in the arguments post-facto. It's just that software engineers like to pretend they're fully rational beings and don't go off of subjective reasons like the rest of society.

bicx 1y ago
I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit. That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)
- bluGill 1y ago
  there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.
- lucyjojo 1y ago
  there are definite differences but in most cases we do not have the ability to make an actual rational choice (verging between a lack of hard numbers and an inability to predict the future). so in fine it's touchy-feely.
  - deleted 1y ago
    [deleted]
- monksy 1y ago
  I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small. You could always target scala/akka engineers with it. Theres a lot of crossover there.
uwagar 1y ago
u forgot TCL, i write web apps in TCL and Apache/Rivet :)
nasretdinov 1y ago
I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.
- askonomm 1y ago
  Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector https://github.com/rectorphp/rector).
  - nh2 1y ago
    > types and runtime type validation This is what "dynamic typing" means. In other languages, you know that the types are right /before/ you run the code.
    - askonomm 1y ago
      Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.php https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.
- vinceguidry 1y ago
  I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.
carlmr 1y ago
>It's just that software engineers like to pretend they're fully rational beings So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit. IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.
pacifika 1y ago
Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”. Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.
layoric 1y ago
> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).
- lawn 1y ago
  It's quite telling that running on a regular server isn't in the list.
- makeitdouble 1y ago
  TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet. Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.
  - MaKey 1y ago
    > Running an on-premise cluster [...] You don't need a cluster for most things. A simple server managed with Ansible playbooks will take you quite far.
simonask 1y ago
Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making. It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development. This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.
- bonoboTP 1y ago
  I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.
- worik 1y ago
  > building bridges or constructing dams. Discuss your ideas with a civil engineer You'd be surprised how similar our professions are Our shoddy work is our fault, we know how to do better, we don't We are like civil engineering in 1850
tonyedgecombe 1y ago
There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.
strken 1y ago
> Is there any actual evidence that one stack is better than another? No, not really. It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file. Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.

bicx 1y ago

I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit. That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)

bluGill 1y ago
there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.
lucyjojo 1y ago
there are definite differences but in most cases we do not have the ability to make an actual rational choice (verging between a lack of hard numbers and an inability to predict the future). so in fine it's touchy-feely.
- deleted 1y ago
  [deleted]
monksy 1y ago
I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small. You could always target scala/akka engineers with it. Theres a lot of crossover there.

uwagar 1y ago

u forgot TCL, i write web apps in TCL and Apache/Rivet :)

nasretdinov 1y ago

I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.

askonomm 1y ago
Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector https://github.com/rectorphp/rector).
- nh2 1y ago
  > types and runtime type validation This is what "dynamic typing" means. In other languages, you know that the types are right /before/ you run the code.
  - askonomm 1y ago
    Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.php https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.
vinceguidry 1y ago
I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.

carlmr 1y ago

>It's just that software engineers like to pretend they're fully rational beings So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit. IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.

pacifika 1y ago

Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”. Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.

layoric 1y ago

> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).

lawn 1y ago
It's quite telling that running on a regular server isn't in the list.
makeitdouble 1y ago
TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet. Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.
- MaKey 1y ago
  > Running an on-premise cluster [...] You don't need a cluster for most things. A simple server managed with Ansible playbooks will take you quite far.

simonask 1y ago

Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making. It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development. This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.

bonoboTP 1y ago
I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.
worik 1y ago
> building bridges or constructing dams. Discuss your ideas with a civil engineer You'd be surprised how similar our professions are Our shoddy work is our fault, we know how to do better, we don't We are like civil engineering in 1850

tonyedgecombe 1y ago

There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.

strken 1y ago

> Is there any actual evidence that one stack is better than another? No, not really. It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file. Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.