4 ms·

I don't quite understand why we need to invent an new word for it? There are people who program and optimize all day and write clever one-liners and create libr

by npstr 6y ago

I don't quite understand why we need to invent an new word for it? There are people who program and optimize all day and write clever one-liners and create libraries and frameworks only they understand (programmers), and people who collaborate & have a holistic view on software development, and as a result actually get stuff done in a solid way (engineers). Yes, you can tell what I think about this article (and the one before it). If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. I don't see the author of this article writing their own OS from scratch, so why stop there? Why should all the auxiliary libs and frameworks be created from scratch? Because they don't like all the communities around the existing ones?[0] If everyone around you is the problem...maybe its you who is the problem. I've never had any pull requests with fixes or minor features rejected from upstream, so my view may be biased. I prefer hiring and working with people who understand the value of contributing to OSS instead of building their own little castles. [0] http://rachelbythebay.com/w/2018/10/09/moat/ http://rachelbythebay.com/w/2018/10/09/moat/

wongarsu 6y ago
>If your goal is to ship a product, there is no reason to reinvent anything that is not your core business As long as the priorities of your product align with the priorities of the library. If the product you're trying to ship is a critical control system and the only relevant libraries are written with a webdev approach of "move fast and occasionally crash" you might be done much quicker if you write your own version.
- npstr 6y ago
  Agreed! If your priorities are e.g. high reliability, it is a good idea to vet any potential software that you are planning to use, and maybe it will have to be written from scratch if existing solutions are found to be outside of the expected specs. But even with such a product, you will have other pieces and parts: think about collecting metrics, marketing tools maybe, obscure internal admin UIs...selecting software for that probably does not need to be evaluated under the same extreme scrutiny as the "critical control software".
  - hansvm 6y ago
    I mean...maybe...so long as the critical software is sufficiently isolated from anything not appropriately vetted. If the untrusted software shares _any_ hardware with your critical system you're setting yourself up for a bad time.
joefourier 6y ago
I think you hit the nail on its head. There's also the fact that there's no hard line between the "vendor-ops" and the "real programmers". Rather, it's a continuum, and one crucial skill is knowing when to use someone else's tools and when to write your own. And when you do, the experience of having used external libraries and frameworks can be very useful. Otherwise if you want to write everything from scratch, you can always write embedded firmware for 8-bit MCUs. It better be in assembly, because otherwise you're just doing "vendor-ops" with a external IDE and some company's compiler. Although technically, you're doing "vendor-ops" for a chip made by someone else, so maybe you should make your own soft core in VHDL and use an FPGA... At some point either you'll be making your own transistors because that's the only way to be a Real Engineer, or you'll accept that there's no problem depending on external vendors as long as you understand how to use the tools you have.
rtlfe 6y ago
> If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. It's certainly not that clear cut because most of the largest tech companies primarily ship products but also have invented their own programming languages.
lioeters 6y ago
Couldn't one argue that most open-source projects are born as someone's "own little castle"? If people didn't build their own little castles, we wouldn't have, for example, UNIX. I agree about hiring and working with people ("engineers") who take full advantage of existing tools and libraries; and can contribute to well-documented and battle-tested libraries in the community. But, as someone who (also) fits the description of a "programmer", I see the value in building our own little castles for fun and profit, to create libraries and frameworks for our own purposes. If existing solutions don't quite do the job, someone has to start these well-documented and battle-tested libraries to benefit the community - even if "only they can understand" it at the beginning. Perhaps the contrast and tension between these approaches are about the inherent risk of innovation. In a team environment, we don't want people inventing their own language or operating system from scratch - unless it directly contributes to the core business, which is rarely the case. For the largest tech companies, they can afford to risk the investment into innovation, to develop and maintain their own languages, frameworks, and libraries - if they bring competitive advantages. This caveat is often unclear though, whether this (re)invented thing actually delivers.
- npstr 6y ago
  Absolutely. Doing the right calls here is very hard, and takes a lot of experience. Btw - I'm not against building your own castles (I love doing that, esp. in my free time) - I am just a bit triggered by the previous blog post arguing unconditionally for it, and now the next one even saying these are two (or even more) different professions. I don't think that is the case. I think we need to understand the contexts, to know when each of the approaches is a likely better fit. Sometimes its very clear, and sometimes you won't know until much later. That's ok. I think it is important to document why a route was chosen, and evaluate if it is still the correct one, once more facts are available, or the environment changes. What I really don't like seeing is ranting about a chosen approach, without informing oneself first about how the decision was reached, and broad generalisations. Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context. I'd love to see an article from the author drawing from their experience on making that kind of decisions.
