4 ms·

It's much, much easier to recall knowledge that you've gained once, than knowledge that you gained 0 times. It has also not been my experience that I "hope to f

It's much, much easier to recall knowledge that you've gained once, than knowledge that you gained 0 times. It has also not been my experience that I "hope to forget" that knowledge either. Perhaps you go about learning a different way than I do, though. After all, can you really write a good application without knowledge of how it will be deployed, and the challenges users face deploying things on specific platforms (eg. Windows, baremetal linux, kubernetes, docker, etc)? I would argue that you'd often write naive applications that gimp itself in unexpected ways depending on how the user intends to use it, without that knowledge. Depending on what types of applications you tend to write, this might be less of a valuable point to you. For example a static site web dev probably wouldn't be as interested in the infrastructure, they just need a server that can bind on ports 80/443. But I see a lot of incredibly naive applications written by potentially naive software developers out there.

jmaker 3y ago
Totally agreed on your first sentence. Yes, I don’t want to keep in memory the minute details of how I set up the infrastructure or the platform. That’s why I have that in IaC format and have a dedicated operator on my team so they can deal with that on a daily basis I, while I do my work. I’m not “learning” ops, I try to delegate as much of it as I can, I have no choice. On my private projects I’ve always had to deal a lot with infrastructure, it’s experience accumulated over many years, and I feel quite unhappy about that waste of time. At work I learned that at some things I’m far more experienced and knowledgeable than our top ops people, while at others I had no idea. On such projects you must collaborate, but at the same time somehow make progress on your business logic. And let’s hope you’re not also responsible for the product. Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother? If you think you can do both and create a “really good” app, or even product, well then you’re likely a genius. It depends on the depth, breadth and consistency of that “knowledge”—some people simply overestimate their capacity while others underestimate their potential. By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production? I said I hoped to forget that ops stuff because I have other duties to attend to and there’s too much variance and unreliability in those ops tasks, you need to make a context switch, hence IaC, hence managed, so you as a non-operator can focus on your tasks. Infrastructure and platforms are commodity goods now.
- starttoaster 3y ago
  > By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production? Many enterprises and companies use Kubernetes as at least _one_ of their deployment targets. So if you're a provider of software that has paying companies consuming it, does it matter if kubernetes is "deep enough for production"? It's being used in production, so I would argue, yes, from the perspective of a software provider, kubernetes is in fact deep enough for production. Though to one of your other points, define deep enough, because that statement seems like a moving target depending on who you talk to. But in general, if a piece of software doesn't work well in kubernetes, it's because the authors of that software hadn't considered any setup other than running as a monolith systemd service with an sqlite db for state. That will move me into the next quote: > Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother? Knowledge is a fairly generic term, isn't it. It's a placeholder word for a series (or bucket) of facts about one or several domains. "Really" is a nuanced word that means different things depending on how it's used. For example, in my sentence fragment, "can you really write," I'm using the word 'really' to express disbelief in one's ability to perform the context. On the word "good" we can use context clues to extrapolate that I probably am using the word "good" to mean one that supports a wide variety of deployment targets with ease because you often do not know how your product consumer's infrastructure looks, but you can probably guess that if its intended deployment target is a linux server, these days, it should probably also be well supported in Docker and Kubernetes. So that is "good." There are a bucket of other concepts that make a piece of software "good" as well that I'll merely touch on for the sake of brevity, such as being well tested, generally lacking unchecked exceptions, runtime panics, is well performant when ran for long periods of time, etc. Though, to be honest, I think you probably could have used context clues to come up with rough definitions of those words yourself, and I suppose your purpose was to glean what I think those words mean. In my opinion, the exercise seemed a bit more tedious than maintaining infrastructure though.

jmaker 3y ago

Totally agreed on your first sentence. Yes, I don’t want to keep in memory the minute details of how I set up the infrastructure or the platform. That’s why I have that in IaC format and have a dedicated operator on my team so they can deal with that on a daily basis I, while I do my work. I’m not “learning” ops, I try to delegate as much of it as I can, I have no choice. On my private projects I’ve always had to deal a lot with infrastructure, it’s experience accumulated over many years, and I feel quite unhappy about that waste of time. At work I learned that at some things I’m far more experienced and knowledgeable than our top ops people, while at others I had no idea. On such projects you must collaborate, but at the same time somehow make progress on your business logic. And let’s hope you’re not also responsible for the product. Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother? If you think you can do both and create a “really good” app, or even product, well then you’re likely a genius. It depends on the depth, breadth and consistency of that “knowledge”—some people simply overestimate their capacity while others underestimate their potential. By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production? I said I hoped to forget that ops stuff because I have other duties to attend to and there’s too much variance and unreliability in those ops tasks, you need to make a context switch, hence IaC, hence managed, so you as a non-operator can focus on your tasks. Infrastructure and platforms are commodity goods now.

starttoaster 3y ago
> By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production? Many enterprises and companies use Kubernetes as at least _one_ of their deployment targets. So if you're a provider of software that has paying companies consuming it, does it matter if kubernetes is "deep enough for production"? It's being used in production, so I would argue, yes, from the perspective of a software provider, kubernetes is in fact deep enough for production. Though to one of your other points, define deep enough, because that statement seems like a moving target depending on who you talk to. But in general, if a piece of software doesn't work well in kubernetes, it's because the authors of that software hadn't considered any setup other than running as a monolith systemd service with an sqlite db for state. That will move me into the next quote: > Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother? Knowledge is a fairly generic term, isn't it. It's a placeholder word for a series (or bucket) of facts about one or several domains. "Really" is a nuanced word that means different things depending on how it's used. For example, in my sentence fragment, "can you really write," I'm using the word 'really' to express disbelief in one's ability to perform the context. On the word "good" we can use context clues to extrapolate that I probably am using the word "good" to mean one that supports a wide variety of deployment targets with ease because you often do not know how your product consumer's infrastructure looks, but you can probably guess that if its intended deployment target is a linux server, these days, it should probably also be well supported in Docker and Kubernetes. So that is "good." There are a bucket of other concepts that make a piece of software "good" as well that I'll merely touch on for the sake of brevity, such as being well tested, generally lacking unchecked exceptions, runtime panics, is well performant when ran for long periods of time, etc. Though, to be honest, I think you probably could have used context clues to come up with rough definitions of those words yourself, and I suppose your purpose was to glean what I think those words mean. In my opinion, the exercise seemed a bit more tedious than maintaining infrastructure though.