5 ms·

This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these com

by pc86 2y ago

This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance. The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/company succeeds. The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time.

deleted 2y ago
[deleted]
ryandrake 2y ago
I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something would rub off, and there would not be so much casual yolo carelessness in the "normal" software world.
- tacitusarc 2y ago
  On the other hand, do I want careless devs working in those industries?
  - ryandrake 2y ago
    I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned. We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...
  - rcxdude 2y ago
    From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.
- jandrewrogers 2y ago
  Anecdotally, working on mission-critical always-on systems when I was a junior developer was influential on the development of good habits when writing code that have carried through in contexts where such code quality was not required. In my view I benefited greatly from this exposure early in my career. A lot of it is pretty basic: checking every single return code, testing every single branch, verifying that the external environment is doing what it claims or should be doing. All of this is muscle memory now, I find it difficult to write a throwaway python script without doing this. I also don’t feel like the degree of thoroughness I put into it significantly slows down development either compared to other developers that YOLO it a bit more; I spend a bit more time writing it, they spend a bit more time debugging it in test. And in prod, the former approach has lower defect rates. It doesn’t need to be safety critical embedded software, which has a somewhat niche set of problems. Even fairly high-level data infrastructure has many of these same challenges.
  - j45 2y ago
    It seems like languages like Go promote this kind of development innately. I'm relatively new to it but found that much interesting about it.
- hiAndrewQuinn 2y ago
  I'm not averse to working on safety critical stuff in a vacuum but if they expect me to do safety critical stuff at the same pace I do my very non-safety critical stuff I'm going to expect a significant salary premium, probably at least 1.5x up from what I'm making currently. I need to charge more if I'm going to be directly responsible for the loss of lives, because sooner or later I'm going to start losing sleep over it.
9rx 2y ago
> The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time. I once unfortunately joined a project where an off-the-shelf ORM had been selected, but when development was well into the deep edge cases started to reveal serious design flaws in the ORM library. A guy wanting (perhaps not a in a joyful sense, but more not seeing any other choice) to build his own ORM that was mostly API-compatible was what saved the project. This was a long time ago. The state of ORM libraries is probably a lot better today. But the advice of ensuring that a library is SQLite-grade before committing to it does rings true even for simple CRUD ORMs. Perhaps especially so.
- diggan 2y ago
  I think both makes sense, different times/contexts require different solutions. Maybe when the project started, the idea was loosely defined, so being able to change large parts quickly are favored over ideal performance. But as the idea and project cements itself, you start to see exactly where the biggest flaws are, and you might draw the conclusion that a lot of problems could be fixed at the ORM layer, so you opt for working on that. Maybe it would have been obvious from the beginning, but chances are the people working on the codebase initially had a very different idea of what exactly is the ideal design, compared to later on in the lifetime of the project.
- pc86 2y ago
  The problem is that for every example like yours where you run into very specific ORM edge cases, and seems completely reasonable, there are about 95 where a story like this is used as justification to spend months building something when a library would have actually worked out just fine and been implemented in weeks or days. And that running into these edge cases is used as justification for "throw the ORM out" not "don't use the ORM for this particular class of query." One of my favorite features of Entity Framework from my .NET days is that it's very easy to just break out of the ORM functionality, even from within an EF-specific function, or to have multiple instances with slightly different configuration (I never had to do that last bit but I know it was possible a decade ago).
  - 2y ago
deleted 2y ago
[deleted]

by pc86 2y ago

deleted 2y ago

[deleted]

ryandrake 2y ago

I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something would rub off, and there would not be so much casual yolo carelessness in the "normal" software world.

tacitusarc 2y ago
On the other hand, do I want careless devs working in those industries?
- ryandrake 2y ago
  I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned. We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...
- rcxdude 2y ago
  From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.
jandrewrogers 2y ago
Anecdotally, working on mission-critical always-on systems when I was a junior developer was influential on the development of good habits when writing code that have carried through in contexts where such code quality was not required. In my view I benefited greatly from this exposure early in my career. A lot of it is pretty basic: checking every single return code, testing every single branch, verifying that the external environment is doing what it claims or should be doing. All of this is muscle memory now, I find it difficult to write a throwaway python script without doing this. I also don’t feel like the degree of thoroughness I put into it significantly slows down development either compared to other developers that YOLO it a bit more; I spend a bit more time writing it, they spend a bit more time debugging it in test. And in prod, the former approach has lower defect rates. It doesn’t need to be safety critical embedded software, which has a somewhat niche set of problems. Even fairly high-level data infrastructure has many of these same challenges.
- j45 2y ago
  It seems like languages like Go promote this kind of development innately. I'm relatively new to it but found that much interesting about it.
hiAndrewQuinn 2y ago
I'm not averse to working on safety critical stuff in a vacuum but if they expect me to do safety critical stuff at the same pace I do my very non-safety critical stuff I'm going to expect a significant salary premium, probably at least 1.5x up from what I'm making currently. I need to charge more if I'm going to be directly responsible for the loss of lives, because sooner or later I'm going to start losing sleep over it.

9rx 2y ago

> The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time. I once unfortunately joined a project where an off-the-shelf ORM had been selected, but when development was well into the deep edge cases started to reveal serious design flaws in the ORM library. A guy wanting (perhaps not a in a joyful sense, but more not seeing any other choice) to build his own ORM that was mostly API-compatible was what saved the project. This was a long time ago. The state of ORM libraries is probably a lot better today. But the advice of ensuring that a library is SQLite-grade before committing to it does rings true even for simple CRUD ORMs. Perhaps especially so.

diggan 2y ago
I think both makes sense, different times/contexts require different solutions. Maybe when the project started, the idea was loosely defined, so being able to change large parts quickly are favored over ideal performance. But as the idea and project cements itself, you start to see exactly where the biggest flaws are, and you might draw the conclusion that a lot of problems could be fixed at the ORM layer, so you opt for working on that. Maybe it would have been obvious from the beginning, but chances are the people working on the codebase initially had a very different idea of what exactly is the ideal design, compared to later on in the lifetime of the project.
pc86 2y ago
The problem is that for every example like yours where you run into very specific ORM edge cases, and seems completely reasonable, there are about 95 where a story like this is used as justification to spend months building something when a library would have actually worked out just fine and been implemented in weeks or days. And that running into these edge cases is used as justification for "throw the ORM out" not "don't use the ORM for this particular class of query." One of my favorite features of Entity Framework from my .NET days is that it's very easy to just break out of the ORM functionality, even from within an EF-specific function, or to have multiple instances with slightly different configuration (I never had to do that last bit but I know it was possible a decade ago).
- 2y ago

deleted 2y ago

[deleted]