6 ms·

I've read similar things about how most programming work is just plumbing together existing code fairly regularly on HN. Is that really what most people do? I

I've read similar things about how most programming work is just plumbing together existing code fairly regularly on HN. Is that really what most people do? Is it a web development thing? That's not my experience at all, and it sounds mind numbingly awful.

pianoben 6y ago
How often do you write hashtables? JSON serializers? Mutexes? HTTP clients? Transaction managers? Connection pools? In my last job as a mobile engineer I can claim that I wrote code all day, and that's true to a point, but most of that code is shepherding data from one format to another, using libraries that I didn't write, causing the UI (whose framework was written by someone else) to update. And you know what? It's still a hard and rewarding job! Having pieces to plumb together hasn't made our jobs easier or dumber, it's just raised the level of abstraction at which we work day-to-day.
- braythwayt 6y ago
  There is a “Red Queen’s Race” between the accelerating productivity gains of abstractions, frameworks, libraries, and other stacks we can leverage, balanced against the fact that each one is a leaky abstraction, and the leaks interfere with each other in weird, mysterious ways. Programming with all these tools is wonderful. Debugging problems in such am environment, not-so-much. But net, it’s a massive win.
dudul 6y ago
I don't want to necessarily draw general truths just from my XP. I think it's a spectrum :) When I compare programming (as in, just writing code) today and 20 years ago, there is nothing really interesting to write anymore. We have libraries for everything, and half of them are clients to integrate with a SaaS that does what you want. The challenges I see that still makes the job stimulating are more found in the architecture design (we have all the building blocks now, but we still need to organize it all in a way that works) and the product (as I said, making sense of business reqs and turning them into something do-able).
shajznnckfke 6y ago
I think the whole reason software is so productive (economically speaking) is that you can leverage software written by others. Depending on your mindset, you could call that “just plumbing”, but a more positive way to describe it is “using the best tool for the job”. The person who wrote the tool you are using could also think they are “just plumbing”. There’s always layers below you and often layers above you too. Nobody wrote their own stack top to bottom other than the TempleOS guy.
- nullsense 6y ago
  >Nobody wrote their own stack top to bottom other than the TempleOS guy. He was the greatest programmer that ever lived.
  - pavlov 6y ago
    He passed? I’m genuinely sorry to learn this. His work was a welcome reminder of unexplored possibilities.
    - nullsense 6y ago
      Yeah, I believe he did die. From what I understand he was mentally ill and lead a fairly troubled life. Watching his walkthrough of TempleOS is pretty fascinating. And for those who didn't get the reference: https://youtu.be/o48KzPa42_o https://youtu.be/o48KzPa42_o
      - markvdb 6y ago
        https://en.wikipedia.org/wiki/Terry_A._Davis https://en.wikipedia.org/wiki/Terry_A._Davis
    - _trapexit 6y ago
      He died in Aug of 2018.
rsynnott 6y ago
To some extent this is how most engineering works. If you're building a bridge, you don't usually start off by building the steel mill first.
geodel 6y ago
Last month one of my friend joined Amazon. At one point this person worked along with engineers who would implement highly optimized systems in C/C++. Now at Amazon his job will be to write little Javascript turdlets to call and parse ten different Amazon services and generate some sort of database table/report to be used by product managers. The way this guy described his work made me (developer of half-assed micro services) feel like a rocket scientist.
- just-juan-post 6y ago
  > Javascript turdlets thank you
visarga 6y ago
Yes, plumbing together things because we don't want to reinvent the wheel every time, but on the next level of abstraction you're all on your own. What approach do you take, how do you represent your data, what kind of user interface, how do you negotiate the project scope - that's on you and your experience. Not to mention that there's always a corner of the project that needs a clever new approach or algorithm and you can do amazing things there.

pianoben 6y ago

How often do you write hashtables? JSON serializers? Mutexes? HTTP clients? Transaction managers? Connection pools? In my last job as a mobile engineer I can claim that I wrote code all day, and that's true to a point, but most of that code is shepherding data from one format to another, using libraries that I didn't write, causing the UI (whose framework was written by someone else) to update. And you know what? It's still a hard and rewarding job! Having pieces to plumb together hasn't made our jobs easier or dumber, it's just raised the level of abstraction at which we work day-to-day.

braythwayt 6y ago
There is a “Red Queen’s Race” between the accelerating productivity gains of abstractions, frameworks, libraries, and other stacks we can leverage, balanced against the fact that each one is a leaky abstraction, and the leaks interfere with each other in weird, mysterious ways. Programming with all these tools is wonderful. Debugging problems in such am environment, not-so-much. But net, it’s a massive win.

dudul 6y ago

I don't want to necessarily draw general truths just from my XP. I think it's a spectrum :) When I compare programming (as in, just writing code) today and 20 years ago, there is nothing really interesting to write anymore. We have libraries for everything, and half of them are clients to integrate with a SaaS that does what you want. The challenges I see that still makes the job stimulating are more found in the architecture design (we have all the building blocks now, but we still need to organize it all in a way that works) and the product (as I said, making sense of business reqs and turning them into something do-able).

shajznnckfke 6y ago

I think the whole reason software is so productive (economically speaking) is that you can leverage software written by others. Depending on your mindset, you could call that “just plumbing”, but a more positive way to describe it is “using the best tool for the job”. The person who wrote the tool you are using could also think they are “just plumbing”. There’s always layers below you and often layers above you too. Nobody wrote their own stack top to bottom other than the TempleOS guy.

nullsense 6y ago
>Nobody wrote their own stack top to bottom other than the TempleOS guy. He was the greatest programmer that ever lived.
- pavlov 6y ago
  He passed? I’m genuinely sorry to learn this. His work was a welcome reminder of unexplored possibilities.
  - nullsense 6y ago
    Yeah, I believe he did die. From what I understand he was mentally ill and lead a fairly troubled life. Watching his walkthrough of TempleOS is pretty fascinating. And for those who didn't get the reference: https://youtu.be/o48KzPa42_o https://youtu.be/o48KzPa42_o
    - markvdb 6y ago
      https://en.wikipedia.org/wiki/Terry_A._Davis https://en.wikipedia.org/wiki/Terry_A._Davis
  - _trapexit 6y ago
    He died in Aug of 2018.

rsynnott 6y ago

To some extent this is how most engineering works. If you're building a bridge, you don't usually start off by building the steel mill first.

geodel 6y ago

Last month one of my friend joined Amazon. At one point this person worked along with engineers who would implement highly optimized systems in C/C++. Now at Amazon his job will be to write little Javascript turdlets to call and parse ten different Amazon services and generate some sort of database table/report to be used by product managers. The way this guy described his work made me (developer of half-assed micro services) feel like a rocket scientist.

just-juan-post 6y ago
> Javascript turdlets thank you

visarga 6y ago

Yes, plumbing together things because we don't want to reinvent the wheel every time, but on the next level of abstraction you're all on your own. What approach do you take, how do you represent your data, what kind of user interface, how do you negotiate the project scope - that's on you and your experience. Not to mention that there's always a corner of the project that needs a clever new approach or algorithm and you can do amazing things there.