In my own (non-technical) case, I had a great 15-year run as a top-of-the-heap IC -- and then my outfit got bought by people whose business model had no use for what I did. Time to do something different, and with it being 2008, going independent felt a whole lot smarter than trying to find a new star-IC role in a scared industry.
Going independent was good for 7-8 years, but then my favorite partners at my favorite clients all got to the end of their roads. New faces; new visions, and the unappealing prospect of spending 3-4 years trying to revive a shrunken pool of business into something better.
A star-IC role opened up somewhere else, and it's been a great ride ever since.
It's the career equivalent of summers in Alaska; winters in the Caribbean. Sometimes the key to staying warm and happy is to be willing to move when the temperature changes.
Thank you for this. It really landed close to home for me.
The problem is a lot of older people seem to believe that once they get to a certain point, they're entitled a position and respect. Is it a wonder why younger people, who might be more up-to-date than them, don't want to work with them?
The trick is to never get that kind of "old" and remain a lifelong learner.
Most of the "new" ideas in computing (neural networks, quantum computing, etc.) aren't new at all. Not to mention that Linux and macOS are basically 1960s-style operating systems.
Knowledge of short-term technical details and skills at dealing with brand new systems are much easier to acquire than deep understanding of core principles as well as engineering experience.
Dismissing senior colleagues as "entitled" and their knowledge and experience as worthless and refusing to work with them as a consequence would be a grave mistake.
Neural networks are a good example. If you skipped the last decade (/two) and you think you know about ANN because you mastered them in 60s... boy do I have news for you. :) Another paradigm shift for me was React (declarative web frontend development), and let's not even go into the whole Rust thingthing
One of the biggest pitfalls of an experienced person can be lack of curiosity, and it is really easy to fall for it, because let's face it, most of the new things are crap and will be forgotten in a few years. However, there are nuggets to be found in the mud, one just needs to keep looking.
It's easy to reflexively dismiss reimaginings of things that have been tried and failed half a dozen times over the years. But sometimes the concept has been tweaked enough, the environment is different enough, the technology underpinnings are better enough that it actually works this time. Virtualization (z/VM--or whatever it was called at the time) was mostly a curiosity on IBM mainframes for years. Then VMware came along (and Linux on Z was pretty successful on IBM mainframes as well).
But also, React is doing things that desktop GUIs had figured out years ago. It did a really good job at distilling the essence into something useful. Angular started the trend of finally moving towards state-driven views. Kudos to all of these developers for making web development less sucky.
To label it as a new thing that nobody else had done before though, that's going a bit far. New on the web, sure. By the time these got introduced, I had been waiting for years for a web framework that incorporates some of the non-web lessons learned. Let's give it lots of credit, but not more than it deserves.
I never claimed it was "first" and I even called out "other frameworks like it." The iPhone was also not the first smartphone.
> CSS still makes layouts unreasonably complex imho.
This we can agree on. Though it could be a lot worse, and some of the newer CSS definitely gets rid of some of the warts. A lot of the bad CSS is mostly the backwards-compatible stuff.
If we stay with that idea for a second: FAANG companies have tens of thousands of engineers. Getting there isn't a "gold medal". You're barely in the stadium. If you made it to Principal Engineer, congrats, you've gotten through the qualifying rounds. Still plenty of room to strive.
There are plenty of valid reasons for why you choose or don't choose FAANG. But "Where would I go once I've achieved that" really shouldn't hold you back.
A startup probably won't be able to afford the standard of engineering that you can find at places like Google. There are good practices you can learn there that you probably won't see at a startup.
As a company scales up, coordinating effort across teams becomes more important for getting stuff done, even as a senior IC. You no longer know the whole stack (assuming you're an early employee) and have to ask other teams to adapt interfaces and add functionality to get your stuff to work.
However, that's the default at FAANG. Coordination is the name of the game and it's so meeting heavy because it's a lot of work to keep everyone aligned, on the same page.
You can learn interesting technical things either way, but it's easier to find a niche as a specialist at a large company. Startups usually need generalists in the early days.
I spent eight years at a startup (4th engineer, rose to chief architect after CTO left, was most senior engineer of 40 or so in co) and joined Google last March.
I learned a lot when I joined the startup (Rails was new to me) and I added some hard yards of scaling up database utilisation with very little extra hardware over the years, but the pace of learning declined over time and my degree of specialization increased as I focused on the biggest bottleneck the business had, technically - even while the business was of course more interested in fattening up its product line for valuation.
I learned a huge amount when I joined Google too, though a lot of that is due to the parallel universe quality of working at a company that had to solve many scaling problems for the first time and did so with inhouse tech which didn't become industry standard (I blame monorepo - it makes it too easy to have incestuous dependencies). A bigger part of the learning was the mode of getting things done between teams. I haven't learned much in terms of transferrable tech, but I have seen better engineering practices put into action, that we could not afford - and didn't have strong enough singular opinions on - at the startup.
I can say it's not the same things every day, everywhere. There is no end to the code at Google, there is more than you can ever hope to understand and it changes too fast anyway. At a startup, you can understand almost everything. More work is political at largeco, necessarily because the org tree sometimes needs shaking to get things moving, but also simply sociologically - a startup is a small team, largeco is a whole nation with internal rivalries and whole divisions that never need to communicate much.
And that is the root of all evil. Everything comes down to a screeching crawl. What could be done in a week by a couple startup folks now takes months or quarters (!). So yes, I don't think "standard of engineering" applies here :-)
In addition to all that was already said, this has the disadvantage of misaligning incentives. At FAANG (or any other big co for that matter), it pays to stretch projects and blow their complexity outside of any reasonable measure, just because the folks in charge of such projects benefit materially from more people and "bigger architecture". It is engineering bureaucracy at its worst, unfortunately.
In contrast, at startups it pays to move fast and one simply cannot afford growing unnecessary "fat", gotta stay lean or die. Obviously, some folks are more comfortable with the former (FAANG/big co) approach, because at the end of the day they just want to get their paycheck and go home, it's not about this job or that job at all. It's a tradeoff, for sure.
A "standard of engineering at Google"? You must be joking.
Best examples of engineering I have ever seen were done at 5-15 people startups. I'm proud of participating in some of those. FAANG on the other hand is a mire of bullshit.
I can easily see it being different elsewhere, of course.
I'm at FAANG and still learning plenty. I'm not here to hit an arbitrary goal but because I have to have a job and it pays well, so might as well turbocharge my savings.
But yes, you should always respect the journey. It never stops: keep participating in it, and keep your eyes open.
Needing to constantly keep up is quite unique to Tech, and is a good or bad thing depending on your outlook
https://www.bostonglobe.com/2022/02/22/opinion/ibm-e-mails-a...
While it's not true everywhere, age bias— even unintentional— means you've got to be pretty freaking indispensable no matter what our constantly changing tech landscape throws our way. We're not talking about the proverbial behoodied-27-year-old-led startup, here... this is IBM.
When I speak about career options to people I lead, I say there is a senior level plateau. At that point, you have to be more intentional about growth. If you want to stay in the field, and you want to progress past senior developer (staying a core contributor is an option!), you need to think about where you are going. You can be a generalist, specialist, or outside of development. Going into management is changing careers, much like going into product development or farming.
If you want to be a generalist, you are looking to expand your influence as you tackle harder and harder problems. Tech leads are generalists. Architects are generalists. All of them have some form of technical leadership to help steer larger and larger efforts. You can also become a generalist that specializes in early startups: you are there to tackle any problem that is in front of the organization until it outgrows the need - at that point you can look for new pastures or help guide the organization while solving smaller and smaller problems.
You can also become a specialist. You learn, in depth, a smaller set of responsibilities, but you can build what others cannot. You can debug and solve problems others cannot. You can be a consultant, or a specialized shared service within an organization. You have options, but mastery is what motivates you, and that mastery can be very valuable in certain situations.
But that is career growth, not planning for the end of your career. Sometimes, that is a parallel track, like management or product. Sometimes, that's retirement. Sometimes, that's moving into another industry. I think that's what the article is talking about instead.