3 ms·

> Most of the available programming work is really just writing glue code to make big software systems work as intended, to the point where it can feel more lik

> Most of the available programming work is really just writing glue code to make big software systems work as intended, to the point where it can feel more like writing configuration files than actual programming. Put simply, 98% of programming these days is scripting. It's that the entire purpose of programming, though? To abstract away the repetitive stuff? I personally see this as a good thing. Even with all the configuration and scripting, there are still plenty of lower-level programming tasks involved in piecing together systems. I'd rather save the difficult programming for the actual difficult tasks instead of re-implementing the already solved problems like CRUD.

ChrisMarshallNY 6y ago
> the already solved problems If I had a dollar for every time I've heard the phrase "XXX is a solved problem," indicating that there's a dependency that "solves" it, I'd be rich. People think that, just because we can google up a dependency that does what we want (sorta/kinda/mostly), the "problem is solved." It's been my experience, that, when our "solution" is to bring in a massive dependency to address a very basic issue that we could solve, ourselves, by banging out a bit of code in a day or two, our problems are just beginning. In some cases, that's exactly what I have done. For example, I use dependencies to handle SOAP (yuck), for ONVIF work, and keychain access for login Face/TouchID validation. These are small, atomic dependencies, written and maintained by reputable authors. The SOAP thing would have taken me a couple of months to write something not as good, but the keychain thing is something I could write, myself, in a couple of days. I just find that I don't really need to, as there is an acceptable alternative. In fact, when I have been dissatisfied with the choices, and have decided to write my own solutions, I have encountered derision. I feel for the OP, but I am sad to hear they are leaving the industry. Maybe it's for the best, or maybe they will always look back in regret. In my case, I have just realized that I can't look to others to validate my work, and have to work on my own. It is not my preferred choice. I worked on (often, huge) teams, my entire career. But I won't compromise my personal ethos to be "down with the kids." If writing good software is no longer in fashion, I guess I'll be unfashionable. I won't deliberately write bad software. I couldn't live with myself. For me, I'm never leaving, but that may mean that I'll need to work on my own. I have a pretty good record of creating stuff that other people value, so we'll see how that goes. More will be revealed...
- vbezhenar 6y ago
  You don't need couple of months to implement SOAP, unless you want to make a framework. SOAP is just an XML passed via HTTP. You can build everything from the ground up in a matter of few days. And if you can re-use any HTTP library and XML parser, it's a matter of few hours. May be there's some layer above SOAP which requires more implementation. I have no idea about OVNIF. But SOAP itself is pretty simple. Basically you're firing SoapUI, figuring out protocol details and write code to deal with that particular XML-based format.
  - ChrisMarshallNY 6y ago
    Thanks for that. I based my estimate, looking at the code for SOAPEngine[0], which is the library I use. It's pretty complete, and that guy knows his stuff. I tend to be fairly anal about testing; especially low-level stuff. It can be a bit excruciating, working with me, as I insist on pounding away at everything. That's why it's taken a week and a half to get to the place I'm at now. I'm working on the login and initial user edit stuff. Basic (but critical) stuff, and I keep encountering edge cases. I'm also debugging the backend SDK. [0] https://github.com/priore/SOAPEngine https://github.com/priore/SOAPEngine
henrik_w 6y ago
For most companies where the software is the product, there is some part of the system that is the core logic. Working on that part necessarily means actually developing, not just gluing pieces together. I have always been able to find work where I could work on those core parts, instead of composing existing systems, libraries and frameworks.
- xkcd-sucks 6y ago
  At many lucrative companies, writing the configs for third party software is the core product Maybe in that case you could call the core product "domain expertise" but it's not how they position themselves

ChrisMarshallNY 6y ago

> the already solved problems If I had a dollar for every time I've heard the phrase "XXX is a solved problem," indicating that there's a dependency that "solves" it, I'd be rich. People think that, just because we can google up a dependency that does what we want (sorta/kinda/mostly), the "problem is solved." It's been my experience, that, when our "solution" is to bring in a massive dependency to address a very basic issue that we could solve, ourselves, by banging out a bit of code in a day or two, our problems are just beginning. In some cases, that's exactly what I have done. For example, I use dependencies to handle SOAP (yuck), for ONVIF work, and keychain access for login Face/TouchID validation. These are small, atomic dependencies, written and maintained by reputable authors. The SOAP thing would have taken me a couple of months to write something not as good, but the keychain thing is something I could write, myself, in a couple of days. I just find that I don't really need to, as there is an acceptable alternative. In fact, when I have been dissatisfied with the choices, and have decided to write my own solutions, I have encountered derision. I feel for the OP, but I am sad to hear they are leaving the industry. Maybe it's for the best, or maybe they will always look back in regret. In my case, I have just realized that I can't look to others to validate my work, and have to work on my own. It is not my preferred choice. I worked on (often, huge) teams, my entire career. But I won't compromise my personal ethos to be "down with the kids." If writing good software is no longer in fashion, I guess I'll be unfashionable. I won't deliberately write bad software. I couldn't live with myself. For me, I'm never leaving, but that may mean that I'll need to work on my own. I have a pretty good record of creating stuff that other people value, so we'll see how that goes. More will be revealed...

vbezhenar 6y ago
You don't need couple of months to implement SOAP, unless you want to make a framework. SOAP is just an XML passed via HTTP. You can build everything from the ground up in a matter of few days. And if you can re-use any HTTP library and XML parser, it's a matter of few hours. May be there's some layer above SOAP which requires more implementation. I have no idea about OVNIF. But SOAP itself is pretty simple. Basically you're firing SoapUI, figuring out protocol details and write code to deal with that particular XML-based format.
- ChrisMarshallNY 6y ago
  Thanks for that. I based my estimate, looking at the code for SOAPEngine[0], which is the library I use. It's pretty complete, and that guy knows his stuff. I tend to be fairly anal about testing; especially low-level stuff. It can be a bit excruciating, working with me, as I insist on pounding away at everything. That's why it's taken a week and a half to get to the place I'm at now. I'm working on the login and initial user edit stuff. Basic (but critical) stuff, and I keep encountering edge cases. I'm also debugging the backend SDK. [0] https://github.com/priore/SOAPEngine https://github.com/priore/SOAPEngine

henrik_w 6y ago

For most companies where the software is the product, there is some part of the system that is the core logic. Working on that part necessarily means actually developing, not just gluing pieces together. I have always been able to find work where I could work on those core parts, instead of composing existing systems, libraries and frameworks.

xkcd-sucks 6y ago
At many lucrative companies, writing the configs for third party software is the core product Maybe in that case you could call the core product "domain expertise" but it's not how they position themselves