The Biggest Difference Between Coding Today and When I Started in the 80s

I miss that too (90's for me). Honestly I don't enjoy programming much anymore for this reason. I remember when it was normal for people to write their own data structures for their programs -- and while not "practical," there's a certain joy you get debugging your own sorting implementation that you don't get, say, copying and pasting frameworks' error messages into Google.

One problem with today's coding environment from an enjoyment perspective is that if something is fun, it will probably be written and packaged into a library. Data structures, algorithms, visualization libraries, abstractions on top of OpenGL, mathematical functions, data stores, neural networks, etc. -- all these things are great fun to actually try to write, and all of these things already exist in better forms than we'll ever write as individuals. Sometimes practical programming today feels more like gluing everybody's fun code together with your not-so-fun code.

Programming when I was growing up: https://www.toysperiod.com/images/lego-parts.jpg

Programming now: http://www.toysrus.com/graphics/product_images/pTRU1-1912094...

I don't wish back those days. I get that it's interesting to work to the bottom of things yourself, sure. But I've run into several problems that I couldn't have hurdled on my own, in any amount of time, without the help of the internet.

- dll broken from MS. This happened to me. I did a lot of sleuthing, taking things apart, and it just didn't make sense. It was for a DB adapter, so the official documents would have been enormous. And unfruitful to read. In the end I got a hotfix from MS.

- Sort algorithm broken in Swift. Another one of those jobs where you take apart everything, because you assume it was your use of it, not Apple's library. Did a workaround after I got someone on SO to confirm it wasn't just me.

- Any number of little things that are unfindable in a manual. Heck, how often do you even look at a manual rather than an example?

- Learning issues. When you're new to a language, you don't necessarily know what you don't know. So being on an island with a manual is going to lead to you dying. Witness the many calls for help on SO from people with score 1. They don't know what's wrong with their code, and they don't know how to ask. Sometimes someone with have mercy on them and help, because it's normally something quite trivial. I remember being 15 and trying to learn c++. It was hard, because every little error you get is cryptic.

- You can make so much more with so much less now. There's a library for just about everything you can think of. The coder is mostly a chef who mixes existing ingredients. This means you can explore writing things that you'd never have time for otherwise. For example I did some web and mobile side projects beside my financial c++ coding. Always good with a breath of fresh air.

I received my first computer in 1980, a TRS-80 color computer, when I was a pre-teen. A few years later, I received a TRS-80 Model 100 laptop, and a few years after that, in 1987 or so, an Amiga 1000, which I used through university.

I agree with most of this article, but with one big difference: I still really enjoy programming, professionally and personally. (And maybe I'm over-stating the authors lack of enjoyment today.)

Back in the beginning, for me, there was the thrill of discovery, in a rather low-level sort of way. My first functional, written from scratch in BASIC program was enormously exciting. A couple of years later, as frustrations with the poor performance of a truly interpreted language pushed me toward learning a faster way, the same thrill was felt when my first machine language program started working. And then again with my first C program for the Amiga.

35 years later, I ask Google questions throughout day, every day, while I'm programming.

Sometimes I of think of it as a compiler for an optimized but very high level language. I rarely have to sweat the details, and when I come across a very powerful and clever solution (typically from Google), it doesn't really mean much to me, because I didn't 'earn' it. And I may or may not remember it in any detail, so I'll probably end up finding it again later.

But gcc does that same kind of thing, right? It converts C++ code into a highly optimized executable using all kinds of tricks that you probably don't know about, and that you very rarely need to explore. (Not never, though, given that every abstraction leaks over a long enough time period.)

The thrill I get today is from higher level and more abstract 'data and design things'. As one example, powerful and novel ways distributed systems can work together.

I'm intentionally leaving unaddressed a lot of the other interest, meaty things in the article, because nostalgia got the better of me.

Another huge difference was how slow compilers were. Programming is a completely different task when you don't mind hitting compile. I remember programming as a kid in the 1980s with my older brother. He would hit compile and we would wait and wait and wait and finally get an error. After a few times he would slam his fists on the keyboard in frustration.

These days I sometimes compile rather than looking up the correct syntax for something.

Fast cycles changes everything. When you don't get up for a cup of coffee during compiles you program differently, learn about your code differently and can think abiout high level design more

Having programmed alone in the eighties, I can just feel it's much better.

For example, I needed to do some UI but back then I hadn't the money to buy a toolkit (Windows was still some years away). Therefore I had to spend much time on making a UI and that UI was just a small concern to me.

Today, I have an idea for a program, then I gather all the libs I can to progress as fast as possible and I just need to code the missing/most important bits.

That is, I can concentrate on what's really important and leave plenty of the 80-other-percent to the open source community...

To me the big difference is the appearance of libraries and frameworks. Back then your code depended on or built on very little pre-existing code. You wrote to devices such as the screen, tapes, disks and printers almost or even literally directly. If you needed a data structure more complex than a discrete value or array you had to include the underlying code yourself every time. Every program was a creation ex nihilio because even if you re-used code you had to copy or write it in again yourself. Environments like Delphi and VB or later versions of Turbo Pascal which came with library code were a revolution.

There are so many options these days, and evaluation often requires all the work of using the package only to find out that it's incompatible or broken or unusable for some other reason. So it's often more efficient to write your own version anyway. At least then you'll know the jerk who made it.

Oh man, do I feel this. I started programming in the late '80s and it really was a creative exercise. Now you just string together other people's stuff and call it a day. Lower barrier to entry is better for the world overall, but as a career, it can be a bit of a bummer.

Old days you would think and then program more (even being repetitive among programs you made).

Nowadays you think and integrate more, find which pieces fits in which one. You do program, of course, but just to glue those pieces together.

Sometimes, when you came from programing microcontrollers and so on, you might miss that you had control of every single bit of what was happening. You just rely that some package will deliver you what it says.

While I would much rather write code in our modern environment and with modern tools, I think programming as a profession is getting more unpleasant due to much higher expectations and lower development budgets, and because a software developer's time is increasingly taken up by (usually necessary) non-programming tasks.

I suppose that's one reason why creating a startup is so attractive to software developers; it's a means by which productivity improvements work for them by allowing them keep more of the wealth they create, instead of against them by setting a higher and higher productivity bar that must be met each year just to keep the same job.

One big thing is you never even knew what you didn't know. I had a C=64 for years and never even heard of the PEEK and POKE commands until years later when I was reading about it on the web. There were no computer experts to talk to back then, at least not where I lived. If it wasn't in the book or discoverable from just fiddling you weren't likely to find it.

The worst part for me is that my library had a computer section, but it was filled with stuff like "FORTRAN for System/360". Apparently the library decided that they had enough computer books and didn't bother getting new ones.

This reminds me a lot of Handmade Hero. https://www.youtube.com/user/handmadeheroarchive For educational purposes, Casey Muratori codes a complete game from scratch, pretty much without any libraries (Win32 and OpenGL).

In one of the videos he said that he doesn't use the internet at work. Hates it. When he has a question, he writes it down. When he needs to learn something, he googles it at home, downloads a bunch of articles as PDFs, then goes through them at work, but offline.

The second biggest difference is that the internet has changed the nature of debugging.

You used to follow the program all the way through on your local machine and interrogate all the variables.

Now, you're debugging across the client and the server. I think that is one of the reason unit testing has taken off. It is much harder to know where something happened.

The third biggest difference is that languages can be a lot more complicated because documentation is searchable so you can have a lot of functions that do the things you might have written yourself.

This really brings me back. I used to write "algorithms" all the time, then at some point it just turned into debugging SQL queries. When I was younger, it was so much more "real" programming. But it's easy to look at things with rose-colored glasses, because there were two huge problems.

First, programming was sooo much slower. Nowadays there's a function or a library for everything. Back then, if you wanted to serialize something to disk, you had to write a serialization function first. Fun, but SLOW.

And secondly, debugging was even moooore slower. The amount of time wasted on trial and error was astounding. Nowadays, if a library or browser or OS is misbehaving, a quick search will usually find the problem and workaround options. Back then, it could easily take days and days to try different solutions (hence the "invention" and "creativity") until one turned out to work, and it might not ever work at all.

So while the author says:

> I have to admit I think programming was actually more fun back then. Without all the modern trappings of working as a programmer that suck major time out of your day we were able to spend a majority of every day actually programming.

What I remember is a majority of every day spent debugging mysterious problems with OS calls and libraries, or writing "grunt" algorithm code for stuff there ought to be a function for already, as opposed to writing the fun new stuff. And let's not even talk about waiting minutes to recompile, or how primitive debugging tools were back then.

You can still find low level coding opportunities in embedded or systems programming. Low level network software, mobile networks, embedded signal processing applications etc.

What I really love in programming is the flow and focus you can attain when coding for hours with little interruption when you master all the libraries you use. You feel how everything quiets down around you, not because there is less noise, but because your concentration is so strong that they fade away. When you stop and go outside it feels like you have been on long trip in a faraway place. You look at people and they are acting just like before you left but you feel like foreigner. When you go to sleep you have weird dreams where you move in some data structure.

http://catb.org/~esr/jargon/html/H/hack-mode.html

edit: I don't think its fundamentally low level vs. high level problem. It's the quality of api/library problem. Compact and logical high level library that you can understand and master without continuous stream of surprises is what is needed. Verbose libraries with unnecessary "enterprise" cruft kill the hacker inside me.

Sometimes as a discipline/indulgence I go to a coffee shop that charges exorbitantly for wifi so I cost myself immediately measurable and painful (because exorbitant) cash if I don't invent the solution on my own. These hours are non-billable but they stretch my creativity and cleverness in ways OP describes, which increases productivity during billable hours etc. Also keeps me sane. :)

This is exactly why MIT stopped teaching Scheme/Lisp. Graduates could think and reason about programming well, but Python is a much better intro to the world of modern programming: 1.) what is my problem 2.) stack overflow 3.) get libraries 4.) read bad documentation of library 5.) hack solution together with vague understanding of black box libraries

