This is my place for storing all the videos, lessons, books and everything in between that contributes to the knowledge of software development and related skills.
Each new entry should be given a checkbox and after its completion I should write a few key takeaways for a later reference.
- Practical Redux - Mark Erikson
- Profiling React Performance
- programmatic profiling of React apps with React Profiler API
- How Next.js and Gatsby work and their differences
- Behind the scenes of We Cargo
- WebGL and DOM can be combined by an abstraction layer
- WebGL can sometimes be implemented as progressive enhancement, rendered underneath the dom elements
- Why We're Bad at Estimating Time
- we often underestimate how long will a task take and there is phsychological reasoning behind that (optimism bias)
- overcoming the planning fallacy:
- Use Historical Data (time tracking)
- Have Someone Else Estimate for You (we estimate more realistically for others)
- Estimate in Ranges, or Build in Time for Delays (cone of uncertanty)
- Use Three-Point Estimations
- Calculate Your Fudge Ratio (the percentage by which you always underestimate)
- Estimate During the Low Point of Your Day (pessimistic approach, usually after lunch)
- https://3perf.com/blog/notion/ - analysing Notion app's speed
- key takeaways for improving app loading performance:
- code splitting (lower parsing and execution time)
- polyfilling only for browsers that need it
- removing unneccessary dependencies
- key takeaways for improving app loading performance:
- https://medium.com/swlh/publish-your-cypress-test-report-with-github-actions-47248788713a
- UI testing best practices
- https://dev.to/noriste/front-end-productivity-boost-cypress-as-your-main-development-browser-5cdk
- GOTO 2016 • Software, Faster • Dan North
- less code is often better than more code (seems super obvious)
- patterns of software team behaviour:
- spike and stabilize
- half of codebase should be short
- technique of deliberately deciding if the code is young or old
- spike
— experiment until you have the goal done
- have time constraint
- do not deliberately decide if the code is quality upfront
- learning is the main goal
- stabilize
- going back to the "experiment" and cleaning up
- writing tests, refactoring
- criteria for stabilization:
- going back to it second time
- going back to it in 6 weeks
- we end up with code that's new and spikey or old and stable
- hair trigger
- if a team can not deploy its own code, it can never go fast
- responsibility and carefullness
- move fast and be careful, deploy and learn (but have rollback ideally, a safety net)
- shallow silos
- in agile methodology anyone should be able to work on everything
- having constraints in team makes the team effective, not everyone needs to do everything, but a team should collaborate and get together to sync
- ginger cake
- pattern for getting started quickly with something
- by having great knowledge on a part of the code, copying is fine because you already know about the ins and outs
- burning ships
- learning pattern
- experimental strategy of commiting to a goal and forcing yourself to only solve problems and goals without additional learning
- knowning "just enough" for getting stuff done
- constraints:
- deadline
- running out of other options
- information
- example: building a todo app in C#, but not knowing the language
- not watching tutorials or reading books
- learning by doing and experimenting
- learning only enough for the next goal
- spike and stabilize
- Product Management Mental Models for Everyone
- Mental models are simple expressions of complex processes or relationships. These models are accumulated over time by an individual and used to make faster and better decisions.
- there are many mental models in the product development (e.g. pareto principle), but sticking only to one will probably give you incorrect image about the world or scenario
- feature/product certanty should define how many resources should you invest into building something new
- e.g. for an experimental product it's better to start small and fast and learn from the customer
- https://untools.co/
- Collection of thinking tools and frameworks to help you solve problems, make decisions and understand systems.
-
https://medium.com/tribalscale/writing-technical-user-stories-434bf96f1dd5
- Good user story:
- Independent (can be built separately to other stories)
- Negotiable (requirements can be adapted)
- Valuable (provides benefit to the end-user)
- Estimable (to reasonable accuracy)
- Small (can be built within one iteration)
- Testable (can be verified by QA)
- Good user story:
- https://medium.com/coleadership/what-does-it-take-to-be-a-successful-tech-lead-d133ee18677
- A good tech lead excels in delivery and execution
- A good tech lead builds a thriving team
- A good tech lead builds alignment
- A good tech lead balances priorities
- A good tech lead is clear about what they want