ramblings.js

// About me:
// - Benji - Kid (Daniel), Dog (bimper), Wife (orit)
// - Excel Online client architecture @ Microsoft
// - Node.js project member - 7 years
// - A bunch of other open source stuff.
// - Magshimim since ±2014.
//   - Taught startech (Nitzani Magshimim)
//   - עקרונות מתקדמיים.
//   - קורס פרוייקט for two years.
//   - פיתוח תוכן / מנטור
//   - Gave a talk about it ±5 years ago 
//    - https://www.reversim.com/2018/12/summit-2018-open-source-development.html
// - A bunch of other fun volunteering stuff (like TechCareer) 
// WinterCG, Streams, Fetch, etc
// Before Microsoft - Testim.io, Peer5, TipRanks



// Cycles are optimally really quick (1-2 weeks).
// - As a way to reduce risk (product market fit, technical etc)

// Roles in a team:
// - Product manager.
//  - Usually domain expertise and business expertise.
//  - Decides the non-technical stuff to do.
//  - Tools: analytics tools (mixpanel, google analytics)
//   - Product specification (user stories)
//  - Decides on UX with the UX team
// - UX team:
//  - Products with UI - there is usually designers/UI/UX.
//  -  Works closely with product.
//  - In good companies there is a design system.
//   - A core set of components and interactions everything follows.
// - QA (sometimes in same team, sometimes elsewhere)
//  - In many companies - there is no QA team.
//  - There is (mostly) no QA in Microsoft.
//  - In not great places: QA does manual testing.
//  - In better places usually, QA is a domain expert that writes test plans and does "product".
// SRE/DevOps - in charge of monitoring and alerts / deployments.
// Project manager (?) -

// None of these jobs are less or more important or hard than development

// Technically:
// - Given proper specification:
//  - break things down to smaller tasks.
//  - estimate how long each task will take. (these are usually wrong)
//  - assign tasks to developers.
//   - Good team leads do a lot of team building and self efficacy building.
// - If tasks are big - (technical) design review.
//  - In a good process: driven by developers.
// - Actual development
//  - A programming language and environment. (Node.js/JavaScript)
//   - Usually all the accompanying frameworks (React, Fastify)
//   - The choice is driven by 100s of factors.
//  - Source control (git, at Microsoft we also have other stuff)
// - Issue tracking (JIRA, Azure DevOps, Trello, GitHub issues, ClickApp)
// - CI - build servers. (Azure DevOps, Jenkins, GitHub actions)
//   - Takes your code on every commit and runs tests.
//    - Ensures your build is almost never broken.
//   - Runs different kinds of tests. The more the better as long as it's fast.
//    - Ideally code builds in under 5 minutes in CI and CI takes under 10 minutes. In practice often much much more.
//   - In large code bases only what's changed is built and the rest is cahced.
// 
// Code Reviews:
//  - Code enters when it improves the codebase not when it is perfect.
//  - Remember that it's a human activity that also builds competence and ownership in the code. Don't attack (it's a human thing).
//   - Err on the side of caution and mind the American.
//    - In American "Please Consider" - "Do it".
//    - Also relevant in other cultures (e.g. Indian culture).
//    - Our culture is very rude and direct (which is often good).
//    - Good faith is a lot more noticeable when proactive.
// Release cycle
// - In a lot of products: CD (continuous delivery)
// - In others not - but still ideally from CI.
// - Usually promotion between environments.
//   - Often: staging, production.
//   - In Microsoft: dogfood, mis, production.
//    - Often automatic rollout based on metric.
// - Monitoring (alerts metrics etc).
//  - A/B tests.
//  - Analytics, user interviews etc.


// There are several human approaches:
// - The Clean Coder (Bob Martin, _NOT_ clean code).
// - Peopleware (Tom DeMarco)
// - Crucial Conversations (about negotiation but also relevant)

// Mention these are just all tools and we can choose to use them or not.


// Culture - in a good culture people can make mistakes and be vulnerable.


if (someCondition) {
    return true;
} else {
    return false;
}

// Nit: please refactor to return someCondition
return someCondition;