7 ms·

> "You'd be surprised how many people get turned off by seeing something that other people tell them is simple, and then it's not simple to them." This. This s

> "You'd be surprised how many people get turned off by seeing something that other people tell them is simple, and then it's not simple to them." This. This should be every platform/infrastructure engineer's motto. Don't tell me your DSL is simple. Don't tell me that Puppet is so simple because oh my god, it uses Ruby. Don't tell me that HCL or terraform or whatever yaml crap is so simple because "they are in yaml". No. They are not. Don't. Make. Me. Learn. It's not because I don't want to learn. It's because I want to learn fundamentals instead of your specific, non-generalizable, 6-month-or-less half-life stuff.

remram 4y ago
Also: if you have to tell me it's simple, rather than showing me examples that make it apparent, I assume it's not.
- wwalexander 4y ago
  I think it’s fair for a project as a whole to describe itself as “simple” as a statement of its goals (vs. e.g. “flexible”, “high-performance”, “easy-to-use”, and so on). For example, Suckless Software describes many of their Linux applications as simple, and it’s a fitting description that also encodes the spartan nature of the projects compared to their more commonly used counterparts. But outside of a README or GitHub project description, I completely agree. Simplicity is the absence of complexity, and will become in retrospect when users choose what you’ve made because you made it simple enough to do so.
  - mmcnl 4y ago
    I don't think it's fair. Simple is subjective. Goals should be objective. I don't want to know and understand the entire context in which a project was conceived.
    - wwalexander 4y ago
      Simple is subjective, which means it shouldn’t be used in contexts where accuracy and objectivity are paramount (like technical documentation). But if I’m searching for e.g. a “simple monitor hardware brightness control for Mac” without extra nice-to-have features or GUIs, a project that describes itself as “simple” gives me a useful clue that the developers might have priorities that match my needs.
- tapanjk 4y ago
  For some reason this comment played in my head in Gilfoyle's voice.
411111111111111 4y ago
None of the technologies you've named could be considered "6-month-or-less half-life stuff." Puppet in particular is ancient by tech standards and is still getting used to date.
- henrydark 4y ago
  They're being used, but less for new projects
  - deleted 4y ago
    [deleted]
- deleted 4y ago
  [deleted]
- hintymad 4y ago
  True. The shelf-life refers to how long one cares to remember the technology. The unfortunate fact is that these techs are so specific that I simply forget them weeks after I don't have to use them any more. The entire Uber engineering team had to endure the horror of writing hundreds of lines of oh-my-god-it's-so-cool-dsl Puppet for simple deployment tasks and waiting for on average 15 minutes before a change took place. Guess how many people missed Puppet when it was ripped off Uber's infra? Probably only the dude who thought Puppet and Graphite were the best systems in the world. And guess how learning the intricacies of Puppet helped anyone's career or ability to build better systems down the road? The answer is zero and zero.
