Sometime around now, some 20 years back, I had my first gig as a "professional" coder. A friend of mine put me in contact with somebody who wanted to allow those that had coding certifications (like a Microsoft MVP) to build a basic profile, upload the all important "badge" image they received, and have a nice looking single page "resume" to share and connect. Maybe I built the first LinkedIn, but I won't necessarily claim that [:: smiles ::]. However, I did learn the most important lesson that sticks with me today. It has also been a wild ride in software...
Photo by Markus Spiske on Pexels.com
https://open.spotify.com/episode/51JZHJfmkkWHPtd3ln0iqL?si=9d16bfb952984aa2
Listen to this post as a podcast!
In reflection, it's hard to think about where to begin. Probably the most poignant thing that pokes at me daily is that we're still learning how to build software and what to use to build it. I like to joke [:: or am I ::] that by the time you've gotten to this point in reading, two new JavaScript frameworks have just come out, both claiming to be the new paradigm in how to build things. The thing it reminds me most of (for any young budding programmers out there) is that the "semantic"s of coding (algorithms, data structures, processing, etc.) are the more fundamental aspects of coding that won't change. The "syntax" of coding (the language or framework used) is constantly in flux, but easier to adapt to once you know the "semantics".
When I first started coding, Web 2.0 hadn't even arrived yet. HTML and table layouts were the lay of the land. There was this thing called WAP which was supposed to give you web pages or content on your mobile phone [:: supposed is the operative word here ::]. I wrote some pretty sweet Perl scripts to handle form processing and image uploads in the cgi-bin of that first project. Heck, JavaScript was still a toddler and a beast to work with, but it was a heck of a lot better than Java Applets if you ask me. [:: ugh, that Java... ::]
It's interesting to see how the "fat client / thin client" web page/app cycle continues. Early web forced a thin client, since you couldn't use JavaScript to do much and you needed the server processing to tell you what to do next. Then when JavaScript finally started getting decent, you could make the pages more interactive and rely less on the back end. Maybe this was the cause for the "cram everything into a page with minimal spacing and 10 point Arial font: and it was a wild ride. The clients got fat because we could do more and bandwidth was still slow. I wrote an entire bible app with chapter navigation and verse searching (that preserved the verse's context by showing the entire passage) thanks to this.
Then AJAX came and we got thin again. Maybe you could consider the client fat still, but with AJAX, you could make a ton of small queries to the server to get what you needed. Your logic was reduced and early AJAX involved injected a huge blob of HTML rendered by the server into a div block you had earmarked for it. Things became nimble again and Google began to take over the world with suggested words as you type.
AJAX and browser wars made the web ugly for devs. You had this awesome way to prevent a full page post back / render, but without standards, each browser decided to implement things differently enough. Except for Internet Explorer, they decided to do their own gig altogether. Now you had browser sniffing scripts and 3 to 4 different versions of some of your code depending on what you wanted to do. CSS was growing in popularity for making things look pretty and each browser had their own way of handling that too [:: shakes angry fist ::]. Then jQuery and Bootstrap came to the rescue by doing all that for you! Our thin clients could reign supreme by not having to worry about browser specifics. That also enabled clients to get fat again.
jQuery allowed the web to get more sophisticated with its easy DOM manipulation, which led to more functionality getting packed in to your average page. This increase in data manipulation, partial results, animations, and more led the way to the modern single page application era we're in now thanks to React, Angular, and a growing VueJS. All your backend needed to do now was be a glorified database, thanks to the JSON format [:: you can kick your DBAs to the curve too if you use GraphQL ::], with a little bit of rules enforcement. The prevalence of broadband made the amount of JS code the user downloaded largely irrelevant, especially since it was loaded (in theory) only once by the user. Fat clients will rule the day!
But maybe there is a shift happening again [:: are you still surprised? ::] There have been enough concern with heavy rendering and SEO that React has a server side rendering option for components. Angular supports this too. Additionally, if your backend is nothing but a data store, you can work your away around some of the HTML shenanigans to show that admin button if you haven't done things right and nothing is protecting you on the backend. The rise of IoT and wearable with limited front end power may be pushing things back to a thin client again. At the same time, web assembly is looking to double down of the fat client by letting you use your favorite backend language (C#, Node Rust) to build even more functional apps in the browser. [:: wait, did you just take the cycle within 1 paragraph?! -- yes, yes I did ::]
Alas, I haven't even gotten into database technologies, mobile, IoT, cloud, containerization, ML/AI, and a plethora of other nuances of code that still fascinates me and gets me excited for the next day. Oh yeah, and bitcoin... [:: smiles ::]
Oh, and that most important lesson I learned way back when? Communication is key. Never stop doing it and never stop refining it. I was fired from that first gig because after delivering the 1.0 (agile was still growing) I went on vacation and never bothered to tell my client. He wasn't too happy given that he was ready to build more features. While one may be able to code in a vacuum, eventually that code will speak to others, and documentation, or collaboration, or hand-offs will require a conversation with somebody else and doing that consistently will lead to the best results. Learn to balance "how much" to communicate with your peers, mentors, advisors, or clients, but never stop doing it and never stop refining it.
So here's to 20 years of a wild ride in code and another 20 years more of it if my fingers will allow me. Then again, voice recognition and rapid application platforms will probably reduce that need, so I'll be safe. [:: smiles ::] Let's see what comes next!