Career

The fastest career growth comes by finding work that aligns with both your interests and what matters most to the company.

• Ask "Empty Question", questions that are not loaded and biases.

Resources

• Dropbox Engineering Career Framework
• Interview Questions to Ask Your Interviewer #interviewing
• Finding your leadership style
  • A few helpful questions that one can ask themself to identify their leadership style.
• Managing people 🤯
  • Not sure how I feel about this one. Not very insightful and I disagree with some of the points.
• Help Your Teammates Navigate Moments of Self-doubt
• How To Criticize Coworkers
• My guiding principles after 20 years of programming
• Levels of Technical Leadership
• Tech Dept
• The Code Review Pyramid
• The unreasonable effectiveness of one-on-ones
• How Google, Twitter, and Spotify built a culture of documentation
• Prioritization as a Superpower
• Maximizing Developer Effectiveness
• Operating well – what I learned at Stripe some take-aways from Sam Gerstenzand's time at Stripe.
  • Operating well is a state, not an outcome. It's constant process of tweaking, iterating, and tuning.
  • "Turn up the heat in every interaction and ask uncomfortable questions." - ask uncomfortable questions.
• Engineering Levels at Honeycomb: Avoiding the Scope Trap
• Things they didn’t teach you about Software Engineering
• Project Management for Software Engineers
  • Initiation - Initiating a project means recognizing that a new project exists and clearly setting out the scope, deliverables, and expectations.
  • Planning - After initiation comes planning — clearly defining the work breakdown, roadmap, and project plan. Most project plans involve some form of Gantt chart or roadmap, though I would suggest tailoring this to your company needs if you are working in a more “agile” setting.
  • Execution - During this phase, the project team spends most of its time completing work, coordinating with people, helping to ensure quality work, keeping track of resources, and updating stakeholders.
  • Monitoring and Control - In parallel with execution, the project team tracks the progress of the project based on the original project plan. This includes tracking the schedule, budget, and scope of the project to make sure it is on track.
  • Closure - Closing a project involves the delivering final results, measuring success, and compiling lessons learned for future projects.
• Recognition and rewards at work
• Brag now, remember later: Document your accomplishments
• DevOps culture: Westrum organizational culture
  • Good culture that optimizes information flow is predictive of good outcomes
  • High cooperation - Create cross-functional teams that include representatives from each functional area of the software delivery process (business analysts, developers, quality engineers, ops, security, and so on). This practice lets everyone share the responsibility for building, deploying, and maintaining a product. It's also important that there is good cooperation within the team.
  • Train the messengers - This means we want people to bring us bad news so we can make things better. Hold blameless postmortems. By removing blame, you remove fear; and by removing fear, you enable teams to surface problems and solve them more effectively. Also create and foster an environment where it is safe to take smart risks and fail, so that anyone can surface problems at any time—even without the ceremony of a postmortem.
  • Share risks - Along with this, encourage shared responsibilities. Quality, availability, reliability and security are everyone's job. One way to improve the quality of your services is to ensure that developers share responsibility for maintaining their code in production. The improvement in collaboration that comes from sharing responsibility inherently reduces risk: The more eyes on the software delivery process, the more you'll avoid errors in process or planning. Automation also reduces risk, and with the right tool choice, can enable collaboration.
  • Encourage bridging - Break down silos. In addition to creating cross-functional teams, techniques for breaking down silos include co-locating ops with the dev team; including ops in planning throughout the software delivery lifecycle; and implementing ChatOps. Another tip is to identify someone in the organization whose work you don't understand (or whose work frustrates you, like procurement) and invite them to coffee or lunch. Informal discussions help foster better communication, and you may understand why they do what they do—and you can come up with creative solutions together.
  • Let failure lead to inquiry - Again, hold blameless postmortems. The response to failure shapes the culture of an organization. Blaming individuals for failures creates a negative culture. If instead, failures lead you to ask questions about what caused the failures and how you can keep them from happening again in the future, you've improved your technical system, your processes, and your culture.
  • Implement novelty - Encourage experimentation. Giving employees freedom to explore new ideas can lead to great outcomes. Some companies give engineers time each week for experimentation. Others host internal hack days or mini-conferences to share ideas and collaborate. Many new features and products began this way. When you release your employees from habitual pathways and repetitive tasks, they can generate enormous value for your organization. And remember that novelty isn't limited to new products and features. Also encourage and reward improvements in process and ideas that help foster collaboration.
