> "The software engineering team had two titles: Software Engineer and Senior Software Engineer. This was typical in the industry. You had to have at least 10 years of experience, but more likely 15 years, as a Software Engineer before being considered for promotion to Senior. The bar was higher for Senior then, too. I’d say a Senior engineer back then was skilled and experienced more like a Staff or Principal engineer today."
amazing to see that the title inflation in our industry has roughly matched actual economic inflation :)
on a more serious/optimistic note, there is a lot more tech to learn today than in 1989, and we probably learn at a faster rate too given the available amount of material (HN, youtube, books, etc). so perhaps not unwarranted. i'd love to pit a senior engineer of today vs a senior engineer of 1989 in doing modern programming tasks.
I suspect that the ones of today would have a mental agility and/or capability to discover things on the fly that simply weren't possible all those decades ago.
I think it's only at the real low-level or hardware/assembly or, for instance, a bit above the stack, say, optimizing a data model or fine-tuning a DB engine for a given domain, that the old timers would really shine.
I see it in my daily life: my dad was a Fortran programmer way before I was born, so, maybe you know... 1970s or something like that. He was actually very good at his job, getting a research position doing some serious programming work that was seen as groundbreaking at the time, doing some finite element modeling on extremely resource constrained environments, probably what we would call data-oriented programming today, but taken to its extreme....
However, he didn't really keep up with programming after a few years, shifting to MATLAB based tasks for some university courses he lectures... and I feel that the complexity of today is just too much for him to grasp as it was. It's just too many moving parts and too many layers of abstraction to sift through.
By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.
> By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.
I've done both. I've gone from high level C# to counting clock cycles for embedded, and then back again.
There is a transition period, but it is perfectly do-able. It is helpful if you have someone to show you the ropes, but after that it isn't too bad.
Heck I've met some teenagers who are into disassembling JVM/CLR stuff. (Which is actually, IMHO, much easier than raw assembly).
Have you ever done scaling calculations for AWS services? Same sort of logic applies to writing code for embedded, there is just a different number of mhz and instead of gigabytes of memory you are talking kilobytes of memory, but other than order of magnitudes, the reasoning is actually not that dissimilar.
My first couple of jobs from late 90s on were C++ and Java: homogeneous giant code bases with no agile, scrum, code review or anything.
I do just fine with modern code bases and their complexity. I know I also have the experience to understand when the complexity is there for the sake of it and when it’s because of the business domain.
I’ve left projects where the first kind was too high because I’ve seen enough to know I don’t have time for that BS anymore :)
amazing to see that the title inflation in our industry has roughly matched actual economic inflation :)
on a more serious/optimistic note, there is a lot more tech to learn today than in 1989, and we probably learn at a faster rate too given the available amount of material (HN, youtube, books, etc). so perhaps not unwarranted. i'd love to pit a senior engineer of today vs a senior engineer of 1989 in doing modern programming tasks.