4 ms·

Your coworkers are your best resource. - Ask them to review your code and suggest changes - Look for questions of taste and ask more. It may feel intuitive to

by cnees 8y ago

Your coworkers are your best resource. - Ask them to review your code and suggest changes - Look for questions of taste and ask more. It may feel intuitive to them, but if you dig in you can often find a good reason/principle behind it. - Read your coworkers' code - Read the comments people leave on others' code

cnees 8y ago
Here are some principles that inform my taste in maintainable code: - Each function should do just one thing. - Don't reuse a variable if making a new variable with a new name would describe the value better. - Give functions verb names that describe what they do. If that's hard, they may be doing too many things. - A function should either change something or return a value (command-query separation) - Any data should have a single, canonical source of truth. https://en.wikipedia.org/wiki/Single_source_of_truth https://en.wikipedia.org/wiki/Single_source_of_truth - When deciding between making code DRY https://en.wikipedia.org/wiki/Don%27t_repeat_yourself https://en.wikipedia.org/wiki/Don%27t_repeat_yourself or not, decide if future changes should affect both places at the same time (use DRY) or not (probably doesn't need DRY, maybe shouldn't have it.) - Avoid spooky action at a distance https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming) https://en.wikipedia.org/wiki/Action_at_a_distance_(computer... and if you can't, refactor or at least add comments. - Write modular functions that can be used without understanding much about the function beside what the name/arguments tell you. One measure of your success in this area is how quickly someone who'd never seen your code could describe what it does.
mitchellst 8y ago
This is the best answer here. You've come to the conclusion that you're good at coding alone, but you don't know how to do it well in a team or company— your team and company. Other answers frame this as a technology problem (patterns and practices) but you'll hack it faster as an acculturation task. Get mentors. Plural. Grab one person in each department where you feel shaky— QA's, solutions architects, operations, maybe product, etc. Tell them you're new at this and you want to ask them questions and work closely with them to get better. (This will not offend them and it will not make them look down on you. If it does, you don't want what they're selling anyway.) Two months into asking them for code reviews and just taking them to lunch and asking about things you know they care about in their areas of responsibility, you'll notice results in terms of your own thinking and output. 1 year in, you'll be very, very good at this.
- mertd 8y ago
  I was in the same boat as the op. Dove in head first into a software engineering role. Ended up working with the only true 10x'er I have known to this day. Nothing improves you faster than getting feedback from someone like that.

by cnees 8y ago

cnees 8y ago

Here are some principles that inform my taste in maintainable code: - Each function should do just one thing. - Don't reuse a variable if making a new variable with a new name would describe the value better. - Give functions verb names that describe what they do. If that's hard, they may be doing too many things. - A function should either change something or return a value (command-query separation) - Any data should have a single, canonical source of truth. https://en.wikipedia.org/wiki/Single_source_of_truth https://en.wikipedia.org/wiki/Single_source_of_truth - When deciding between making code DRY https://en.wikipedia.org/wiki/Don%27t_repeat_yourself https://en.wikipedia.org/wiki/Don%27t_repeat_yourself or not, decide if future changes should affect both places at the same time (use DRY) or not (probably doesn't need DRY, maybe shouldn't have it.) - Avoid spooky action at a distance https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming) https://en.wikipedia.org/wiki/Action_at_a_distance_(computer... and if you can't, refactor or at least add comments. - Write modular functions that can be used without understanding much about the function beside what the name/arguments tell you. One measure of your success in this area is how quickly someone who'd never seen your code could describe what it does.

mitchellst 8y ago

This is the best answer here. You've come to the conclusion that you're good at coding alone, but you don't know how to do it well in a team or company— your team and company. Other answers frame this as a technology problem (patterns and practices) but you'll hack it faster as an acculturation task. Get mentors. Plural. Grab one person in each department where you feel shaky— QA's, solutions architects, operations, maybe product, etc. Tell them you're new at this and you want to ask them questions and work closely with them to get better. (This will not offend them and it will not make them look down on you. If it does, you don't want what they're selling anyway.) Two months into asking them for code reviews and just taking them to lunch and asking about things you know they care about in their areas of responsibility, you'll notice results in terms of your own thinking and output. 1 year in, you'll be very, very good at this.

mertd 8y ago
I was in the same boat as the op. Dove in head first into a software engineering role. Ended up working with the only true 10x'er I have known to this day. Nothing improves you faster than getting feedback from someone like that.