The view that such work just constitutes writing "glue" is super reductive. So much time is also spent empathizing with others: talking to stakeholders, understanding existing processes, determining requirements, and simplifying. So if we can reduce the solution to glue instead of needing to write a complicated system, that's hands down a win.
Just because you're not doing much (any?) interesting engineering doesn't mean you're not creating a lot of value. But it probably does mean that if you really deeply care about engineering in itself you should reconsider your employment options. But learning when you can just glue and how is a super-valuable skill, even if some of your work involves pushing the envelope.
The worst engineers are not those who just glue stuff together, it's the people who cv-drivenly develop 100x too slow, resource intensive and broken buzzword bingo clusterfucks that could be solved, correctly and cheaply, with a page of shell script.
Any engineer who comes up with a solution that requires less new code being written is a more valuable engineer IMO. Less code is less time spent on building then maintaining code for all eternity.
If you go through the build/buy/partner decision, and decide to buy or partner with development comprising of glue code - then that's probably the optimal solution for your org. And you made the right engineering choice.
> Any engineer who comes up with a solution that requires less new code being written is a more valuable engineer IMO
Of course less code is good, all things being equal.
But taking that idea literally, basically no tooling code gets ever written and people develop some sort of learned helplessness around dysfunctional workflows that are just about feasible but fantastically wasteful of engineering time. This tends to happen a lot, also because tooling is often perceived by management as an unnecessary luxury.
Agree, In my own experience it’s only orgs with a min 50 to 100 developers who can afford to have a single developer (it was me!) out working on productivity tools.
The view that such work just constitutes writing "glue" is super reductive. So much time is also spent empathizing with others: talking to stakeholders, understanding existing processes, determining requirements, and simplifying. So if we can reduce the solution to glue instead of needing to write a complicated system, that's hands down a win.