6 ms·
> [from Dilbert] Will there ever be an engineer who says "that last guy did a great job. Let's keep all of it"? I don't know about other people here, but this
by aeturnum 6y ago
> [from Dilbert] Will there ever be an engineer who says "that last guy did a great job. Let's keep all of it"?
I don't know about other people here, but this is almost always how I feel? I almost always feel like the previous team made choices that were sensible given the facts at the time. Most changes I want to make come from the changes in our product since that chunk of code was written.
Of course I have my own methodological practices and sometimes I will re-write some particularly ugly copy & paste job the way I want "as a treat," but mostly if something works it works and you move on.
The best code is the code that already exists and works.
- mywittyname 6y agoIt sounds like you have empathy. A lot of people look at issues with a code base and just assume the problem is due to stupidity. Rather than coming from the angle of, "this person was probably as capable as I am, why did they make this decision?"
- disgruntledphd2 6y agoYeah, the trouble is that it's easy to update a method to account for a bug, but the cumulative effect of those changes tends to make a codebase more difficult to reason about for new starters. In general, being able to take a few steps back and look at the whole system is often rewarding, but it's super difficult. Actually, people who come to a project later can often be great for this, as they can see the project as it is now, rather than as it evolved. Unfortunately, we tend to be quite bad at letting people take the time to build said mental model. Also, most people hate reading code (or at least they don't take the time to do so). Personally, I really like reading code, and I find legacy projects much easier to work on than many of my colleagues.