131–140 of 431 posts
Earlier quoted context omitted.
"checkout project, reformat all source files, commit"
lol I love when people do this and it and now whenever I `git blame` their name shows up.
https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...
I once had a manager that was fond of saying: > Experience is what you get when you don’t have any. The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.
And the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)
"The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."
Brooks reasons that the combined experience of doing the first project well and the second project badly leads to better designs from then on.
Earlier quoted context omitted.
It depends on your goals, though. Depending on the company, that can be a very good way to be treated as a cost centre to be minimised.
Yes, let's minimize the only dev working on legacy software.
Earlier quoted context omitted.
"checkout project, reformat all source files, commit"
lol I love when people do this and it and now whenever I `git blame` their name shows up.
Given this, I tend to prefer a single, formatting-only commit when introducing formatting standards to an existing codebase. Otherwise, it’s difficult to take advantage of QOL features like auto formatting in your editor, or other formatting tools which tend to operate on entire files. Then PRs end up being mixed with formatting changes, which adds friction to the review process.
I think it’s less awful if your expectations are not that of a new project. Yes, there’s a ton of ugly bits at the interface level that you can’t fix. You make it as comfortable as possible while figuring out where to go next if anywhere.
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.
Certainly the most secure code. Not sure about best.
Better on every axis: security, performance, resource consumption, reliability, verification, documentation... Code is a pure liability that you accept to get a useful service.
Earlier quoted context omitted.
Certainly the most secure code. Not sure about best.
Better on every axis: security, performance, resource consumption, reliability, verification, documentation... Code is a pure liability that you accept to get a useful service.
How 'bout job security?
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. This is an organizational problem.
I’m actually kind of struggling to imagine a scenario where a junior developer has the agency to slap entire frameworks onto existing systems. Maybe a late stage startup? Coding practices, definitely.
I always considered legacy projects more interesting than zero to one. A lot less reinventing the wheel and bikeshedding, a lot of puzzles - painful ones, sure, but at least it's not a bunch of CRUD (or the usual startup experience, which is a constant flux of rewriting-crud-very-fast)