TeMPOraL 6y ago
> and people who collaborate & have a holistic view on software development, and as a result actually get stuff done in a solid way (engineers). Part of "holistic view on software" is recognizing how much garbage and reinventing the wheel there is out thee. Part of being an engineer is recognizing trade-offs: dependencies come with costs of their own, so it only makes sense to use them if you expect to get more from them than you're going to pay for them. And pay you will - dependencies have to be understood, managed, upgraded and deployed. Rachel writes from the POV of reliability engineering; in her story, her problem is as much with a shitty dependency being used as with in-house people who consider vetting their dependencies and collaborating with dependency vendors to be outside their job description. But both are, in fact, a part of good engineering, and are a part of the price you should be paying when you link against a third-party library.

by npstr 6y ago

wongarsu 6y ago

>If your goal is to ship a product, there is no reason to reinvent anything that is not your core business As long as the priorities of your product align with the priorities of the library. If the product you're trying to ship is a critical control system and the only relevant libraries are written with a webdev approach of "move fast and occasionally crash" you might be done much quicker if you write your own version.

npstr 6y ago
Agreed! If your priorities are e.g. high reliability, it is a good idea to vet any potential software that you are planning to use, and maybe it will have to be written from scratch if existing solutions are found to be outside of the expected specs. But even with such a product, you will have other pieces and parts: think about collecting metrics, marketing tools maybe, obscure internal admin UIs...selecting software for that probably does not need to be evaluated under the same extreme scrutiny as the "critical control software".
- hansvm 6y ago
  I mean...maybe...so long as the critical software is sufficiently isolated from anything not appropriately vetted. If the untrusted software shares _any_ hardware with your critical system you're setting yourself up for a bad time.

joefourier 6y ago

I think you hit the nail on its head. There's also the fact that there's no hard line between the "vendor-ops" and the "real programmers". Rather, it's a continuum, and one crucial skill is knowing when to use someone else's tools and when to write your own. And when you do, the experience of having used external libraries and frameworks can be very useful. Otherwise if you want to write everything from scratch, you can always write embedded firmware for 8-bit MCUs. It better be in assembly, because otherwise you're just doing "vendor-ops" with a external IDE and some company's compiler. Although technically, you're doing "vendor-ops" for a chip made by someone else, so maybe you should make your own soft core in VHDL and use an FPGA... At some point either you'll be making your own transistors because that's the only way to be a Real Engineer, or you'll accept that there's no problem depending on external vendors as long as you understand how to use the tools you have.

rtlfe 6y ago

> If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. It's certainly not that clear cut because most of the largest tech companies primarily ship products but also have invented their own programming languages.

lioeters 6y ago

Couldn't one argue that most open-source projects are born as someone's "own little castle"? If people didn't build their own little castles, we wouldn't have, for example, UNIX. I agree about hiring and working with people ("engineers") who take full advantage of existing tools and libraries; and can contribute to well-documented and battle-tested libraries in the community. But, as someone who (also) fits the description of a "programmer", I see the value in building our own little castles for fun and profit, to create libraries and frameworks for our own purposes. If existing solutions don't quite do the job, someone has to start these well-documented and battle-tested libraries to benefit the community - even if "only they can understand" it at the beginning. Perhaps the contrast and tension between these approaches are about the inherent risk of innovation. In a team environment, we don't want people inventing their own language or operating system from scratch - unless it directly contributes to the core business, which is rarely the case. For the largest tech companies, they can afford to risk the investment into innovation, to develop and maintain their own languages, frameworks, and libraries - if they bring competitive advantages. This caveat is often unclear though, whether this (re)invented thing actually delivers.

npstr 6y ago
Absolutely. Doing the right calls here is very hard, and takes a lot of experience. Btw - I'm not against building your own castles (I love doing that, esp. in my free time) - I am just a bit triggered by the previous blog post arguing unconditionally for it, and now the next one even saying these are two (or even more) different professions. I don't think that is the case. I think we need to understand the contexts, to know when each of the approaches is a likely better fit. Sometimes its very clear, and sometimes you won't know until much later. That's ok. I think it is important to document why a route was chosen, and evaluate if it is still the correct one, once more facts are available, or the environment changes. What I really don't like seeing is ranting about a chosen approach, without informing oneself first about how the decision was reached, and broad generalisations. Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context. I'd love to see an article from the author drawing from their experience on making that kind of decisions.

TeMPOraL 6y ago

> and people who collaborate & have a holistic view on software development, and as a result actually get stuff done in a solid way (engineers). Part of "holistic view on software" is recognizing how much garbage and reinventing the wheel there is out thee. Part of being an engineer is recognizing trade-offs: dependencies come with costs of their own, so it only makes sense to use them if you expect to get more from them than you're going to pay for them. And pay you will - dependencies have to be understood, managed, upgraded and deployed. Rachel writes from the POV of reliability engineering; in her story, her problem is as much with a shitty dependency being used as with in-house people who consider vetting their dependencies and collaborating with dependency vendors to be outside their job description. But both are, in fact, a part of good engineering, and are a part of the price you should be paying when you link against a third-party library.