I started writing code in 1986 as a kid. My first program was in BASIC on a Commodore 64 with a tape drive: 10 BEEP 20 GOTO 10. Made my father proud. Annoyed my mother with the constant beeping.
In 1998, I was writing code in Delphi. It was great. The Delphi language was cool, better than VB6 at the time, so many built-in components. I was developing Windows applications internally for a company that did vibration monitoring on large machines.
The systems back then were simpler. The UI was less sophisticated, so we didn't use any third party frameworks. We didn't use a lot of abstraction / design patterns, we just made it work and changed it later if it needed changing, because it was easy to change the code because it was so simple (but harder to roll out because we released code on floppy disks).
Fixing bugs was so much quicker, because there were not as many layers - there was the UI and the code that handled the UI. That's it.
Now in 2022 I am writing software doing ETL for a company that does grocery analytics. There is a UI written in Angluar, then a C# API with a controller, which sends a mediator message, which is handled by a handler, which calls a service (potentially in another API), which calls it's dependencies to get things done, and then finally calls a repository to save things. Sometimes we have different APIs for each part, sending messages via RabbitMQ and NServiceBus. So many layers, so hard to trace bugs.
Now we write code with less coupling and it is more able to handle business logic changes easily without breaking the rest of the code because it is abstracted, and we have unit tests to test changes have not broken existing code. I see why these things are good, but they have a cost in terms of productivity and developer frustration.
In 1998 I had to know Delphi and it's database to be good at my job. In 2022, I have to know C#, SQL Server, Azure, Docker, Html/CSS, JSON, Http, Anguar/React/Vue. I also have to know how to use many third party C# and UI framework components and how to do units tests in front end and back end.
Honestly, I felt more productive, and less frustrated as a developer, back in 1998, when everything was simpler.
Perhaps there is value in making things as simple as we can, and only making them more complex when they need to be, instead of doing it because it is considered industry practice to do so.
Topic idea came from reading this post on Hacker News...
What was being a software developer like about 30 years ago?
https://news.ycombinator.com/item?id=33403174
Top comments (1)
As another old dude, I have to disagree at least in some parts. Well, it was "more fun to compute" in the old days. As a kid, you are playing and experimenting rather than developing, and while one person types "20 GOTO 10", another one codes interrupt handlers in assembly to fake more than 16 colors.
As an early web developer, it took a multitude of complex event handlers to modify styles or images on mouse over, which is now a simple
:hoverdeclaration inCSS. There were a lot of workarounds, and a lot of simplistic programming interfaces like Macromedia Flash 3 Action Script, Microsoft Visual Basic, or Commodore BASIC with line numbers and its limited instruction set.All of those "good old days" tools I would now call low-code tools. You can still use computers in this simplistic ways, building your website with WordPress or WebFlow and use UI libraries to focus on your actual business goals.
When it comes to web development specifically, I feel much more productive than any time before. We have a lot of complexity, a lot of opportunities, but also a lot of choices. We can use WebFlow, ReactJS, VueJS, JamStack, or set up a team of highly skilled senior developers to fabricate a new, 100% perfect, clean code, alternative from scratch. It all depends on how to use technology and make the right choices.
Thanks for your post anyway! I enjoyed the old days and this made some nice memories come back into my mind!