|
|
|
|
|
|
by fsloth
2204 days ago
|
|
|
This in an excellent advice. In real world the value of a codebase is not in it's aesthetics. It's how and what sort of added value it bring's to it's users. And how much value your employer can capture from it (i.e. it's price). The question you should ask is not "how to make this more beautiful" but "how to bring in more value to the customer". Don't go on a refactoring crusade alone. If you want to become a valued individual contributor try to understand the added value created by the product as much as you try to understand the codebase. |
|
|
That said, intuition and sensibility are your most important professional assets; you definitely want to nurture and listen to them. The feeling that code is "ugly" is often a signal that it hides surprising behaviors (bugs) or that changes involve more effort and risk than they should. Any software org you want to be part of does care about its ability to continue shipping working software. Protecting that capability is very much part of your job. Don't check in sloppy work. But let senior people take the heat on correcting others' sloppy work, at least until you learn what the attitudes about it are like.
Similarly, don't go having opinions about customer value or business strategy until you have a relationship with the product manager and an understanding of the context, intentions, and roadmap. When you do, they should be weakly held and gently expressed. Software engineering is your domain; there will be times when you know something that others don't and you have a duty to be firm about it. This will never be the case for business.