5 ms·

Not guessing is perhaps the most important thing to the business. I developed a lot of my problem solving skills in semiconductor manufacturing where the cost

Not guessing is perhaps the most important thing to the business. I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve. I'll throw an entire contraption away the moment I determine it has accumulated some opacity that antagonizes root cause analysis. This is why I aggressively avoid use of non-vanilla technology stacks. You can certainly chase the rabbit over the fence into the 3rd party's GitHub repo, but I find the experience gets quite psychedelic as you transition between wildly varying project styles, motivations and scopes. Being deeply correct nearly all of the time is probably the fastest way to build a reputation. The curve can be exponential over time with the range being the value of the problem you are entrusted with.

Taek 2y ago
I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc. Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.
- jppope 2y ago
  I completely agree - though there are places where I trust an implementation of things like a well known algorithm. However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.
  - noduerme 2y ago
    Rolling your own, though, does come down to hammering in the extra nails... and hoping that whoever's doing the job knows where to put those supports in place. If you have someone who looks into the future and sees what issues might come up in a few years, then it's way cheaper than relying on frameworks. If you don't, then you're stuck with some janky software that no one else can fix. I think this is why the larger the scale, the more likely companies are to rely on frameworks which themselves are janky, but at least well understood.
  - whstl 2y ago
    The low quality of modern libraries is something that REALLY shocks me. The library space has become competitive, and people are running them as business. The goal is not to be correct or even good, but to be a "first mover" and selling tutorials, books, Github sponsorships, Patreon subscriptions... It's bad not only in terms of security, but also in terms of developer experience. I am constantly amazed at how little documentation things have, at how many BASIC cases they don't cover (let alone edge cases) and how many security holes those libraries have, and the number of dependencies just keeps getting bigger and bigger. Another issue is that newer developers are being taught just the newfangled library and have zero experience with the foundations. The number of React devs who don't know how to use HTML forms without a library is nuts.
    - GiorgioG 2y ago
      > The low quality of modern libraries is something that REALLY shocks me. How could you be shocked? Everything that's happened in the software industry outside of medical/DoD has been about delivering features as fast as you can, quality be damned.
      - whstl 2y ago
        I am shocked because this was not always the reality. I have qualified my statement with "modern".
  - tcfhgj 2y ago
- noduerme 2y ago
  This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions? Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)
  - chrisweekly 2y ago
    Moment.js is one of those libraries to avoid; the bloat....
    - aabaker99 2y ago
      I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs. Do you have a recommendation to replace Moment for that use case? I’m hopeful for the future with JavaScript Temporal.
      - microflash 2y ago
        dayjs is a similar library that I’ve used to replace Moment with minimal effort.
      - g8oz 2y ago
        A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended. https://github.com/moment/luxon/blob/master/docs/why.md https://github.com/moment/luxon/blob/master/docs/why.md
- infinghxsg 2y ago
  [dead]
- 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.
- jon-wood 2y ago
  This is very contextual. If I'm building a web application for an early stage startup which is basically a bunch of pretty CRUD views I'm absolutely using a framework for it, there's no point in hand rolling everything when the problem being solved is exactly what a framework is designed to do. If it's something safety critical, or where getting software updates out to it is going to be a problem, I'm probably going to end up hand rolling a lot more and depending on frameworks less, because I need to understand what the failure modes are and how it's going to deal with them.
- tshaddox 2y ago
  What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.
- flessner 2y ago
  I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions. Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.
- roguecoder 2y ago
  Frameworks are just someone else's architecture. They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation. On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL. I'd much rather take an outgrown-framework over a spaghetti mess.
theutopian 2y ago
Well said, well written.
skrebbel 2y ago
> This is why I aggressively avoid use of non-vanilla technology stacks I was with you until this line. I've never seen a codebase where Not Invented Here Syndrome resulted in a stack that "antagonizes root cause analysis" in any way. I once worked at a C++ shop that had NIH'ed a supposedly thread safe string class, and it wasn't pretty. There's plenty mature robust tech out there, and the chance that your own inventions are equally free of quirks and edge cases as battle-tested frameworks/libraries/databases that have had 1000s of eyeballs on them sounds quite unlikely to me, regardless of your programming skill.
- rcxdude 2y ago
  I think you may have misread, they are saying they will try to stay on something as common and boring as possible, as opposed to NIH.
sitkack 2y ago
You ultimately own all of your dependencies, even if you never look at them. Back in the 90s and early 2000s, when starting a new project I'd do a couple things. 1) look for all the problems we were going to need to solve and look for 3rd party libs that solve those problems 2) I would do a set of PoC using just that 3rd party library and see what the dev experience as like. I build it from source, read the code, look at the code hygiene, etc. 3) Everything would get checked in as source into our repo, a "full build" would build the 3rd party libraries, you would get source level debugging into everything. You could make invasive changes into libs as part of development, etc. Every dependency had to earn its place, you didn't just pull in a bunch of things because you needed one function. When you need this capability is at the exact wrong time for your build and dev process to be able to take on this work. People are panicking, shits broken, no one knows what is going on. If you have everything lined up, you can still do solid engineering using the scientific method, fix your problem and move on.
sevensor 2y ago
Ooh, I was in semiconductor manufacturing too! As a junior ion implant engineer, I was looking into yield problems. Some of the tests were flaky and I traced the issue back to one of the transistors not delivering enough current. Great, we know how to fix that! More arsenic! I proposed a small scale experiment, those wafers tested great, and we started rolling out the process change. Those wafers tested great too. Until we got word back from packaging post test. Every single die failed for excessive current draw. Several hundreds of thousands of dollars worth of scrap. I was correct, but I wasn’t deeply correct. What surprises me in retrospect is that everybody signed off on this. It’s not like we didn’t have processes, I just somehow managed to talk a bunch of people who should have known better into doing it anyway.

