[HN Gopher] Ask HN: In what ways is programming more difficult t...
___________________________________________________________________
Ask HN: In what ways is programming more difficult today than it
was years ago?
Reading Peter Seibel's _Coders at Work_ , and this is Joe Armstrong
on the issue: >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. For context this book is copyrighted 2009
so this interview is more than a decade old, and I'm sure many
things have changed since then.
Author : luuuzeta
Score : 122 points
Date : 2022-10-02 14:17 UTC (8 hours ago)
| Veuxdo wrote:
| 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.
| mdaniel wrote:
| I don't think "reduced freedom" was the intention with
| "microservices" in that their contract was the network
| boundary. That said, I am 100% on-board with microservices made
| $x more frustrating because _deploying_ a service is one thing,
| _managing_ and _upgrading_ it is a whole other can of worms
| thdxr wrote:
| think the rise of the metacreators in software contributes to a
| lot of noise which indirectly makes things difficult
|
| 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't
| make sense. and a lot of energy goes into unwinding mainstream
| rhetoric
|
| I cite this as difficult because while most of the other hard
| parts of software are enjoyable, this one is just an energy suck
| zasdffaa wrote:
| Library/ecosystem size. They're now abso-bloody-lutely massive,
| and more than a single person can hold in their head.
| mr_tristan wrote:
| 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 "what's
| going on" can require mind-boggling amounts of information.
|
| Also, even if you understand and agree with Werner Vogels' mantra
| "everything fails all the time", it's incredibly challenging to
| make a truly robust distributed system. There'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.
| dhosek wrote:
| My traditional way of understanding a program was to find
| main() (or it's equivalent) and find my way through the code
| from there. In modern codebases, this doesn't work at all. I do
| find it a bit amusing that younger devs find it magical that I
| can trace through code without running it and find bugs.
| atomicnumber3 wrote:
| Yeah, I agree, and I didn't even start all that long ago. For
| many programs, if you read main, all it does is kick off
| thread pools and then wait. And so to find the "entry point"
| you have to know how all the whatever (be it http or
| whatever) handlers work for this system. And it also feels
| like this kind of stuff is the first thing people end up
| DIYing / NIHing so even when languages or stacks have normal
| ways of doing things, somebody has always come along and
| muddied the water at some point and now you're stuck with it.
|
| Even UI is so damn hard these days because it's all
| JavaScript with a truly pitiful standard library and needs to
| handle 50 different screen sizes and browsers and run on both
| gaming desktops and 30 year old phones running leaked android
| pre-releases.
|
| I'll say it. I miss my days of programming in Java Swing. May
| GridBagLayout forever bless your pack()s.
| sys_64738 wrote:
| 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.
| gw99 wrote:
| Well my pet hate is that I write a lot of YAML. It's poorly
| structured, unreliable, nuanced, schemaless and difficult to edit
| reliably. I _prefer XML and XSLT_ to this shit show. Oh and
| unnecessarily distributed things.
|
| In summary, apparent simplicity that causes actual complexity is
| a big problem now.
| camjohnson26 wrote:
| 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.
|
| 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.
| Aromasin wrote:
| I've been a hardware engineer for the past few years and I do
| think a lot of it seems greener on the other side. I use FPGAs
| and microcontrollers for a whole host of things, along with
| traditional electronic elements.
|
| The tools more often than not want me to pull my hair out
| (coded mostly in Tcl...), the technical forums and support are
| often non-existent, and the technologies quite often haven't
| been update with QoL changes in 20+ years.
| falcolas wrote:
| Marketing.
|
| 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 _their_ solution.
|
| 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.
| slim wrote:
| keeping up with dependencies, I guess, is the main hassle.
| mike31fr wrote:
| I think it'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.
|
| 20 years ago, if I needed to convert a json file to xml (that'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/semantic parsing.
|
| Today, I type "npm install json2csv" and I'm done.
|
| 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'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's going on behind the scenes, that might be
| complicated. Other than that it's only advantages.
|
| Progress and history always go this way, things always get easier
| and cheaper to build. I don't see why programming would be
| different.
| ycuser2 wrote:
| > Today, I type "npm install json2csv" and I'm done.
|
| You have to do a little bit more: You have to search for it and
| decide which of the n converters you will use (licence, other
| dependecies, ..)
|
| But I get your point.
| routerl wrote:
| You just made something click for me.
|
| My parent was an electrical engineer. While their skillset
| was varied, and heavily weighted towards physics and math,
| their day job was mostly about knowing how to pick parts out
| of a catalogue, which catalogue to use when, and maintaining
| good relations with the suppliers behind those catalogues. I
| always saw this as a weird disjunction.
|
| Until now.
|
| I've just realized that while my core skillset is in math,
| logic, computer science, and system design, I do spend a lot
| more of my time researching repositories, packages, licenses,
| etc, than actually coding. But with the new perspective your
| comment gave me, I finally saw that as totally in line with
| other, older engineering disciplines.
|
| So, to address the original point of this thread, it seems as
| if programming has finally evolved into a semi-mature
| engineering discipline, wherein our ability to gauge the
| quality of existing supplies is more important than our
| ability to produce new supplies.
| rileyphone wrote:
| Brad Cox had a concept of Software ICs, in the chip sense,
| that align with this. He envisioned these as sharable
| objects rather than just libraries, but either way that's
| the present we've been given accidentally.
| pdntspa wrote:
| I'm not so sure about that, CPAN was a thing as early as 1993,
| and I remember loving the articles in Visual Basic Programmers
| Journal reviewing various libraries and OCX controls. If
| whatever it was had some popularity, you would probably find
| _something_ that could do the conversion.
|
| But whether it was free or not? Maybe another matter entirely.
|
| And worst comes to worst there was always some awful code to
| cut-and-paste on ExpertSexChange
| mylons wrote:
| the entire javascript ecosystem
| siraben wrote:
| 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'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.
| martin_a wrote:
| I'd like to add a datapoint from my professional life. I work
| with a very niche-specific automation solution for the print
| industry.
|
| 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.
|
| As I'm not doing developments daily this "low-tech" approach was
| nice: One file that would be copied to your production system and
| linked there and that's it. For debugging you had the integrated
| logging interface, a web-based thing, not too fancy.
|
| One or two major release ago, they switched to a
| TypeScript/NodeJS based scripting system.
|
| While I can now "glue parts together" by using npm, I also have
| to transpile my code after every change and have to run an extra
| step to "package" everything for deploying it. Creating a new
| script requires a specific console command which will then
| prepare the file & folder structure.
|
| 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's being run. I'm sure that's cool for hardcore
| programmers, but maaaaaaaan, ain't nobody got time for that if
| you've got business stuff to run.
|
| 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's no big deal.
|
| 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('test.txt', 'UTF-8'); and you could then work
| with your file handle.
|
| Now I' 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.
|
| To be honest: I'm still guessing that's the problem and need to
| ask some smarter people, but thing like that "just worked"
| before.
|
| 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...
| hbrn wrote:
| We used to write code for computers.
|
| Today code is written for humans.
|
| Mostly by people who aren't great communicators.
| dagmx wrote:
| Security is harder.
|
| Devices have become more complex and interconnected. Expectations
| for software are also higher, while there's more resources poured
| into finding and exploiting vulnerabilities.
|
| 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.
|
| 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.
| otikik wrote:
| 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.
|
| And all that has to work, kindof. It's a bit crazy.
| ravenstine wrote:
| The amount of software that needs to be maintained is far
| greater, therefore there aren't as many "quick wins" to be found
| anymore. Not to say that new software isn't being written all the
| time, but more and more of what makes up the typical software
| developer'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 "standards."
| thewebcount wrote:
| 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/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).
|
| Fast forward to today and the most painful parts of my day are
| dealing with shitty tools. git's incomprehensible interface.
| Jenkins CI/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.
| whartung wrote:
| > For me it's the prevalence and growth of tools with
| completely shitty user interfaces.
|
| Indeed.
|
| I'm old school green screen hack, but I think that user
| interfaces are a black hole of time and bike shedding.
|
| Back in the day it was a green screen. If you were lucky, you
| might have line drawing characters. Mind, we're talking smart
| terminals and curses level work here, vs block mode IBM
| displays, but still. When options are limited, there's less
| time spent on discussing and implementing options.
|
| Did people settle? Yes, they did. They made do, they made it
| work, and work got done. I recall a tire store running a linux
| desktop with their work order system some green screen app in a
| terminal. Yet, tires still got mounted and sold.
|
| I think they've changed recently, but Lowes used a terminal
| based UI for all of their order taking and work orders. Whether
| it was a stove or carpet installation or buying a couple of
| chaptiks and a 30 pack of batteries. The employees were adept
| at navigating it and got the job done.
|
| Did they require training? Of course they did. But training was
| required no matter what the UI was, as they UIs simple encase
| process. Process unique to the company, and those processes
| always have to be trained. Just raw truth.
|
| I'm no artist, I have no color sense, my layouts are a
| struggle, and putting 3 fields on a 5K screen is challenging no
| matter what. But I think the real values of the capabilities of
| modern UIs are marginal at best for most routine use cases,
| specifically in the back office (where the vast majority of
| software is designed and written).
| BlargMcLarg wrote:
| Most people aren't spending days on their UI. The bike
| shedding is happening where it affects you no matter what you
| run.
|
| I dunno why this place has an obsession with 'le good old
| ways', but either way it's not the elephant in the room.
| CyanLite5 wrote:
| Anybody remember the C10K challenge?
|
| In the 90s you could count on one hand the number of large scale
| systems that could support thousands of users concurrently.
|
| Any half-decent mobile app these days could easily get to a few
| hundred thousand concurrent users.
| Wesmio wrote:
| My younger colleagues have not experienced they need to play and
| upgrade their systems.
|
| Swap? What's that? Network stuff? Huh? I have wifi.
|
| They have a laptop, a.good one, and that's just it.
|
| 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.
|
| 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.
|
| 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
| AnimalMuppet wrote:
| It's far more complicated, because the expectations are
| different.
|
| Once upon a time, "UI" was "print the output to a file".
|
| Then it was some interconnected CICS screens.
|
| Then it was some interconnected web pages.
|
| Now it's some interconnected web pages that also display properly
| on mobile devices, that display in the user's chosen language
| (and numeric format), that displays properly no matter the user's
| screen size, that hopefully allows blind users to use a screen
| reader, that respects Europe's privacy laws, that has good
| security...
|
| It's easier now because we have better tools. It's harder now
| because the baseline expectations are so much higher.
| Goosey wrote:
| The Micro-Services trend.
| iepathos wrote:
| 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.
| "no paralysis of choice" yeah, no choice of a more readable and
| maintainable language to work with.
| agumonkey wrote:
| 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't exist at large before internet.
|
| Also society's pace. Things moved more seasonally.. nowadays
| there's <lang> fatigue in many places.
| dale_glass wrote:
| Years ago? Not very different. The 90s and before? A few ways.
|
| 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.
|
| 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's quite easy to spend
| days or even weeks trying to set things up and work out issues
| with things that aren't even the thing you were trying to write.
|
| 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.
|
| 4. Security. Pretty much everything interacts with outside
| untrusted inputs, and so it's far more important than before to
| treat every input correctly. Anything from image loaders to
| parsers to APIs may be exploited.
| mdaniel wrote:
| > Why? I have no clue, and VS Code is a giant of a thing
|
| That experience is why I relentlessly bang on the drum of "do
| not swallow errors" because it makes troubleshooting
| indescribably hard
|
| I would guess the more links in the call/dependency chain, the
| more opportunities for misplaced assumptions or laziness to
| sneak in, leading to your cited outcome
| GMoromisato wrote:
| I talked about how programming has evolved (and become more
| difficult) here: https://gridwhale.medium.com/gridwhale-and-a-
| brief-history-o...
|
| As always, the core issue is complexity. We expect our programs
| to do much more than before, and that requires additional
| complexity.
|
| 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).
|
| With GridWhale, I'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.
|
| I've got a long way to go, but I think this is the right
| direction.
| nurettin wrote:
| 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't even know theory.
| Let's just layer more ifs and more logic until it is done. State
| machines? Constraint solvers? Logarithmic complexity? That's the
| job of the next developer. I rely on pure IQ.
| georgeburdell wrote:
| It's not just the choices; as others have pointed out, there
| "needs" to be a CI/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.
| dadoge wrote:
| Established companies with opinionated infrastructure can help
| with this.
|
| 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!)
|
| 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.
|
| 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.
| tgflynn wrote:
| > each discipline has a sensible set of tools IMO
|
| More like 4 or 5 distinct sets of tools and that collection
| changes every few years.
| dadoge wrote:
| That's fine. I'd rather use Airflow than Luigi,
| BigQuery/Snowfake over Hive.
|
| Evolution is generally good.
|
| So, yes, within a discipline there is more than one tool, but
| often only 1 or 2 current tools that are mature and worth
| using if you're starting a new project
| debacle wrote:
| Libraries and APIs 25 years ago were expensive, well-documented,
| and stable.
|
| Users had much lower expectations.
|
| Programming was slow and intentful. Programming today is much
| more stressful, I think.
| tester756 wrote:
| Hmm, I do wonder... are people better at software engineering now
| than they were 2 decades ago?
|
| Testing, architectures, patterns, principles, software life
| cycle, building abstractions, system modeling etc.
| tgflynn wrote:
| 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'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's little comparison
| between what you had to know to consider yourself an expert web
| developer in 2000 compared to today.
| jll29 wrote:
| Indeed, it's a monster language - every 5 years it looks
| completely different, but it'll take 15 years to get even the
| mainstream compilers to implement the changes from 5 years
| before.
|
| It makes little sense to violate everything we know about
| language design (esp. regarding simplicity and orthogonality)
| and the cognitive limitations of humans (esp. developers) and
| keeping the Frankenstein language alive.
|
| It got hashtables in its standard library only when everyone
| and their dog had already been forced to implement their own
| for 15 years!
|
| And STL is so complicated that Stroustroup joked that he
| couldn't have done it if Alex Stepanov hadn't been able to pull
| it off. That may be a compliment to Stepanov's intellect, but
| it isn't a compliment for C++'s design.
| dqpb wrote:
| Cargo cult worship of OOP runs deep in the workplace.
| jleyank wrote:
| 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.
|
| And I assume most people are considering web applications rather
| than native. If so, it's like a full circle from xterms...
| eitland wrote:
| When I started VB and Java Swing interfaces were allowed.
|
| Today, every single business application is somehow supposed to
| have its own design language and can't use any standard UI
| library.
|
| Also, deeply ironically, I think now certain web applications are
| now heavier than Swing applications (obviously not IDEs, but
| ordinary applications).
| memset wrote:
| 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.
|
| 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.
| gw99 wrote:
| Oh yes this. I wrote a timesheet system in VB4 32-bit back in
| the day in 4 days and rolled it out to 10,000 users. And it
| worked. And it stayed working for 15 years until it was
| replaced.
|
| In 4 days worth of work now, I couldn't even do an evaluation
| of which UI tech is still going to be around in 2 years...
| mike_hearn wrote:
| Code signing requires you to buy certificates, but that's the
| sort of thing you can delegate to a non-technical assistant as
| it mostly involves filling out forms, getting access to the
| corporate credit card and/or receiving phone calls. In very
| large organizations you probably have code signing certs
| already and will need to find who has access to them, although
| there's no theoretical reason why you can't have different
| departments independently buy certificates for the same
| organization.
|
| The bigger pain, and one reason why desktop apps became less
| popular, is that with the rise of macOS and (to some extent)
| Linux, you need to distribute your app to three platforms all
| of which use different code signing technologies and
| approaches, none of which are portable/standards based or
| convenient. Also, software update was ignored by platform
| vendors.
|
| Nowadays things are a bit different. Windows got MSIX, which is
| a real package manager and which can silently upgrade apps in
| the background on a schedule even if they're currently running.
| macOS has the widely used Sparkle framework for updates and of
| course Linux has had updating package managers for a long time.
|
| Up until recently it was still a pain to actually use all those
| technologies, even though maybe developing your
| {JVM,Electron,Flutter,native,etc} app was itself quite pleasant
| and easy. My company has made a tool to fix that [1] and so you
| can now build self-updating Windows/Mac/Linux packages from
| your app files and all the signing is handled for you locally.
| It's an abstraction over the platform-native distribution
| technologies designed with an obsessive focus on being as
| simple as web app distribution is.
|
| Making this stuff easy in turn opens up possibilities for
| (re)simplifying the dev stack. For example, in some cases you
| could now make an app that just logs in directly to your RDBMS.
| No need for a backend/frontend, REST, JSON, web server
| frameworks, giant JS transpiler pipeline etc. Just use a real
| GUI toolkit and connect it directly to the output of queries.
| Any privacy or business logic can be implemented this way using
| a mix of row-level security [2], security-definer stored
| procedures [3] and RDBMS server plugins (e.g. [4] or [5]).
| There are lots of nice things about this, for example, it
| eliminates a lot of nasty security bugs that are otherwise hard
| to get rid of (XSS, XSRF, SQLi etc).
|
| [1] https://www.hydraulic.software
|
| [2] https://www.postgresql.org/docs/current/ddl-
| rowsecurity.html
|
| [3] https://www.postgresql.org/docs/current/sql-
| createprocedure....
|
| [4] https://tada.github.io/pljava/
|
| [5] https://pgxn.org/dist/plv8/doc/plv8.html
| nhance wrote:
| If you haven't been watching the low-code/no-code space you may
| be in for a rude awakening.
|
| These tools continue to get better every day. The target is
| only "good enough" and once reached it presents an outsized
| advantage over custom builds.
|
| I fully expect no-code/low-code to grow in nearly permanent
| ways within many organizations.
| bornfreddy wrote:
| Any examples that are interesting?
| mike_hearn wrote:
| For example Oracle APEX comes with their DB and has a lot
| of capabilities.
|
| https://apex.oracle.com/en/
|
| The demo video takes you through creating a full blown
| database backed app with maps and other geo features, from
| nothing more than an initial CSV file. The code backing the
| app is represented as database tables, so you can use
| queries to explore the app.
|
| The core issue is really the same one the no-code/low-code
| platforms have always had, or even that VB6 had - the ramp
| isn't smooth. Eventually you hit the limits of the tool or
| there's a business requirement the tool can't meet and you
| get stuck. Often that requirement may be something indirect
| and non-obvious, like growing the team to the point where
| you start needing 'real' abstractions, or keeping up with
| some new feature the underlying platforms added that
| competitors are exploiting but which aren't exposed. Hence
| why so many companies have mobile apps that are just
| ordinary Android/iOS apps instead of written using low-code
| tools.
| gw99 wrote:
| I've been through that "no code" cycle at least three
| times, ironically including Oracle in two of those
| cycles, and they always died on their ass. I suspect the
| same will happen again.
|
| It's really hard to build something generic enough. MS
| Access was as near to it as was feasible I suspect.
| akitzmiller wrote:
| 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 / Java and
| Oracle development expertise
|
| The idea of developing and running this application with a single
| person would have been laughable.
|
| 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.
|
| 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!
| sseagull wrote:
| This is one thing I feel conflicted about. On one hand, it is a
| lot easier to do those things (VMs, docker, DBs, etc).
|
| On the other hand, now a regular run-of-the-mill developer is
| also supposed to be knowledgeable about sooo much stuff that is
| not so directly related to their code. As you say, sometimes
| it's nice to be able to hand that off to specialists - a person
| can't be good at everything.
| throwaway09223 wrote:
| Programming is enormously more complicated today because modern
| development environments aren't designed for simplicity.
|
| When I first started programming all of my tools had a simple
| workflow:
|
| * Write a single text file
|
| * run a single command to build (cc thing.c)
|
| * Run the resulting file as a standalone command
|
| People learning to program are often new in general. They're
| figuring out their text editors. Figuring out how to run
| programs. Figuring out so many basic things seasoned developers
| take for granted.
|
| 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.
|
| 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.
| _wldu wrote:
| I agree 100%. Massive frameworks with massive complexity. I
| don't enjoy them at all. That's one reason I like Go. It's very
| modern, but I can still use vim and a simple Makefile to
| control it.
| rmah wrote:
| I started programming professionally in the late 1980's (almost
| a half century ago :-)... and we had IDE's, UI builders,
| databases, "resource managers", etc. One the UI side, we had to
| deal with windows, layouts, menus, event loops, controllers,
| graphs, etc, etc, etc. Pretty much everything you have to deal
| with today. It was, IMO, just as complicated (if in a somewhat
| different way).
|
| Yes, most commercial software packages were written in C. They
| certainly weren't in one file. They were large systems that
| took hundreds, sometimes thousands of files and 100k's to
| millions of lines of code. If anything, we had to write more
| code to do things because pre-packaged libraries weren't as
| comprehensive back then. I still remember waiting hours and
| hours for our application to build. And the old timers told us
| that that was blazingly fast, lol.
|
| I would agree with a previous poster that there are many more
| choices today. And I guess if you suffer from a fear of making
| the wrong choice, that is a problem. But the other side of that
| is that literally thousands and thousands of examples and even
| robust code libraries are now available for free that you can
| drop in and use. That is a HUGE plus.
| throwaway09223 wrote:
| Yes we had those things but my point is that they were
| optional and not commonly used _except_ in large system
| projects. We didn 't throw all that complexity at people
| learning the basics.
|
| The interface for beginners scaled all the way down to a very
| basic single text file, and most beginners would program for
| months or even years without using those things. It wasn't
| necessary to teach these tools in school - you could complete
| an entire degree writing single-file C programs without ever
| using an IDE.
|
| Many utilities were distributed as a .c file and a Makefile
| and that's it (before the rise of autoconf)
| thewebcount wrote:
| I agree with most of what you're saying, but for me, the
| IDE was waaaaay easier than dealing with a Makefile (yet
| another programming language that has nothing to do with my
| goal), or worse, entering random hard-to-remember commands
| and options on the command line. Even if my program was a
| single file, it was usually just Cmd-R to build and run. No
| need to memorize that I needed to add "-l math" if I was
| doing anything with math functions, or whatever.
| ducharmdev wrote:
| If you have a base familiarity with the command line, I think
| many build tools do have great basic defaults, e.g. `dotnet
| run`, `cargo run`, `npm run dev`, etc. Vite is another example
| of good defaults in frontend dev; it allows you to sidestep a
| lot of the difficulty one may run into with webpack.
|
| But I think you're right in many ways though. For seasoned
| devs, cli tools give a lot of flexibility and allow dev tasks
| to be automated in pipelines more easily, but it requires one
| to read documentation or use the help subcommand to discover
| what else you can do. Which is not a big deal when you are
| experienced, but I definitely remember struggling early on with
| things like that when I was self-teaching how to program.
| falcolas wrote:
| I agree with all of this, and then some. My recent lament was
| how one tool in my tool chain for a project managed by someone
| else in my company which, despite being in the same language,
| required a specific variable to be set in my environment.
|
| Back in my day, being on the path was sufficient. And it is for
| all the other Java projects. I spent too long sorting that one
| out.
| NoraCodes wrote:
| I mean, invoking rustc on a single rust file is no harder than
| invoking gcc on a single file. cargo adds other features, as do
| make, cmake, etc for c.
| kaeshiwaza wrote:
| I still work like that 30 years after, thanks to Go... I would
| not like beginning today !
| gajus wrote:
| 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/website that passes the expectations of a user for their
| primary website/program.
| acd wrote:
| In the past write monolith, debug one application and one
| database. Attach debugger to monolith. Cache in ram/l3 cache.
| Deployment copy monolith binary in placce, run it.
|
| 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.
| Ekaros wrote:
| Also there is lot of code and services you didn't write these
| days. In past you could be relatively certain that SQL server
| was sane, but now we have glued chain of different things
| together with all of the configuration options that we are
| probably unsure if they are all correct.
| c2h5oh wrote:
| 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.
|
| 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's hard and the fact it's slightly less
| hard with go is one of the reasons of the language popularity.
| aappleby wrote:
| The overabundance of both frameworks and CPU performance causes
| programmers to massively overdesign systems that end up
| underperforming.
| Alacart wrote:
| I don't think it is more difficult than it use to be. There's
| more layers in some cases, but most of the time those are
| abstraction layers that making things _easier_ (or at least
| attempt to).
|
| I think the difference is maybe one of perception. We can do more
| so the baseline expectations of users/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.
|
| 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't have to.
| dynamite-ready wrote:
| 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 'soft' form of standardisation on common practices
| (best demonstrated by React / Typescript).
|
| My tongue is in my cheek, but I often wonder.
| ronyfadel wrote:
| Deploying has become a nightmare.
|
| It used to be transfer your source files via FTP, now it's
| setting up Docker and Kubernetes and I don't know what.
|
| Ofc the latter is better for teams, but now you must learn a
| whole stack just to deploy code.
| tw20212021 wrote:
| Who stops you from deploying with FTP? :)
| continuational wrote:
| When I started out, there was DOS. It came with a command you
| could type in: QBASIC.
|
| 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't
| remember if it also came with a debugger and a way to create
| stand-alone executable, or if that came later.
|
| It had built in commands for drawing, input and sound, all well
| documented. And the UI was straightforward and intuitive.
|
| This doesn't really exist anymore.
| dragonwriter wrote:
| > I can't remember if it also came with a debugger and a way to
| create stand-alone executable, or if that came later.
|
| It didn't, it came earlier: QBasic was (and is, it stopped
| being part of the default install with Win2k but is still
| available for current Windows OSs) a stripped down interpreter-
| only version of QuickBASIC, a compiled BASIC.
| vore wrote:
| You can do the same thing if you type https://editor.p5js.org/
| into your address bar ;-)
| bluedino wrote:
| It seems like this could be a special website or something
| packaged with a browser like Firefox.
|
| A plug-in or add on for the tutorial on how to make HTML/JS
| pages right there inside the browser.
| zeroonetwothree wrote:
| 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.
|
| 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.
| mkl95 wrote:
| Many companies are OK with distributed systems but they don't
| wanna invest the resources to set up proper observability and
| monitoring.
|
| At those companies fixing a bug that would be relatively
| straightforward with a monolithic architecture is a humongous
| pain in the ass.
|
| 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.
| dtagames wrote:
| There's some truth to this, but unless you're in a senior
| architect position or starting a clean sheet project, it's
| unlikely that you'll have the freedom to choose your platform or
| framework as a programmer. Like pilots, most people will start
| out doing "short haul" work on existing equipment and routes.
| This means you'll have to learn the frameworks that your employer
| (or desired employer) uses.
|
| 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 "interactive apps" (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's possible, it's also arduous. In today's world, you must
| also learn the frameworks, tooling, and CI/CD processes that lead
| to your work making it onto someone else's screen. That'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.
|
| 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.
|
| Finally, and this is the final nail in the coffin for some more
| experienced programmers, the misunderstanding of the concept of
| "agile" or "XP" 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's top-down, "How
| long will it take you to write and debug a feature that doesn't
| exist?" 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.
| thakoppno wrote:
| > frameworks and platforms, are the biggest technical burdens
| for programmers today.
|
| This sounds precisely correct from my experiences lately. At
| some version of scale, one simply cannot run the application on
| just a workstation. The complexity of distributed systems has
| gone way up, primarily in my opinion, because it solves an
| organization's problem, not an individual programmer's.
| ww520 wrote:
| Complexity of the platforms and packages.
| jasoneckert wrote:
| While I agree with many of the other comments here, I'll offer
| one more way in which programming is more difficult today: speed.
|
| 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).
| intelVISA wrote:
| It's only harder if you make it so, the buzzword / abstraction
| fog has gotten quite thick, I feel lots of shops lose sight of
| the basics.
|
| Advances in automation and tooling make it easier than ever to
| develop complex projects with lean teams but it can't be done if
| your org opts to inherit a brittle dependency chain every time "I
| don't want to reinvent the wheel" surfaces.
| issa wrote:
| There is certainly a lot of choice, but when is the last time you
| had to:
|
| - really worry about disk space or memory size
|
| - check if something would work on IE
|
| - worry about version control
|
| - manually scale something
| marginalia_nu wrote:
| 1, 3, and 4: Every day.
|
| You can not worry about these things, sure, but then your
| software will be slow and expensive to run.
| parasti wrote:
| A little off topic, because I can'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'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.
| ipaddr wrote:
| The c64 opened to a prompt you could easy program vs a browser
| which could lead you to a programming site.
|
| qBasic was installed on windows machines and didn't require the
| internet.
|
| People on mobile don't have a keyboard that makes programming
| fun.
|
| You needed to program to get your computer to fully work
| before.
|
| It was easier to learn before because you had to and
| programming was part of operating a computer.
| teeray wrote:
| 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.
| 62951413 wrote:
| And all the YAML-oriented programming it entails. When
| frequently the only way to test is to constantly re-deploy two-
| line changes via CI/CD just to see what breaks in a few
| minutes.
| spamalot159 wrote:
| Depending on your CI/CD pipelines it could be a few dozen
| minutes - up to an hour, which totally breaks all
| productivity flow.
| neilobremski wrote:
| Programming is now more opaque configuration than it is traceable
| logic paths. This makes paper debugging impossible.
| throw_m239339 wrote:
| One word: Bureaucracy.
|
| But I understand that in the context of large teams.
|
| Coding itself is the exact same thing as 40 years ago, input,
| processing, output
| hulitu wrote:
| Programmers don't write widgets anymore. They write OpenGL
| surfaces. And they must wait for vsync to blink the cursor.
| jll29 wrote:
| 1. Yes, overburdened by choice is indeed one of the main
| challenges today.
|
| 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 "developer fashion" (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 "dead" 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.
|
| 3. Computer security for many systems is critically important yet
| very difficult, and attackers are everywhere.
|
| 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.
| mdaniel wrote:
| > 3. Computer security for many systems is critically important
| yet very difficult, and attackers are everywhere.
|
| I would offer that a lot of the attack surface came from the
| intersection of the Internet and shipping faster than testers
| could keep up. The Internet means a mistake's blast radius is
| no longer just limited to insider threats or downloading shady
| software onto your own machine, now every computer in the world
| is a potential threat. The shipping "faster than thinking"
| means years worth of best practices about SQLi or CSRF or IDOR
| or or or get swept under the rug
|
| In some ways, this is the same as 2 in your list, and I guess
| some of 1 also given that some frameworks and tools help that
| problem and some are "welp, good luck, don't screw up"
| yodsanklai wrote:
| > you can choose 20 different programming languages, dozens of
| framework and operating systems and you're paralyzed by choice.
|
| 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're introverted,
| it's taxing. There's always some person that needs extra
| convincing.
|
| Code review wasn'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).
|
| But the worse part for me is the accumulation of abstraction
| layers and dependencies. I'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/7. This causes a lot of
| stress.
| ravenstine wrote:
| I really appreciate the code review process, but one of the
| sorts of tyranny that can come from code review is for
| _everything_ needing some kind of explanation. It 's not
| necessarily a good thing for crap to get into a codebase, but
| as long as the code works well and is readable, I am less
| concerned if something is redundant. Either someone will
| realize that redundancy later or it will remain in place
| because it's just not that important. But code reviews today
| can feel like an anal probe from FBI agents.
| [deleted]
| 0x445442 wrote:
| Yeah, I call it collectivized micro management.
| coliveira wrote:
| > But the worse part for me is the accumulation of abstraction
| layers and dependencies.
|
| Yes, open source has a lot of positives, but the bad part is
| how it has created a culture that incentivizes such a huge
| amount of dependencies for every project. It seems that for any
| new requirement the only possible solution is to add a new
| dependency on yet another library. This results in fragile
| builds and daily changes caused by dependency updates. In some
| cases it causes as much troubles as the perceived benefits.
| usgroup wrote:
| 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.
|
| The likelihood that the next thing you do sees you scurrying
| about Stackoverflow even after 20 years in the job, is quite high
| now.
| comfypotato wrote:
| 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.
| jstx1 wrote:
| 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.
| carapace wrote:
| In a word: complexity.
|
| 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.
|
| The only downside, the great undertow, is burgeoning complexity.
| A "thundering herd" attack on the human mind.
| ericmcer wrote:
| It'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.
|
| 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.)
| dragonwriter wrote:
| 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.
|
| 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.
|
| Information overload and analysis paralysis bite hard.
|
| (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.)
| [deleted]
| theonemind wrote:
| Programming has turned into gluing together mystery meat. You
| can'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'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's lifetime.
| Joeri wrote:
| I can't shake the feeling we are inching closer to the
| programmer-archeologist from a deepness in the sky, where
| gluing together mystery meat is the only sensible thing that
| still needs doing.
|
| _"We should rewrite it all," said Pham.
|
| "It's been done," said Sura, not looking up. She was preparing
| to go off-Watch, and had spent the last four days trying to
| root a problem out of the coldsleep automation.
|
| "It's been tried," corrected Bret, just back from the freezers.
| "But even the top levels of fleet system code are enormous. You
| and a thousand of your friends would have to work for a century
| or so to reproduce it." Trinli grinned evilly. "And guess what
| --even if you did, by the time you finished, you'd have your
| own set of inconsistencies. And you still wouldn't be
| consistent with all the applications that might be needed now
| and then."_
|
| https://www.goodreads.com/quotes/9427225-pham-nuwen-spent-ye...
| bentlegen wrote:
| In the past you just wrote the mystery meat yourself, and I
| assure you it didn't taste better. Like, I literally wrote and
| deployed my own garbage JavaScript dependency manager in the
| late 2000s and we all thought it was great. It wasn't.
| [deleted]
| wpietri wrote:
| I agree with a lot of what you say!
|
| When I was a kid, my first computer had 4k of RAM; my next one
| had 48k. I learned a lot about how everything worked, because
| there was very little to it. Over the years things have grown,
| but I've had a chance to grow along with it.
|
| But somebody starting out today start in the middle of vast
| layers of complexity. From processors and hardware that are
| hugely more complicated up through virtualization,
| containerization, rich OSes, languages and standard libraries
| with decades of history, tons of add-on libraries, and then out
| to user platforms with their own tangled ecosystems and decades
| of history. It's a lot!
|
| I think it's so much harder now for developers to develop
| "mechanical sympathy", that intuitive understanding of the
| rhythms of machinery. Apparently slight shifts in code can be 3
| orders of magnitude difference in performance. So much of what
| they deal with is historically determined. (E.g., what
| percentage of working developers has every actually seen a
| carriage returning or a line feeding?) And it's all running on
| much shorter cycles with an ever-updating mass of tools,
| libraries, frameworks, and operating systems.
|
| On the one hand, people can do some amazing,valuable stuff with
| very little training. That's great! But I think it's a lot
| harder to truly master the craft, and I'm concerned that a lot
| of programmers spend their time in professional contexts where
| the feedback loops are long or broken such that they are
| encouraged to be less analytical than superstitious, cargo-
| culting their way to from one overly-aggressive sprint deadline
| to the next.
| xhrpost wrote:
| This sums up mostly what I've been feeling for the last 10+
| years. When I started "web 2.0" development in 2005, there was
| a much smaller library ecosystem. I had to use what tools were
| available, most of which were developed by for-profit companies
| and thus heavily documented. If the feature I needed didn't
| exist, I had to build it. I spent much more time reading
| documentation and specifications than I do today. Now, I do try
| to read docs first for whatever FOSS I'm using, but often they
| are lacking the specificity I need and I end up just running
| through a bunch of Google searches and SO questions hoping to
| find my specific "glue case".
|
| Whatever challenging "science" aspect I was expecting from my
| "computer science" skills just doesn't seem to exist. The
| concerns of logic and program efficiency/structure are still
| important, just not what I have to do most of the time when
| gluing stuff together. I'm trying to accept my fate these days
| and just be thankful I work in a well-paid field with good
| people, but it's tough as I feel it does affect my overall
| performance and personal enjoyment as flow is so hard to
| achieve anymore.
| ozim wrote:
| We have tools to fight it - code reviews, dependency scanning,
| QA.
|
| I am guilty as the next guy of throwing stuff that "just works"
| out there.
|
| It is also important what kind of software you write - if you
| write frameworks, you better get unit tests and full blown
| process in place to make sure your framework will work in 10
| years time.
|
| If you work on a business application - in 6 months time your
| application might be gone or requirements change in a way that
| everything you wrote does not matter anymore and future
| proofing was just a waste of time.
|
| I would like that more devs/software engineers understood which
| one they are writing.
| wizofaus wrote:
| > in 6 months time your application might be gone or
| requirements change in a way that everything you wrote does
| not matter anymore
|
| I'd say if you write code with the assumption this might be
| true, you're almost guaranteeing it will be - business
| requirements do often change but typically that means having
| to modify/refactor existing code so that core components
| continue to work the same way, because those core
| requirements haven't changed. While you can make occasional
| assumptions about which requirements are more likely to
| change than others I'd much rather write all my code on the
| assumption the requirements won't change too significantly
| and that the tools/automated testing and other processes are
| in place to support that. There's far too much
| "throwaway/POC" code that ends up getting used in production,
| often for years, then mysteriously stops working down the
| line because nobody ever assumed it would need to survive
| that long. Whereas I don't believe I've seen a project fail
| because too much time was spent ensuring code was well
| written and well tested.
| wpietri wrote:
| > Whereas I don't believe I've seen a project fail because
| too much time was spent ensuring code was well written and
| well tested.
|
| This does indeed happen. Kent Beck tells a story of being
| called in to help a European insurance project where, sick
| of all the legacy code, they spun off a new company to
| start fresh. Teams of bright people spent years building
| The Right Thing and doing it The Right Way. But they never
| delivered anything actually useful, and by the time the
| sponsors were entirely fed up, they still couldn't promise
| anything soon. So they fired everybody, hired back one
| team's worth, and then started fresh on well-written code
| that actually did something immediately useful.
|
| I think there's a middle path between "write garbage that
| succeeds" and "write perfect code that never gets used". I
| think it's narrow but doable, and it requires dogged
| attention to both "ship early and often" and "build in a
| way that's sustainable over the long term".
| ozim wrote:
| I argue that real dichotomy is:
|
| "write perfect code that gets used a lot, frameworks,
| libraries"
|
| "write throw away glue code with use of libraries and
| frameworks"
|
| Because for me "write garbage that succeeds" vs "perfect
| code that never gets used" is false dichotomy.
|
| Where most devs want to write libraries and frameworks
| because these are places where "eternal fame" is - even
| better if you can write your own programming language
| that is the highest echelon of software engineering.
|
| Ugly truth is most devs are driving beat up honda - where
| Linus Torvalds, Anders Hejlsberg, Bjarne Stroustrup are
| F1 drivers - you can rev up your honda on street lights
| all you want - but that is not the same league.
|
| So most devs write business apps and many of them
| overshoot quality.
| wpietri wrote:
| > So most devs write business apps and many of them
| overshoot quality.
|
| I think this can be true for sufficiently bad definitions
| of quality, which I agree are very common. To me, though,
| overengineering something doesn't really increase
| quality, because actual need puts an upper bound on
| quality.
| wizofaus wrote:
| I don't doubt there are projects that struggle or even
| fail due to over-engineering, but I wouldn't consider
| code written on the assumption it won't be needed in 6 or
| even 12 months' time (therefore not needing, say, code
| review, automated testing or even the ability to build on
| anything other than an individual developer's machine,
| which I've seen happen more times than I care to
| remember) to be any sort of sensible "middle ground".
| wpietri wrote:
| I have tried reading this sentence/paragraph multiple
| times without great confidence I know what you're saying.
|
| But if your notion is that there's no place for throwaway
| code, I disagree. The trick with throwaway code is to
| actually throw it away. Temporary and permanent code,
| used appropriately, are both vital to projects that are
| resilient in the face of real-world circumstances like
| lack of certainty and changing needs. It's the third kind
| you have to watch out for: https://web.archive.org/web/20
| 190709091156/http://agilefocus...
| hardwaregeek wrote:
| > Whereas I don't believe I've seen a project fail because
| too much time was spent ensuring code was well written and
| well tested.
|
| Oh I definitely have. In fact I'd wager that it's the
| leading cause of failure for programmer lead startups. It's
| far too easy to spend time worrying about code and ignoring
| the business when your skillset lies in code and not in
| business.
| wizofaus wrote:
| Sure, but that's failure due to not getting the business
| requirements right. If the code had been hastily thrown
| together with no regard for process it's hard to believe
| it would've produced a better outcome.
| the_jesus_villa wrote:
| 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: <?php
| $data_from_backend = [whatever I need to do on backend];
| echo $data_from_backend; ?>
|
| 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.
| firekvz wrote:
| PHP its seen only as something from the dark ages when u using
| VC money and the more new tech u mention to them more money u
| get, not all the web is based on US and able to pay 5k monthly
| AWS bills just to even set up a silly enviroment to test
| stuff/learn or start launching a side/new project
| asciimov wrote:
| The low hanging fruit has been taken.
|
| 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.
|
| Today, that's unlikely to happen. Gone are the days of some
| people hacking in their room creating a solution to some problem.
| Most of the "low hanging" 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.
| kragen wrote:
| We waste all our time getting flamed by assholes on this website
| instead of programming.
| openfuture wrote:
| OMG this made my day. I wasn't expecting it but it's so true
| haha.
| f0e4c2f7 wrote:
| Google doesn't work as well now. You kind of have to know more
| tricks to still be able to find similar quality information.
| jghn wrote:
| Depending on one's definition of "years ago", the fact that
| google exists at all is a giant boon.
| marginalia_nu wrote:
| Dunno, I think if anything reliance on Google has increased.
| Back in the day I usually looked at the documentation. Back in
| the day there _was_ documentation. Also books, like not written
| to be a bait-and-switch cash-grab but they were genuinely well
| put together by experts in the field.
| logicalmonster wrote:
| The standards for software are definitely elevated.
|
| 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.
|
| 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.
| tyingq wrote:
| Chasing dependency chains. Both due to the sprawl, and things
| like vulnerability scanning.
| zffr wrote:
| 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.
|
| For example, there's still a lot of python 2 code snippets that
| won't work now that python 3 is the default interpreter.
| mikewarot wrote:
| 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.
|
| For the most part, those programs written with those tools
| _still_ work.
|
| Today everything is update on the fly, and subject to random
| breakage. GIT is better, everything else has gone downhill.
| nope96 wrote:
| What I loved about Turbo Pascal (and probably Delphi), was you
| could put the cursor under any function, press F1, and get
| documentation that showed that function being used in an
| example problem. Great way to learn.
| ipaddr wrote:
| It worked great until you had to install it on a machine that
| didn't have the vb runtime. The browser removed that aspect
| which was handy.
| makapuf wrote:
| Until it was not and we redeployed a much heavier runtime in
| the form of electron.
| coliveira wrote:
| What I found incredible is that the new generation doesn't even
| know the feeling of working in an environment that gives you
| the power you had with something like Delphi, Borland Pascal,
| or Visual Basic. With one of these tools you could create
| pretty much any kind of application you wanted (with VB maybe
| you needed some Visual C++ for the difficult parts).
|
| Today's new developers have to deal with a landscape that is,
| in my opinion, discouraging. You have to spend a huge amount of
| time setting up environments, creating sane default
| configurations, and learning about hundreds of dependencies,
| before you can even start creating something that would be
| considered semi-useful.
| lr4444lr wrote:
| There's no time to do things correctly: only "pretty well". The
| bar for productivity in terms of time to iterative deliverable
| business value is getting higher, and it's frustrating having to
| make quality/throughput trade offs.
| FpUser wrote:
| 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.
| MonkeyMalarky wrote:
| I feel like the existence of sites like stackoverflow have led to
| less quality in available documentation. Like the responsibility
| has been offloaded.
| chrismartin wrote:
| Perhaps, but they also deliver thousands of helpful recipes for
| "using thing X with thing Y" that neither X nor Y's documenters
| would have anticipated the need for. We are fortunate that
| Stack Exchange has tried to keep this community relatively open
| (and not e.g. paywalled).
| voidhorse wrote:
| I'm inclined to agree. I also feel SO gives newbies the wrong
| impression about programming.
|
| It's great to have quick solutions to small problems, but too
| often newbs stop with the SO answer and move on, which means
| while they've solved their problem in the moment they never
| spend the time to actually learn the underlying reasons why the
| solution worked or explore the issue deeper to actually achieve
| understanding.
|
| The _good_ software engineers I know are all yak shavers.
| They're willing to spend extra time learning how something
| _really_ works and ensuring they fully understand an issue and
| its solution, even if the issue is just a small part of what
| they need to accomplish.
| OliverM wrote:
| Knowledge of the entire machine'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: 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/sounds facilities
| were available No need to worry about what resources
| simultaneously-running programs could be using (there weren't
| any) Actually no need to worry about concurrency at
| all (you just couldn'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
|
| _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?
| thomastjeffery wrote:
| Context.
|
| 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 "what" and the
| "how" are easy to find.
|
| What we don'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 "why" and the "when" are
| really difficult to pin down.
|
| 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.
|
| Because there is so much mysticism involved, people who have
| spent years or decades treating operating systems, package
| managers, development environments, etc. as _playgrounds to
| explore_ have an advantage that is difficult to articulate, let
| alone teach.
|
| 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...
|
| 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's really tricky to find
| direction to go from vague concepts to working projects.
| PragmaticPulp wrote:
| Programming today is easier in many ways: Information is readily
| available for free (I recall saving up a lot of money for a kid
| to buy specific programming books at the book store after
| exhausting my library's offerings). Compilers and tooling are
| free. Salaries are much higher and developers are a respected
| career that isn't just "IT". Online programming communities are
| more abundant and welcoming than impenetrable IRC cliques of
| years past. We have a lot that makes programming today more
| comfortable and accessible than it was in the past.
|
| However, everything feels vastly more complicated. My friends and
| I would put together little toy websites with PHP or Rails in a
| span of weeks and everyone thought they were awesome. Now I see
| young people spending months to get the basics up and running in
| their React front ends just to be able to think independently of
| hand-holding tutorials for the most basic operations.
|
| Even business software felt simpler. The scope was smaller and
| you didn't have to set up complicated cloud services
| architectures to accomplish everything.
|
| I won't say the old ways were _better_ , because the modern tools
| do have their place. However, it's easy to look back with rose-
| tinted glasses on the vastly simpler business requirements and
| lower expectations that allowed us to get away with really simple
| things.
|
| I enjoy working with teams on complex projects using modern tools
| and frameworks, but I admit I do have a lot of nostalgia for the
| days past when a single programmer could understand and handle
| entire systems by themselves because the scope and requirements
| were just so much simpler.
| systemvoltage wrote:
| The list of things we've added in last 10 years is just
| staggering: https://landscape.cncf.io/
|
| The litmus test for abstractions getting out of control is if a
| KPMG consultant brings it up while sipping Gin and tonic in
| business class.
|
| Another problem is explosion of DSLs. Everything is yaml and
| you spend ages learning things like Terraform and Docker
| compose yaml syntax.
| oneplane wrote:
| I'd say DSLs significantly improve specialised tasks. Someone
| who is working on declarative infrastructure configuration
| all day really doesn't benefit from classic imperative
| languages.
|
| But if you do "a little bit of everything" and infrastructure
| on the side, you're bound to become a master of none.
| scarface74 wrote:
| The opposite of using yaml to provision infrastructure in a
| few minutes was a months long acquisition process for new
| hardware.
|
| As far as Terraform/HCL and CloudFormation/Yaml, the
| alternative is writing code to do the same thing in your
| language of choice using the CDK with either CloudFormation
| or the recently ported Terraform/CDK.
| the_only_law wrote:
| > Information is readily available for free
|
| As much as people decry the internet and it's role in modern
| society, I'm glad that I generally have easy access to massive
| archives of knowledge.
| not_kurt_godel wrote:
| > My friends and I would put together little toy websites with
| PHP or Rails in a span of weeks and everyone thought they were
| awesome.
|
| Agreed, LAMP was just so damn fun in how you could go from zero
| to a fully functioning site in a day or two. Having to manage
| all the statefulness of fetching & displaying data
| asynchronously from the client adds an incredible amount of
| complication both in theory and in practice.
|
| Also agree that the old tech wasn't necessarily better either -
| but it sure would be cool if someone could replicate the
| developer experience from back then and produce a result that's
| up to modern engineering and UX standards.
| antod wrote:
| I think things are more complicated precisely because things
| got easier.
|
| The more complexity we can now handle, the more complexity we
| will create.
| darepublic wrote:
| > Spending months to get the basics up and running in their
| React frontends just to be able to think independently of hand-
| holding tutorials for the most basic operations.
|
| Frontend devs who were present before the advent of the major
| web frameworks, and worked with the simplicity of js script +
| DOM (or perhaps jquery as a somewhat transparent wrapper)
| benefited from seeing the evolution of these frameworks,
| understanding the motivations behind the problem they solve,
| and knowing what DOM operations must be going on behind the
| curtain of these libraries. Approaching it today not from the
| 'ground up' but from high level down is imo responsible for a
| lot of jr web devs have surprising lack of knowledge on basic
| website features. Some, probably a minority, of student web
| devs may get conditioned to reach for libraries for every
| problem they encounter, until the kludge of libraries starts to
| cause bugs in and of itself or they reach a problem that no
| library is solving for them. I feel like this is particularly
| bad outcome for web devs because web I feel is uniquely
| accessible for aspiring developers. You can achieve a ton just
| piggybacking off the browser and DOM and it's API, the
| developer tools in the browser etc. But not if you are
| convinced or otherwise forced to only approach it from the
| other side -- running before you crawl, or trying to setup a
| webpack config before you even understand script loading, etc.
| phpisthebest wrote:
| I remember when jQuery was first released.... I wish things
| were that simple again
| Karrot_Kream wrote:
| This is true for other devs as well. I started playing around
| with networking code as a teenager (back when port 80 (before
| 443) was prominent but not the clear majority of traffic on
| the net.) Watching the evolution of TCP, HTTP, the C10K
| problem, retry storms, and event loops has made a lot of
| sense: clear responses to clear issues. But I've noticed a
| lot of junior devs grow up with the solutions (nginx,
| haproxy, exponential backoff, etc) but don't know the
| problems that necessitated the solutions. A lot of junior
| training is teaching juniors which solutions to apply to
| which problems, because unlike us they didn't watch the field
| evolve to where it is now.
| oldge wrote:
| Looking back over my relatively short 30 year career across
| an assortment of tech companies (hp, google, microsoft,
| apple, etc) I would add that this mostly changed due to what
| was rewarded. Around 15 years ago when the first vestiges of
| OKR review processes and the idea of "impact" started to
| form; We shifted our designs from things that made our long
| term outlook better (simple) to things that were easy to
| explain to management how they had HUGE impact (complex).
|
| Be right back, writing a new design doc for a messaging
| service and protocol spec to go with it that I can use to pad
| my next review cycle.
| ozim wrote:
| This is a good explanation.
|
| Newbies drop directly to webpack/react and are overwhelmed or
| having a lot of trouble getting some details right.
|
| Unfortunately a lot of details that are lost in time are
| accessible if you go through "build stuff basically from
| ground" so understanding first "why" we needed these
| frameworks and what were problems to solve.
|
| There is also bunch of people who go to rediscover basic
| stuff and they claim "you don't need a framework - vanilla js
| is enough" - but they also miss context and did not run into
| problems that were pain points before we had frameworks.
| sarchertech wrote:
| At my current company we have a take home assignment for some
| roles. When I have to grade one the first thing I do is check
| to see whether you can submit the input by pressing enter.
|
| About half the time you can't because it's not actually a
| form, and they forgot to add handler for enter.
| BolexNOLA wrote:
| This is such an interesting perspective. I feel the exact same
| way as a video producer/editor. The tools we are getting are
| incredible, and tasks that used to take literally days can be
| done now in minutes. It's kind of baffling what we have in our
| toolbox. But it is also radically changing the expectations of
| our clients and I find I don't get to spend as much time on the
| nuts and bolts I really enjoy - cut, color, and baking the best
| possible export for the situation - and instead have to find a
| plug-in to solve every little issue a client thinks up (or
| created for me haha).
|
| On a somewhat related but tangential note: I also now have
| clients demanding certain programs and ecosystems, which is
| absolutely ridiculous to me. The software I use to give you a
| final cut should in no way be determined by you. Yet somehow we
| have ceded that ground!
| ravenstine wrote:
| Get rid of the assumption of "frontend first" and most of the
| complication of web development disappears instantaneously.
|
| Something I am appreciating about Svelte/Kit and Phoenix is
| that they are admitting what was right about PHP and server-
| rendered webpages. I'm a frontend engineer and think that SPAs
| have their place, but frontend JS represents a kind of tyranny
| seen nowhere else in tech.
| throwaway81523 wrote:
| Phoenix, do you mean the Elixir web framework? I had thought
| it was Elixir's counterpart to Rails.
| throwawaymaths wrote:
| Phoenix liveview is server rendered interactive websites.
| softwaredoug wrote:
| Dependencies are more complicated.
|
| 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.
| silisili wrote:
| For me...the rise of a billion devops tools with their own
| opinionated designs and syntax.
|
| Programming is programming, and the language doesn't make a ton
| of difference to me, though I do have strong preferences.
|
| 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.
|
| To Docker or not to Docker. Kubernetes? ECS? RPM? How about just
| lambda functions?
|
| What about your config management.. Ansible? Chef? Puppet? Salt?
|
| It's the worst part of switching jobs to me. Especially when
| feeling like you have to invest time learning a system that's
| falling(or even has already fallen) out of favor.
|
| 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.
| jordanpg wrote:
| This is in large part what drove me out of programming to
| become a patent attorney. I started out as a moderately
| competent enterprise java backend developer who really knew his
| way around the major app servers.
|
| Then things changed around me quickly, and one day I woke up
| and realized that I had hardly any idea what was going on any
| more. Cloud ops, docker, kubernetes, etc. It was exhausting
| trying to keep up and it made me lose interest in getting
| better.
|
| I always knew I wasn't going to be a programmer forever, but
| modern devops stuff accelerated the transition out.
| iepathos wrote:
| It's just a matter of a specialization. You were a backend
| app engineer who wasn't specialized in containers and cloud
| deployments. You shouldn't be expected to know everything in
| the software engineering landscape. The same way you're a
| patent attorney now and aren't expected to practice criminal
| law.
| jll29 wrote:
| Good patent attorneys share with good software architects the
| ability to distil a design to its essence, and with good
| scientists the ability to detect the crucial novelty.
| davnicwil wrote:
| > Patent attorney
|
| Interesting career move! Are you using your software skills
| in any way (ie does it involve software patents?) or was it
| just a hard gear shift because of other interests/factors?
| slyall wrote:
| Bit ironic that somebody who has problems keeping up with the
| fast changing world became a patent attorney..
| ungamedplayer wrote:
| I think that almost any sane, logical human should be
| having problems keeping up with the fast changing world.
|
| There is simply too much shit, too much stupid and not
| enough time to understand things without sacrificing
| family, relationships, or health.
|
| World is messed up, and it's not worth understanding it
| anymore, I don't think the payout is worth the cost.
| iepathos wrote:
| I deal with devops tooling and infrastructure a lot for my
| startup, so the part you consider hard is the part I consider
| easy. It's just a matter of specialization. Doing devops like
| 20-30 years ago would've been awful compared to today where
| there are a ton of tools with clear documentation to accomplish
| full CI/CD chains.
| wagslane wrote:
| It's so much easier today when it comes to good tooling,
| scalability of services, specialized tools, etc.
|
| It's so much worse today when it comes to things like paralysis
| of choice and configuration.
|
| I'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's a very hard problem.
| BiteCode_dev wrote:
| Fads, noise vs signal ratio, paradox of choice, economical
| pressures, culture wars, value signaling taking over, incentives
| to bs/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...
|
| Also if you start today, you gotta learn some part of the pyramid
| your abstractions stand on, and that's growthing work as time
| passes.
| thewebcount wrote:
| 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?
| pevey wrote:
| I second this about the declining quality of docs. Part of the
| proliferation of different solutions to the same problem IMO is
| that existing solutions might have such poor documentation that
| it may seem easier to seriously reinvent the wheel. I can
| vividly remember when php3 came out because I happened to be
| working on a project right then. This was before you could
| carry around iPhones and iPads, so I printed the whole manual
| and put it in a 4-inch binder so I could read it on the train,
| etc. I can still see those pages. I was new to programming in
| general at the time, but I could learn anything I wanted to do
| with php using those docs. Every single function was thoroughly
| explained. Haven't seen anything like it in a very long time.
| The Prisma docs comes closest.
___________________________________________________________________
(page generated 2022-10-02 23:01 UTC)