xorcist 4y ago
While I understand the sentiment, I don't really get the particulars. So, instead of learning Puppet or Terraform, you want to implement one from scratch? I have that itch too, I also try to implement the basics of something like git or Ansible in my own toy system when learning it. But that's just to get some hang of why the tool looks like it does. I'm still there to use the tool. That goes double if you're working with others. I totally get the bit about wanting to learn fundamentals, but not the bit how it turns you off some higher level tool.
- g9yuayon 4y ago
  Not really. Use whatever technology that you know best, but hide unnecessary complexity through the right tools. I'm not sure about the OP, but I had extremely good experience when I was in Netflix. A single engineer, Joe Sondow, created the app Asgard. Using Asgard, I didn't need anyone to teach me how to configure clusters or networking topologies. The app got affordance, consistency, and constraints right, to the point that at any point what I guessed was either right or the only way to complete my tasks. Michael from the cloud team created command-line tools for managing AMIs. They exposed just what one needs to achieve while hiding anything about how things were done. As a result, I can still remember how to use these tools, years after I left Netflix. Similarly for doing service discovery, fault injection, load balancing, autoscaling, predictive autoscaling, logging events, publishing metrics, and the list can go on. Everything in Netflix, at least when I was there, followed the unspoken principle of making everything a non-event: zero unnecessary mental load, maximum flexibility, maximum freedom to engineers, and full transparency. Things just happened. Tools were just in place. The tools could be primitive and could lack of features, but the they did not get in my way whatsoever.
  - fivre 4y ago
    > [The AMI management tools] exposed just what one needs to achieve while hiding anything about how things were done No, they exposed just what _someone working at Netflix who produces AMIs for Netflix's infrastructure and is required to conform to assorted Netflix expectations lest they be told to go pound sand_ needs. Accepting that constraint makes the problem much easier. When you try to make a general-purpose tool, you rapidly run up against: - Some other user needs to do something that you don't, that the existing configuration surface cannot possibly account for. You now have either a tool that exposes two (and soon, three or four or five ad infinitum) means of doing thing (likely without any indication why you'd use one or the other) or a tool that exposes <original means of doing thing> and <fill in your own thing from scratch>. - Someone has other parts of their infrastructure whose design is, for lack of a better description, "fucking stupid". They don't have the power or will to change that, but they're happy to ask you to include a workaround for it in your product. They also have a number of friends whose surrounding infrastructure is similarly fucking stupid, and some of those are important contracts where sales will force your hand to build the workaround instead of asking the customer not do fucking stupid things. Yes, a single well-managed organization can delegate various pieces of complexity throughout the org and avoid having other parts worry about them. General-purpose tools do not have that complexity. The reason you have to learn new concepts and tools to learn Terraform effectively is because you're taking all the complexity of dealing with a cloud services provider and then adding an additional layer of complexity on top to augment the things you can do with the cloud provider. The value proposition is that this still better than what you'd do by hand and, crucially, something that other people who know Terraform can understand. Realistically, you can hire another engineer who's familiar with Terraform. You can't clone Matt.
bsder 4y ago
> Don't. Make. Me. Learn. It's not because I don't want to learn. I disagree. I. Don't. Want. To. Learn. Almost nothing in between me and getting my problem solved is interesting nowadays. Everything I have to learn is just another yak I have to shave in between me and getting my problem solved. This is doubly irritating when the yak is infrastructure (configuration systems, build systems, source control systems, etc.) that has zero bearing on my problem. Here was one: "We want to add audio to our phone app." GROAN. App is in Flutter on Android which implies: 1) Flutter 2) Dart 3) Gradle (dear God, help me) 4) Groovy 5) Oboe (for sound on Android) implying 6) Android NDK 7) CMake (hey Satan, I'll take your help too) 8) C++ And I'm leaving out a bunch of stuff. And there will be even more for iOS. NONE if this is interesting to me. Only 2,5 and 8 are directly applicable to my problem. Everything else is a tower of garbage that I have to chop through with a machete in order to get to the task that I actually want to solve. And, as I understand it, somehow the web and Javascript universe is worse. So, no, I don't want to learn.
- speed_spread 4y ago
  Wow, that's a truly horrible tech stack. Flutter, not even once.
  - bsder 4y ago
    Most of that isn't flutter. It's the Android tech stack. iOS isn't any better with Xcode, Swift, Cocoapods, Ruby, etc. Flutter and Dart are actually some of the more interesting things that I'm not so irritated learning.
    - ratww 4y ago
      This is a classic issue of leaky abstractions, so it is definitely "caused" by Flutter/Dart. What led to this might not be their "fault", but as it stands this is something that only Flutter/Dart can solve. It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. Same for Oboe: it could be prebuilt rather than leaving it all to you (although depending on how you're using it, it's debatable if it's Flutter/Dart's concern). The bottom part of the stack doesn't have control over the top part. Gradle can't really modify itself so that Flutter's abstraction is no longer leaky. Save for some ruling by Google/Apple/etc, the reason you need the whole stack is not because of some fundamental need, but rather because it was a choice made by the tools at the top of it.
WalterBright 4y ago
My sophomore calculus Prof, whenever he'd introduce a new concept he'd say "ees treeveeal!" It was a such a trademark that the students would keep a log in their notes of every "ees treeveeal!". (Of course, the joke was none of it was trivial.) One day, he remarked that this new concept "ees non-treeveeal". We knew we were in for it then! My jet engine Prof would lay out the boundary conditions of a problem. Then, "Und now zat vee haff zee eekvayshuns, vee merely turn zee krank!" What can I say. I enjoyed those classes very much.
- coupdejarnac 4y ago
  This gives me flashbacks to undergrad engineering courses. Nearly none of my professors, at a top 10 electrical engineering program, were able to explain things very well. Then you'd have to dive into poorly written textbooks to figure out what was going on. Kids these days have no idea how good things are with lots of youtube videos and online tutorials that give clear explanations for how things work. Even then, I noticed my old engineering program is still managing to fuck things up by doing things like using synthetic, poorly documented fictional microprocessors to teach assembly and computer architecture.
  - WalterBright 4y ago
    I have no idea why someone would want to teach with a fictional microprocessor.
    - rednab 4y ago
      [I'm well aware of who I am replying to here, I'm merely taking the bait and providing some hopefully fun links for people to dig into. :)] Because that's how Professor Wirth ¹) does it ²), because it allows for some interesting educational side-treks ³), and because the difference between a fictional and real microprocessor is smaller than some might think ⁴). ¹) https://people.inf.ethz.ch/wirth/index.html https://people.inf.ethz.ch/wirth/index.html ²) https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html https://people.inf.ethz.ch/wirth/CompilerConstruction/index.... ³) "So what instruction would you add to this CPU to make the work we've been doing easier? Great, implement that instruction in the provided emulator." ⁴) https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html (edit: And, of course, there's FPGA implementations of Professor Knuth's MMIX (http://mmix.cs.hm.edu/ http://mmix.cs.hm.edu/), too: https://github.com/tommythorn/fpgammix https://github.com/tommythorn/fpgammix)
