Skip to main content

Skills Senior Engineers need, beyond coding

Source: https://skamille.medium.com/an-incomplete-list-of-skills-senior-engineers-need-beyond-coding-8ed4a521b29f
  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

Comments

Popular posts from this blog

सूनापन

मुद्दत हो गयी उन तन्हायियो को गुजरे , फिर भी इन आँखों में नमी क्यों है  ? तोड़ दिया मोहब्बत पर से यकीन मेरा, फिर भी मेरी दुनिया में तेरी कमी क्यों है ? हसरत है क्यों आज भी तेरी चाहत की मुझे, क्यों याद तेरी जेहेन से मिटती नहीं ? जलजला क्यों उमड़ता है ख्वाबो में मेरे, उस आशिकी की आगज़नी क्यों है  ? सन्नाटो में भी क्यों सुनता हू तुझे मेरी परछाई से क्यों तू जाती नहीं ? इन डबडबाती आँखों को तलाश तेरी, आज भी कहीं क्यों है   ?

How the Python import system works

How the Python import system works From:  https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/ If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like  ImportError: attempted relative import with no known parent package ; or tried to figure out how to structure a project so that all the imports work correctly; or hacked  sys.path  when you couldn't find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us  Importing files from different folder  (1822 votes),  Relative imports in Python 3  (1064 votes) and  Relative imports for the billionth time  (993 votes), are a good indicator of that. The Python import system doesn't just seem complicated – it is complicated. So even though...

What does it mean to “shift testing left”?

What does it mean to “shift testing left”? I used to think shifting left meant starting all these testing activities earlier in the process, but I realise it is more than that: it means  doing different things . Shifting left on testing means thinking about architecture and design differently, considering different stakeholders early and continually. Which in turn means shifting left on security, accessibility, and all the other dimensions of quality that we should care about. So shifting left on testing motivates all kinds of assurance activities, which can stop us over-investing in a solution that was never going to work. It is like TDD on steroids. As an unintended consequence, we can remove much of the traditional work that testers would have to do downstream when they only have late sight of the product. Again, we aren’t doing that work earlier, we are setting ourselves up to never need it at all!