How to learn something new in a technical space

how-to-learn-something-in-a-technical-space.md

As a learning plan, for a time-bound target (weekly, monthly even yearly) following guidelines must be followed:

Start with Why

• Explain "Why you are going to build" (whatever it is that you are going to build)

Now, "What"

• A table of contents (granulated to a common sense level) of what are you going to do/learn/build
• Expectations in terms of scale (keep it small) and timeline (keep it short) of the Demo/POC that you would be building. Couple of examples:
  • Slack OAuth2 login(small scale) in 2 days(short timeline)
  • Using DynamoDB or Firebase-DB for data logging and retrieval for a few tables(small scale) in 2 weeks(short timeline)

Code and documentation

• Code to be at a Public repo. Private only if extremely sensitive info is included in the code (why would sensitive info be in code?)
• A well written README file (understandable by everyone, not just by you) including setup instructions(include screenshots if required), development guide, tech-stack used, demo URL, coding standards used and contribution guidelines (these are bare minimum, and mandatory)
• Everything that is documented should be simple enough to read and understand by non-tech people

TDD

• TDD (absolutely no exceptions)
• If code coverage is below 100%, mention valid reason(and "lack of knowledge" or "too much time consuming" are not valid reasons)

Other guidelines

• All F+L coding and other guidelines apply as "minimum standards" (again, valid reasons apply for exceptions)
• Build statuses, downtime statuses, application errors, performance issues etc. must (not should, but must) go to appropriate Slack channel (use your own/personal Slack setup if nothing else is available - it is free)

Result

• The product/app(or whatever would be built) must do whatever it is supposed to do - ideally with no bugs

Review

• Assess/review if the "result" is in sync with the "why" in the beginning