As a programmer, I often feel the funnest part of the job is when you're writing new code, but at the same time, it's often more efficient to search for an existing library. This internal conflict between what's enjoyable and what's efficient often leads down a path of least enjoyment and efficiency (e.g., writing a library whose functionality already exists and then seeing it die and replaced by open-source alternatives after many person-years of wasted effort).

As a side note, I'm one of the creators of a tool called Sourcegraph (https://sourcegraph.com) and this post actually captures a big part of the problem we're trying to solve. Being able to jump to def and find references / usage examples across open source makes reading / understanding / grokking code a lot more fun and efficient. Would love to hear people's thoughts.

I didn't see anybody mention compile times. Today, it is instant -- click to run.

My first programming job - our product was a CAD package for Windows 2.1 and the new v3.0 beta. It took 9 hours to do a full recompile on our fastest computer, a fancy new 486dx-33 with 8MB of RAM!

NINE HOURS TO COMPILE.

Now I get impatient if it takes more than 15 seconds to compile, build the firmware image, download it to hardware and reboot.

It's a different world, for sure.

I think it makes us a little careless. The approach to coding is different. THEN there was a huge penalty to break the build, and we tended to think through a solution very carefully before implementing it. Now, I'll confess, I'm just as likely to plug in some magic numbers and see what happens, or set a breakpoint down in the guts of some heavy code and see what's happening as I am to very carefully think through all the permutations and be sure of everything before hitting Go.

