4 ms·

Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side yo

by slx26 7y ago

Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!

dpau 7y ago
For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)
EpicEng 7y ago
For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening. Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why. Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
- xrd 7y ago
  And the documentation is written by fanboys who are marketing it more than they are documenting it.
  - EpicEng 7y ago
    Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.
heyoni 7y ago
And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\
Dig1t 7y ago
To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.
- rhn_mk1 7y ago
  With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?). Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
jdashg 7y ago
Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.
gerbilly 7y ago
It's the difference between a difficult problem, and a complex one. I think most of us here would find complexity more interesting. Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
muzani 7y ago
I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.

by slx26 7y ago

dpau 7y ago

For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)

EpicEng 7y ago

For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening. Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why. Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.

xrd 7y ago
And the documentation is written by fanboys who are marketing it more than they are documenting it.
- EpicEng 7y ago
  Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.

heyoni 7y ago

And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\

Dig1t 7y ago

To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.

rhn_mk1 7y ago
With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?). Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.

jdashg 7y ago

Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.

gerbilly 7y ago

It's the difference between a difficult problem, and a complex one. I think most of us here would find complexity more interesting. Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)

muzani 7y ago

I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.