3 ms·

I'd say the problem is way different and it's a people problem. A small percentage of people invest enougu resources to be able to have the big picture and writ

I'd say the problem is way different and it's a people problem. A small percentage of people invest enougu resources to be able to have the big picture and write higher quality solutions. There is a huuge percentage of people with minimal education learning along the way and by learning along the way they reinvent things as a part of their learning process. This also incentovizes rising popularity of low quality but simpler tooling

etothepii 6y ago
The number of developers (and developer managers) who want to only complete tasks where someone (else) has defined the inputs and the outputs is extraordinary. It is my firm belief that the vast majority of value in Software Development is in understanding the problem and the ways that Software can help. Crucially this includes knowing when it can't. When asked what my job was once I said, "to think and write code, the hard part is doing it in that order."
- shade 6y ago
  This is a pet peeve of mine - I've worked with folks who were/are good developers but wanted to constrain their role to only development tasks. No effort to get exposure to build automation/deployment pipelines or understand how Docker/Kubernetes work at a high level, no desire to understand the bigger business domain or how our customers use the product. Pretty much just "give me a fully groomed ticket and leave me alone until I tell you it's done." On the one hand, I get it - sometimes it actually is nice to have a ticket that you don't have to think too much about the bigger context for, and can just crank out code. On the other hand, I don't think it's particularly good for your career security if you're limiting your own role to "minimally communicative code monkey" - if that's all you want to do, there's an awful lot of competition out there. I've made an effort the past couple of years, across multiple jobs now, to get some real exposure to the ops aspects of my roles (most recently, prototyping and then helping implement CI/CD pipelines for Azure Durable Functions) as well as making an effort to understand the business domain, where the gaps in our product offerings are, and what the competitors in that sector look like. It's really helpful in terms of looking for a more efficient way to solve a business problem, not to mention being able to say things like "hey, the market we're in is moving pretty heavily to Kubernetes, so it's really important that we decide how we're going to support that." I'm not saying you need to be (or can be) an expert in all of those things, but I think having the high level exposure is really important, at least when you get to a senior IC level. A minor bonus is it helps you develop a Spidey sense for when the business is pursuing strategies that don't seem likely to work, giving you a chance to either try to offer feedback/seek clarification on why, or to pull the plug and find a new gig if it seems bad enough.
  - etothepii 6y ago
    It's very frustrating and makes it easy for management to outsource your role. Sometimes that's the right thing, but given how little most "ordinary" companies leverage technology and how utterly most non-tech understand what can (and can't) be done it's usually the wrong call.

etothepii 6y ago

The number of developers (and developer managers) who want to only complete tasks where someone (else) has defined the inputs and the outputs is extraordinary. It is my firm belief that the vast majority of value in Software Development is in understanding the problem and the ways that Software can help. Crucially this includes knowing when it can't. When asked what my job was once I said, "to think and write code, the hard part is doing it in that order."

shade 6y ago
This is a pet peeve of mine - I've worked with folks who were/are good developers but wanted to constrain their role to only development tasks. No effort to get exposure to build automation/deployment pipelines or understand how Docker/Kubernetes work at a high level, no desire to understand the bigger business domain or how our customers use the product. Pretty much just "give me a fully groomed ticket and leave me alone until I tell you it's done." On the one hand, I get it - sometimes it actually is nice to have a ticket that you don't have to think too much about the bigger context for, and can just crank out code. On the other hand, I don't think it's particularly good for your career security if you're limiting your own role to "minimally communicative code monkey" - if that's all you want to do, there's an awful lot of competition out there. I've made an effort the past couple of years, across multiple jobs now, to get some real exposure to the ops aspects of my roles (most recently, prototyping and then helping implement CI/CD pipelines for Azure Durable Functions) as well as making an effort to understand the business domain, where the gaps in our product offerings are, and what the competitors in that sector look like. It's really helpful in terms of looking for a more efficient way to solve a business problem, not to mention being able to say things like "hey, the market we're in is moving pretty heavily to Kubernetes, so it's really important that we decide how we're going to support that." I'm not saying you need to be (or can be) an expert in all of those things, but I think having the high level exposure is really important, at least when you get to a senior IC level. A minor bonus is it helps you develop a Spidey sense for when the business is pursuing strategies that don't seem likely to work, giving you a chance to either try to offer feedback/seek clarification on why, or to pull the plug and find a new gig if it seems bad enough.
- etothepii 6y ago
  It's very frustrating and makes it easy for management to outsource your role. Sometimes that's the right thing, but given how little most "ordinary" companies leverage technology and how utterly most non-tech understand what can (and can't) be done it's usually the wrong call.