[ravenstine]

> [...] write good code.

When people say this, I don't know what they mean.

What makes code "good"? Everyone's answer is different, other than that perhaps most of us agree on things like YAGNI, DRY, and KISS... more or less.

I'm not even sure that any version of "good" code is all that influential on one's career. It should probably be #4 on your list rather than #1. Most people would rather with work with a charismatic team player who's easy to work with whose code is adequate over a 10x developer who's a jerk.

This isn't to say that good code (in the abstract sense) isn't important or that writing good code isn't a part of one's success; if your code is really bad then you're way more likely to be let go from your job. But for a likeable person, is it really so important that they write good code rather than adequate code? Maybe. I kind of think not, but mileages may vary.

[theamk]

It is hard to define "good" code in general case, but in the specific case of discussing engineer's employment in a specific organization, the answer is pretty simple:

"good" code is the code that you peers consider "good".

That could be because the engineer is writing the code which conforms to all style guides and uses the principles that existing codebase uses; or, in some places, this could be because engineer writes code which performs exceptionally well; or, in other places, this could be because engineer writes code very fast (you probably want to avoid those).

[unoti]

> [...] write good code.

> When people say this, I don't know what they mean.

Code does something for the business (or for the customer). Good code both does what the business needs, but is also possible to quickly and easily modify and extend as the needs of the business change.

These two characteristics, that the code should fulfill the needs of the business and also be able to grow, imply a number of other characteristics of good code. It should be easy to read so you can scale the developer force up and down easily. It should be testable, to facilitate rapid changes and health within the code base.

On the operations front, good code should have operational metrics and monitoring, so you can see that it's working well without digging too hard, and can see what areas need attention if any. It should operate in a reasonably trouble-free way, so you're focusing your time on what's next instead of problems caused in the past. Sometimes I hear of teams where the developers want to leave because they're continuously solving operational problems instead of doing feature development-- those teams should be working on rewriting/reworking their systems in a way that they operate trouble free, which is new development.

The goodness of code is determined by how well it serves its purposes-- both in the past as well as into the future.

Some of these these ideas and much more are well-covered in books such as "Clean Architecture" by Robert Martin.