beachy 4y ago
I think this is just a subset of the larger guide, don't brag about subjectives. Don't say your product is the best, the greatest, the simplest, the most powerful. That's marketing BS, noise. It's ok to say things that can be verified, like it's the cheapest, the fastest, the only one with yellow spots.
- progrus 4y ago
  Or, if you really do want something qualitative: “my favorite”.
- elcomet 4y ago
  Why wouldn't you say it if it helps to sell the product ? It's marketing, not science.
bonestamp2 4y ago
Everything seems simple once you're an expert at it. Experts are often the worst at teaching it for that reason.
kkukshtel 4y ago
This is such a pet peeve of mine, especially when peeking at other programming domains I don't typically work in. Seeing readme's say "Simply..." or just throw around domain terminology with 0 context immediately puts me off using the library.
_the_inflator 4y ago
I can relate. The thing is, that these "Heureka" moments stem usually from long times of frustration working within a certain domain or with a certain concept. After working with certain stuff for long periods I can find usually a way to explain it in a very easy way. However, this does not mean, that concepts are easy to grasp without putting in more time and learning all about what my abstraction kept out. It is still a hermeneutic circle.

remram 4y ago

Also: if you have to tell me it's simple, rather than showing me examples that make it apparent, I assume it's not.

wwalexander 4y ago
I think it’s fair for a project as a whole to describe itself as “simple” as a statement of its goals (vs. e.g. “flexible”, “high-performance”, “easy-to-use”, and so on). For example, Suckless Software describes many of their Linux applications as simple, and it’s a fitting description that also encodes the spartan nature of the projects compared to their more commonly used counterparts. But outside of a README or GitHub project description, I completely agree. Simplicity is the absence of complexity, and will become in retrospect when users choose what you’ve made because you made it simple enough to do so.
- mmcnl 4y ago
  I don't think it's fair. Simple is subjective. Goals should be objective. I don't want to know and understand the entire context in which a project was conceived.
  - wwalexander 4y ago
    Simple is subjective, which means it shouldn’t be used in contexts where accuracy and objectivity are paramount (like technical documentation). But if I’m searching for e.g. a “simple monitor hardware brightness control for Mac” without extra nice-to-have features or GUIs, a project that describes itself as “simple” gives me a useful clue that the developers might have priorities that match my needs.
tapanjk 4y ago
For some reason this comment played in my head in Gilfoyle's voice.

411111111111111 4y ago

None of the technologies you've named could be considered "6-month-or-less half-life stuff." Puppet in particular is ancient by tech standards and is still getting used to date.

henrydark 4y ago
They're being used, but less for new projects
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
hintymad 4y ago
True. The shelf-life refers to how long one cares to remember the technology. The unfortunate fact is that these techs are so specific that I simply forget them weeks after I don't have to use them any more. The entire Uber engineering team had to endure the horror of writing hundreds of lines of oh-my-god-it's-so-cool-dsl Puppet for simple deployment tasks and waiting for on average 15 minutes before a change took place. Guess how many people missed Puppet when it was ripped off Uber's infra? Probably only the dude who thought Puppet and Graphite were the best systems in the world. And guess how learning the intricacies of Puppet helped anyone's career or ability to build better systems down the road? The answer is zero and zero.

