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.

Growth Mindset

Fixed vs. Growth: The Two Basic Mindsets That Shape Our Lives

• 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
  • Java, Kotlin, Crystal, Micronaut Framework, Docker, GraphQL, Elixir and Phoenix
• Create sample projects and demos
  • URL shortener in Go
  • Rails Best Practices Sample App
  • React and Redux frontend
  • Go backend
  • My karaoke list
• Practice coding exercises:
  • Exercises in C
  • Recursion examples in Ruby
  • Hackerrank: andyatkinson

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.

Rehearsal

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.