TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: In what ways is programming more difficult today than it was years ago?

237 pointsby luuuzetaover 2 years ago
Reading Peter Seibel&#x27;s <i>Coders at Work</i>, and this is Joe Armstrong on the issue:<p>&gt;Also, I think today we’re kind of overburdened by choice. I mean, I just had Fortran. I don’t think we even had shell scripts. We just had batch files so you could run things, a compiler, and Fortran. And assembler possibly, if you really needed it. So there wasn’t this agony of choice. Being a young programmer today must be awful—you can choose 20 different programming languages, dozens of framework and operating systems and you’re paralyzed by choice. There was no paralysis of choice then. You just start doing it because the decision as to which language and things is just made—there’s no thinking about what you should do, you just go and do it.<p>For context this book is copyrighted 2009 so this interview is more than a decade old, and I&#x27;m sure many things have changed since then.

130 comments

OliverMover 2 years ago
Knowledge of the entire machine&#x27;s activity. When I was a young teenager the home machine of choice was the Commodore 64 and its competitors. When you turned it on you usually had an interactive programming language REPL start up, probably some variant of Basic, and that was it. Off you went:<p><pre><code> No OS to worry about (the machine probably had a very basic BIOS to handle peripherals but that was it) No permissions model A tiny API to interact with whatever graphics&#x2F;sounds facilities were available No need to worry about what resources simultaneously-running programs could be using (there weren&#x27;t any) Actually no need to worry about concurrency at all (you just couldn&#x27;t do it) No need to worry about what language to use (either the one blinking at you when you turned on the machine, or assembly language for the processor) No need to worry about how to restructure computations to use a computation shader or SIMD </code></pre> _You_ were the owner of every resource in the machine and it all danced to your tune. And, best of all, you could come to a complete understanding of how every part of those machines worked, in just a few weeks of practice. Who today knows the intricacies of their laptops to the same extent?
评论 #33063802 未加载
评论 #33062161 未加载
评论 #33064219 未加载
评论 #33064268 未加载
评论 #33063602 未加载
PragmaticPulpover 2 years ago
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.<p>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.<p>Even business software felt simpler. The scope was smaller and you didn’t have to set up complicated cloud services architectures to accomplish everything.<p>I won’t say the old ways were <i>better</i>, 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.<p>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.
评论 #33056411 未加载
评论 #33056500 未加载
评论 #33056520 未加载
评论 #33059980 未加载
评论 #33059060 未加载
评论 #33061266 未加载
评论 #33061447 未加载
评论 #33061990 未加载
评论 #33066354 未加载
评论 #33057664 未加载
thomastjefferyover 2 years ago
Context.<p>We have 1,000 more solutions to 1,000 more problems. We have extensive documentation on all the new things. Documentation is mostly focused on nouns, sometimes on verbs. The &quot;what&quot; and the &quot;how&quot; are easy to find.<p>What we don&#x27;t have is clarity on how they fit together. The overwhelming majority of work done in software is fitting the pieces together in a way that works. The &quot;why&quot; and the &quot;when&quot; are really difficult to pin down.<p>The biggest overhead is trying to conceptualize the systems that make up the foundations of software: operating system libraries, compiler toolchains, shell environments, dependencies, etc.<p>Because there is so much mysticism involved, people who have spent years or decades treating operating systems, package managers, development environments, etc. as <i>playgrounds to explore</i> have an advantage that is difficult to articulate, let alone teach.<p>Anyone learning software today is presented with a lot of exciting opportunities to explore programming itself. There are handy web-based editors where you can write programs that do input and output all in the browser itself. No need to learn about shells or packages or git...<p>But those things we factored out of the learning experience are probably the most meaningful subjects to learn about, if you want to actually create something. It&#x27;s really tricky to find direction to go from vague concepts to working projects.
评论 #33061332 未加载
oppositelockover 2 years ago
I&#x27;ve been programming professionally since about 1994, using C++, Java, Scheme, Python, Go, JavaScript and friends.<p>Today, tools are incredibly better; compilers, debuggers, profilers. I&#x27;ll take something from JetBrains or Visual Studio any day over what I had available in the 1990&#x27;s. There were some gems back then, but today, tools are uniformly good.<p>What has gotten difficult is the complexity of the systems which we build. Say I&#x27;m building a simple web app in JS with a Go backend and I want users to have some kind of authentication. I have to deal with something like Oauth2, therefore CORS, and auth flows, and to iterate on it, I have some code open in Goland, some code open in VS Code and my browser, and as a third component, I have something like Auth0 or Cognito in a third window. It&#x27;s all nasty.<p>If I&#x27;m writing a desktop application, I have to deal with code signing, I can&#x27;t just give it to a friend to try. It&#x27;s doubly as annoying if it&#x27;s for a cell phone. If I need to touch 3D hardware, I now have to deal with different API&#x27;s on different platforms.<p>It&#x27;s all, tedious, and it&#x27;s an awful lot of work to get to a decent starting point. All these example apps in the wild are always missing a lot of the hard, tedious stuff.<p>Edit:<p>All that being said, today, I can spin up a scalable server in some VM&#x27;s in the cloud and have something available to users in a week. In the 1990s, if there was a server component, I&#x27;d be looking for colo facilities, installing racks, having to set up software, provision network connections, and it would take me ten times as long to the first prototype. I&#x27;d have to write more from scratch myself. Much as some things today are more tedious, on net, I&#x27;m more productive, but part of that is more than 25 years of experience.
评论 #33062351 未加载
评论 #33062234 未加载
评论 #33062259 未加载
throwaway09223over 2 years ago
Programming is enormously more complicated today because modern development environments aren&#x27;t designed for simplicity.<p>When I first started programming all of my tools had a simple workflow:<p>* Write a single text file<p>* run a single command to build (cc thing.c)<p>* Run the resulting file as a standalone command<p>People learning to program are often new in general. They&#x27;re figuring out their text editors. Figuring out how to run programs. Figuring out so many basic things seasoned developers take for granted.<p>I became quite fluent in C, writing many, many useful programs with just a single text file. By the time I had a need to learn about linking multiple files in large projects I was already fluent and comfortable with the language basics.<p>Contrast this with modern environments: I need to learn whole sets of tools for managing development environments (venv, bundle, cargo, etc etc etc). These development harnesses all change rapidly and I am constantly googling various sets of commands and starter configs to get things running. These are all things that a seasoned developer will be constantly dealing with on a complex project, but it seems like little effort has been put into creating basic defaults to simplify things for beginners.
评论 #33056567 未加载
评论 #33062305 未加载
评论 #33056757 未加载
评论 #33056528 未加载
评论 #33060268 未加载
评论 #33056710 未加载
评论 #33056697 未加载
silisiliover 2 years ago
For me...the rise of a billion devops tools with their own opinionated designs and syntax.<p>Programming is programming, and the language doesn&#x27;t make a ton of difference to me, though I do have strong preferences.<p>But that is the -easy- part. The hard part is everything else. Jenkins? Gitlab runners? Github Actions? There are at least 5 people regularly use, all have their own way of doing things and syntax.<p>To Docker or not to Docker. Kubernetes? ECS? RPM? How about just lambda functions?<p>What about your config management.. Ansible? Chef? Puppet? Salt?<p>It&#x27;s the worst part of switching jobs to me. Especially when feeling like you have to invest time learning a system that&#x27;s falling(or even has already fallen) out of favor.<p>I used to love the idea of owning the whole pipeline. Now I just want to sit in a hole writing solid code, and let someone else handle all the CI and systems parts.
评论 #33059461 未加载
评论 #33062048 未加载
评论 #33060062 未加载
评论 #33070283 未加载
mr_tristanover 2 years ago
There is so much abstraction going on now, debugging can be very, very challenging. Many systems are distributed and virtualized, so even trying to create a detailed visualization of &quot;what&#x27;s going on&quot; can require mind-boggling amounts of information.<p>Also, even if you understand and agree with Werner Vogels&#x27; mantra &quot;everything fails all the time&quot;, it&#x27;s incredibly challenging to make a truly robust distributed system. There&#x27;s just so much happening so rapidly, low-probability problems become consistent failures as you scale, and the wrong recovery approach can have non-obvious second-order effects leading to bigger problems.
评论 #33059868 未加载
评论 #33061465 未加载
teerayover 2 years ago
The greatest difficulty I find programming today is hard dependency on cloud services without an adequate simulation of those services locally. I strongly believe that you need to be able to run your code, and many teams just can’t without sprawling (expensive) test environments. If you can’t run things on your machine, you sacrifice the ability to experiment without spending time deploying, checking with colleagues about shared test infrastructure, burning cash to run dev clusters, etc., etc. It just slows down the feedback loop.
评论 #33058597 未加载
dale_glassover 2 years ago
Years ago? Not very different. The 90s and before? A few ways.<p>1. Concurrency. Multiple cores are a completely normal thing now, so having to think about how different threads may interact went from a theoretical concern to a very practical one.<p>2. Dependencies. Back then you could just turn on the computer and start coding. Today many things have large amounts of dependencies that need installing, compiling or setting up. Weird problems can happen. I have an issue where VS Code just refuses to autocomplete in the test section of my project. Why? I have no clue, and VS Code is a giant of a thing. It&#x27;s quite easy to spend days or even weeks trying to set things up and work out issues with things that aren&#x27;t even the thing you were trying to write.<p>3. Teamwork. Modern computers allow for large programs, which require teams to develop. A lot of the work in building modern successful software is in organization, record keeping, documentation and working with other people.<p>4. Security. Pretty much everything interacts with outside untrusted inputs, and so it&#x27;s far more important than before to treat every input correctly. Anything from image loaders to parsers to APIs may be exploited.
评论 #33060577 未加载
memsetover 2 years ago
UIs are way harder. Back in the day, you could drag and drop form controls in VB and bind the data to a database without writing a single line of code. Today, every step of that requires boilerplate. Backend, fronted, rest api, and so on.<p>Distributing native apps has gotten harder in some ways with code signing required in order to share binaries without scary pop ups or the OS blocking outright.
评论 #33059073 未加载
评论 #33059317 未加载
评论 #33060143 未加载
iLemmingover 2 years ago
There&#x27;s too much information today. Makes it difficult to focus. We have social media, email, Slack, Discord, Telegram, Hackernews, Reddit, etc. We say that our brains are too distracted. In fact, that all is over-stimulation of neurons.<p>In the past, when we had no Internet, or when the resources for studying were scarce, we would intently stare at the screen, trying to understand what the program does. You&#x27;d have to disassemble and debug the program and even try to explain it to your cat, dog or a rubber duck. These days programmers are often not even familiar with the term &quot;rubber duck debugging&quot;. We would study and read actual RFCs; programming wasn&#x27;t &quot;fish for that stuff on Stackoverflow or Google&quot; kind of thing.<p>We used to let our brains wonder. Thinking about past and present. That allowed us to generate awesome, great ideas.<p>Today we have tons of tools and techniques that seem to be vastly better than the tools we had in the sixties, eighties, and nineties. But if you compare that with how much computational power, memory and storage capacity have expanded since then, and compare with how we utilize that power, somehow it feels like our applications are getting worse, not better.<p>It&#x27;s nearly impossible today to perform any programming without the Internet. And that&#x27;s why programming today is much more difficult than in the past. There&#x27;s too much information. Too many ways to succeed, and even more to fail.
评论 #33064683 未加载
theonemindover 2 years ago
Programming has turned into gluing together mystery meat. You can&#x27;t make a business case for essentially writing every library you need. It would take too long to have anything like modern stuff. So you always deal with a huge pile of unknowns all of the time. The job consists more of the meta-skill of navigating unchartered waters intelligently, but you get dinged for doing the real job and people doing a terrible job get the rewards. The bad people glue the stuff together without trying to understand it, don&#x27;t document stuff, pull in any dependency that gets them closer to their goal, and put up a victory flag when the thing does what they want it to do. Then the war goes on day by day dealing with under-documented stuff and a giant pile of dependencies with no internal logic. The hero goes on to do it again, and a team of saps tries to make sense of a Gordian knot for the rest of the product&#x27;s lifetime.
评论 #33060106 未加载
评论 #33060247 未加载
评论 #33060795 未加载
评论 #33060063 未加载
评论 #33060733 未加载
评论 #33063903 未加载
评论 #33062795 未加载
评论 #33060757 未加载
mikewarotover 2 years ago
Programming in the past was far easier, you had better tools, like Visual Basic, and Delphi. They had excellent built in documentation, with working code examples. Delphi even included an installation builder, for bundling your program. It all just worked. Your program would run in any Windows environment you or your customers were ever likely to use.<p>For the most part, those programs written with those tools <i>still</i> work.<p>Today everything is update on the fly, and subject to random breakage. GIT is better, everything else has gone downhill.
评论 #33059556 未加载
评论 #33060375 未加载
评论 #33059645 未加载
tgflynnover 2 years ago
I think the overabundance of choices is still a major issue but I think an even bigger problem is the growth in complexity of languages and development environments. C++ was already a complex language in 1998. Today it&#x27;s probably at least three times bigger, to the point where being a true expert in the language is almost beyond the capacity of a single individual. Other languages and ecosystems are no better. There&#x27;s little comparison between what you had to know to consider yourself an expert web developer in 2000 compared to today.
评论 #33060110 未加载
评论 #33064428 未加载
thewebcountover 2 years ago
For me it’s the prevalence and growth of tools with completely shitty user interfaces. I started out on the Apple II as a kid. By the time I was ready for my first job, I was doing classic Mac and Windows 3.1&#x2F;95 stuff. The tools were by no means perfect but they seemed to get better and better over time. Comparing, say, Metrowerks Code Warrior to AppleSoft BASIC was a huge improvement. (I could have done without Visual Studio’s tabs within tabs within tabs configuration windows, though.) But overall there was forward progress. You gained significantly more power, but you also gained significant ease-of-use (with some bumps along the way).<p>Fast forward to today and the most painful parts of my day are dealing with shitty tools. git’s incomprehensible interface. Jenkins CI&#x2F;build system that’s barely more than a log of every damn line the compiler outputs, but split up in a way that somehow makes it even harder to figure out what went wrong when something does go wrong. JFrog’s Artifactory that looks like it’s having seizures when you search for the thing that Jenkins built. And then when you find it, it lists the path, but you can’t click on the path to download it. There’s a separate button in a different place for that. These tools feel like they did a user study and whenever something was easy for the user, they threw that out and figured out a way to make it harder. Interacting with this shit is infuriating, especially when you’re on a deadline to get something out the door. I feel like I’m taking crazy pills when I bring up these problems and other people just shrug. As if that’s the way it’s always been and it can’t be changed.
评论 #33060013 未加载
jll29over 2 years ago
1. Yes, overburdened by choice is indeed one of the main challenges today.<p>2. And the pace of development, not because one cannot learn fast enough, but what one has learned will quickly be made obsolete because of &quot;developer fashion&quot; (favourite front end JS frameworks, anyone?). This happens because communities are important, e.g. for answering dev questions and fixing bugs, so one cannot adopt a &quot;dead&quot; framework. Each new language suffers from lacking essential libraries, components (and for managers: talent for hire), so it is risky to adopt one that has not yet accrued critical mass, yet it is also risky to miss a trend.<p>3. Computer security for many systems is critically important yet very difficult, and attackers are everywhere.<p>On the upside, in the past, machines were more heterogeneous, however today there are just a few survivors: Windows, Mac OS X, Linux and in the mobile space Android and iOS. Because many apps are Web apps, cross-platform has become easy, although the user experience of a Web app in no way is comparable to a native app. WASM is likely to address some of that, and - I hope - will remove much of the ugliness of abusing the HTML+HTTP paradigm intended for technical documentation for distributed application.
评论 #33060531 未加载
asciimovover 2 years ago
The low hanging fruit has been taken.<p>Years ago, a curious individual could solve some basic problem, maybe its a better file system, or a better kernel, or a new scripting language. Your program might take off, and you could build eventually find an entire industry around the problem you tackled.<p>Today, that&#x27;s unlikely to happen. Gone are the days of some people hacking in their room creating a solution to some problem. Most of the &quot;low hanging&quot; fruit is now in very niche areas, you will have to do some extensive study just to understand the problem well enough to approach it.
评论 #33072283 未加载
sirabenover 2 years ago
Setting up developer environments has become vastly more complicated than it was in the past. With language-specific package managers, ad-hoc installation processes (along with surreptitious editing of shell config files under the user&#x27;s nose), variety of operating systems, library versions and instruction sets, trying to get reproducible builds and environments seems close to impossible without some unified tools such as Nix or well-written Dockerfiles. This is even before issues such as resolving dependency conflicts and trying to work with out-of-tree changes to dependencies and patched dependencies.
irrationalover 2 years ago
I’ve been doing web development since the mid 90s. In the beginning it was just plain html files that you would manually ftp (not even sftp) to a web server. Later it was html, css, and JS - but it was still a manual process. Eventually jQuery was added to help since nobody was standards compliant and instead of writing different css&#x2F;JS for every browser, you just used jQuery and it took care of making it work on every browser. Files were still manually uploaded to the web server. Then came ES5. That led to an enormous floodgate of complexity. Suddenly you were expected to have a build system to transpire code to match the lowest browser specs you would support. Then came more complex front end code via react&#x2F;Vue. Then came typescript. Then came pipelines like Jenkins. And docker. And serverless architecture. And it is absolutely mind boggling how complicated web development is today when It is still just plain html, css, and JS being delivered to the browser.
评论 #33063961 未加载
yodsanklaiover 2 years ago
&gt; you can choose 20 different programming languages, dozens of framework and operating systems and you’re paralyzed by choice.<p>In practice, a lot of these choices are already made of us. When you join a new project, the space of choice is limited. But when choice is too be made, what I find difficult is that you need to reach a consensus with your colleagues. When you&#x27;re introverted, it&#x27;s taxing. There&#x27;s always some person that needs extra convincing.<p>Code review wasn&#x27;t as pervasive and can be tiring too. Sometimes you need to explain again and again why you made that decision (it was in a design document, it was discussed in a meeting, and then the question is brought again in the code review).<p>But the worse part for me is the accumulation of abstraction layers and dependencies. I&#x27;m working on a project with tons of internal dependencies that are loosely specified and documented, all of them introduce some unreliability. The whole edifice is fragile, and yet is expected to work 24&#x2F;7. This causes a lot of stress.
评论 #33056343 未加载
评论 #33059495 未加载
jasoneckertover 2 years ago
While I agree with many of the other comments here, I&#x27;ll offer one more way in which programming is more difficult today: speed.<p>30 years ago, nearly all projects I worked on were waterfall and my development team was far more relaxed. Spending days tinkering and thinking of a good solution was valued over sprints and rapid commits. Of course, we got far less done back then, but it was also less stressful (in my experience, at least).
continuationalover 2 years ago
When I started out, there was DOS. It came with a command you could type in: QBASIC.<p>Typing this one magic word brought up an IDE, including an editor with highlighting, an interactive help system, samples, an in-editor REPL, and single-key shortcut to run the program. I can&#x27;t remember if it also came with a debugger and a way to create stand-alone executable, or if that came later.<p>It had built in commands for drawing, input and sound, all well documented. And the UI was straightforward and intuitive.<p>This doesn&#x27;t really exist anymore.
评论 #33056583 未加载
评论 #33062921 未加载
评论 #33059694 未加载
评论 #33059222 未加载
mike31frover 2 years ago
I think it&#x27;s a lot easier to build what you have in mind than it was 20 years ago when I started because of increasing levels of abstraction and also because of open source.<p>20 years ago, if I needed to convert a json file to xml (that&#x27;s a very bad example because 20 years ago JSON was just born and nobody used it, but no other example as simple as that one comes to mind, sorry ), that would have taken me days of coding just for that single utility function. And probably lots of headaches with regular expressions or syntaxic&#x2F;semantic parsing.<p>Today, I type &quot;npm install json2csv&quot; and I&#x27;m done.<p>The only thing that might be harder for people starting today is that the level of abstraction is so high today that we almost don&#x27;t even need to understand the underlying computer science to be a developer, and so the few rare times when you do need to understand what&#x27;s going on behind the scenes, that might be complicated. Other than that it&#x27;s only advantages.<p>Progress and history always go this way, things always get easier and cheaper to build. I don&#x27;t see why programming would be different.
评论 #33059928 未加载
评论 #33064494 未加载
评论 #33059146 未加载
wglbover 2 years ago
This is a great book--it starts with JWZ (duct-tape programmer) and ends with Donald Knuth. (One theme that runs through the book is that nobody likes C++ and nobody uses debuggers.)<p>When I read that section, I wasn&#x27;t really convinced. Not that programming is not quite different than it was way back when, but the difficulty that we face is that there is so much more software around. Some bad, some good. Many more useful tools.<p>For example, since I started programming the following innovations have significantly added to tools that we have to apply to programming:<p><pre><code> * The C language. Much better than writing high-performance code in assembler. * SQL. The power of SQL is extraordinary. * Lots of disk space. Now we don&#x27;t have to store our programs on punched cards. * Extraordinary increase in memory. * Networking, beyond dial-up connectivity. * Other highly useful languages, such as Python * Google, probably the top-used resources by programmers * IDEs </code></pre> The illusion that we are hampered by lots of choice is a bit illusory. Usually our programming environment is set not by our own individual choice, but often by the environment we plug into--by what resources we are going to access, and other team decisions.
评论 #33073943 未加载
thewebcountover 2 years ago
Oh, the other way that things have gotten more difficult is that documentation now seems to lack the depth it once had. For example, I tend to use Xcode for development. There are all sorts of functions within the app that I know about but can’t comprehend (like the memory graph), and the docs are barely more than a screen shot labeling everything and giving a 2 sentence description of it at the most basic level. Like on the memory graph, what do the different symbols tell me? Why are some blocks of memory represented by a square, and some by … what is that? A pyramid? What’s the significance? How does that help me in tracking down my memory bug?
评论 #33061054 未加载
logicalmonsterover 2 years ago
The standards for software are definitely elevated.<p>Maybe about 20 years ago, if you had a website that allowed users to post a comment and upload a small jpeg, it was considered crazy bonkers cool.<p>Today, you probably need some advanced 3d UI that communicates with your phone and millions of users in real-time with geotracking and 100 other features to get a pizza to your door in under 5 minutes to barely raise an eyebrow about the technology.
dagmxover 2 years ago
Security is harder.<p>Devices have become more complex and interconnected. Expectations for software are also higher, while there’s more resources poured into finding and exploiting vulnerabilities.<p>Keeping on top of all of that, isolating your memory access and permissions, etc… is a lot harder today than it was even a few years ago.<p>In every other way I think programming is easier now. Languages are more ergonomic, even the ones that are decades old. Libraries are more easily available and there are tons more resources today than ever before for learning.
gw99over 2 years ago
Well my pet hate is that I write a lot of YAML. It&#x27;s poorly structured, unreliable, nuanced, schemaless and difficult to edit reliably. I <i>prefer XML and XSLT</i> to this shit show. Oh and unnecessarily distributed things.<p>In summary, apparent simplicity that causes actual complexity is a big problem now.
评论 #33074012 未加载
评论 #33064587 未加载
dtagamesover 2 years ago
There&#x27;s some truth to this, but unless you&#x27;re in a senior architect position or starting a clean sheet project, it&#x27;s unlikely that you&#x27;ll have the freedom to choose your platform or framework as a programmer. Like pilots, most people will start out doing &quot;short haul&quot; work on existing equipment and routes. This means you&#x27;ll have to learn the frameworks that your employer (or desired employer) uses.<p>And those things, frameworks and platforms, are the biggest technical burdens for programmers today. The ability of the web to create what we used to call &quot;interactive apps&quot; (but are today just apps) has lead to the desire and expectation that all web content will take on this level of polish and appearance. While that&#x27;s possible, it&#x27;s also arduous. In today&#x27;s world, you must also learn the frameworks, tooling, and CI&#x2F;CD processes that lead to your work making it onto someone else&#x27;s screen. That&#x27;s a whole lot harder than what we used to do -- like when publishing meant copying a floppy and putting it in an envelope, for example.<p>The ability of platforms to change their specs and rules all the time (and their insistence on doing so) is another new programmer burden. In the old days, one could write to a piece of hardware or OS and expect that code to run for a long time. Not so anymore. Now the hardware is virtualized and many layers of middleware and SaaS are required to make your code do anything. All of those are moving targets and will change out from under you, without your desire or permission, while you try to continue to deliver new code and service your old code.<p>Finally, and this is the final nail in the coffin for some more experienced programmers, the misunderstanding of the concept of &quot;agile&quot; or &quot;XP&quot; and how it became scrum -- a series of micromanagement theatrics and paperwork pushing -- has made programming a lot more difficult and a lot less fun. One of the best parts of software development was the unpredictability and experimentation that led to innovative results and small, incremental improvements. Close contact with customers was also a hallmark of early software development. Today&#x27;s top-down, &quot;How long will it take you to write and debug a feature that doesn&#x27;t exist?&quot; management mentality cannot and does not lead to quality software, as everyone can tell. It does lead to programmer burnout, quiet quitting, and a lot of wasted time in dev shops.
评论 #33056223 未加载
eitlandover 2 years ago
When I started VB and Java Swing interfaces were allowed.<p>Today, every single business application is somehow supposed to have its own design language and can&#x27;t use any standard UI library.<p>Also, deeply ironically, I think now certain web applications are now heavier than Swing applications (obviously not IDEs, but ordinary applications).
jleyankover 2 years ago
Sorta sad. Decades have passed and it’s harder to program machines that have staggeringly more resources. One would have thought that some amount of overhead could have been added to create an abstract environment to work in. Ah well, more job security with complexity I guess.<p>And I assume most people are considering web applications rather than native. If so, it’s like a full circle from xterms…
coffeedanover 2 years ago
I think programming is made worse today by how programmers are managed. Agile, Kanban, Scrum, JIRA - they’re all there so upper management can get a sky high view of what’s going on, but it’s all based on “estimates” that are often shots in the dark. They might give the CEO a warm, fuzzy feeling, but they’re often based on fiction. And I waste half my day in “planning poker”, “retrospectives”, “standups” - yuck.
评论 #33064319 未加载
评论 #33062766 未加载
Alacartover 2 years ago
I don&#x27;t think it is more difficult than it use to be. There&#x27;s more layers in some cases, but most of the time those are abstraction layers that making things <i>easier</i> (or at least attempt to).<p>I think the difference is maybe one of perception. We can do more so the baseline expectations of users&#x2F;customers are higher. I also think that there has been a higher growth of people specializing in one area rather than every programmer sort of being a full stack generalist by default. So for a front end specialist, databases and server side may seem like a black box and more complicated than ever. Or someone specializing in kernel programming might think front end is more complicated than ever.<p>Generally you can still do things the way they were done in the past if you want to. New tools might make things easier and learning them might seem complex, but you don&#x27;t have to.
MonkeyMalarkyover 2 years ago
I feel like the existence of sites like stackoverflow have led to less quality in available documentation. Like the responsibility has been offloaded.
评论 #33059775 未加载
评论 #33059420 未加载
falcolasover 2 years ago
Marketing.<p>Every choice we make as developers today not only has to be vetted by the team, it has to fight against all of the other options and the opinions created by people who are paid to convince others to use <i>their</i> solution.<p>I’ve had to push back against both my peers and managers who suggest technology that’s been marketed to them. And by push back, I mean spending days researching these new technologies to see if they’re just an old technology with new wrappings, a VC backed promise that’s still a few years from being usable, or doesn’t solve the problem at all.
gU9x3u8XmQNGover 2 years ago
Honestly; navigating the corporate and other “professional” systems is the nightmare for me - especially in big business.<p>I won’t go into too much detail, as it will just turn into a vent. And the current industry direction in general doesn’t make it easy (containers, industry leading black-box “solutions”, system admin and security).<p>In my immediate experience; cowboys that just “do” no matter the risk, informed or not; are really thriving right now. Not sure if this is a post-pandemic large lockdown results driven thing..<p>But if you follow good&#x2F;great practice, are a responsible, policy and process following individual - constructive and critical thinker; you’re in for a hard time. Smaller firms seem to handle this better, in my past experience.<p>Theres also a group of individuals in between these two that seem to be struggling.
评论 #33064702 未加载
Veuxdoover 2 years ago
Maybe not harder, but microservices have made programming more frustrating. You have reduced freedom to write business logic; now most of your code is infrastructure, connections, and security (you are using the internet as a data bus, after all). Programming with microservices feels like practicing taekwondo in a closet.
评论 #33060617 未加载
c2h5ohover 2 years ago
Much larger projects. More and more often you are working on just one aspect of something bigger, without having a good grasp of the whole thing. Situations where you and maybe a small team own entirety of a project are less and less common.<p>Concurrency and multi-threading. To get good performance you used to care about a single thread on a single CPU core that you had exclusive access to. Now you have to utilize multiple cores, care about context switches and in even more extreme cases handle NUMA memory architecture. It&#x27;s hard and the fact it&#x27;s slightly less hard with go is one of the reasons of the language popularity.
dynamite-readyover 2 years ago
The weight of user expectations, and the tools created to meet them. In between this, the big tech companies have leveraged this situation to put large segments of software developers on a treadmill, by using open source projects and excellent marketing, to impose a &#x27;soft&#x27; form of standardisation on common practices (best demonstrated by React &#x2F; Typescript).<p>My tongue is in my cheek, but I often wonder.
jollybeanover 2 years ago
A lot of arbitrary complexity in our stacks and it can be totally overwhelming for young people just moving through the drudgery.<p>Look at an Android project: there are maybe 12 different kinds of files! For a &#x27;Hello World&#x27;. You have manifests, gradle (which is yet another programming language), snippets in Kotlin and Java, and entirely different xml &#x27;language&#x27; for view definition, massive APIs, massive complexity and &#x27;weight&#x27; in the simulators.<p>It&#x27;s hard for people to focus on the problems space when were are overwhelmed with layers of tooling and abstractions.
gajusover 2 years ago
Expectations. If you look back at software 20 years ago, even the most popular websites had relatively low complexity, both in terms of UI and functionality. A single person could have built most of them and value came primarily from content. Even early versions of Google were not that complex to build. Now the entry barrier for a minimum valuable product has dramatically increased to the point where it takes a big team and years to develop a program&#x2F;website that passes the expectations of a user for their primary website&#x2F;program.
lr4444lrover 2 years ago
There&#x27;s no time to do things correctly: only &quot;pretty well&quot;. The bar for productivity in terms of time to iterative deliverable business value is getting higher, and it&#x27;s frustrating having to make quality&#x2F;throughput trade offs.
akitzmillerover 2 years ago
About 20 years ago, I was at a pharmaceutical company and, to put together a web application, - we had to buy a prod and a dev database server - we had to buy a prod and a dev application server - we needed Oracle as a database - we needed a DBA, a sysadmin, and a hardware team - we needed Tomcat &#x2F; Java and Oracle development expertise<p>The idea of developing and running this application with a single person would have been laughable.<p>Today, because tools are soooo accessible, I can, and do, routinely spin up my own VM, apply Puppet, drop my MySQL and Django containers onto that VM, and pull https certificates in addition to doing the front and back end software development.<p>Life would be waaay simpler if I could just write server side web application code and wait around for database developers, sys admins, and front-end folks to do their thing. Imagine not having to learn a testing harness because there are actually people testing the software!
评论 #33059534 未加载
RickJWagnerover 2 years ago
Just so much crap to learn.<p>I started in the mainframe&#x2F;COBOL days. There, the programs could be sophisticated but the systems documentation was excellent. Just a little complex and you really had to understand algorithms and such.<p>Then came client&#x2F;server. That brought transaction monitors (like Tuxedo) and took away the benevolent dictator model (IBM) that gave you transactions practically for free. New stuff to learn, pitfalls to avoid.<p>Then came J2EE. A ton of complexity and false starts on fledgling technology. XML processing, etc. Finally REST came along and made things somewhat understandable-- but still you had to manage transactions finally.<p>And now we&#x27;re in the Kubernetes age. Once again, tons of infrastructure to learn, but a strong framework. (So somewhat like the mainframe days.)<p>It&#x27;s all a big circle. You have to constantly learn. I really think it is harder to get on board now than it was in the past.
BiteCode_devover 2 years ago
Fads, noise vs signal ratio, paradox of choice, economical pressures, culture wars, value signaling taking over, incentives to bs&#x2F;fake, sea of unskilled juniors, higher customer expectations, everything talks to the networks, OSes vendors policies, legacy everywhere, faster path of technical change, legal and corporate contexts...<p>Also if you start today, you gotta learn some part of the pyramid your abstractions stand on, and that&#x27;s growthing work as time passes.
acdover 2 years ago
In the past write monolith, debug one application and one database. Attach debugger to monolith. Cache in ram&#x2F;l3 cache. Deployment copy monolith binary in placce, run it.<p>Now, write distributed micro service. Many many programs. Many databases and queues. How do I debug that? How do I monitor that. We get scalability minus L3 cache access. Now deployment orchestration. Win zero down time deployment.
评论 #33060089 未加载
dragonwriterover 2 years ago
I think the quoted excerpt fro the book hits the big problem. Up into the 1990s, you had a narrow range of well-supported options built in on most platforms, often with bundled hardcopy or online docs, and it was a pain to find or get more options and information on those other options, so where to start was an easy choice.<p>Now, getting a decent toolchain takes some (usually small, but nonzero) effort, and there is a flood of conflicting information on every decision, including that first step.<p>Information overload and analysis paralysis bite hard.<p>(If you can get past that initial hurdle, things are immensely better than any time else in history in most ways, though the trap of getting overwhelmed by info and options is persistent.)
specialistover 2 years ago
We used to spend more time programming.<p>What passed for project management before XP and Agile wasn&#x27;t great. But at least it didn&#x27;t impose ridiculous administrative burden onto devs.<p>Gods, we used to complain about doing weekly status reports. Now it sounds like heaven.
martin_aover 2 years ago
I&#x27;d like to add a datapoint from my professional life. I work with a very niche-specific automation solution for the print industry.<p>That solution always had some scripting capabilities, which were a subset of JS with some software-specific extensions. Nothing really fancy, a few useful things were missing but overall there always was a way to reach your goal.<p>As I&#x27;m not doing developments daily this &quot;low-tech&quot; approach was nice: One file that would be copied to your production system and linked there and that&#x27;s it. For debugging you had the integrated logging interface, a web-based thing, not too fancy.<p>One or two major release ago, they switched to a TypeScript&#x2F;NodeJS based scripting system.<p>While I can now &quot;glue parts together&quot; by using npm, I also have to transpile my code after every change and have to run an extra step to &quot;package&quot; everything for deploying it. Creating a new script requires a specific console command which will then prepare the file &amp; folder structure.<p>Debugging can, in theory, still be done through the web-based interface, but the recommendation is to set up a launch.json file, so VS Code can directly connect to the software on a pre-defined port and you can set breakpoints and step over your code while it&#x27;s being run. I&#x27;m sure that&#x27;s cool for hardcore programmers, but maaaaaaaan, ain&#x27;t nobody got time for that if you&#x27;ve got business stuff to run.<p>Somewhat anecdotal, but I spent 4 hours on Friday with trying to extract numbers from a txt file and write them to another file. Reading the file, running a regex, that&#x27;s no big deal.<p>But creating a temporary file is a HUGE pain with the new system. In the old system it was something like: var fh = job.createNewFile(&#x27;test.txt&#x27;, &#x27;UTF-8&#x27;); and you could then work with your file handle.<p>Now I&#x27; fiddling around with the third npm package to create temporary files and it seems like the problems is not me using the packages wrong but how those packages try to create a file in a Windows environment which fails.<p>To be honest: I&#x27;m still guessing that&#x27;s the problem and need to ask some smarter people, but thing like that &quot;just worked&quot; before.<p>Oh: And now everything is async, which really gives me headaches, or you have to create a function which can then be called with an await so everything else waits for it...
Wesmioover 2 years ago
My younger colleagues have not experienced they need to play and upgrade their systems.<p>Swap? What&#x27;s that? Network stuff? Huh? I have wifi.<p>They have a laptop, a.good one, and that&#x27;s just it.<p>And while security should always have been a thing, the chance that you write an application accessable on the internet is much higher today than 10 or 20 years ago.<p>Beside that, there a much better tools available and easier to use than ever before. Building a whole platform is possible with a small team.<p>Building a highly scalable self healing zero downtime system is basically gifted to you when following modern practices like good java frameworks (magic) and k8s
ronyfadelover 2 years ago
Deploying has become a nightmare.<p>It used to be transfer your source files via FTP, now it’s setting up Docker and Kubernetes and I don’t know what.<p>Ofc the latter is better for teams, but now you must learn a whole stack just to deploy code.
评论 #33060542 未加载
the_jesus_villaover 2 years ago
It was definitely easy to jump from learning HTML to learning that I can run code on the backend and render the output by just adding a tag like this:<p><pre><code> &lt;?php $data_from_backend = [whatever I need to do on backend]; echo $data_from_backend; ?&gt; </code></pre> Right there inside the same document, rather than learning about Node, APIs, a templating engine, etc. It kind of just worked and was very simple. Of course, for professional apps this caused a ton of problems and now using PHP that way is seen as something from the dark ages.
评论 #33060113 未加载
mkl95over 2 years ago
Many companies are OK with distributed systems but they don&#x27;t wanna invest the resources to set up proper observability and monitoring.<p>At those companies fixing a bug that would be relatively straightforward with a monolithic architecture is a humongous pain in the ass.<p>Technically, programming is not more difficult than it used to be. But in practice it is, due to how expensive and complicated it is to know what is going on, and how little the average manager cares about it.
softwaredougover 2 years ago
Dependencies are more complicated.<p>You used to know and a few basic APIs (your OS, your stdlib…). You’d probably spend more time implementing basic utilities. However now you have to manage a complex software supply chain of dependencies of varying quality and security risk.
noufalibrahimover 2 years ago
The setup.<p>My first language was GW-BASIC on an IBM compatible. Turn on the machine, type GWbasic and hit enter. You get the IDE, the editor and everything else in a single shot. Zero barrier. You could write decent programs in it and gave you that ongoing sense of achievement. Nowadays, you have a long series of things to do (clone a template, setup your editor&#x2F;environment, download this and that etc.) just to get started.
unity1001over 2 years ago
Years ago your users would be educated professionals in different large organizations or the government. Today, anyone can be your user. Creating easily usable software for the general public and daily use is more difficult than creating software that will be used for educated professionals.
apatheticonionover 2 years ago
Depends on what kind of programming and at what point you&#x27;re at.<p>Learning programming today is difficult because of context. Some kids don&#x27;t even know what a file system is. The idea of an interpreter evaluating a text file doesn&#x27;t click because what even is a text &quot;file&quot;?<p>Being an intermediate application developer I would argue is easier than before and possibly the best place to be in your career. Web Development with React and Angular turns front end development into a more complex excel-like experience. It&#x27;s still programming, obviously, but the tools take a lot of the complexity out of it and a lack of experience has you blissfully ignorant of anti-patterns and a lack of testing.<p>Back end web developers have the best life (technologically speaking). Complete control of the runtime, any language they want to use and normally pretty straightforward implementations. Security and testing are often overlooked but that&#x27;s okay.<p>Senior application developers hold so much context that they are often frustrated by the design decisions of the tools they use. &quot;Why can&#x27;t we all write web applications with Rust, except using JavaScript modules because Rust modules are terrible, but only once Web Assembly has access to the DOM - actually the web sucks and we should write native applications. I can&#x27;t wait to retire.&quot;<p>Devops is both harder and easier. It&#x27;s easier to build a scalable reliable system, but is harder to get started because, while a simple cloud VM is still available, you feel dirty if you haven&#x27;t provisioned everything using some form of orchestration.<p>Desktop application developers are in the worst place possible. Microsoft doesn&#x27;t even know what GUI API it wants to use. No one uses Apple&#x27;s native Desktop API, Linux is.... anyway (don&#x27;t flame, I love GTK4). The best option is Electron until everyone is using a single platform.<p>Mobile development is hard af, there are almost no engineers in the field and you need a PHD just to install Android studio and pick the right Android SDK.<p>All in all, I love it
rr808over 2 years ago
Security is a point that hasn&#x27;t been mentioned. My first job the corporate was barely attached to the internet. We could deploy applications internally with completely lax security, never had to worry about TLS or account management or often even passwords.
ericmcerover 2 years ago
It&#x27;s interesting his choice is around what programming language you choose, as I kinda assume everyone I work with will be a solid programmer just as a baseline requirement. How well you can slot your code into complex systems and how to design those systems is usually what is difficult.<p>We have way better resources for learning but also much higher expectations. You need to be able to write good code without much thought so that you can maintain a higher level of context while programming. Sometimes you get to write just a nice little isolated bit of code, but usually there are a lot of moving pieces. (no matter how functional and immutable we try to make it.)
kragenover 2 years ago
We waste all our time getting flamed by assholes on this website instead of programming.
评论 #33061176 未加载
thdxrover 2 years ago
think the rise of the metacreators in software contributes to a lot of noise which indirectly makes things difficult<p>lot of people with large followings espousing opinions and practices when they hardly spend time shipping product. this makes it hard, for even someone senior and experienced, to know what they should pay attention to. sometimes it feels like you should pay attention to things you fundamentally know doesn&#x27;t make sense. and a lot of energy goes into unwinding mainstream rhetoric<p>I cite this as difficult because while most of the other hard parts of software are enjoyable, this one is just an energy suck
minhmeokeover 2 years ago
Vetting all your software, hardware, and firmware dependencies to ensure that they are trustworthy. Today&#x27;s software is often very complex and comes from such a wide variety of sources that we rely on third-party security experts to do this, rather than trusting a single vendor as was done in the past.<p>Ensuring that your software will still function in 20 years. Previously you had shrink-wrapped software packages on physical media with explicit releases and versions. Now everything depends on cloud services and APIs which could change or disappear at any moment.
nurettinover 2 years ago
Most programmers today have never seen a single user, single process machine. They did not experience a constrained hardware or used a compiled language. They just want to layer their over-bloated lego pieces until the job gets done. Have a roach infestation? Bring in the entire military and all intelligence agencies to do the job. Most of them won&#x27;t even know theory. Let&#x27;s just layer more ifs and more logic until it is done. State machines? Constraint solvers? Logarithmic complexity? That&#x27;s the job of the next developer. I rely on pure IQ.
jongjongover 2 years ago
The challenge nowadays is navigating the layers upon layers of unnecessary complexity. It&#x27;s not even possible to choose the best tool for the job anymore because managers have been primed to only accept certain tools and it&#x27;s impossible to convince them otherwise. The herd mentality is too strong.<p>Imagine being a firefighter and your boss tells you that you can&#x27;t use a water hose to put out the fire; instead you must use either a portable fan or a flamethrower. That&#x27;s what programming feels like these days.
评论 #33064285 未加载
parastiover 2 years ago
A little off topic, because I can&#x27;t think of any ways in which programming is harder now. IMO getting into programming is easier than ever. The most popular language in the world (Javascript) is installed on nearly every computer and you can start programming with a single keystroke that opens devtools. Create a canvas and you&#x27;re ready to dive into graphics programming with OpenGL. That stuff used to require a compiler, SDL, drivers, and what not. Really curious to see actual ways in which programming itself is harder now.
评论 #33059780 未加载
syntheweaveover 2 years ago
The number one thing that is difficult is that there are lots of problems that have been already solved, but not well. Whereas at the beginning, being first to solve and ship the resulting features as a product was significant, and performance optimization was often a key enabler of feature viability, now quality of solution has lept to the forefront. No crashes, security errors, data loss or corruption. With high quality comes a larger degree of process.<p>It&#x27;s not a bad thing. It just means that knowing one language and some algorithms - formerly the exact skillset of a typical CS grad - isn&#x27;t really &quot;enough&quot; to do anything. Instead it&#x27;s whole stacks of software that an organization has staked their own project on. At an old company, they built most of the stack, but nobody who built it is around anymore. At a new company, it&#x27;s open source, but they don&#x27;t have anyone to spare to maintain it. Eventually there is some threshold that gets crossed where the stack is the problem, and that drives an attempt at solving things better.<p>But it&#x27;s no longer the case that most orgs have to build most of their own software; it&#x27;s nearly always glue and one piece of special sauce.
debacleover 2 years ago
Libraries and APIs 25 years ago were expensive, well-documented, and stable.<p>Users had much lower expectations.<p>Programming was slow and intentful. Programming today is much more stressful, I think.
usgroupover 2 years ago
I think there were fewer programmers and programming was applied to fewer things. I think over time both aesthetic variability, new entrants and the proliferation of corporate backed super frameworks (which carry needless complexity from day zero and assume all sorts of needless deployment scenarios) became common place.<p>The likelihood that the next thing you do sees you scurrying about Stackoverflow even after 20 years in the job, is quite high now.
georgeburdellover 2 years ago
It’s not just the choices; as others have pointed out, there “needs” to be a CI&#x2F;CD pipeline in place for even simple projects just because. Unit testing, integration testing, automated builds and deployments. And yet somehow code is as buggy as ever because the Internet has enabled Day 1 patches. When I started programming, you got software on a diskette, so the consequences for non-working software were severe.
intelVISAover 2 years ago
It&#x27;s only harder if you make it so, the buzzword &#x2F; abstraction fog has gotten quite thick, I feel lots of shops lose sight of the basics.<p>Advances in automation and tooling make it easier than ever to develop complex projects with lean teams but it can&#x27;t be done if your org opts to inherit a brittle dependency chain every time &quot;I don&#x27;t want to reinvent the wheel&quot; surfaces.
anovikovover 2 years ago
I think the main difficulty is that programming that actually gets things done, these days requires a lot of collaboration and thus, soft skills. Because you can&#x27;t get much done by yourself anymore. And soft skills is a thing nerds naturally suck at, which makes personal qualities demanded from a good programmer sort of self-contradicting.
kidsilover 2 years ago
Noise. So much noise. I miss being able to write code for hours without any distractions via Slack &#x2F; Email &#x2F; Zoom.
wagslaneover 2 years ago
It&#x27;s so much easier today when it comes to good tooling, scalability of services, specialized tools, etc.<p>It&#x27;s so much worse today when it comes to things like paralysis of choice and configuration.<p>I&#x27;ve been working on a new project for Boot.dev students and the goal is to get them a simple but professional dev environment on their machine. It&#x27;s a very hard problem.
GMoromisatoover 2 years ago
I talked about how programming has evolved (and become more difficult) here: <a href="https:&#x2F;&#x2F;gridwhale.medium.com&#x2F;gridwhale-and-a-brief-history-of-computing-be24e5263328" rel="nofollow">https:&#x2F;&#x2F;gridwhale.medium.com&#x2F;gridwhale-and-a-brief-history-o...</a><p>As always, the core issue is complexity. We expect our programs to do much more than before, and that requires additional complexity.<p>But we already know how to deal with complexity: we add a layer of abstraction. The problem, in my view, is that current abstraction layers are either too low-level (e.g., React) or tackling only part of the problem (e.g., AWS Lambda).<p>With GridWhale, I&#x27;m working on creating a layer of abstraction that appears as a single, unified machine that you have full control over, but is actually running on a distributed, scalable micro-services architecture.<p>I&#x27;ve got a long way to go, but I think this is the right direction.
评论 #33064775 未加载
ChicagoBoy11over 2 years ago
There&#x27;s some story online of the guys behind SICP talking about why they abandoned the traditional lisp-based course for its modern python variant, but the gist of it is that, according to them, the kind of &quot;blank sheet of paper&quot; coding that the book was sorta based on is rarer and rarer these days, and that much more of the work revolves around understanding other people&#x27;s codebases&#x2F;ideas and building things on top of other people&#x27;s software. I think this can also serve as a potential shift that could be considered being &quot;harder&quot; in terms of modern computing... in a world where the ecosystem is pretty barren, walking from the very middle to the edge is pretty easy... the more it evolves, the more challenging that trek is.
评论 #33063463 未加载
cat_plus_plusover 2 years ago
Same reason why building a house is so much more difficult than it was years ago - mind numbing, overwhelming bureaucracy. It&#x27;s easier than ever to solve an important personal, business or non profit need in 10 lines of code, but coding environments are not optimized for such needs. Everything has to be portable, and scalable, and localizable and accessible and graphical and event driven and tools wouldn&#x27;t let you just have user fill in a single language form from beginning to end and press a button to process it using high school level math or 70s era text parser. What is forgotten is how many ideas need to start quick and dirty and gradually mature if rising need justifies the resources.
dadogeover 2 years ago
Established companies with opinionated infrastructure can help with this.<p>I sure wouldn’t want to write the backend of a crud app in Fortran, nor the front end. Or do anything with Fortran besides scientific computing (Fortran = Formula Translator…it was built with a limited use case in mind!)<p>Companies that adapt to newer frameworks and not write everything in C++ are more efficient, but only if they control how much variation of tooling there is within a discipline.<p>So today, you do have to specialize in a discipline a bit more (front end, backend, data) but each discipline has a sensible set of tools IMO. A developer can and should get some exposure to a secondary discipline to be well rounded and “T-shaped”, but should also appreciate the value of specialization.
评论 #33056140 未加载
ameliusover 2 years ago
Programming is still easy for the most part, except now you have to pay 30% to a feudal lord.
评论 #33061950 未加载
Gooseyover 2 years ago
The Micro-Services trend.
Jemmover 2 years ago
Put simply, systems now are designed for teams of people and automated testing. This adds complexity and verbosity not necessarily needed for small shop projects.<p>The reliance on Design Patterns (Gang of Four) went from nice to use, to mostly required.<p>So many developers now go right in to coding without learning other skills. The result is software to automate or help a system that the coders don&#x27;t really know how to do manually and it shows. These coders know one language, one framework and maybe very good at that but they don&#x27;t actually know how a computer works or why what they are doing work.
patrulekover 2 years ago
Everything is changing a lot faster. You must put a lot of effort to catch up with trends in different domains or be lazy and specialize in only one without certainty that you (your knowledge) will not be useless in a few years.<p>Fast growing businesses that require more workforce than market can provide. This result in more inexperienced developers writing code and frustration of the experienced developers (if they have to work with the former ones).<p>Too much of dubious quality blog posts (we now have too much information we need to verify with opposite to having too little information that was hard to find years ago).
AnimalMuppetover 2 years ago
It&#x27;s far more complicated, because the expectations are different.<p>Once upon a time, &quot;UI&quot; was &quot;print the output to a file&quot;.<p>Then it was some interconnected CICS screens.<p>Then it was some interconnected web pages.<p>Now it&#x27;s some interconnected web pages that also display properly on mobile devices, that display in the user&#x27;s chosen language (and numeric format), that displays properly no matter the user&#x27;s screen size, that hopefully allows blind users to use a screen reader, that respects Europe&#x27;s privacy laws, that has good security...<p>It&#x27;s easier now because we have better tools. It&#x27;s harder now because the baseline expectations are so much higher.
CyanLite5over 2 years ago
Anybody remember the C10K challenge?<p>In the 90s you could count on one hand the number of large scale systems that could support thousands of users concurrently.<p>Any half-decent mobile app these days could easily get to a few hundred thousand concurrent users.
jmartin2683over 2 years ago
As many have noted, it’s harder because you’re now starting at a much higher level of abstraction. This makes it very, very difficult to develop an understanding of how any of this stuff actually works. As we push further and further away from the actual machines doing the work, understanding everything that makes up that huge stack gets way more complicated.<p>Always start at the bottom and work up. You’ll avoid much of the frustration of confusion, at the expense of a slow start. Most importantly, when you’re done you’ll be useful at every level.
FpUserover 2 years ago
There are number of laws preventing things from doubling indefinitely every X years in physical world. Unfortunately when it comes to software the amount of bullshit doubles every year without any end in sight.
dijonman2over 2 years ago
The people make it harder. 20 years ago it was exclusive to those who had passion. Now it’s full of people who just want to get paid and that changes the interpersonal dynamic significantly.
ravenstineover 2 years ago
The amount of software that needs to be maintained is far greater, therefore there aren&#x27;t as many &quot;quick wins&quot; to be found anymore. Not to say that new software isn&#x27;t being written all the time, but more and more of what makes up the typical software developer&#x27;s job is to constantly fix bugs and sacrifice standards to get things done with to Eldritch horrors of codebases. We cope by installing tools like Eslint and telling ourselves it means we have &quot;standards.&quot;
mrietover 2 years ago
Many of the technical problems have been solved by frameworks: persistence, transactions, concurrency, etc.<p>The business processes covered by systems have grown much more complexer. The organizations have grown larger because software is doing more (more safely and easily).<p>The modern programmer faces thus larger organizations, larger&#x2F;more-sided discussions and far a complexer social, political and business-related landscape than 20 years ago.<p>While the technical problems have gotten much easier, in general.
camjohnson26over 2 years ago
Only thing I can think of is we’re so much farther away from the hardware now because of layers of virtualization. 20 years ago the code more or less mapped directly onto a physical reality and you could dig in to it intuitively if something went wrong.<p>Now with dynamic languages, interpreters, docker, kubernetes, AWS and layers of dev tools and frameworks it can be harder to know what your code is actually doing. But those abstractions can also give you superpowers.
评论 #33056620 未加载
winddudeover 2 years ago
The speed in which the cutting edge advances. When you&#x27;re focused on something I find especially at a job, you&#x27;re less exposed to advances and less focused on experimentation.<p>Yes, like you said the massive amount of code and options, often each with their own trad-offs and advantages<p>The hardest thing is sometimes not always chasing the newest and latest thing to gain a bit of performance, or improving an f score, etc.
comfypotatoover 2 years ago
Organizing information exchange in such a way that respects agent autonomy and heterogeneity. Developers have choices; programming environment infrastructure and interfaces between the developed systems need to allow the people to do what they want and still communicate. They way I just press “share” on my phone and can instantly port whatever content to whatever other application is a marvel.
sys_64738over 2 years ago
The layers to get the the hardware is absurd. Just layers of pure garbage to abstract everything away making it feel slower than 25 years ago.
mbrodersenover 2 years ago
It isn’t. Programming today is <i>so</i> much easier, in every single way, than it used to be 40 years ago when I learned how to program. I am pretty sure that people making a living today, programming by copy-pasting code from Google searches, would have had <i>real</i> trouble programming without the internet back then.
aapplebyover 2 years ago
The overabundance of both frameworks and CPU performance causes programmers to massively overdesign systems that end up underperforming.
carapaceover 2 years ago
In a word: complexity.<p>Everything else has gotten better: the machines are almost-inconceivably faster and larger (in capacity, logical size; in physical size they are of course ever smaller!), the compilers are smarter than ever, the languages more ergonomic and safer, etc.<p>The only downside, the great undertow, is burgeoning complexity. A &quot;thundering herd&quot; attack on the human mind.
giantg2over 2 years ago
Monoliths were easier and more reliable.<p>Sure microservices are faster to elevate and more reusable, but the systems have become a birds nest of dependencies. A lot of the time our troubleshooting relies on the other teams that own those services. Coordinating and communicating takes significant overhead and inevitably leads to occasional issues.
dehrmannover 2 years ago
User expectations are higher. The era of the solo developer making meaningful applications is largely over.<p>There&#x27;s also the Rick Cook quote:<p>&gt; Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
agumonkeyover 2 years ago
A lot of stuff today has to be networked, cross platform (although web and other stacks lifts you quite above) and security. Your clean code can be abused by botnets in so many ways. This didn&#x27;t exist at large before internet.<p>Also society&#x27;s pace. Things moved more seasonally.. nowadays there&#x27;s &lt;lang&gt; fatigue in many places.
nvarsjover 2 years ago
I agree with Armstrong here. Just look at the Kubernetes landscape. It’s easy to get crippled by the vast array of choices for every little thing. It’s a consultant’s dream though.
naniwaduniover 2 years ago
Almost every <i>concrete task</i> is easier, or at least not meaningfully harder.<p>But getting to that point where you feel like you&#x27;re accomplishing something, where what you&#x27;ve produces feels like it measures up to the standards you&#x27;ve been taught to expect, that barrier&#x27;s gone up so much faster.
zffrover 2 years ago
There are lots of versions of things and online content doesn’t always specify what version it applies to. This can lead to confusing situations where things that are supposed to work don’t work for you.<p>For example, there’s still a lot of python 2 code snippets that won’t work now that python 3 is the default interpreter.
jstx1over 2 years ago
They had fewer options to choose from but they didn’t have discussion forums, stackoverflow, youtube and all the other wonderful resources to get help and learn from. And once you decide what to work on, most of those other options out there don’t affect you at all. It seems pretty great if you ask me.
otikikover 2 years ago
The field has expanded. Things are deprecated but still in use. AI synthetic 3D coexists with supermarket machines using a version of Windows 98 for embedded systems, an a bank mobile app written in electron talking to a Java API which eventually calls COBOL.<p>And all that has to work, kindof. It’s a bit crazy.
nitwit005over 2 years ago
Most things you get hired to work on make use of the internet. It used to be rare.<p>That comes with a lot of problems. You end up dealing with user accounts, authentication, request retries, what to do if the server is down, etc. Plus all the security and abuse issues.
ynbl_over 2 years ago
its too big of a field to say. lots of things are easier and lots are harder. PHP being phased out makes things much easier. languages are cleaner now (as in cleaner than php). hardware is worse (laggy monitors, keyboards, GUIs, internet connections flying all over the place and spamming popups in your face), but CPUs are faster. newer build systems are somewhat cleaner, but theres tons of system complexity as usual, probably worse than before. while a lot of RCE problems are being fixed, security is harder now with worse solutions on offer (for example, identity being solved by ad hoc junk like recaptcha, SMS, photo id, video, web based authentication providers).
tester756over 2 years ago
Hmm, I do wonder... are people better at software engineering now than they were 2 decades ago?<p>Testing, architectures, patterns, principles, software life cycle, building abstractions, system modeling etc.
lvl102over 2 years ago
Think programming was easy up until 90s then it got really hard in 00s and then it started becoming a lot easier along with advances in cloud around 2015-16.
RockingGoodNiteover 2 years ago
Social politics. Can&#x27;t say a thing today that would have been seen as funny in a diverse team 20 years ago. We&#x27;re like robots in Teams chat.
issaover 2 years ago
There is certainly a lot of choice, but when is the last time you had to:<p>- really worry about disk space or memory size<p>- check if something would work on IE<p>- worry about version control<p>- manually scale something
评论 #33060504 未加载
zasdffaaover 2 years ago
Library&#x2F;ecosystem size. They&#x27;re now abso-bloody-lutely massive, and more than a single person can hold in their head.
f0e4c2f7over 2 years ago
Google doesn&#x27;t work as well now. You kind of have to know more tricks to still be able to find similar quality information.
评论 #33056277 未加载
评论 #33060496 未加载
throw_m239339over 2 years ago
One word: Bureaucracy.<p>But I understand that in the context of large teams.<p>Coding itself is the exact same thing as 40 years ago, input, processing, output
评论 #33063137 未加载
hulituover 2 years ago
Programmers don&#x27;t write widgets anymore. They write OpenGL surfaces. And they must wait for vsync to blink the cursor.
neilobremskiover 2 years ago
Programming is now more opaque configuration than it is traceable logic paths. This makes paper debugging impossible.
tyingqover 2 years ago
Chasing dependency chains. Both due to the sprawl, and things like vulnerability scanning.
hbrnover 2 years ago
We used to write code for computers.<p>Today code is written for humans.<p>Mostly by people who aren&#x27;t great communicators.
mylonsover 2 years ago
the entire javascript ecosystem
rektideover 2 years ago
Lots of good answers about here. I think the individual coder&#x27;s struggle is pretty well covered via many good points. But I think we haven&#x27;t looked at this question from much of a big picture. So here&#x27;s some of the challenges that make programming difficult today, on a bigger scale:<p>Weirdly, I think the biggest difficulty <i>is</i> that we are much better served. A huge amount of what we do is well paved. React, bundlers (which are fairly isomorphic to each other webpack&#x2F;rollup&#x2F;esbuild&#x2F;parcel&#x2F;snowpack&#x2F;vite), Systemd, Kubernetes, React, gRPC&#x2F;protobuf, npm&#x2F;node, even uring or eBPF... the list of well entrenched technologies is high. There&#x27;s better set ways to do things, well served, than there used to be.<p>The difficulties show up in a number of fashions. First, it precludes innovation, is highly stasist, when there is a humming along underbelly that maintains life. In the Matrix, the Elders of Xion admitted it was just highly automated machines that kept life alive, and in some ways our ascent upwards has decoupled us similarly; we&#x27;re rarely liable to go back &amp; reconsider the value of trying other ways. We&#x27;re kind of &quot;stuck&quot; with a working set of system layers, that we don&#x27;t innovate on or make much progress on. Our system layer is pretty old and mature. Everything is ingrown &amp; interlocked, depends on the other things.<p>When we do try to break out, rarely is it precisely targetted reconsiderations: often the offshoot efforts are from iconoclasts, smashing the scene &amp; building something wildly different or aggressively retro. Iconoclasts seek pre-modern times, rather than a new post-modern alterations or rejiggerings.<p>Another difficulty with having vastly more assumed is that there&#x27;s less adventurers in the world, less find-out-the-truth&#x2F;roll-up-your-sleeves&#x2F;dig-in&#x2F;read-through-the-source mentality &amp; experience (and more looking only on the surface for easy &quot;solutions&quot;). Being generally well served means we rarely go off the beaten path. So our wilderness survival skills&#x2F;resourcefulnesses are attrophied, and newcomers are less likely to have developed these deep hunting skills that used to be both simpler (because our systems back then were simpler, had less code) and more essential. A lot of these modern works aren&#x27;t even <i>that</i> hard to dig into. But there&#x27;s shockingly few guides for how to run gdb or a debugger on systemd, few guides to debgging kube&#x27;s api-server or it&#x27;s operators, few people who can talk to implementing gRPC.<p>I don&#x27;t think we&#x27;re at crisis levels at all, but i think the industrial stratification &amp; expectations of being well served will start to haunt us more and more across decades, that we&#x27;ll lose appreciation &amp; comprehension (alike the Matrix problem), we&#x27;ll fail to make real progress.<p>GraphQL is an interesting case-study to me. It rejected almost all common web practices &amp; went back to dumb SOAP like all-purpose endpoints. The advantage of just getting the data you ask for was good, of not having to think about assembling entities, of having a schema system. But so many of these things are things the actual web can and should be good at. We spent a long time having schema systems battle each other, but that higher-level usable web just kept failing to get built out, so total disruption made sense. We still haven&#x27;t a lot of good replacements for GraphQL, still haven&#x27;t made strong gains, but still, it feels like GraphQL is somewhat fading, that we&#x27;re less intimidated by making calls &amp; pulling data than we used to be.
lamontcgover 2 years ago
I think its easier to learn to develop software now than it was at peak Java&#x2F;Object-Orientation.<p>A lot of the abstraction then was simply mind boggling, and while the patterns all still exist today a lot of them have been simplified by language features and put on a diet.
zeroonetwothreeover 2 years ago
There’s so many more regulations and rules. You can’t just spin up a website without considering GDPR and a million other regulations, you have to create a privacy policy, consider deletion, recovery, etc.<p>Sure we have some frameworks and such to make this easier but it really puts a damper on experimentation and raises the barrier of entry significantly.
iepathosover 2 years ago
I think this Fortran quote is hilarious cause that language is ugly and awful to work with, which is why no one uses it anymore. &quot;no paralysis of choice&quot; yeah, no choice of a more readable and maintainable language to work with.
评论 #33067914 未加载
jrochkind1over 2 years ago
web development is just so much more complicated, there are so many different parts and choices. I honestly don&#x27;t understand how someone figures it all out today!
ffwacomover 2 years ago
Non technical management are putting in their 2 cents.
dqpbover 2 years ago
Cargo cult worship of OOP runs deep in the workplace.
aaronbrethorstover 2 years ago
JavaScript frontend dependency hell, for starters.
ww520over 2 years ago
Complexity of the platforms and packages.
ikirisover 2 years ago
people have like... expectations.<p>I miss the days where you could hate your users and the code didn&#x27;t have to like have a SLA.<p>&#x2F;s
throwaway0asdover 2 years ago
Hands down the greatest problem for programming as a profession&#x2F;industry is talent identification. Every couple of years some new job board or head hunter claims to solve this problem, but they never do. The problem remains unsolved, and the reason is because there is no agreement upon definitions of minimally acceptable competency.<p>The effect is guessing. Everybody guesses on whether a candidate can potentially do the job. Some of those new hiring start ups might be slightly better at guessing, but its really still just job boards or head hunters with a large margin of error.<p>The way other industries solve this problem is to establish baselines of accepted practice. If you exceed the baseline you may or may not be employable, but you do at least exceed the minimal technical qualifications to practice. This is true of professions like: teacher, truck driver, lawyer, doctor, nurse, accountant, real estate, fork lift operator, and really just about everything else. Unfortunately, most software employers spend all their candidate selection effort attempting to determine minimally acceptable technical competence instead of more import things, such as soft skills, and even still its often just guessing.<p>Other industries apply this solution in one of two ways: education plus a required internship that may result in a license or education plus a license followed by an agent&#x2F;broker relationship. Education may refer to a university education or a specific technical school depending upon the industry and&#x2F;or profession.<p>To mitigate hiring risks, since everybody is just guessing anyways, employers turn to things like tools and frameworks to ease requirements around education and&#x2F;or training. This is problematic as it frequently results in vendor lock-in, leaky abstraction problems, and catastrophic maintenance dead-ends when a dependency or tool reaches end of life. Even still potentially having to rewrite the entire product from scratch every few years is generally assumed to be less costly than waiting for talent in candidate selection since there is no agreed upon definition of talent and hiring is largely just guessing anyways.<p>All of this makes programming both easier and more difficult, depending upon which side of a bell curve your capabilities reside. Reliance upon tools to solve a very human competence problem is designed to broaden bell curves which allows more people to participate but also eliminates outliers. This means if you, as a developer, lack the experience and confidence to write original software then you might perceive that programming today is much easier. If, on the other hand, you have no problem writing original software without a bunch of tools and dependencies you may find software employment dreadfully slow and far more challenging than it should be for even the most simple and elementary of tasks.
slimover 2 years ago
keeping up with dependencies, I guess, is the main hassle.
throwaway285255over 2 years ago
I am forced to use tools, languages&#x2F;frameworks that are inferior and very slow and cumbersome. It feels like I&#x27;m always forced to hop on one leg, when I could simply just run and get where I need to go orders of magnitude faster.<p>Every single ticket I get, I just immediately see for my mind&#x27;s eye: a couple of tables, and a couple of queries. And sometimes if it&#x27;s something really weird, I see 5-10 lines of shell script.<p>But I&#x27;m &quot;not allowed&quot; to use those tools, and instead I have to use ORM, Object Oriented Data Model, different JSON translation operations, grotesque frameworks and in the end spend three weeks of very frustrating wasteful work, trying to coerce these humongous tools to achieve the simple feature, that would have just been three days of easy pleasant work if I was &quot;allowed&quot; to use a database.<p>I worked in a bank in 2006 and we used VB6 to create CRUD based apps in no time, which were super stable, fast and responsive. Just a simple MVC stack, query the database, get recordsets, render a view. This was a really simple task back then.<p>Now it takes ages and so so much work and effort to create an equivalent web based app, which is always slow and buggy, and the work is mainly incredibly frustrating trying to reverse-engineer and figure out some inane &quot;smart&quot; logic in a framework, that tries (and fails) to automate a task that was already very simple and quick, and didn&#x27;t need automating at all.