> Yeah, I guess I would in retrospect refine my opinion to “software architecture is iterable and not completely separable from implementation” or that “architecture (as imagined by distinct architects who are shielded from implementation concerns) is not important”.
This, I'd agree with. You have to be at the coalface to know what the hell is going on. At the same time, you have to be cognizant of business needs and why things are the way they are, which is to me a fair approximation of "the job of a principal engineer."
(My other hat here is "head of API governance" and that's largely a business-flavored analysis of APIs being brought onto our company-spanning platform. I couldn't escape having both in my head if I tried.)
> It sounds like you’re doing the better thing of running up and down the layers of abstraction so your contributions empower people rather than disempower them
Ideally, yes. In reality, I work for The Phone Company, and The Phone Company hires a lot, and I mean a lot, of vendor devs. I am doing their thinking for them a lot of the time; the swerve is that I can and do write code (have released moderately popular open-source libraries on their framework of choice, for example) and so the usual development practices of "sure let's make a dozen packages for marginal functionality" don't fly.
I am disempowering them, because ultimately, we will eventually be cycling out our vendors and I will be the one who has to own their output. So that output has to be something I can live with. But this place is Processes Georg and should absolutely not be counted.
(I like the job. I will enjoy when I eventually go back to a shop where the developers have a reason to feel ownership over the work.)
This, I'd agree with. You have to be at the coalface to know what the hell is going on. At the same time, you have to be cognizant of business needs and why things are the way they are, which is to me a fair approximation of "the job of a principal engineer."
(My other hat here is "head of API governance" and that's largely a business-flavored analysis of APIs being brought onto our company-spanning platform. I couldn't escape having both in my head if I tried.)
> It sounds like you’re doing the better thing of running up and down the layers of abstraction so your contributions empower people rather than disempower them
Ideally, yes. In reality, I work for The Phone Company, and The Phone Company hires a lot, and I mean a lot, of vendor devs. I am doing their thinking for them a lot of the time; the swerve is that I can and do write code (have released moderately popular open-source libraries on their framework of choice, for example) and so the usual development practices of "sure let's make a dozen packages for marginal functionality" don't fly.
I am disempowering them, because ultimately, we will eventually be cycling out our vendors and I will be the one who has to own their output. So that output has to be something I can live with. But this place is Processes Georg and should absolutely not be counted.
(I like the job. I will enjoy when I eventually go back to a shop where the developers have a reason to feel ownership over the work.)