xorcist 4y ago

While I understand the sentiment, I don't really get the particulars. So, instead of learning Puppet or Terraform, you want to implement one from scratch? I have that itch too, I also try to implement the basics of something like git or Ansible in my own toy system when learning it. But that's just to get some hang of why the tool looks like it does. I'm still there to use the tool. That goes double if you're working with others. I totally get the bit about wanting to learn fundamentals, but not the bit how it turns you off some higher level tool.

g9yuayon 4y ago
Not really. Use whatever technology that you know best, but hide unnecessary complexity through the right tools. I'm not sure about the OP, but I had extremely good experience when I was in Netflix. A single engineer, Joe Sondow, created the app Asgard. Using Asgard, I didn't need anyone to teach me how to configure clusters or networking topologies. The app got affordance, consistency, and constraints right, to the point that at any point what I guessed was either right or the only way to complete my tasks. Michael from the cloud team created command-line tools for managing AMIs. They exposed just what one needs to achieve while hiding anything about how things were done. As a result, I can still remember how to use these tools, years after I left Netflix. Similarly for doing service discovery, fault injection, load balancing, autoscaling, predictive autoscaling, logging events, publishing metrics, and the list can go on. Everything in Netflix, at least when I was there, followed the unspoken principle of making everything a non-event: zero unnecessary mental load, maximum flexibility, maximum freedom to engineers, and full transparency. Things just happened. Tools were just in place. The tools could be primitive and could lack of features, but the they did not get in my way whatsoever.
- fivre 4y ago
  > [The AMI management tools] exposed just what one needs to achieve while hiding anything about how things were done No, they exposed just what _someone working at Netflix who produces AMIs for Netflix's infrastructure and is required to conform to assorted Netflix expectations lest they be told to go pound sand_ needs. Accepting that constraint makes the problem much easier. When you try to make a general-purpose tool, you rapidly run up against: - Some other user needs to do something that you don't, that the existing configuration surface cannot possibly account for. You now have either a tool that exposes two (and soon, three or four or five ad infinitum) means of doing thing (likely without any indication why you'd use one or the other) or a tool that exposes <original means of doing thing> and <fill in your own thing from scratch>. - Someone has other parts of their infrastructure whose design is, for lack of a better description, "fucking stupid". They don't have the power or will to change that, but they're happy to ask you to include a workaround for it in your product. They also have a number of friends whose surrounding infrastructure is similarly fucking stupid, and some of those are important contracts where sales will force your hand to build the workaround instead of asking the customer not do fucking stupid things. Yes, a single well-managed organization can delegate various pieces of complexity throughout the org and avoid having other parts worry about them. General-purpose tools do not have that complexity. The reason you have to learn new concepts and tools to learn Terraform effectively is because you're taking all the complexity of dealing with a cloud services provider and then adding an additional layer of complexity on top to augment the things you can do with the cloud provider. The value proposition is that this still better than what you'd do by hand and, crucially, something that other people who know Terraform can understand. Realistically, you can hire another engineer who's familiar with Terraform. You can't clone Matt.

bsder 4y ago

> Don't. Make. Me. Learn. It's not because I don't want to learn. I disagree. I. Don't. Want. To. Learn. Almost nothing in between me and getting my problem solved is interesting nowadays. Everything I have to learn is just another yak I have to shave in between me and getting my problem solved. This is doubly irritating when the yak is infrastructure (configuration systems, build systems, source control systems, etc.) that has zero bearing on my problem. Here was one: "We want to add audio to our phone app." GROAN. App is in Flutter on Android which implies: 1) Flutter 2) Dart 3) Gradle (dear God, help me) 4) Groovy 5) Oboe (for sound on Android) implying 6) Android NDK 7) CMake (hey Satan, I'll take your help too) 8) C++ And I'm leaving out a bunch of stuff. And there will be even more for iOS. NONE if this is interesting to me. Only 2,5 and 8 are directly applicable to my problem. Everything else is a tower of garbage that I have to chop through with a machete in order to get to the task that I actually want to solve. And, as I understand it, somehow the web and Javascript universe is worse. So, no, I don't want to learn.

speed_spread 4y ago
Wow, that's a truly horrible tech stack. Flutter, not even once.
- bsder 4y ago
  Most of that isn't flutter. It's the Android tech stack. iOS isn't any better with Xcode, Swift, Cocoapods, Ruby, etc. Flutter and Dart are actually some of the more interesting things that I'm not so irritated learning.
  - ratww 4y ago
    This is a classic issue of leaky abstractions, so it is definitely "caused" by Flutter/Dart. What led to this might not be their "fault", but as it stands this is something that only Flutter/Dart can solve. It is not strictly necessary to use Gradle/Groovy to build an Android app, so to use it was Flutter/Dart's choice. Just as it isn't necessary to use Xcode, Cocoapods or Ruby (of course, you still need either Objective-C or Swift, but only one) to make an iOS one. Same for Oboe: it could be prebuilt rather than leaving it all to you (although depending on how you're using it, it's debatable if it's Flutter/Dart's concern). The bottom part of the stack doesn't have control over the top part. Gradle can't really modify itself so that Flutter's abstraction is no longer leaky. Save for some ruling by Google/Apple/etc, the reason you need the whole stack is not because of some fundamental need, but rather because it was a choice made by the tools at the top of it.

WalterBright 4y ago

My sophomore calculus Prof, whenever he'd introduce a new concept he'd say "ees treeveeal!" It was a such a trademark that the students would keep a log in their notes of every "ees treeveeal!". (Of course, the joke was none of it was trivial.) One day, he remarked that this new concept "ees non-treeveeal". We knew we were in for it then! My jet engine Prof would lay out the boundary conditions of a problem. Then, "Und now zat vee haff zee eekvayshuns, vee merely turn zee krank!" What can I say. I enjoyed those classes very much.

coupdejarnac 4y ago
This gives me flashbacks to undergrad engineering courses. Nearly none of my professors, at a top 10 electrical engineering program, were able to explain things very well. Then you'd have to dive into poorly written textbooks to figure out what was going on. Kids these days have no idea how good things are with lots of youtube videos and online tutorials that give clear explanations for how things work. Even then, I noticed my old engineering program is still managing to fuck things up by doing things like using synthetic, poorly documented fictional microprocessors to teach assembly and computer architecture.
- WalterBright 4y ago
  I have no idea why someone would want to teach with a fictional microprocessor.
  - rednab 4y ago
    [I'm well aware of who I am replying to here, I'm merely taking the bait and providing some hopefully fun links for people to dig into. :)] Because that's how Professor Wirth ¹) does it ²), because it allows for some interesting educational side-treks ³), and because the difference between a fictional and real microprocessor is smaller than some might think ⁴). ¹) https://people.inf.ethz.ch/wirth/index.html https://people.inf.ethz.ch/wirth/index.html ²) https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html https://people.inf.ethz.ch/wirth/CompilerConstruction/index.... ³) "So what instruction would you add to this CPU to make the work we've been doing easier? Great, implement that instruction in the provided emulator." ⁴) https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html (edit: And, of course, there's FPGA implementations of Professor Knuth's MMIX (http://mmix.cs.hm.edu/ http://mmix.cs.hm.edu/), too: https://github.com/tommythorn/fpgammix https://github.com/tommythorn/fpgammix)

beachy 4y ago

I think this is just a subset of the larger guide, don't brag about subjectives. Don't say your product is the best, the greatest, the simplest, the most powerful. That's marketing BS, noise. It's ok to say things that can be verified, like it's the cheapest, the fastest, the only one with yellow spots.

progrus 4y ago
Or, if you really do want something qualitative: “my favorite”.
elcomet 4y ago
Why wouldn't you say it if it helps to sell the product ? It's marketing, not science.

bonestamp2 4y ago

Everything seems simple once you're an expert at it. Experts are often the worst at teaching it for that reason.

kkukshtel 4y ago

This is such a pet peeve of mine, especially when peeking at other programming domains I don't typically work in. Seeing readme's say "Simply..." or just throw around domain terminology with 0 context immediately puts me off using the library.

_the_inflator 4y ago

I can relate. The thing is, that these "Heureka" moments stem usually from long times of frustration working within a certain domain or with a certain concept. After working with certain stuff for long periods I can find usually a way to explain it in a very easy way. However, this does not mean, that concepts are easy to grasp without putting in more time and learning all about what my abstraction kept out. It is still a hermeneutic circle.