Values help clarify cultural norms on teams. In the face of challenges, these values can help bring positivity, inspiration or motivation. Here are some values that resonate with me.
- Desire to learn
- Embrace challenges
- Persist in the face of setbacks
- See effort as a path to mastery
- Learn from criticism
- Find lessons and inspiration in success of others
Continual Learning and Practice
The best way to learn programming is to practice programming. Programming as a career requires continual learning and investment into oneself.
Learning and investment may include breadth and depth. Learning new technologies and specialization into preferred, in-demand, or as-needed on the job technologies.
My favorite techniques are to try and create a sample project for a real need I have. Or if I’m learning a particular programming language, use a well-understood domain so that I can focus on the language details.
- Make a Hello World or some samples
- Create sample projects and demos
- Practice coding exercises:
I appreciate learning
I do this in a variety of ways such as creating sample projects, or practicing coding exercises on sites like HackerRank: andyatkinson.
Before making a production to code or infrastructure, it is best to rehearse the steps (aka Fail Fast). For example when making production database changes we use techniques like:
- Create a detached database with the same data and hardware
- Use a benchmarking tool like pg_bench to gather some runtime statistics and system load knowledge
- Collect before and after timing information from experimental parameter changes or index changes
- Write steps out as a script and ask for a peer review
- Estimate load and desired outcome
- Write up rollback steps or recovery plans, trying to consider failure scenarios
Prefer code readability to code terseness
- Avoid clever tricks in production code. Or add some specs/tests to the code or at least some helpful comments describing why.
- Code is read at code review time. Please consider your code reviewer trying to grok what is happening and provide helpful feedback.
- In high-pressure time-crunched situations, code is read for debugging reasons and needs to be understood quickly.
- Code is read when code needs to change
- Code is read when writing unit tests to understand what it is doing, to test positive and negative scenarios demonstrating happy path functionality and error case handling
- Conduct your own Pull Request review before asking others to review.
- Remove unrelated changes.
- Replace magic numbers with descriptively named constants in the same file
- Use enumerated types where possible
- Use validations and constraints where possible to clarify what constitutes an error
- Don’t optimize code performance until there is concrete evidence of problems.