/Career Advice

Lessons From Debugging

- Matt Rickard tl;dr: (1) Reproduce with the smallest example. In the simplest environment. (2) Read and re-read the error statement. Read the stack trace. Add more logging if you don’t know where the error is thrown. (3) Change one thing at a time. (4) Divide and conquer. Sometimes that means binary search on good/bad commits. Other times isolating the problem. (5) Be open to debugging in different environments. (6) State your assumptions. (7) Get a second set of eyes on it. (8) If you're debugging some stateful code, think about \_how\_ you ended up at that state. A recipe that (reproducibly) gets you to that state is often the path to fixing it. (9) Look at the logs, all the logs. (10) When in doubt, start with the most recent changes, especially dependencies changes.

featured in #453

How To Opt Out Of The Career Ladder

- Jean Hsu tl;dr: Jean explores the career ladder, particularly its alignment with definitions of success. “Working full-time? Strive to level up through promotions and checking off the leveling system’s boxes. Working as an IC? Climb the IC levels and then try to move into a leadership position.” Many individuals, especially those further in their careers, find the traditional ladder less appealing. Jean encourages readers to introspect on their values, understand the role they want work to play in their lives, and notice what genuinely sparks their interest. She shares personal experiences and emphasizes that the conventional career ladder doesn't have to dictate one's path.

featured in #452

5 Rules That Will Drive A Long, Healthy Career

- Nikhyl Singhal tl;dr: From the VP of Product at Facebook, each of the following is discussed in detail : (1) Product manage your career like it’s a product. (2) Ensure each transition is career additive. (3) Whom you know will matter as much as what you know. (4) Find a strength area and try to build a superpower in it. (5) Bet on yourself.

featured in #452

Don’t Cross The Beams

- Kent Beck tl;dr: Kent discusses the nuances of code refactoring, emphasizing the difference between "horizontal" and "vertical" refactorings. "Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around – eliminating risk quickly and exploiting proven opportunities efficiently." Kent also introduces the concept of "Succession," which deals with breaking down the refactoring process into manageable, efficient steps.

featured in #450

Asking Questions The Right Way

- Vadim Kravcenko tl;dr: Vadim differentiates between technical questions that address code and processes, with project management questions that deal with team dynamics. Key advice includes: (1) Conducting thorough research before posing a question to ensure you're not asking something readily available. (2) Ensuring clarity and precision in question formulation to get meaningful answers. (3) Avoiding the XY problem, where a perceived solution might overshadow the actual issue at hand. (4) Utilizing the "rubber duck method" as a tool for clarity, where explaining a problem aloud to an inanimate object can help in understanding and structuring thoughts. (5) Recognizing the importance of the medium and tone when asking questions, choosing the right platform and approach based on the nature of the query. And more.

featured in #449

7 Simple Habits Of The Top 1% Of Engineers

- Leonardo Creed tl;dr: 1) Use consistent standards - adhering to a uniform coding style for readability and scalability. 2) Write aesthetic, simple code - producing clean, organized, and logical code that's easy to understand. 3) Don't allow surprises - ensuring code predictability through adherence to principles and thorough testing. 4) Communicate often - actively seeking feedback and collaborating for better end results. 5) Detach from the code itself - viewing code objectively, open to revisions for the best outcome. 6) Code fast... and slow - taking a deliberate approach to coding, ensuring quality over speed. 7) Code for the human, not the computer - writing code that's comprehensible to humans, emphasizing its value to both developers and users.

featured in #448

Growth In A Downturn

- James Stanier tl;dr: James delves into the frustrations many face due to limited career progression opportunities during economic downturns. "The most important thing to embrace is that there are things you can control, and things you can't." James shares what these are and suggests reshaping the narrative around promotions and focusing on personal impact. By creating a workback plan - which outlines the impact you want to have in the future and the steps that you need to take to get there - one can strategically prepare for future promotions, even in challenging times.

featured in #447

The Journey To Staff Engineer: Main Takeaways

tl;dr: These takeaways are a roadmap for engineers aspiring to reach higher levels in their careers, based off of a conversation with several staff engineers at larger tech companies: (1) Make your work visible: It's essential not just to do the work but to ensure that others are aware of it. (2) Build relationships within and outside of your team. (3) Learn to lead: Staff engineers often influence without having the direct power of a manager. (4) Work on high-impact and complex technical projects, ideally, with others. (5) Promotion timelines vary and not everyone gets promoted quickly.

featured in #447

Good Performance Is Not Just Big O

- Julio Merino tl;dr: Julio argues that a fast and responsive application is not solely about understanding big O complexities. While tech companies often emphasize algorithms in interviews, real-world code often suffers from performance issues unrelated to big O. Julio lists various factors impacting performance, including storage, networking, data handling, CPU and memory usage, concurrency, graphics, and development time. For instance, an O(n) algorithm might be slower than an O(n^2) one in specific scenarios.

featured in #447

Possibilities If You Don't Ask For What You Want Vs. If You Do

- Addy Osmani tl;dr: Addy argues that by hesitating to ask for what one wants, you not only miss out on immediate opportunities but also deprive your future self and others of potential benefits. If you don’t ask for what you want, you: (1) Sell yourself short. By not expressing desires, one misses out on feedback and potential connections. (2) Limiting your own learning. Not all requests will be met with a 'yes', but each 'no' is a lesson that refines one's approach and understanding. (3) The Ripple Effect. Expressing desires provides clarity to others and can lead to unforeseen payoffs in the future. (4) Breaking free from hesitation. Defining one's goals, practicing articulation, and maintaining a positive yet realistic mindset, one can more confidently ask for what they want. 

featured in #446