How To Give Pushback To Leadership
- Sean Goedecke tl;dr: “Pushing back against leadership has high stakes. Doing it well can actually build your leadership team’s trust in you, even though you’re telling them something they don’t want to hear. Doing it very badly can have serious repercussions for the success of the project or your own career.”featured in #582
How To Set Boundaries And Stop People Pleasing At Work
tl;dr: “People-pleasing tendencies manifest in many different ways, such as saying “yes” when you really want to say “no,” or by putting other people’s happiness above your needs. While this tendency is often rooted in good intentions, people pleasing can often be a hindrance to our growth.”featured in #581
How / Why To Get Good At Debugging Your Mind
tl;dr: “I’ve focused very heavily on overcoming flaws in my mind for the past ~11 years. Initially it was because I had to overcome huge problems that significantly reduced my quality of life. But years after I overcame them, I still continue to ‘debug’ my own mind because I like the growth and quality of life I get out of it. And also because it’s just interesting.”featured in #581
What Makes Strong Engineers Strong?
- Sean Goedecke tl;dr: “What defines a strong engineer is the ability to do tasks that weaker engineers can’t, even with near-unlimited time. But what are the concrete skills or traits that make up that ability? What is it about strong engineers that makes them able to do a much wider range of tasks? In order of importance, I think it’s self-belief, pragmatism, speed, and technical ability.” Sean elaborates on these qualities.featured in #581
What Makes Strong Engineers Strong?
- Sean Goedecke tl;dr: “What defines a strong engineer is the ability to do tasks that weaker engineers can’t, even with near-unlimited time. But what are the concrete skills or traits that make up that ability? What is it about strong engineers that makes them able to do a much wider range of tasks? In order of importance, I think it’s self-belief, pragmatism, speed, and technical ability.” Sean elaborates on these qualities.featured in #580
Mistakes Engineers Make In Large Established Codebases
- Sean Goedecke tl;dr: “There’s one mistake I see more often than anything else, and it’s absolutely deadly: ignoring the rest of the codebase and just implementing your feature in the most sensible way. In other words, limiting your touch points with the existing codebase in order to keep your nice clean code uncontaminated by legacy junk. For engineers that have mainly worked on small codebases, this is very hard to resist. But you must resist it! In fact, you must sink as deeply into the legacy codebase as possible, in order to maintain consistency.”featured in #578
Preferring Throwaway Code Over Design Docs
- Doug Turnbull tl;dr: Instead of relying on detailed design docs before coding, the author advocates for "coding binges" - creating messy prototype code in draft PRs to explore solutions, getting early feedback, and then gradually refactoring into clean, production-ready PRs. Design docs still have their place, but hands-on coding often reveals problems and solutions that design docs can't predict.featured in #576
featured in #576
featured in #575
How To Grow Professional Relationships
- Tejas Kumar tl;dr: “This spectrum is how I measure professional relationships and where I stand in those relationships. It outlines seven states moving from a competitive, zero-sum mindset to one of shared identity (which is equally problematic). Tejas shares each state.featured in #575