Of course, there also wasn't as much you needed to know back then. I look at something like a modern "Roadmap to becoming a Web developer in 2017" [0] and I wonder how anyone is able to get through all of that.

[0] https://github.com/kamranahmedse/developer-roadmap

Can't help but see the parallel between this craft and many other crafts. In the beginning the people doing it are independent, isolated artisans. You might've been the one guy in your village who knows how to, let's say, make barrels. Except for maybe your own sons, whom you yourself taught. In fact the skill is so uniquely identified with you and your family, people actually go ahead and make it your surname - William the cooper slowly becomes William Cooper.

Fast forward to let's say the early 1900s, and people have figured out how to automate and mass-produce barrels very efficiently, such that there's really nothing much to it anymore. It becomes a question of your materials-sourcing abilities. One person can make lots more barrels a lot more easily, and do it better than you can. Because of this, most people just buy a barrel when they need one; they don't make them by hand anymore.

tl;dr: The good-ol' days were simpler back then, but today's amenities are nice too.

Biggest difference between coding in the 80's vs. now:

Then: memory and CPU cycles were not cheap

Now: everything is multithreaded and often asynchronous

Mid-late 80's. A young, precocious kid spending summers at the library on their Commodore 64 creating text adventures set in Tolkien-esque vignettes. A well-worn book of BASIC exercises and puzzles at his side for reference.

Early 90's. The young teenager pilfers another Turbo-C demo disk from a thick book on the discount table at the back of the bookstore. His last demo ran out of time and he can't continue work on his game without it. He can't afford the software license. He logs onto the local BBS when he gets home and reads about something called, 'Mode-X'. Mind blown.

