4 ms·

To make an analogy here—all programming used to be at most as complex as making a shed in your backyard. Now a lot of programmers are designing and implementing

To make an analogy here—all programming used to be at most as complex as making a shed in your backyard. Now a lot of programmers are designing and implementing the equivalent of high-rise buildings. The existence of the large-scale programming tools creates the sense that you have to use them for your backyard shed projects. The thing is, you don't! Nowadays you don't even have to go out and buy Turbo Pascal in order to practice, you can just create an HTML file on your desktop and open it in your favorite web browser! Heck, if creating a file is too complicated you can press F12 and start scripting right away. Most operating systems come with Python preinstalled, so you can just drop into a REPL at any time, or write a script and run it. Programming hasn't become more complicated to get into, it's just that software engineering is growing up and people are given the false impression that they need to start with the professional tooling. We in the industry should be reminding people how truly simple it is to get started with something small, not bemoaning the existence of the large, complex and nearly interchangeable tools that we have to choose between to work at scale.

danielvaughn 3y ago
I really want to create a series of tutorials on getting started with programming, but with this kind of focus. The biggest risk as a beginner is getting (a) distracted and (b) overwhelmed. By filtering out the noise and starting out small and simple, we'll make it much easier for newcomers to grasp the basics before learning about modern toolchains.
colonelpopcorn 3y ago
At the same time, it used to be expected you would learn to program a computer you bought. So much so, that operating systems shipped with BASIC and a language manual. That is not the case today, but I guess software doesn't ship in the same ways it used to either.
bluetomcat 3y ago
If you don't start with the professional tooling, you may have good fun, but nobody will hire you. When I entered the industry 20 years ago, "software development" generally meant desktop application development (Visual C++, Delphi) and "server-side web development" (PHP talking to MySQL, spitting out HTML). By just knowing how to upload files to an FTP server, you could do your own address book application or CD catalogue, and get hired. Now you need to fool non-technical people into demonstrating "industry" knowledge of a specific combination of Tool A/B/C.
- mbork_pl 3y ago
  > If you don't start with the professional tooling, you may have good fun, but nobody will hire you. You're right, though some people want to learn to program to either have fun, or to make simple tools for themselves (see e.g. the discussion here: https://news.ycombinator.com/item?id=38877423 https://news.ycombinator.com/item?id=38877423; disclaimer: I only read a small fragment, but it seemed very interesting)
  - sim7c00 3y ago
    too right. i am too bored with modern tools and frameworks hence i do not work as a programmer. i wish i could, but i cant get interested in it. not knowing modern tools and frameworks directly makes me unhireable. i always ask people who want to learn. do you want to learn programming, or want to be a programmer? (the later implying hirablility)
- deleted 3y ago
  [deleted]
geff82 3y ago
You are right - Frameworks make building Skyscrapers easier. But it also means that you somehow first have to understand how to build them and THEN you have to understand what you don't need. Sure, starting out with some Python or Javascript interpreter is incredibly cheap and easy. But actually getting into serious programming is.... complicated. It feels like every shed now requires the foundation of the skyscraper.
js8 3y ago
> Now a lot of programmers are designing and implementing the equivalent of high-rise buildings. I get your point, but I think it's a bit of a myth. I work on mainframe applications and when you look at the actual business logic, there is a comparable amount of it in the apps that are 20, 30, 40 years old. I would even say that the modern methods of building software are to the detriment because there is a lot of incidental complexity coming from the tooling. It seems that creation and maintenance of business logic for a given domain isn't really much helped with modern tooling, so it takes about the same time to develop. On the other hand, businesses today are demanding things to be done cheaper with more UX polish. This means that actual software capabilities (which require domain knowledge) are made less general and take more time to develop. I would say today, many applications are simpler in terms of features than 20 years ago.
- lolinder 3y ago
  If by "features" you mean "business logic", you might be right. But UX polish that makes the application accessible to ordinary people who are going to give the app 2-3 minutes to prove itself is a feature, and one that can take an overwhelming amount of engineering to get right. Dismissing that engineering because your mainframe applications do more "work" with less code is shortsighted, a continuation of the "frontend developers aren't real engineers" meme that has finally started to die.
  - deleted 3y ago
    [deleted]
  - daaaaomizez662 3y ago
    It's a feature if you are in the buisness of selling software to end users that need or want that, but that isn't the customer base of mainframe programmers or similar kinds of deep backend work. If all your customers care about is that the paperwork crunching and adding up the numbers gets done right and on time every day (and after that, as cheaply as possible) then it's actively counterproductive to spend resources on a nice frontend. I don't think anybody is implying that there is no market for frontend engineering, just that resources spent on frontend are necessarily resources not spent elsewhere, and that different teams naturally have different priorities.

danielvaughn 3y ago

I really want to create a series of tutorials on getting started with programming, but with this kind of focus. The biggest risk as a beginner is getting (a) distracted and (b) overwhelmed. By filtering out the noise and starting out small and simple, we'll make it much easier for newcomers to grasp the basics before learning about modern toolchains.

colonelpopcorn 3y ago

At the same time, it used to be expected you would learn to program a computer you bought. So much so, that operating systems shipped with BASIC and a language manual. That is not the case today, but I guess software doesn't ship in the same ways it used to either.

bluetomcat 3y ago

If you don't start with the professional tooling, you may have good fun, but nobody will hire you. When I entered the industry 20 years ago, "software development" generally meant desktop application development (Visual C++, Delphi) and "server-side web development" (PHP talking to MySQL, spitting out HTML). By just knowing how to upload files to an FTP server, you could do your own address book application or CD catalogue, and get hired. Now you need to fool non-technical people into demonstrating "industry" knowledge of a specific combination of Tool A/B/C.

mbork_pl 3y ago
> If you don't start with the professional tooling, you may have good fun, but nobody will hire you. You're right, though some people want to learn to program to either have fun, or to make simple tools for themselves (see e.g. the discussion here: https://news.ycombinator.com/item?id=38877423 https://news.ycombinator.com/item?id=38877423; disclaimer: I only read a small fragment, but it seemed very interesting)
- sim7c00 3y ago
  too right. i am too bored with modern tools and frameworks hence i do not work as a programmer. i wish i could, but i cant get interested in it. not knowing modern tools and frameworks directly makes me unhireable. i always ask people who want to learn. do you want to learn programming, or want to be a programmer? (the later implying hirablility)
deleted 3y ago
[deleted]

geff82 3y ago

You are right - Frameworks make building Skyscrapers easier. But it also means that you somehow first have to understand how to build them and THEN you have to understand what you don't need. Sure, starting out with some Python or Javascript interpreter is incredibly cheap and easy. But actually getting into serious programming is.... complicated. It feels like every shed now requires the foundation of the skyscraper.

js8 3y ago

> Now a lot of programmers are designing and implementing the equivalent of high-rise buildings. I get your point, but I think it's a bit of a myth. I work on mainframe applications and when you look at the actual business logic, there is a comparable amount of it in the apps that are 20, 30, 40 years old. I would even say that the modern methods of building software are to the detriment because there is a lot of incidental complexity coming from the tooling. It seems that creation and maintenance of business logic for a given domain isn't really much helped with modern tooling, so it takes about the same time to develop. On the other hand, businesses today are demanding things to be done cheaper with more UX polish. This means that actual software capabilities (which require domain knowledge) are made less general and take more time to develop. I would say today, many applications are simpler in terms of features than 20 years ago.

lolinder 3y ago
If by "features" you mean "business logic", you might be right. But UX polish that makes the application accessible to ordinary people who are going to give the app 2-3 minutes to prove itself is a feature, and one that can take an overwhelming amount of engineering to get right. Dismissing that engineering because your mainframe applications do more "work" with less code is shortsighted, a continuation of the "frontend developers aren't real engineers" meme that has finally started to die.
- deleted 3y ago
  [deleted]
- daaaaomizez662 3y ago
  It's a feature if you are in the buisness of selling software to end users that need or want that, but that isn't the customer base of mainframe programmers or similar kinds of deep backend work. If all your customers care about is that the paperwork crunching and adding up the numbers gets done right and on time every day (and after that, as cheaply as possible) then it's actively counterproductive to spend resources on a nice frontend. I don't think anybody is implying that there is no market for frontend engineering, just that resources spent on frontend are necessarily resources not spent elsewhere, and that different teams naturally have different priorities.