6 ms·

Programming today is easier in many ways: Information is readily available for free (I recall saving up a lot of money for a kid to buy specific programming boo

Programming today is easier in many ways: Information is readily available for free (I recall saving up a lot of money for a kid to buy specific programming books at the book store after exhausting my library’s offerings). Compilers and tooling are free. Salaries are much higher and developers are a respected career that isn’t just “IT”. Online programming communities are more abundant and welcoming than impenetrable IRC cliques of years past. We have a lot that makes programming today more comfortable and accessible than it was in the past. However, everything feels vastly more complicated. My friends and I would put together little toy websites with PHP or Rails in a span of weeks and everyone thought they were awesome. Now I see young people spending months to get the basics up and running in their React front ends just to be able to think independently of hand-holding tutorials for the most basic operations. Even business software felt simpler. The scope was smaller and you didn’t have to set up complicated cloud services architectures to accomplish everything. I won’t say the old ways were better, because the modern tools do have their place. However, it’s easy to look back with rose-tinted glasses on the vastly simpler business requirements and lower expectations that allowed us to get away with really simple things. I enjoy working with teams on complex projects using modern tools and frameworks, but I admit I do have a lot of nostalgia for the days past when a single programmer could understand and handle entire systems by themselves because the scope and requirements were just so much simpler.

darepublic 4y ago
> Spending months to get the basics up and running in their React frontends just to be able to think independently of hand-holding tutorials for the most basic operations. Frontend devs who were present before the advent of the major web frameworks, and worked with the simplicity of js script + DOM (or perhaps jquery as a somewhat transparent wrapper) benefited from seeing the evolution of these frameworks, understanding the motivations behind the problem they solve, and knowing what DOM operations must be going on behind the curtain of these libraries. Approaching it today not from the 'ground up' but from high level down is imo responsible for a lot of jr web devs have surprising lack of knowledge on basic website features. Some, probably a minority, of student web devs may get conditioned to reach for libraries for every problem they encounter, until the kludge of libraries starts to cause bugs in and of itself or they reach a problem that no library is solving for them. I feel like this is particularly bad outcome for web devs because web I feel is uniquely accessible for aspiring developers. You can achieve a ton just piggybacking off the browser and DOM and it's API, the developer tools in the browser etc. But not if you are convinced or otherwise forced to only approach it from the other side -- running before you crawl, or trying to setup a webpack config before you even understand script loading, etc.
- sarchertech 4y ago
  At my current company we have a take home assignment for some roles. When I have to grade one the first thing I do is check to see whether you can submit the input by pressing enter. About half the time you can’t because it’s not actually a form, and they forgot to add handler for enter.
  - 7speter 4y ago
    As someone whose been learning the last few years, a lot of learning materials suggest you don’t make a proper form element and just make your own button instead of using using a form element and all the built in benefits it brings for reasons I don’t really know. I’ve probably wondered about this sort of thing for few good hours total, but I guess this comment steers me in the right direction.
    - Falkon1313 4y ago
      Yeah, don't do that unless you have good reason to do so. Browsers have a standard, default, expected behavior. Sometimes, in rare cases, it makes sense to break that in order to do something else instead. But you shouldn't just silently break it for no reason other than to confuse the user.
    - Mezzie 4y ago
      In addition to what others have mentioned, using elements for their stated/official purpose helps with accessibility. Yes, you can use the role attribute, but some accessibility technology works more completely if you use proper elements. (And just can be easier to use; I guess the best way to compare it is using VO on a site where everything is just divs is like the blind version of this[0] Or Comic Sans. Just visceral 'ugh'.). [0] https://www.theworldsworstwebsiteever.com/ https://www.theworldsworstwebsiteever.com/
  - wruza 4y ago
    I always found this behavior strange. Tab often doesn’t work correctly in a browser, cycling through elements that shouldn’t be focused, sometimes in a strange order. Enter submits a form. How does one cycle through “fields” then? I have also seen premature form sends when you hit enter to autocomplete etc. It also creates multiline textarea vs input inconsistency. Desktop frameworks “committed” input on enter and most often focused the next field, so you could skip them by enter enter enter. This worked correctly since FoxPro/TurboVision/Norton times. Only Ctrl-Enter would press a “default” button out of order. But web has its own ways as usual.
Forgeties79 4y ago
This is such an interesting perspective. I feel the exact same way as a video producer/editor. The tools we are getting are incredible, and tasks that used to take literally days can be done now in minutes. It’s kind of baffling what we have in our toolbox. But it is also radically changing the expectations of our clients and I find I don’t get to spend as much time on the nuts and bolts I really enjoy - cut, color, and baking the best possible export for the situation - and instead have to find a plug-in to solve every little issue a client thinks up (or created for me haha). On a somewhat related but tangential note: I also now have clients demanding certain programs and ecosystems, which is absolutely ridiculous to me. The software I use to give you a final cut should in no way be determined by you. Yet somehow we have ceded that ground!
systemvoltage 4y ago
The list of things we've added in last 10 years is just staggering: https://landscape.cncf.io/ https://landscape.cncf.io/ The litmus test for abstractions getting out of control is if a KPMG consultant brings it up while sipping Gin and tonic in business class. Another problem is explosion of DSLs. Everything is yaml and you spend ages learning things like Terraform and Docker compose yaml syntax.
- scarface74 4y ago
  The opposite of using yaml to provision infrastructure in a few minutes was a months long acquisition process for new hardware. As far as Terraform/HCL and CloudFormation/Yaml, the alternative is writing code to do the same thing in your language of choice using the CDK with either CloudFormation or the recently ported Terraform/CDK.
- oneplane 4y ago
  I'd say DSLs significantly improve specialised tasks. Someone who is working on declarative infrastructure configuration all day really doesn't benefit from classic imperative languages. But if you do "a little bit of everything" and infrastructure on the side, you're bound to become a master of none.
  - systemvoltage 4y ago
    On the other hand, having to learn 17 different DSLs (from crontab to AWS policy) isn't that far fetched from reality and it puts a lot of burden on people. Every product has a specialized DSL with unique restrictions and just never general enough. Stack Overflow is overflowing with such questions. People are thoroughly confused by "127.0.0.1:9090" vs. "127.0.0.1:9090:9090" or "9090:9090" or "0.0.0.0:9090"... docker network configs. Good lord, it is terrible, sorry, not to shed bad light on Docker; but to exemplify that this is a common thing. One of the worst experiences in programming is writing CI/CD pipelines. One wonders why...
    - oneplane 4y ago
      In most cases (including your examples) it's not really the DSL that is the problem, but the domain specific problem. Portmapping in docker isn't uniform because there are many options available that are all equally useful and up to the user to select. Crontabs have to describe time periodic values, and pretty much any other application that tries to solve a specific problem will not be all that generic (since they are not meant to solve all problems generically at once). Like I wrote in my comment, how much specific things you need to know will depend on how many specific tasks you perform. If you specialise in nothing, everything will have depths unknown. It will also dilute attention/focus which in turn means you'll never be able to fully understand a specific domain or application. This was reflected in https://news.ycombinator.com/item?id=33056052 https://news.ycombinator.com/item?id=33056052 where the path it took for many developers and engineers in general to find a fitting solution is unknown to newcomers and also simply not taught in favour of delivering "reviewables" in hopes of a positive review (https://news.ycombinator.com/item?id=33056705 https://news.ycombinator.com/item?id=33056705) . Sidenote: mapping ports used to be rather verbose, you'd have to include the address family, the address and the port, on both sides of the mapping. That's 6 elements (excluding separators). So most applications including docker made various parts optional. You can map two ports to any interface, or opt to specify one interface but not the other one etc. A novice user of a new application might be best served by not using any shorthand forms and only using the fully qualified names everywhere. By spelling out every option explicitly (including optional values) there is no more guessing what may or may not have been configured.
the_only_law 4y ago
> Information is readily available for free As much as people decry the internet and it’s role in modern society, I’m glad that I generally have easy access to massive archives of knowledge.
ravenstine 4y ago
Get rid of the assumption of "frontend first" and most of the complication of web development disappears instantaneously. Something I am appreciating about Svelte/Kit and Phoenix is that they are admitting what was right about PHP and server-rendered webpages. I'm a frontend engineer and think that SPAs have their place, but frontend JS represents a kind of tyranny seen nowhere else in tech.
- throwaway81523 4y ago
  Phoenix, do you mean the Elixir web framework? I had thought it was Elixir's counterpart to Rails.
  - throwawaymaths 4y ago
    Phoenix liveview is server rendered interactive websites.
- 7speter 4y ago
  Its really hard to find proper learning materials to get started with the backend; its all a bunch of shortcuts glued together because the tutorial really wants to show you how to make a react frontend first and foremost.
not_kurt_godel 4y ago
> My friends and I would put together little toy websites with PHP or Rails in a span of weeks and everyone thought they were awesome. Agreed, LAMP was just so damn fun in how you could go from zero to a fully functioning site in a day or two. Having to manage all the statefulness of fetching & displaying data asynchronously from the client adds an incredible amount of complication both in theory and in practice. Also agree that the old tech wasn't necessarily better either - but it sure would be cool if someone could replicate the developer experience from back then and produce a result that's up to modern engineering and UX standards.
antod 4y ago
I think things are more complicated precisely because things got easier. The more complexity we can now handle, the more complexity we will create.
- Falkon1313 4y ago
  If you think we're actually handling it. Seems to me there's a whole lot of "let's just glue all these black boxes together, cross our fingers and hope they do what we want, and still do the same thing after the next update" vs. in simpler times actually writing and understanding the code.
conductr 4y ago
> Even business software felt simpler. This made me remember how acceptable a developer designed utility used to be. Now, you can barely launch an MVP without finding or paying for design and high quality UX/UI. If you do it’s likely going nowhere in terms of traction. I’m sure this has only seemed to be the new rule and there are a few exceptions. But not many. Even Stripe all those years ago really took off after investing in design. They’ve remained rather polished. But they’re also an exceedingly well funded operation.
matwood 4y ago
> Information is readily available for free (I recall saving up a lot of money for a kid to buy specific programming books at the book store after exhausting my library’s offerings). Gave me flashbacks to when I was younger. I would work on a problem until hitting a wall I couldn't get around then go into Books A Million with pencil and paper and copy concepts/algos out of CS books. I was too poor to spend $50+ on a book at the time. Now, anything a new programmer wants to know is just a Google search away. But, there is so much more that just diving in can be hard. Even simple things are complicated I think mainly because expectations are so much higher.
bradlys 4y ago
> Salaries are much higher and developers are a respected career that isn’t just “IT”. I agree the compensation is higher. I don’t agree the respect is any higher. Software engineer is highly associated with terms like neckbeard, redditor, incel, autistic, etc. I’m extremely hesitant to tell anyone I’m a software engineer. If anything - I’ll lie and say I do product management just to avoid the association. People treat me way better when I say I’m a PM instead of an eng.

darepublic 4y ago

> Spending months to get the basics up and running in their React frontends just to be able to think independently of hand-holding tutorials for the most basic operations. Frontend devs who were present before the advent of the major web frameworks, and worked with the simplicity of js script + DOM (or perhaps jquery as a somewhat transparent wrapper) benefited from seeing the evolution of these frameworks, understanding the motivations behind the problem they solve, and knowing what DOM operations must be going on behind the curtain of these libraries. Approaching it today not from the 'ground up' but from high level down is imo responsible for a lot of jr web devs have surprising lack of knowledge on basic website features. Some, probably a minority, of student web devs may get conditioned to reach for libraries for every problem they encounter, until the kludge of libraries starts to cause bugs in and of itself or they reach a problem that no library is solving for them. I feel like this is particularly bad outcome for web devs because web I feel is uniquely accessible for aspiring developers. You can achieve a ton just piggybacking off the browser and DOM and it's API, the developer tools in the browser etc. But not if you are convinced or otherwise forced to only approach it from the other side -- running before you crawl, or trying to setup a webpack config before you even understand script loading, etc.

sarchertech 4y ago
At my current company we have a take home assignment for some roles. When I have to grade one the first thing I do is check to see whether you can submit the input by pressing enter. About half the time you can’t because it’s not actually a form, and they forgot to add handler for enter.
- 7speter 4y ago
  As someone whose been learning the last few years, a lot of learning materials suggest you don’t make a proper form element and just make your own button instead of using using a form element and all the built in benefits it brings for reasons I don’t really know. I’ve probably wondered about this sort of thing for few good hours total, but I guess this comment steers me in the right direction.
  - Falkon1313 4y ago
    Yeah, don't do that unless you have good reason to do so. Browsers have a standard, default, expected behavior. Sometimes, in rare cases, it makes sense to break that in order to do something else instead. But you shouldn't just silently break it for no reason other than to confuse the user.
  - Mezzie 4y ago
    In addition to what others have mentioned, using elements for their stated/official purpose helps with accessibility. Yes, you can use the role attribute, but some accessibility technology works more completely if you use proper elements. (And just can be easier to use; I guess the best way to compare it is using VO on a site where everything is just divs is like the blind version of this[0] Or Comic Sans. Just visceral 'ugh'.). [0] https://www.theworldsworstwebsiteever.com/ https://www.theworldsworstwebsiteever.com/
- wruza 4y ago
  I always found this behavior strange. Tab often doesn’t work correctly in a browser, cycling through elements that shouldn’t be focused, sometimes in a strange order. Enter submits a form. How does one cycle through “fields” then? I have also seen premature form sends when you hit enter to autocomplete etc. It also creates multiline textarea vs input inconsistency. Desktop frameworks “committed” input on enter and most often focused the next field, so you could skip them by enter enter enter. This worked correctly since FoxPro/TurboVision/Norton times. Only Ctrl-Enter would press a “default” button out of order. But web has its own ways as usual.

Forgeties79 4y ago

This is such an interesting perspective. I feel the exact same way as a video producer/editor. The tools we are getting are incredible, and tasks that used to take literally days can be done now in minutes. It’s kind of baffling what we have in our toolbox. But it is also radically changing the expectations of our clients and I find I don’t get to spend as much time on the nuts and bolts I really enjoy - cut, color, and baking the best possible export for the situation - and instead have to find a plug-in to solve every little issue a client thinks up (or created for me haha). On a somewhat related but tangential note: I also now have clients demanding certain programs and ecosystems, which is absolutely ridiculous to me. The software I use to give you a final cut should in no way be determined by you. Yet somehow we have ceded that ground!

systemvoltage 4y ago

The list of things we've added in last 10 years is just staggering: https://landscape.cncf.io/ https://landscape.cncf.io/ The litmus test for abstractions getting out of control is if a KPMG consultant brings it up while sipping Gin and tonic in business class. Another problem is explosion of DSLs. Everything is yaml and you spend ages learning things like Terraform and Docker compose yaml syntax.

scarface74 4y ago
The opposite of using yaml to provision infrastructure in a few minutes was a months long acquisition process for new hardware. As far as Terraform/HCL and CloudFormation/Yaml, the alternative is writing code to do the same thing in your language of choice using the CDK with either CloudFormation or the recently ported Terraform/CDK.
oneplane 4y ago
I'd say DSLs significantly improve specialised tasks. Someone who is working on declarative infrastructure configuration all day really doesn't benefit from classic imperative languages. But if you do "a little bit of everything" and infrastructure on the side, you're bound to become a master of none.
- systemvoltage 4y ago
  On the other hand, having to learn 17 different DSLs (from crontab to AWS policy) isn't that far fetched from reality and it puts a lot of burden on people. Every product has a specialized DSL with unique restrictions and just never general enough. Stack Overflow is overflowing with such questions. People are thoroughly confused by "127.0.0.1:9090" vs. "127.0.0.1:9090:9090" or "9090:9090" or "0.0.0.0:9090"... docker network configs. Good lord, it is terrible, sorry, not to shed bad light on Docker; but to exemplify that this is a common thing. One of the worst experiences in programming is writing CI/CD pipelines. One wonders why...
  - oneplane 4y ago
    In most cases (including your examples) it's not really the DSL that is the problem, but the domain specific problem. Portmapping in docker isn't uniform because there are many options available that are all equally useful and up to the user to select. Crontabs have to describe time periodic values, and pretty much any other application that tries to solve a specific problem will not be all that generic (since they are not meant to solve all problems generically at once). Like I wrote in my comment, how much specific things you need to know will depend on how many specific tasks you perform. If you specialise in nothing, everything will have depths unknown. It will also dilute attention/focus which in turn means you'll never be able to fully understand a specific domain or application. This was reflected in https://news.ycombinator.com/item?id=33056052 https://news.ycombinator.com/item?id=33056052 where the path it took for many developers and engineers in general to find a fitting solution is unknown to newcomers and also simply not taught in favour of delivering "reviewables" in hopes of a positive review (https://news.ycombinator.com/item?id=33056705 https://news.ycombinator.com/item?id=33056705) . Sidenote: mapping ports used to be rather verbose, you'd have to include the address family, the address and the port, on both sides of the mapping. That's 6 elements (excluding separators). So most applications including docker made various parts optional. You can map two ports to any interface, or opt to specify one interface but not the other one etc. A novice user of a new application might be best served by not using any shorthand forms and only using the fully qualified names everywhere. By spelling out every option explicitly (including optional values) there is no more guessing what may or may not have been configured.

the_only_law 4y ago

> Information is readily available for free As much as people decry the internet and it’s role in modern society, I’m glad that I generally have easy access to massive archives of knowledge.

ravenstine 4y ago

Get rid of the assumption of "frontend first" and most of the complication of web development disappears instantaneously. Something I am appreciating about Svelte/Kit and Phoenix is that they are admitting what was right about PHP and server-rendered webpages. I'm a frontend engineer and think that SPAs have their place, but frontend JS represents a kind of tyranny seen nowhere else in tech.

throwaway81523 4y ago
Phoenix, do you mean the Elixir web framework? I had thought it was Elixir's counterpart to Rails.
- throwawaymaths 4y ago
  Phoenix liveview is server rendered interactive websites.
7speter 4y ago
Its really hard to find proper learning materials to get started with the backend; its all a bunch of shortcuts glued together because the tutorial really wants to show you how to make a react frontend first and foremost.

not_kurt_godel 4y ago

> My friends and I would put together little toy websites with PHP or Rails in a span of weeks and everyone thought they were awesome. Agreed, LAMP was just so damn fun in how you could go from zero to a fully functioning site in a day or two. Having to manage all the statefulness of fetching & displaying data asynchronously from the client adds an incredible amount of complication both in theory and in practice. Also agree that the old tech wasn't necessarily better either - but it sure would be cool if someone could replicate the developer experience from back then and produce a result that's up to modern engineering and UX standards.

antod 4y ago

I think things are more complicated precisely because things got easier. The more complexity we can now handle, the more complexity we will create.

Falkon1313 4y ago
If you think we're actually handling it. Seems to me there's a whole lot of "let's just glue all these black boxes together, cross our fingers and hope they do what we want, and still do the same thing after the next update" vs. in simpler times actually writing and understanding the code.

conductr 4y ago

> Even business software felt simpler. This made me remember how acceptable a developer designed utility used to be. Now, you can barely launch an MVP without finding or paying for design and high quality UX/UI. If you do it’s likely going nowhere in terms of traction. I’m sure this has only seemed to be the new rule and there are a few exceptions. But not many. Even Stripe all those years ago really took off after investing in design. They’ve remained rather polished. But they’re also an exceedingly well funded operation.

matwood 4y ago

> Information is readily available for free (I recall saving up a lot of money for a kid to buy specific programming books at the book store after exhausting my library’s offerings). Gave me flashbacks to when I was younger. I would work on a problem until hitting a wall I couldn't get around then go into Books A Million with pencil and paper and copy concepts/algos out of CS books. I was too poor to spend $50+ on a book at the time. Now, anything a new programmer wants to know is just a Google search away. But, there is so much more that just diving in can be hard. Even simple things are complicated I think mainly because expectations are so much higher.

bradlys 4y ago

> Salaries are much higher and developers are a respected career that isn’t just “IT”. I agree the compensation is higher. I don’t agree the respect is any higher. Software engineer is highly associated with terms like neckbeard, redditor, incel, autistic, etc. I’m extremely hesitant to tell anyone I’m a software engineer. If anything - I’ll lie and say I do product management just to avoid the association. People treat me way better when I say I’m a PM instead of an eng.