Before Google, and before there was actually content on the Internet, it was the MSDN documentation CDs and about 20-30 very large books.
People scoff these days about stack overflow, but we were more reliant on examples in print that sometimes wouldn't work. Stack overflow is just a resource only slightly les trustworthy than a first edition manual.
On the flip side, most coding was quite simple, but for internet work you needed to know perl or c++ as well.
There's legendary stories of the very few software developers out there, having huge "conferences" (parties) across Las Vegas and almost every Ski Resort on the planet. To be in demand meant that if you were an Ad Exec or a Software Engineer in the 80s and early 90s, you were set.
Back in the day, we used to have several monitors when developing web applications, mainly to mimic laptop use and desktop use.
I thought that the dynamic resizing features in modern UI development would negate the need for these, but apparently not.
Future of UI, or rather HCI, has to be voice or gesture. First company to make an intuitive interface and UX for the internet that everyone can use for their TV will be onto a winner.
About a decade ago, everyone was told that scientific documents were impenetratable by common folk, so to make them more accessible and attract more funding, a narrative should be created and include literary devices to spice them up.
Now everything reads like a TED talk.
There's always Leetcode and Hacker Rank.
If you get involved in an open source project your horizons may narrow quickly, so it's best understanding the strengths of being a generalist or being best in a particular area.
The key thing in the development sphere is that nothing stands still, and neither should you.
I don't think there is an end goal. Programmers do seem to have an abundance of Ego, so maybe best to keep that under control?
Personally, seniority comes with opportunity. If you keep stretching and learning, you can work in pretty much any industry you want.
Learn your development environment (IDE, or text editor). It may contain features that will make your life easier, both during development and during debugging.
If working in a team, create a policy document that everyone signs off on. Don't sacrifice quality for speed when it comes to policy.
This ensures that code is transferable between team members without too much noise.
Being able to use search engines is a definite skill that certainly cannot be understated. Once upon a time we'd have shelves of $100 books to pore over, and that would take time in itself. Being able to use the correct terminology and the correct search engine logic will help in delivering software faster.
The most starry of starry eyed startups will want a team that is already fit for scale, so they build for scale before they need it. Possibly convinced by VC behaviour and getting as much from each funding round as possible. If you have to scrap your 1st round team and re-employ for 2nd at scale its going to be a hard sell.
There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.
People scoff these days about stack overflow, but we were more reliant on examples in print that sometimes wouldn't work. Stack overflow is just a resource only slightly les trustworthy than a first edition manual. On the flip side, most coding was quite simple, but for internet work you needed to know perl or c++ as well.