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.
The Biggest Difference Between Coding Today and When I Started in the 80s
11–20 of 117 posts
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#12I 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…
>there was the thrill of discovery, in a rather low-level sort of way
Same here, but whenever I embark on a new project today I remind myself of this mantra: "Do not reinvent the wheel" Someone out there has probably already solved your problem, so why not speed up the process and use the fruit of their brain power as a tool to speed up your process? Carpenters or mechanics do not invent a new type of hammer or drill every time they embark on a new project. Why should we?
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#13To 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 nihi…
Very true, and I'm wondering now why this wasn't a Thing in the old days. The obvious answer is "no distribution mechanism for shipping libraries separately from the machine/OS/compiler/interpreter", but that's not entirely true.
The pre-internet Amiga had a thriving public domain and shareware scene where volunteers would advertise in the magazines and you could pick and choose apps/demos/games for the price of postage and a floppy disk. But it was all binary, no source, and I don't remember any libraries ever being distributed that way. Maybe dev tools were too fragmented for that to be practical.
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#14I 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...
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#15As 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 " 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"
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#16I 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…
>there was the thrill of discovery, in a rather low-level sort of way Same here, but whenever I embark on a new project today I remind myself of this mantra: "Do not reinvent the wheel" Someone out there has probably already solved your problem, so why not speed up the process and use the fruit of their brain power as a tool to speed up your process? Carpenters or mechanics do not invent a new type of hammer or drill…
to me this is more like you learned to be a woodworker because you liked actually creating things with your hand tools, and now all day long is just using a CNC router is copy-pasting CNC patterns from cncoverflow and then glueing the machined wooden pieces together.
it's not woodworking anymore, it's glueing and google-fu to find the best patterns on cncoverflow, together with maybe some shim-building here and there and making your own custom stain
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#17Earlier quoted context omitted.
>there was the thrill of discovery, in a rather low-level sort of way Same here, but whenever I embark on a new project today I remind myself of this mantra: "Do not reinvent the wheel" Someone out there has probably already solved your problem, so why not speed up the process and use the fruit of their brain power as a tool to speed up your process? Carpenters or mechanics do not invent a new type of hammer or drill…
to me this is more like you learned to be a woodworker because you liked actually creating things with your hand tools, and now all day long is just using a CNC router is copy-pasting CNC patterns from cncoverflow and then glueing the machined wooden pieces together. it's not woodworking anymore, it's glueing and google-fu to find the best patterns on cncoverflow, together with maybe some shim-building here and there…
Speaking for my own professional experience, while there is a ton of glue and google-fu, the net results are frequently interesting and at least someone novel.
I guess it's a question of what is done with newly available, powerful tools and abstractions.
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#18Earlier quoted context omitted.
>there was the thrill of discovery, in a rather low-level sort of way Same here, but whenever I embark on a new project today I remind myself of this mantra: "Do not reinvent the wheel" Someone out there has probably already solved your problem, so why not speed up the process and use the fruit of their brain power as a tool to speed up your process? Carpenters or mechanics do not invent a new type of hammer or drill…
to me this is more like you learned to be a woodworker because you liked actually creating things with your hand tools, and now all day long is just using a CNC router is copy-pasting CNC patterns from cncoverflow and then glueing the machined wooden pieces together. it's not woodworking anymore, it's glueing and google-fu to find the best patterns on cncoverflow, together with maybe some shim-building here and there…
I just searched for cncoverflow based on your comment. I was disappointed to find it doesn't exist. It sounds cool. ;-)
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#19Of 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
You only need to know all that stuff for the online poser olympics.
In the real world, 99% of people just pick 1 stack and get on with their lives.
Re: The Biggest Difference Between Coding Today and When I Started in the 80s
#20As 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 wo…
I get why some places would want to test your programming skills, I mean, google does a lot of 80's style invention talked about in the article. But for 90% of programming jobs, you're better off with a gaffatape programmer who brings social skills as well as business understanding.
Especially outside of full software companies, the ability to evaluate business processes as well as digitizing them is simply invaluable, and you'll almost never need to write your own x anyway.