371–380 of 431 posts
And I would add, you are not an "expert" until you had to reverse engineer a program who's source disappeared a decade or more ago :) But an interesting article for modern times.
This is usually doable until it's DEWS/SAGE radar code from the 50's. That's what NASA started with and the last guy died in the 90s. We got every other subsystem off the mainframe, but had to keep it around for the radar stuff until 2004 or so.
Details please ;-)
Earlier quoted context omitted.
That would require staying in one company for more than 2 years, which means you probably lost out on 20-30% of income over next 2 years.
It’s okay to enjoy work and focus on your craft for two years rather than jump for more money. If you like your employer and colleagues and are growing as an engineer isn’t that better in the long term? I think jumping around can risk creating an engineer who leaves a place worse than when they started.
These aren't mutually exclusive.
> If you like your employer and colleagues and are growing as an engineer isn’t that better in the long term?
Better than liking your employer and colleagues and growing as an engineer and also having more money? No.
This isn't a field with low demand for talent. You can have all these things--don't settle for less.
> I think jumping around can risk creating an engineer who leaves a place worse than when they started.
That's a risk that companies should be willing to pay to avoid.
But a lot of companies aren't willing to given their engineers adequate pay increases each year, and it's not engineers' responsibility to accept less money than they are worth. If you want more experienced engineers, you have to pay for more experienced engineers. That's just basic free market economics: if you don't like that you don't like capitalism.
Some companies understand this and do better, but these are the exceptions not the rule. If you find such an exception, stick with them!
I fundamentally disagree with the narrative that engineers are supposed to be passionate about their craft and learning and interest and not care about the money. That's propaganda spread by corporations to get us to accept less pay, and if you believe it you'll be exploited. And as it turns out, the places that pay the best are also usually the best places to be passionate about your craft, so there's no real conflict. The places that pretend to pay you in learning and passion instead of money generally don't deliver on the learning and passion either.
Earlier quoted context omitted.
I thought it was pretty funny how we had this large project that was supposed to replace a legacy system (that was mostly a bad hack that got pushed to production). But when it was finished it failed to meet the basic requirements for the only customer that used the system.
Once you're senior enough those cases won't be funny any more, just sad.
But yes, it's sad.
You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.
There's a tradeoff here too. If your codebase was started in Java 6, I dearly hope you won't continue to write code in that style anymore for new code.
You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.
"checkout project, reformat all source files, commit"
As an embedded engineer in a new position I always volunteer to take up an old crusty legacy product that nobody else wants to touch. It's a quick education into how the company approaches projects and all the ghosts they had to fight along the way. All the business logic is there, and sometimes it's even documented. And once you have a semblance of knowledge about how the thing works and how to make fixes, you've bu…
Additionally, reading through other people's code is educational and it also builds self-esteem.
Earlier quoted context omitted.
> Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company Nope, assuming that code works and handles UTF8 (sorry, but there is a point where it is too far gone to save). You’ve made yourself essential. You know the business better. You are strategic. And often, you become the one person who knows the legacy code base. And you will quickly find yourself a p…
These insights are essential for playing the long game; it may sound distasteful for people early in their careers. That’s fine, but when you’re running out the clock to retirement, can’t go wrong.
Even at a young age, some people find it super fascinating to work with old stuff and study the traces of people long gone.
If you're that kind of person, digging into an old assembly codebase is going to be so much more fun than learning some newfangled web framework.
Earlier quoted context omitted.
It feels like you're just finding other ways to describe people who are senior in title only which is far too common. Any senior that uses their title to justify a 'you can't tell me way to do attitude, is a senior in title only. I think the term is the issue. Senior development means something more intrinsic than it does in other title, like a senior manager. I think what we're attempting to define is something clos…
The title is more or less meaningless these days. That said the other problem is people can't always appreciate the perspective of a more seasoned developer. Some people who are very junior or intermediate think they know better since they don't have the experience. Lots of things in software come down to judgement/intuition and are not black and white. A lot of software development is about working with people and c…