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.
> 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.
All projects I have done for the first ten or so years of my commercial work have been picking up an ancient code base long after the original team has left, and making it work. I reserved the nice and clean code for my personal hobby projects. At work, it was about getting the shit from the past working and maybe improve it a little along the way. You even adopt the coding style you hate, just to minimize diffs and making it easier to navigate the history.
Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.
> Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy Truth is harsh, however this seems to be 100% accurate for nearly all cases of employment. Rarely do you get to focus on simply interesting problems and good engineering as a primary concern
Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.
> Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy Truth is harsh, however this seems to be 100% accurate for nearly all cases of employment. Rarely do you get to focus on simply interesting problems and good engineering as a primary concern
Boredom is in the mind, not the task. Things aren't boring, people are. An important type of intelligence is the capacity to find what's interesting about a task that others lack the imagination to see. One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.
I keep telling people v1 of anything always sucks. One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.
I always pick apart previous teams' work.. it's how I learn. I question most every decision because I'm curious why they made those decisions. And it lets me think about how I'd do it better. And yes, I know that many poor decisions are not necessarily the developer's fault. It could be bad specs, lack of time, etc.
In most cases, "better" means different things in different contexts. (Customer-driven vs performance-driven, for example) Of course, this isn't news for most of us. Where I think a lot of us fall short is assuming that definition has changed since the code was written.
I have hobbies. The most interesting work is going to be 10% interesting and 90% not interesting. In most cases it will be less interesting than that. Prioritizing "interesting" work means you'll always be exploited by the companies that can sell you on less pay, less benefits, less time off, less respect in exchange for some pittance of perceived novelty. Don't fall for this trap.
tell me you don't have ADHD without telling me you don't have ADHD
In a world where everyone has ADHD, I welcome these few non-ADHD aliens.
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.
It's not limited to shiny new frameworks. Following naming conventions, design choices, etc, can take work, especially if you see something that isn't "best practice". Heck, sometimes you need to refactor something and the best thing you can do is reimplement any bugs you found (obviously with documentation and discussion to try to surface the why)
You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance? And you've found a way to completely forestall the non-technical demands that force non-ideal design choices? You're sitting on a gold mine friend.
I should say not prevent it. But minimize it in the maximum possible way. I am sitting on a gold mine. But I can’t prove it. That’s the problem with this stuff. The industry moves horizontally with each design such that nobody knows if say the current design trend was better than the last. We go better or we go worse and nobody knows if it actually was. Maybe I am sitting on a gold mine. The problem is you’d never kn…
I'm not the OP, but I'll say that I don't believe you, because you're telling me you have The Perfect Solution, without providing even a hint of what that solution is. If I was skeptical at first, I'm now certain you're selling smoke & mirrors until you provide any evidence at all you actually have an idea here.
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.
> 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.
Using the latest framework improves their future job prospects. Whatever company they work for will lay them off in a split second and won't provide anywhere near the comp increases that a new job would. So why should they care about the long term of a project?
Companies have no loyalty to employees which means employees have no loyalty to companies.