6 ms·

It's actually the perfect litmus test, and a good way to check someone's seniority or competence in in about 5 minutes flat: Developers who disclaim responsibi

It's actually the perfect litmus test, and a good way to check someone's seniority or competence in in about 5 minutes flat: Developers who disclaim responsibility, or show no interest in, how their software is scaled, securely locked down, deployed or monitored are probably not that great. Or, perhaps, they simply haven't been humbled yet by a bad incident, miscommunication, or a complete lack of understanding of how real life works. I worked with a Microservices Architect (and developer) once, and when I asked how he intended for failures to cascade properly between services; how he would maintain cohesive state, especially if things went wrong; and how he would diagnose problems between them, he confidently told me: "That is for devops to work out." Back in the day of desktop apps, the people who showed no interest in how their software was installed on desktop computers were more or less the same ones that are now disinterested in operations, deployment, etc.

jiggawatts 4y ago
Whenever speaking with pure developers, inevitably I will hear this sentence: "I just want to...." It's terribly rude, but I stop paying attention, because inevitably the rest of the sentence can be translated to: "... ignore my responsibilities, such as security, observability, availability, privacy, security, recoverability, documentation, scalability, and long term supportability.
- fizzynut 4y ago
  That's an interesting way to frame it. I would say the context of such a sentence is usually something along the lines of: "Because X wasn't designed with <problem> security, observability, availability, privacy, security, recoverability, documentation, scalability, and long term supportability </problem> in mind, to just do Y it is now also my responsibility to do <problem>"
  - jiggawatts 4y ago
    I've had these conversations with developers facing the proverbial blank canvas of a new Visual Studio project they had created mere days ago. Excuses are just that: excuses.
throw1234651234 4y ago
What answer did you want to hear? Mine would be "Goes to dead-letter queue to be reprocessed OR fails, logs to central logs, team gets an alert." Haven't seen "distributed logging" magic work in practice. I have co-workers who spent years on tracing request ids through each layer. It got scrapped after a couple of months because no one used it.
- mickeyp 4y ago
  > I have co-workers who spent years on tracing request ids through each layer. It got scrapped after a couple of months because no one used it. "Hey bob, it seems the money we sent through the system disappeared. Can we trace it?" "Sorry no, we got rid of the reconciliation id we use across our systems."
  - throw1234651234 4y ago
    That sounds cute to you, but it's a huge waste of time for most applications. Pulling out the banking example is a cliche at this point. If it's a move money issue - that's solved - transaction to credit/debit. Reject and log if failed. Maybe with a retry. Maybe from a queue. If it's financial documents moving, they go through a serious of queues and get dead-lettered and handled appropriately. The kicker? All of these have a customer / transaction ID and don't need some special request id "traceable throughout the system" - it's traceable as is, search for it by customer / transaction ID. This even applies if you are using K8S for no reason. The only company I know that's justified in using K8S is an AWS/GCP/Azure competitor in the ML space needing to spin up VMs instantly at scale.
    - dinkledunk 4y ago
      k8s saves a TON of time if you need to run on more than 1 machine and you use a managed solution (by AWS/GCP/Azure) and only use it as a glorified docker container orchestrator. Ingress solves how to route HTTP traffic coming into your domain. PersistentVolume solves how and where to store data. LivenessCheck solves how to restart your crapware when it freezes. Just don't go crazy with it unless you actually need the fancy stuff.
0x445442 4y ago
Most enterprise developers aren’t allowed to know the answers to your questions as none of them fits into a feature rooted in a quarterly OKR. For most enterprises developers it takes a couple of weeks to create a git repo because it requires a service ticket to Devops.
P5fRxh5kUvp2th 4y ago
> I worked with a Microservices Architect (and developer) once, and when I asked how he intended for failures to cascade properly between services; how he would maintain cohesive state, especially if things went wrong; and how he would diagnose problems between them, he confidently told me: "That is for devops to work out." JFC, that's an incompetent. I know a lot of people will consider that too strongly said, but I don't think so. Any jackass can succcessfully build for the happy path, it's precisely where the happy path isn't that real skill comes into play.

jiggawatts 4y ago

Whenever speaking with pure developers, inevitably I will hear this sentence: "I just want to...." It's terribly rude, but I stop paying attention, because inevitably the rest of the sentence can be translated to: "... ignore my responsibilities, such as security, observability, availability, privacy, security, recoverability, documentation, scalability, and long term supportability.

fizzynut 4y ago
That's an interesting way to frame it. I would say the context of such a sentence is usually something along the lines of: "Because X wasn't designed with <problem> security, observability, availability, privacy, security, recoverability, documentation, scalability, and long term supportability </problem> in mind, to just do Y it is now also my responsibility to do <problem>"
- jiggawatts 4y ago
  I've had these conversations with developers facing the proverbial blank canvas of a new Visual Studio project they had created mere days ago. Excuses are just that: excuses.

throw1234651234 4y ago

What answer did you want to hear? Mine would be "Goes to dead-letter queue to be reprocessed OR fails, logs to central logs, team gets an alert." Haven't seen "distributed logging" magic work in practice. I have co-workers who spent years on tracing request ids through each layer. It got scrapped after a couple of months because no one used it.

mickeyp 4y ago
> I have co-workers who spent years on tracing request ids through each layer. It got scrapped after a couple of months because no one used it. "Hey bob, it seems the money we sent through the system disappeared. Can we trace it?" "Sorry no, we got rid of the reconciliation id we use across our systems."
- throw1234651234 4y ago
  That sounds cute to you, but it's a huge waste of time for most applications. Pulling out the banking example is a cliche at this point. If it's a move money issue - that's solved - transaction to credit/debit. Reject and log if failed. Maybe with a retry. Maybe from a queue. If it's financial documents moving, they go through a serious of queues and get dead-lettered and handled appropriately. The kicker? All of these have a customer / transaction ID and don't need some special request id "traceable throughout the system" - it's traceable as is, search for it by customer / transaction ID. This even applies if you are using K8S for no reason. The only company I know that's justified in using K8S is an AWS/GCP/Azure competitor in the ML space needing to spin up VMs instantly at scale.
  - dinkledunk 4y ago
    k8s saves a TON of time if you need to run on more than 1 machine and you use a managed solution (by AWS/GCP/Azure) and only use it as a glorified docker container orchestrator. Ingress solves how to route HTTP traffic coming into your domain. PersistentVolume solves how and where to store data. LivenessCheck solves how to restart your crapware when it freezes. Just don't go crazy with it unless you actually need the fancy stuff.

0x445442 4y ago

Most enterprise developers aren’t allowed to know the answers to your questions as none of them fits into a feature rooted in a quarterly OKR. For most enterprises developers it takes a couple of weeks to create a git repo because it requires a service ticket to Devops.

P5fRxh5kUvp2th 4y ago

> I worked with a Microservices Architect (and developer) once, and when I asked how he intended for failures to cascade properly between services; how he would maintain cohesive state, especially if things went wrong; and how he would diagnose problems between them, he confidently told me: "That is for devops to work out." JFC, that's an incompetent. I know a lot of people will consider that too strongly said, but I don't think so. Any jackass can succcessfully build for the happy path, it's precisely where the happy path isn't that real skill comes into play.