Ask HN: Do you feel you are mostly writing glue code?
Lately, we are writing glue code to connect a bunch of services which finance department pays for. Writing any service which can be acquired from the market is forbidden. Anyone else feels like this?
Yes I have done that most of the time. I have thought a bit about this and feel that it should be true for most of us for software industry to scale. If you are in a solid tech company this will always be the case. Anything which can be used generally will be made into a framework and then most engineers will be expected to use that. This helps the company immensely as it can now hire top 1-2% who are extremely good at making these frameworks or guard-rails and the rest can be lesser quality devs who will do the plumbing. An example: writing multi-threaded programs and reasoning about them is hard so why not make a framework which takes care that developers only write business logic and integrate with various APIs.
This is now true in most companies now as Open source projects are doing the same thing. Look at Apache Spark for example which makes writing distributed programs for Machine Learning, ETL and Analytics much easier for developers.
Sometimes, though I suspect in a lot of cases that's probably for the best. I mean, if a product or service exists and does what you need it to, isn't it better to take advantage of that rather than reinvent the wheel every time? Sure, you could create your own inhouse CMS for those client websites or what not, but it's likely not worth it given the effort of making your updates, fixing security holes, etc. Same with anything really. You could in theory try and go all the way back to the start on your own, but where does it end? Eventually you'll be doing ten times more work for little extra benefit.
Are there examples where doing the extra work could be better? Of course, I know that one from experience. All that time trying to integrate a CMS and a forum script and a bunch of other standalone things was a nightmare, and in that case I definitely wish I'd just rolled the whole thing myself instead.
But in many cases, it's probably better to use pre-existing solutions rather than spend all your time reinventing the wheel or falling victim to not invented here syndrome. That way, you're relying on well tested solutions with a decent amount of support available online and a guarantee it'll still work when most of your team has moved on to pastures new.
Yes, many jobs are like this. Nothing wrong with it, it just depends on individual devs if they are okay with it or not. We are just 5 devs in our team and our manager spends a good amount of time optimizing dev hours so he can get the most useful features out. If this means using external services then that choice always wins (assuming we can afford it).
Every team I've been on has had it's majority of engineers doing exactly that. Honestly, many are happy in that role.
Usually theres a handful of people that tend wiggle their way into more backend, architectural things (libraries, in-house tools, etc.). If you're bored, try to be that person.
I understand the business interest in separating concerns. Focusing your talent on solving only the most unique problems is kind of charming, IMO, but the part where we write the glue code for third-party services can definitely feel soul-sucking.
I think that most code that is well defined and I understand well I can reason about as basically transforms of dictionaries. It's often but of course not always a red flag if I can't reason about it in that way.
I used to match patchwork quilts out of plugins, different HTML widgets, and try to make use of pre-made frameworks for CSS in the past. I always felt like I was 80% of the way finished before I started.....but the hard part was building the other 80%.
A few years ago I flipped the way I built stuff, preferring small, self-built pieces of code only I had authored, and not only was our code smaller and easier to maintain, it also significantly dropped the amount of bugs and conflicts we were having.
The problem that often happens with pre-built, well-tested solutions, is that they often only partly solve what you need to do. Edge cases might be the only cases you have, it's often better to get the one tailor made for solving your exact problem.
I've found the exact opposite at every job I've had. Typically pre-build solutions do WAY more than you need from them, and you can make wrappers for any very rare edge cases they don't solve which Ive found to be few and far between. Dependency managers go a long way toward making the patchwork nature of diverse libraries..manageable.
Also, I've found solutions custom rolled under pressure have more bugs and issues and theres never enough time to correctly debug, test, and QA before you're on to the next project.
However, CSS and HTML widgets may not lend themselves to libraries as easily as imperative programming languages.
You also, may just be solving more complex problems that require much more specialized libraries!
Ah see what I end up doing is solving the problem and thinking deeply about what I need our solution to do, and more importantly, figuring out exactly what we don't need our solution to do.
Once I've solved the same problem about 4 or 5 times, I end up 'standardizing' the solution into a prototype plugin, which usually goes through 1 or 2 total rewrites, and by the time I've got the plugin resulting from that process, usually it's precisely what we need, and had all the kinks worked out.
I realize the irony here, but I release these solutions into open source and re-use them. And I know they're available for others to use and benefit from, and I fully understand why somebody like me might not actually use them directly haha. I hope people at least read my solutions in a literary sense and consider them while rolling their own solution that directly meets their own needs.
Naturally it depends on the situation and trade-offs, but I agree with what you wrote pretty often. I summarize all this as: "Software is not really made of cogs."
This is now true in most companies now as Open source projects are doing the same thing. Look at Apache Spark for example which makes writing distributed programs for Machine Learning, ETL and Analytics much easier for developers.
Are there examples where doing the extra work could be better? Of course, I know that one from experience. All that time trying to integrate a CMS and a forum script and a bunch of other standalone things was a nightmare, and in that case I definitely wish I'd just rolled the whole thing myself instead.
But in many cases, it's probably better to use pre-existing solutions rather than spend all your time reinventing the wheel or falling victim to not invented here syndrome. That way, you're relying on well tested solutions with a decent amount of support available online and a guarantee it'll still work when most of your team has moved on to pastures new.
Usually theres a handful of people that tend wiggle their way into more backend, architectural things (libraries, in-house tools, etc.). If you're bored, try to be that person.
A few years ago I flipped the way I built stuff, preferring small, self-built pieces of code only I had authored, and not only was our code smaller and easier to maintain, it also significantly dropped the amount of bugs and conflicts we were having.
The problem that often happens with pre-built, well-tested solutions, is that they often only partly solve what you need to do. Edge cases might be the only cases you have, it's often better to get the one tailor made for solving your exact problem.
Also, I've found solutions custom rolled under pressure have more bugs and issues and theres never enough time to correctly debug, test, and QA before you're on to the next project.
However, CSS and HTML widgets may not lend themselves to libraries as easily as imperative programming languages.
You also, may just be solving more complex problems that require much more specialized libraries!
Just glad you found a solution that works!
Once I've solved the same problem about 4 or 5 times, I end up 'standardizing' the solution into a prototype plugin, which usually goes through 1 or 2 total rewrites, and by the time I've got the plugin resulting from that process, usually it's precisely what we need, and had all the kinks worked out.
I realize the irony here, but I release these solutions into open source and re-use them. And I know they're available for others to use and benefit from, and I fully understand why somebody like me might not actually use them directly haha. I hope people at least read my solutions in a literary sense and consider them while rolling their own solution that directly meets their own needs.