Taek 2y ago

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc. Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.

jppope 2y ago
I completely agree - though there are places where I trust an implementation of things like a well known algorithm. However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.
- noduerme 2y ago
  Rolling your own, though, does come down to hammering in the extra nails... and hoping that whoever's doing the job knows where to put those supports in place. If you have someone who looks into the future and sees what issues might come up in a few years, then it's way cheaper than relying on frameworks. If you don't, then you're stuck with some janky software that no one else can fix. I think this is why the larger the scale, the more likely companies are to rely on frameworks which themselves are janky, but at least well understood.
- whstl 2y ago
  The low quality of modern libraries is something that REALLY shocks me. The library space has become competitive, and people are running them as business. The goal is not to be correct or even good, but to be a "first mover" and selling tutorials, books, Github sponsorships, Patreon subscriptions... It's bad not only in terms of security, but also in terms of developer experience. I am constantly amazed at how little documentation things have, at how many BASIC cases they don't cover (let alone edge cases) and how many security holes those libraries have, and the number of dependencies just keeps getting bigger and bigger. Another issue is that newer developers are being taught just the newfangled library and have zero experience with the foundations. The number of React devs who don't know how to use HTML forms without a library is nuts.
  - GiorgioG 2y ago
    > The low quality of modern libraries is something that REALLY shocks me. How could you be shocked? Everything that's happened in the software industry outside of medical/DoD has been about delivering features as fast as you can, quality be damned.
    - whstl 2y ago
      I am shocked because this was not always the reality. I have qualified my statement with "modern".
- tcfhgj 2y ago
noduerme 2y ago
This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions? Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)
- chrisweekly 2y ago
  Moment.js is one of those libraries to avoid; the bloat....
  - aabaker99 2y ago
    I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs. Do you have a recommendation to replace Moment for that use case? I’m hopeful for the future with JavaScript Temporal.
    - microflash 2y ago
      dayjs is a similar library that I’ve used to replace Moment with minimal effort.
    - g8oz 2y ago
      A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended. https://github.com/moment/luxon/blob/master/docs/why.md https://github.com/moment/luxon/blob/master/docs/why.md
infinghxsg 2y ago
[dead]
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.
jon-wood 2y ago
This is very contextual. If I'm building a web application for an early stage startup which is basically a bunch of pretty CRUD views I'm absolutely using a framework for it, there's no point in hand rolling everything when the problem being solved is exactly what a framework is designed to do. If it's something safety critical, or where getting software updates out to it is going to be a problem, I'm probably going to end up hand rolling a lot more and depending on frameworks less, because I need to understand what the failure modes are and how it's going to deal with them.
tshaddox 2y ago
What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.
flessner 2y ago
I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions. Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.
roguecoder 2y ago
Frameworks are just someone else's architecture. They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation. On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL. I'd much rather take an outgrown-framework over a spaghetti mess.

theutopian 2y ago

Well said, well written.

skrebbel 2y ago

> This is why I aggressively avoid use of non-vanilla technology stacks I was with you until this line. I've never seen a codebase where Not Invented Here Syndrome resulted in a stack that "antagonizes root cause analysis" in any way. I once worked at a C++ shop that had NIH'ed a supposedly thread safe string class, and it wasn't pretty. There's plenty mature robust tech out there, and the chance that your own inventions are equally free of quirks and edge cases as battle-tested frameworks/libraries/databases that have had 1000s of eyeballs on them sounds quite unlikely to me, regardless of your programming skill.

rcxdude 2y ago
I think you may have misread, they are saying they will try to stay on something as common and boring as possible, as opposed to NIH.

sitkack 2y ago

You ultimately own all of your dependencies, even if you never look at them. Back in the 90s and early 2000s, when starting a new project I'd do a couple things. 1) look for all the problems we were going to need to solve and look for 3rd party libs that solve those problems 2) I would do a set of PoC using just that 3rd party library and see what the dev experience as like. I build it from source, read the code, look at the code hygiene, etc. 3) Everything would get checked in as source into our repo, a "full build" would build the 3rd party libraries, you would get source level debugging into everything. You could make invasive changes into libs as part of development, etc. Every dependency had to earn its place, you didn't just pull in a bunch of things because you needed one function. When you need this capability is at the exact wrong time for your build and dev process to be able to take on this work. People are panicking, shits broken, no one knows what is going on. If you have everything lined up, you can still do solid engineering using the scientific method, fix your problem and move on.

sevensor 2y ago

Ooh, I was in semiconductor manufacturing too! As a junior ion implant engineer, I was looking into yield problems. Some of the tests were flaky and I traced the issue back to one of the transistors not delivering enough current. Great, we know how to fix that! More arsenic! I proposed a small scale experiment, those wafers tested great, and we started rolling out the process change. Those wafers tested great too. Until we got word back from packaging post test. Every single die failed for excessive current draw. Several hundreds of thousands of dollars worth of scrap. I was correct, but I wasn’t deeply correct. What surprises me in retrospect is that everybody signed off on this. It’s not like we didn’t have processes, I just somehow managed to talk a bunch of people who should have known better into doing it anyway.