• Motivating Developers to Care About Documentation
• 10 Tips for Running Engineering Meetings on Zoom
• Make haste slowly: quantify economics - how to priortize features
• What Is Negative Engineering?

  Negative engineering is the time-consuming and sometimes frustrating work that engineers undertake to ensure the success of their primary objectives.

• Career Cheat Codes I Know at 36 That I Wish I Knew at 26
• Burnout
• How to make difficult technical decisions you and your team won't regret
  • What is the cost of making the wrong decision?
  • What is the ramp-up time of the decision? E.g. do you have early adopters you can try with?
• Mastering Programming by Kent Beck
• How do I make sure my work is visible?
• Cognitive Load is what matters
• Good software development habits
• The Gervais Principle - the officer according to The Officer; how companies are organized into Sociopaths, Losers and the Clueless.
• Accountability Sinks

  In The Unaccountability Machine, Dan Davies argues that organizations form “accountability sinks,” structures that absorb or obscure the consequences of a decision such that no one can be held directly accountable for it.

Salary

• How you can ~1.5x your salary through negotiation
  • Always start by asking for salary range (when being hired)
  • Approach the negotiation as a conversation, not negotiation
  • Seek leverage:
    • Get other offers
    • Line up other interview as a future leverage
    • Make the company really want you by excelling in the interviews (prepare for them, consider it an investement)
    • Sometimes the leverage doesn't need additional work: the company needs you to sign quickly, the company doesn't want to loose you, the company wants you to be invested, etc.
  • Negotiation isn't just about salary base: additional equity, signing bonus, relocation bonus, extra time off, etc.

Software Engineer

Resources

• The Product-Minded Software Engineer
  • Proactive with product ideas/opinions
  • Interest in the business, user behavior and data on this
  • Curiosity and a keen interest in "why?"
  • Strong communicators and great relationships with non-engineers
  • Offering product/engineering tradeoffs upfront
  • Quick product validation cycles
  • End-to-end product feature ownership
• The Grug Brained Developer - A layman's guide to thinking like the self-aware smol brained
• An incomplete list of skills senior engineers need, beyond coding
• How Google takes the pain out of code reviews, with 97% dev satisfaction
  • Continuous improvement over perfection.
  • Maintain or improve the health of the codebase
  • Follow the Style Guide.
  • Always Share Knowledge.
  • Write Small Changes (<200 LoC).
  • Strict Standards for Lightweightness (reviews under 24h).
  • Politeness and Professionalism
    • Predicting Developers’ Negative Feelings about Code Review
    • Destructive Criticism in Software Code Review Impacts Inclusion
    • Detecting Interpersonal Conflict in Issues and Code Review: Cross Pollinating Open- and Closed-Source Approaches
    • Using research to make code review more equitable
• The art of good code review
  • code review checklist:
    • Security
    • Observability
    • Performance
    • Robustness
    • Complexity
    • Readability
    • Maintainability
    • Over-engineering (YAGNI)
    • Using existing abstractions correctly
    • Naming stuff
    • Comments
    • Tests
    • Doing one thing at a time (separate PRs)
    • "Do I want to maintain this?"
• The surprising connection between after-hours work and decreased productivity
• Readability: Google's Temple to Engineering Excellence
• Software Engineering at Google
  • Knowledge Sharing
• The ideal PR is 50 lines long

  50-line code changes are reviewed and merged ~40% faster than 250-line changes. They’re 15% less likely to be reverted than 250-line changes and have 40% more review comments per line changed. If your median PR is 50 lines long, you’re probably shipping 40% more total code than your teammate writing 200+ line PRs.

Senior Software Engineer

Responsibilities

• Connect the dots between engineering and revenue

Resources

