14 things you need to be a successful software developer (v3)
•Als PPTX, PDF herunterladen•
0 gefällt mir•129 views
As we passed 140 years of software development, you would think the path to success has been worked out, documented, taught, and largely understood and yet, most software is late, over budget, or full of bugs (sometimes all three). This talk is not about the new Wizz-bang tech that will change your life by solving the issues in software development and only cost you a monthly subscription to your favourite tech company, rather this talk is focused on the only thing that you have control to change, YOURSELF. Join Robert as he will share 14 rules for being successful in software development, a talk he wished he had gotten over 20 years ago.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 14 things you need to be a successful software developer (v3)
Ähnlich wie 14 things you need to be a successful software developer (v3) (20)
Mehr von Robert MacLean
Mehr von Robert MacLean (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
14 things you need to be a successful software developer (v3)
- 1. 14 things you need to be a successful software developer
- 2. What you will see Modern Development 1. Diverse and empowered teams 2. Practice constant verification 3. No=one is best positioned to avoid a problem than those who just made it 4. Software system are alive Reality of software development 5. Remember the triangle 6. Embrace Risk 7. Low tech is good enough 8. You’ll never stop learning Empathy, trust and safety 9. Communication is more important than technology skills 10. Don’t be the smartest person in the room… until you should be 11. You don’t know, what you don’t know 12. Assume good intentions 13. When in doubt, ask a duck 14. Protect yourself
- 5. What can you control? Seek out diverse teams Find ways to remove bias in hiring Share with others on the benefits
- 7. What can you control? Assume others have different info, but are not wrong Focus on the entire lifecycle of software development, not just coding Practice YOU BUILD IT, YOU RUN IT
- 8. No-one is best positioned to avoid a problem than those who just made it
- 9. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
- 10. What can you control? Run PIRs Build blameless cultures
- 11. Software system are alive
- 12. What can you control? Ship early, ship often, get feedback Focusing on maintenance will make for cheaper systems Do risky things often
- 14. Software development is not about coding
- 15. Capacity
- 16. What can you control? Look beyond your role Customer Obsession Remember Conway’s law
- 17. Embrace risk
- 18. What can you control? Learn to articulate and measure risk Remember that slipping is not falling If you are surprised, it means you need to look at communication in your team
- 19. Low tech is good enough
- 20. What can you control? Most code is repetitive, so you’ll need to find challenge elsewhere Build systems and write code where understanding is a feature Customer obsession
- 21. You’ll never stop learning
- 22. Skills Knowledge
- 27. Skills Knowledge C# Git Google AWS Engineer A Engineer A Engineer B Engineer C
- 28. Skills Knowledge C# Git Google AWS Engineer A Engineer A Engineer B Engineer C
- 30. AWS Azure Common cloud tech Azure Specific AWS Specific
- 31. What can you control? T-Shaped is your first focus Most people will need broad skills in future Skills need reinforcement
- 33. Communication is more important than technology skills
- 34. What can you control? Find ways to communicate more Communication is a skill. All skills need to be practiced Remember experience is not linked to skill
- 35. Don’t be the smartest person in the room… until you should be
- 36. What can you control? Participate in the community Find a mentor, be a mentor
- 37. You do not know, what you do not know
- 38. What can you control? Learn to deal with ambiguity Seek out diverse views
- 40. What can you control? Breed transparency Show vulnerability Assume good intentions
- 41. When in doubt ask a duck
- 43. What can you control? Take breaks Ask for help Get a duck
- 44. Protect yourself
- 45. What can you control? Build a list of values and interview questions for them Setting the boundary from the start is easier than moving a boundary Get a mentor
- 46. What you saw Modern Development 1. Diverse and empowered teams 2. Practice constant verification 3. No-one is best positioned to avoid a problem than those who just made it 4. Software system are alive Reality of software development 5. Remember the triangle 6. Embrace Risk 7. Low tech is good enough 8. You’ll never stop learning Empathy, trust and safety 9. Communication is more important than technology skills 10. Don’t be the smartest person in the room… until you should be 11. You don’t know, what you don’t know 12. Assume good intentions 13. When in doubt, ask a duck 14. Protect yourself
- 47. Geek Of The Year 6pm @ 7 December developerug.org.za Call for speakers open Tickets and sponsor packages available in January devconf.co.za
Hinweis der Redaktion
- Scrum had this right & self organizing Avoid titles Small 8 to 10 Tightly focused with broad context You build it, you own it Interview: ask to meet the team
- QA Unit tests Test environments CI Observability All software is adding features to a known state NOT RETROS
- Retros, postmortems, safety PIRS 5 whys
- Norm Kerth
- Compare to putting bits on a CD and it is done Heart beat Gardener 80% of cost is maintenance Bits on a platter are just wasted electrons if no one uses it Ship often Short term goals
- Capacity Features Time People are not resources Quality is a feature
- Conways law; software resembles the organisation that made it
- Slipping is learning Sprints When you are surprised, it is a communication issue Dates: ‘when you realise you late; you do not know the new date – don’t fall in the trap of just adding dates to the end Interview question: Tell me about the last mistake a team member made and how the company responded to it
- Most software is not interesting What is your goal? Give customers value, they don’t care if it is high tech Easy to communicate Responsible innovators
- Tech moves fast Get good at finding cross references between things, get comfortable with not knowing, get vocal at saying I do not know but I will find out Surfers ride waves but also sit and wait Networking, events and conferences
- Growth is breadth, depth and see saw
- Tim Brown IDEO CEO
- T shaped teams
- Specialist
- Cross skill Diverse teams Make sure you have ability to talk Assume good intent Team charters
- Don’t go dark / Stand ups Small deliverables (t-shirt sizing) Kanban/scrum boards to keep everyone accountable to each other Learn to love a meeting Learn to love documentation Brilliant jerk / guy in the room Delivery vs academic
- Pay it forward Get involved Conferences & user groups
- Community is writing, social, youtube, events, organising events
- Saying no, saying yes Don’t give dates you don’t know Cope with uncertainty > build trust Dunning-Kruger Asking the dumb questions Client demands you know everything; they know less than you and they telling you They can’t hire someone who knows, they can only hire someone who lies
- Politics Assume your good intentions The problems you perceive is the problem you are responsible for
- Burnout Healthy boundaries Get a mentor Know your values
- Slips are the outcome of risk, they are not the focus – managing a slip is just more embracing or risk. Embracing of risk is more critical Growth was focused on T-shape which just is flawed in how it is commonly used. More emphasis on breadth and learning across
- None is best positioned to avoid a problem than those who just made it used to be postmortums which is a terrible term (death/failure focused) and focuses on process. New one talks to process but focuses on people Software systems are alive focuses on SaaS, cloud and modern dev. It focuses on shipping and getting feedback The triangle became software dev is not about coding, which is partly a move from the previous into the right section but allows it to expand to CI/CD Zoo rule dropped the debugging aspect which had nothing about empathy, trust and safety. It focuses on asking for help now
- Burnout Healthy boundaries Get a mentor Know your values