"You write "Of course, I'd like to do it myself" so I guess you're one of them."
Umm.... no, not really. I'm a developer who's gradually moved in to more business-oriented consulting over the last several years. I still do a lot of development (> 50%, certainly), but I've realized that for the majority of the projects I work on, the difficulties are not programming or tech skills/knowledge, it's making sure we all know what is to be programmed, and dealing with any changes that come up.
Everyone thinks they're stuff is unique/cutting-edge/hard/impossible/ground-breaking tech marvels. In some cases it is, but I'm finding those instances to be more rare the older I get. Why? My own skills are getting better (slowly), there's far more tools and libraries to tackle much larger problems better, and my own network of people I can tap has grown to include some insanely talented people.
"the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc."
I would posit those are far more in the realm of "communication" issues I brought up. Yes, you need to have a technical background to do them correctly, but you don't do that stuff in a vacuum. You do those things in concert with other people (customer, team, etc).
For example - the basics of build and deployment are known problems. One might even class them as 'junior' problems. How many times have you had builds fail because someone didn't know how to schedule jenkins properly? Or because an alert wasn't set up to notify someone of an issue? The mechanics aren't very hard, but deciding what the specifics of the processes should be is hard, because you have to communicate ideas/deadlines/responsibilities/etc with multiple people or teams. That's what I'm getting at.
Umm.... no, not really. I'm a developer who's gradually moved in to more business-oriented consulting over the last several years. I still do a lot of development (> 50%, certainly), but I've realized that for the majority of the projects I work on, the difficulties are not programming or tech skills/knowledge, it's making sure we all know what is to be programmed, and dealing with any changes that come up.
Everyone thinks they're stuff is unique/cutting-edge/hard/impossible/ground-breaking tech marvels. In some cases it is, but I'm finding those instances to be more rare the older I get. Why? My own skills are getting better (slowly), there's far more tools and libraries to tackle much larger problems better, and my own network of people I can tap has grown to include some insanely talented people.
"the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc."
I would posit those are far more in the realm of "communication" issues I brought up. Yes, you need to have a technical background to do them correctly, but you don't do that stuff in a vacuum. You do those things in concert with other people (customer, team, etc).
For example - the basics of build and deployment are known problems. One might even class them as 'junior' problems. How many times have you had builds fail because someone didn't know how to schedule jenkins properly? Or because an alert wasn't set up to notify someone of an issue? The mechanics aren't very hard, but deciding what the specifics of the processes should be is hard, because you have to communicate ideas/deadlines/responsibilities/etc with multiple people or teams. That's what I'm getting at.