• A Senior Engineer's CheckList
• An incomplete list of skills senior engineers need, beyond coding
• What Makes a Senior Engineer? Writing Software vs Building Systems
  • Defining Requirements - work with the Product Manager to understand what problem they want to solve; maybe you’ll have some ideas on how to solve it with much lower effort?
  • Defining NFR’s - talk to your PM about the non-functional requirements - how many users should the System handle, what are the requirements for performance, throughput, latency? Are there any security or compliance considerations? Do we need auditing? What’s the desired availability?
  • Planning Iterations - work with your team to propose an implementation plan; make sure you define small, demoable milestones, so that you can start delivering value ASAP; agree with the PM on the milestones.
  • Determining Dependencies - make sure you identified all the dependencies outside of your team and work with your EM or with the teams directly to get some ETA’s for them. Adjust your milestones accordingly.
  • Testing - depending on how your company operates, decide on your testing strategy with your team or with the QE team. Agree on the quality threshold needed for the rollout (e.g. no unresolved Major bugs or test coverage above X%).
  • Deployment - work with your team to decide how the system will be deployed. Do you need some new infrastructure for it or can you reuse the existing? If you need a lot of it, what will be the cost?
  • Observability - decide how are you going to monitor the health of the system and set up processes for solving production issues (e.g. team on-call). Use a third-party solution (like Sumo Logic) to set up monitors and dashboards for that purpose.
  • Rollout Communication - once you agree on a rollout date with your team and the PM, make sure that all stakeholders are aware of it. Check whether any documentation changes are required.
  • Measuring Success - decide on metrics that will tell you whether the project was a success. Is anyone using the new system? Do users manage to accomplish their tasks? You can leverage your Observability suite for this purpose.
• The Senior Shift
• Path to Senior Engineer handbook
• How to find great senior engineers #interviewing - some suggestions for interview:
  • "What important truth do very few people agree with you on?"
  • The Three Why's - similar to what one would do during incident analysis, ask why multiple times to press for more nuanced answer
  • Use case-studies. You lay out particular technical scenario and ask the candidate to figure out what they would do

Staff Engineer

Responsibilities

Setting technical direction: providing vision for long-term technical development of specific area, e.g. API design.

• getting people from vague sense of "getting better" to clear idea of what "better" is and why

Mentorship & Sponsorship^1: sharing experience and advice along with understanding the recipient's context.

Providing engineering perspective: self descriptive.

Exploration: being assigned on new or burning topics to quickly iterate on finding a solution (or failing to do so which is fine as well).

Being glue^2: doing the needed but often invisible work to keep the gears turning.

• Timeframes get longer with higher titles, early on in the career the development cycle can be within weeks or months. In senior roles it shifts to months, quarters, or even longer.

Resources

• Staff Engineer: Leadership beyond the management track by Will Larson (book)
• StaffEng
• 6 ways staff engineers help reach clarity
• Staff Engineering at Carta
• Mailbag: Resources for Engineering Directors
• The Other Kind of Staff Software Engineer
• Mike Acton’s Expectations of Professional Software Engineers - 50 basic expectations for a professional software engineer, e.g. "I can articulate precisely what problem I am trying to solve."
  • For any problem there’s a maximum amount of time and effort worth investing in solving it. At least have some idea of the upper bound.
  • Read (at least partially) the (available) documentation for the hardware, platform, and tools that you use most commonly.
• Being a glue
• What does sponsorship look like?
• The Product-Minded Software Engineer

Engineering Manager

• The Engineering Manager — Empowering ourselves to empower others.
• A reading list for new engineering managers (2018)
  • book recommendations on various topic for new engineering managers
• From Engineer to Tech Lead - Doubts and Challenges
• The 25 Micro-Habits of High-Impact Managers
• What you give up when moving into engineering management
• Developer satisfaction surveys
• 35 Impactful Questions Managers Should Ask Themselves Regularly
• The Ultimate Guide to Onboarding Software Engineers
• How we onboard engineers at a devtools startup
• 11 Principles of Engineering Management
• Stop Overcomplicating It: The Simple Guidebook to Upping Your Management Game
• What To Do When Your Feedback Doesn't Land
• Flo Health’s path to the hiring strategy in engineering
• Get Straight to the Point
• Moving From IC to Engineering Manager
• Moving From Blame to Accountability
• Great management and leadership books for the technical track
• Advantages of incompetent management

Hiring

• How to Freaking Find Great Developers By Having Them Read Code

VP of Engineering

• On Becoming a VP of Engineering, Part 2: Doing the Job
• 9 key lessons learned on my path from Engineer to VP 🔑