Late 90's. He drops out of high school to write Perl for a living. He makes a bigger salary than either of his parents ever did. More than his peers who were flipping burgers for minimum wage. He writes scripts to generate a website from his journal log files and shares it with his, "other friends." The ones who know the right incantations to make computers do things beyond playing video games or listening to music.

I wasn't a professional programmer at the time by a long stretch but I do remember having to figure most things out for myself. I caught the tail-end of the mid-80's craze to teach every kid how to program in BASIC. As a lone geek in astronomy club and pilfering his fathers' textbooks on classical mechanics I knew that computers were for programming and that was how you made computer games. I don't think I would've understood trigonometry or linear algebra any other way.

It's amazing how much the Internet has changed absolutely everything. Somewhere between 1999 - 2007 when persistent, high-speed access became the new normal programming changed. CPAN was a big deal and a huge tool... that idea caught on like wildfire. Now every language has a package manager and you can hardly start getting anything done without downloading a hundred or so megabytes of source code first. Learning has changed completely. We forget as easily as we discover since the knowledge is persisted for us. Learning about Duff's Device was a huge step for me... now I work with programmers who don't even know what the size of an integer is (a silly question of course... but totally unaware of how such a construct is implemented in the machine) and they do great work and provide immense value. Yet they couldn't construct a binary tree or heap if they needed to; the default is to, "just google it."

Yet when push-comes-to-shove I still find that sometimes forgetting all of that lets you get real, productive work done. Analysis, paralysis is a real problem in the face of an abundance of choice. Especially when there's not a clear "match" to your requirements. Sometimes it's just easier to solve the problem with your own solution that fits your use case.

Main difference, IMO: now you're at least 10 times more productive. No waiting for floppy discs nor 75-125KB/s hard disks (!), better tools (better SCMs, compilers, etc.), using the Web for searching (ideas, fixes, help, etc.). If it was fun back then, now is amazing -:)

First paid programming gig was working on network equipment in the 90s. If you thought MacOS was primitive, we had to write everything from bootstrapping, to the OS, to the network stack and up from scratch. On some platforms we had to debug with morse code on an LED, uphill both ways in the snow. I miss those "primitive" times as well, but.. We're so much more efficient now. Things that used to take person years now take minutes to download, and we can move on to making our stuff do things that are much more valuable to society, rather than duplicating the same work as everyone else over and over. We have the shoulders of the Stallmans, Torvalds, and many others of the world to stand on now.

Anytime I read something like this I just want to quit the entire industry. It's depressing. It's all just shit now.

Back in the 80s I would cite this sketch whenever someone talked about how good coding used to be back in the day: https://www.youtube.com/watch?v=Xe1a1wHxTyo

Honestly, when people ask me in job interviews what the hardest (programming) thing I've done, I default to "I taught myself pointers in C in the early 90s". Kids today have it so easy!

markets prefer efficiency and using best of breed 3rd party software/libs etc is efficient vs. everyone re-inventing the wheel (inefficient).

So much of programming these days is glue code, even with IOT, devices and sdk's and libs are getting better and better.

The creativity of today comes from ingenious ways of developing new processes the arise from gluing together existing ones.

If you want to be doing greenfield algos go get a PHD in comp sci...and stay at the uni.

Absolutely THIS:

"...and the real skill is in finding it, relating it to what you need, deciding if it is useful or adaptable, and if it is of a decent quality"

His 'out of date' point about help resources is a key point.

SO posts should come with unit tests and library version manifests.

As somebody else who started coding in the mid 80s I feel this is one of the disconnects of the interview process: interviews evaluate you on the basis of an "80s programming model" where if you needed a red black tree library, you likely had to write it on your own.

It would be a lot more representative of today's work if you were asked: given these 3 github repos with packages that all purport to do X, which one would you pick for this set of requirements and why? and how long would it take you and a team of 3 to get it done? Then you have an hour sitting next to the interviewer that can see what you are looking at in the code, what you are googling, how you are estimating and so on.

You could be the best algorithm writer in the whole world, but these days when do you ever have the luxury to write greenfield code? It's all "let's leverage open source" and "we don't have the budget to write our own frameworks" and "why do you want to spend X months writing this, when I googled and in 5 minutes I found 8 packages that do it" and "estimate how long it would take you to do <insert fuzzily defined huge task>" etc. etc. etc.

Personally I do miss the days where I felt that all I did was coding, as opposed to putting together a collage with code found elsewhere.

I sometimes feel like doing an Ask HN about "how do you find a coding job where you actually code most of the day when you are 20 years into your career"