this repo has no description
4
fork

Configure Feed

Select the types of activity you want to include in your feed.

📚 add ShoutBox metaphor to social media issues and fix typos in Teamwork

docs(Social Media Issues): add ShoutBox metaphor explaining how social media functions as noise-cancelling megaphones
docs(Teamwork): fix typos and improve phrasing in various sections

+8 -7
+1
Social Media Issues.md
··· 29 29 - Social Media companies have incentives to build echo chambers as that's one of the best ways to create engagement and keep users active. 30 30 - [As a creator, Social Media companies use their filtering power to make money forcing people to pay to show the content to users](https://youtu.be/l9ZqXlHl65g). 31 31 - E.g. Instagram controls what shows and in which order it does to maximize time spent in app and make money. 32 + - [The "ShoutBox" metaphor](https://medium.com/@pwang/reframing-the-social-media-problem-as-an-attention-crisis-52253dbfe627): Social media apps function like noise-cancelling megaphones in a warehouse full of competing sounds - they amplify individual output by default, creating a broadcast environment that forces filtering rather than thoughtful communication. 32 33 33 34 ## Social Network Improvements 34 35
+7 -7
Teamwork.md
··· 37 37 - Having skin in the game improves the decision making process. 38 38 - [Have direct responsible individuals for everything. Everyone's problem is no one's problem](https://nintil.com/programming). Having a name accountable instead of a vague "the team" or "the process" makes it easy to make changes. 39 39 - Write postmortems after large changes. This will create [[Feedback Loops]] to guide learning about what happened and how it can be avoided next time. It'll also help calibrate for the previous decisions. 40 - - Do [lightweight self reviews](https://andrewhuth.substack.com/p/writing-good-performance-self-reviews) . Worst case scenario, they help you update your resume. 40 + - Do [lightweight self reviews](https://andrewhuth.substack.com/p/writing-good-performance-self-reviews). Worst case scenario, they help you update your resume. 41 41 - Make time to pay technical debt. [[Systems]] evolve organically over time and might get stuck on a local maximum. Alternative abstractions/designs might be better to continue progressing! There are two kinds of tech debt: 42 42 - Things you haven't built yet. 43 43 - Things you shouldn't have built that way. ··· 47 47 2. Make a list of everything that feels off, no matter how big or small. 48 48 3. Wait a bit, like a month, but address everything. 49 49 - This translates to ideas to review, tools to try, docs you want to write up, ... 50 - - Culture should incentive people to fix things outside their area. Encourage submitting Pull Requests that might be rejected. 51 - - Teams [need slack to absorb and adapt when unexpected things come up](https://www.neelnanda.io/blog/38-slack) and to prioritize the development of force multipliers (tooling and automation). 50 + - Culture should incentivize people to fix things outside their area. Encourage submitting Pull Requests that might be rejected. 51 + - Teams [need slack to absorb and adapt when unexpected things come up](https://www.neelnanda.io/blog/38-slack) and to prioritize the development of force multipliers (tooling and automation). 52 52 - Lack of [[slack]] compounds. It gets harder and harder to get out as more things get added to backlogs and more patches get added on the systems you build (slowing you down in the end). 53 53 - A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done. 54 54 - [Balance putting code where they are most comfortable while optimizing for speed vs putting the code where it belongs when considering a longer term perspective on the overall system.](https://twitter.com/jmwind/status/1477399261700526080). ··· 61 61 - Spend time at work thinking strategically. E.g: Think about the approach you will take to address the company's needs over the medium to long term. 62 62 - **How to drive change in a team**: find people who agree on the problem, start small, experiment, scale, repeat. Making big change is hard. Keeping things simple is hard. 63 63 - On the other hand, beware of changing too many things. You don't feel the pain of things you're not doing! 64 - - Scale organizational efforts across a portfolio of synergistic products. 64 + - Scale organizational efforts across a portfolio of synergistic products. 65 65 - Don't replace prototypes with roadmaps. Encourage prototyping to learn and build confidence with different parts of your software stack. 66 66 - Ask people ["when do you think you'll get this done"](https://mobile.twitter.com/Carnage4Life/status/1438982223395393536), write it down and then follow up at that time. That makes teams more effective. 67 67 - Every document must have a specific goal written at the top of it. ··· 114 114 - Most software or processes should be opinionated. In increases [[Coordination|collaboration]]. Flexible processes lets everyone invent their own workflows, which eventually creates chaos as teams scale. 115 115 - As teams scale, traditional approaches to decision making force a tradeoff between transparency and efficiency. 116 116 - The easiest way to ensure everyone can understand the how and why of a decision is to adopt systems that, through their daily operation, ensure such context is automatically and readily available to those who might want it (and explicitly not only those who presently need it). 117 - - [Run 1:1s (one-on-ones)](https://erik.wiffin.com/posts/how-to-get-the-most-out-of-your-11s/). A recurring meeting with no set agenda between a manager and one of their reports. Don't make it a status update (these should be async). Chat about anything bothering you, career growth or type work that is interesting for you. End it with actionable next steps. 117 + - [Run 1:1s (one-on-ones)](https://erik.wiffin.com/posts/how-to-get-the-most-out-of-your-11s/). A recurring meeting with no set agenda between a manager and one of their reports. Don't make it a status update (these should be async). Chat about anything bothering you, career growth or type of work that is interesting for you. End it with actionable next steps. 118 118 - Say no a lot, up front. [Distractions are anything that doesn't help you keep your existing features running, or deliver your top priority faster](https://alexturek.com/2022-03-07-How-to-do-less/). Finishing work is more important than starting it. 119 119 - As a new team member: 120 120 - Ask questions without judging. Never ever be _negative_ about the stuff they created. It was done for a reason. 121 121 - Beware of [Normalization of Deviance](https://danluu.com/wat/). 122 122 - When meeting/emailing interesting people ask if they know anyone else you can meet with. [Try to expand your network with successful folks in the area/space!](https://twitter.com/AdamRy_n/status/1297920306900865024) 123 - - Keep a [private work log](https://youtu.be/HiF83i1OLOM?list=PLYXaKIsOZBsu3h2SSKEovRn7rGy7wkUAV). It'll make easier for everyone to advocate what you did. 123 + - Keep a [private work log](https://youtu.be/HiF83i1OLOM?list=PLYXaKIsOZBsu3h2SSKEovRn7rGy7wkUAV). It'll make it easier for everyone to advocate what you did. 124 124 - [Don't sabotage the team](https://erikbern.com/2023/12/13/simple-sabotage-for-software)! 125 125 - [Nobody gets credit for fixing problems that never happened](https://news.ycombinator.com/item?id=39472693). People get credit for shipping things. Figure out how to reward and recognize people for preventing problems. 126 126 - The same practices that make great [[Artificial Intelligence Models]] [promts](https://platform.openai.com/docs/guides/prompt-engineering) also make [great practices with humans](https://x.com/tayloramurphy/status/1849269205155123568): ··· 150 150 - There's a real danger in thinking that what made you successful in the past will make you successful now. 151 151 - Read all the things. 152 152 - The team you'll be working on will probably have some kind of [normalized deviance](https://danluu.com/wat/). Try to [understand why everything is as it is](https://fs.blog/chestertons-fence/) before doing any recommendations. Don't come in with "the answers". 153 - - [Chesterton's fence](https://www.meyerperin.com/posts/2022-04-02-chestertons-fence.html) is an important concept to keep in mind when starting a new job or a new scope of work. The [context of why a certain architectural choice was made](https://vickiboykis.com/2021/11/07/the-programmers-brain-in-the-lands-of-exploration-and-production/) is just as important as understanding its current pain points. 153 + - [Chesterton's fence](https://www.meyerperin.com/posts/2022-04-02-chestertons-fence.html) is an important concept to keep in mind when starting a new job or a new scope of work. The [context of why a certain architectural choice was made](https://vickiboykis.com/2021/11/07/the-programmers-brain-in-the-lands-of-exploration-and-production/) is just as important as understanding its current pain points. 154 154 - Record first impressions / friction log as you go. [Beginner's mind has real value](https://eugeneyan.com/writing/onboarding/)! 155 155 - Build great relationships so you can be supported in decisions to get some early wins. 156 156 - One of the most valuable things you can do during onboarding is update/write documentation and [create/update checklist of all the processes](https://lifeitself.org/tao/onboarding#create-an-onboarding-issue). This will help you and your team in the long run.