Skip to content

Latest commit

 

History

History
84 lines (76 loc) · 5.54 KB

developers.md

File metadata and controls

84 lines (76 loc) · 5.54 KB

Developers

  • [developer-tooling]

  • [interview]

  • [software-engineering-skills]

  • [developer-community]

  • [developer-experience]

  • Reflections on 10,000 Hours of Programming 2021

    • Seasoned google engineer tells some high level nuggets of truth

  • Rules of thumb for a 1x developer

  • Professional Programming: The First 10 Years

    • Fearlessness is undervalued
    • You can’t predict the future; try and you might end up in trouble
    • Nothing really matters, except bringing value to the customer
    • Perfection is unachievable
    • If you can’t connect it to the business, it doesn’t matter
    • Write tests that give you confidence that the system works as it should
      • 'how' is largely irrelevent
    • Using other people’s code is not as good as I thought
    • Some companies get it, others don’t. But nobody’s perfect
    • Investing in feedback loops is never wasted effort
    • Always leave something unfinished at the end of the day
    • Sharpen the axe
      • improve your daily tools
    • Hiring is hard
    • The most important trait in developers: rolling up their sleeves because it has to get done
    • Work on a codebase with other people over a longer period of time
      • see how decisions pan out
      • how extendable is your code
    • Knowing the full stack
    • Typing can be the bottleneck
    • Code reviews aren’t waterproof
    • Not every code review is worth the effort
    • Negativity begets negativity
    • Every dial at 100% all the time doesn’t work
    • Code has mass
    • Programming as a part of my life
      • You have to program/interest outside work

  • An incomplete list of skills senior engineers need, beyond coding - For varying levels of seniority, from senior, to staff, and beyond - Camille Fournier 2021

    1. How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it
    2. How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time
    3. How to mentor an early-career teammate, a mid-career engineer, a new manager who needs technical advice
    4. How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
    5. How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it
    6. How to influence another team to use your solution instead of writing their own
    7. How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated
    8. How to lead a project even though you don’t manage any of the people working on the project
    9. How to get other engineers to listen to your ideas without making them feel threatened
    10. How to listen to other engineers’ ideas without feeling threatened
    11. How to give up your baby, that project that you built into something great, so you can do something else
    12. How to teach another engineer to care about that thing you really care about (operations, correctness, testing, code quality, performance, simplicity, etc)
    13. How to communicate project status to stakeholders
    14. How to convince management that they need to invest in a non-trivial technical project
    15. How to build software while delivering incremental value in the process
    16. How to craft a project proposal, socialize it, and get buy-in to execute it
    17. How to repeat yourself enough that people start to listen
    18. How to pick your battles
    19. How to help someone get promoted
    20. How to get information about what’s really happening (how to gossip, how to network)
    21. How to find interesting work on your own, instead of waiting for someone to bring it to you
    22. How to tell someone they’re wrong without making them feel ashamed
    23. How to take negative feedback gracefully

  • The Developer Advocate's Guide to Getting Buy-In

    • You present an idea, everyone agrees, but nobody commits and work never happens

    • Buy-in is an agreement to support a decision. So, when we are trying to get buy-in, we're trying to get decision-makers to support our ideas. So, the act of getting buy-in is a process that involves building trust, communicating your ideas well, and hopefully creating champions so that when you ask for a commitment, you already have the right people on board.

  • A Human-Centered Approach to Developer Productivity

    • Humans are messy
    • It's impossible to separate technical problems from human problems
    • A thoughtful birds eye view of software made by humans