
Ask HN: Do you feel you are mostly writing glue code? - xstartup
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?
======
indogooner
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.

------
cimmanom
There's an argument to be made that that's a sign of an engineering
organization that has its priorities straight and is serving the business
well.

------
CM30
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.

------
justaguyhere
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).

------
dallbee
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.

------
ClevelandCoder
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.

------
mcintyre1994
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.

------
psyc
That’s the nature of some jobs, and it can be a sound strategy. I’ve mostly
managed to avoid these jobs, personally.

~~~
nickthemagicman
Can't agree more. Why self roll your own code when you can use a tested,
somewhat proven, piece of existing code.

~~~
err4nt
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.

~~~
nickthemagicman
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!

Just glad you found a solution that works!

~~~
err4nt
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.

~~~
nickthemagicman
Glad you have the free time to do that! I work for an extremely fast moving
biz and don't! And thanks for your contributions to OSS!

------
dozzie
It's no big wonder if one extrapolates from how many trivial questions you ask
here.

~~~
xstartup
I like to keep difficult one for myself.

------
farnsworthy
Longer than lately. It's "assembly" (not the other one).

------
jitendrac
yup, That is pretty common thing, In the days of api-for-everything gluing is
written more than api itself!!!

