How to compare different approaches
- Always think about different approaches (even if you already finished/committed code)
- Don't just choose one that looks good
- List them and compare them
- Always ask you why choose this approache
- Try hard to find problems in your current approach, and how to fix them
For small coding
- Implement them if possible
- Then compare which makes code cleaner, less change etc
Example: Exclude source and javadoc from -jar
APP_BIN=$APP_BIN_DIR/$(ls $APP_BIN_DIR | grep -E 'jarName-version.*jar' | grep -v sources | grep -v javadoc | grep -v pom)
How to quickly scan/learn new classes
Sometimes we need quickly scan/check a bunch of related classes to check how to implement a function, use a method etc
- Check the class's Javadoc
- Check the class signature
- Check main methods:
- static methods
- using ctrol+o or outline view
- Check call hierarchy in source code
- Check test code/examples
- Google search code example
When refactor/change the code, also check/change/improve its related code.
Find related doc, check/read the doc carefully.
- Mark/Note the important part of the doc.
For some task, we can use the trial and error approach, just do it, then fix it.
But for some task(production or physical hardware related), it's better to figure out the right way to do it first.
Evaluate the outcome of the action.
- best/worst outcome
How to implement/work on a feature
- what's goal, what to achieve
- how to test/verify/deploy/enable it in test or production environment easily
- useful tricks: dry-run,
- able to enable/disable default configuration automatically, but override it manually
- how to measure whether the change makes improvement
Think different/3+/more approaches
Compare them
Don't stop until find a solution that looks good to you
Use tools(notebook, whiteboard)
- Usually we are not happy with the first approach that comes to our minds, and find out a different approach: maybe it's a little better or maybe just be different. In some cases, we stop there: maybe we started to talk it with others or present it (to get others' ideas)
-Example: add Explanation to transform actions
Before ask a question
- Try to Solve it by yourself
- Make sure you read all related code/doc: from top to bottom(quickly, scan but don't ignore any code that may be important)
- Example: NightlyTestRunner
Verify the assumption
- Be aware of the the assumption we or others made in the design or the code.
- Verify whether it's true or not
- Example: one line one record in csv, one-to-one between tms id and bam_id
Alternatives
- Check and realize alternatives
Sometimes, we want A, but maybe B also works and is even better.
- Example: asset letter or account statement
Use tools
Write down in whiteboard or notebook or app
Take a picture now
- always bring the phone
Check carefully and verify your claim before blame others or think others are wrong
We incline to think others are wrong or made a mistake even if someone told you he/she did that - we made a very brief search and didn't check carefully, then started to think they are wrong.
Prefer to use code to enforce the rule than documentation
Example: all tests must extends XbaseUnitTest.
Make API/feature easier
- to use
- to test/rollback in production (feature flag)
Realize your assumption/decision and verify it first
- Otherwise you may go farther but on the wrong path
Step by step and verify each step
Identify useful info and active quickly (or you may forget about it)
Don't let your past experience affect you
- Try it, it may be different this time
Example: big item delivery
When some thing totally doesn't make sense:
- maybe they are totally different things, you are comparing Apple with Banaba
Example: 12/15, 1/15
Related
Lessons Learned about Programming and Soft Skills - 2016
- Always think about different approaches (even if you already finished/committed code)
- Don't just choose one that looks good
- List them and compare them
- Always ask you why choose this approache
- Try hard to find problems in your current approach, and how to fix them
For small coding
- Implement them if possible
- Then compare which makes code cleaner, less change etc
Example: Exclude source and javadoc from -jar
APP_BIN=$APP_BIN_DIR/$(ls $APP_BIN_DIR | grep -E 'jarName-version.*jar' | grep -v sources | grep -v javadoc | grep -v pom)
How to quickly scan/learn new classes
Sometimes we need quickly scan/check a bunch of related classes to check how to implement a function, use a method etc
- Check the class's Javadoc
- Check the class signature
- Check main methods:
- static methods
- using ctrol+o or outline view
- Check call hierarchy in source code
- Check test code/examples
- Google search code example
When refactor/change the code, also check/change/improve its related code.
Find related doc, check/read the doc carefully.
- Mark/Note the important part of the doc.
For some task, we can use the trial and error approach, just do it, then fix it.
But for some task(production or physical hardware related), it's better to figure out the right way to do it first.
Evaluate the outcome of the action.
- best/worst outcome
How to implement/work on a feature
- what's goal, what to achieve
- how to test/verify/deploy/enable it in test or production environment easily
- useful tricks: dry-run,
- able to enable/disable default configuration automatically, but override it manually
- how to measure whether the change makes improvement
Think different/3+/more approaches
Compare them
Don't stop until find a solution that looks good to you
Use tools(notebook, whiteboard)
- Usually we are not happy with the first approach that comes to our minds, and find out a different approach: maybe it's a little better or maybe just be different. In some cases, we stop there: maybe we started to talk it with others or present it (to get others' ideas)
-Example: add Explanation to transform actions
Before ask a question
- Try to Solve it by yourself
- Make sure you read all related code/doc: from top to bottom(quickly, scan but don't ignore any code that may be important)
- Example: NightlyTestRunner
Verify the assumption
- Be aware of the the assumption we or others made in the design or the code.
- Verify whether it's true or not
- Example: one line one record in csv, one-to-one between tms id and bam_id
Alternatives
- Check and realize alternatives
Sometimes, we want A, but maybe B also works and is even better.
- Example: asset letter or account statement
Use tools
Write down in whiteboard or notebook or app
Take a picture now
- always bring the phone
Check carefully and verify your claim before blame others or think others are wrong
We incline to think others are wrong or made a mistake even if someone told you he/she did that - we made a very brief search and didn't check carefully, then started to think they are wrong.
Prefer to use code to enforce the rule than documentation
Example: all tests must extends XbaseUnitTest.
Make API/feature easier
- to use
- to test/rollback in production (feature flag)
Realize your assumption/decision and verify it first
- Otherwise you may go farther but on the wrong path
Step by step and verify each step
Identify useful info and active quickly (or you may forget about it)
Don't let your past experience affect you
- Try it, it may be different this time
Example: big item delivery
When some thing totally doesn't make sense:
- maybe they are totally different things, you are comparing Apple with Banaba
Example: 12/15, 1/15
Related
Lessons Learned about Programming and Soft Skills - 2016
