Downloaded 11 times
Uploaded byTrisha Gee
Career Advice for Architects
Trisha Gee emphasizes that modern architects in software development must prioritize skills like communication, adaptability, and time management over purely technical knowledge. She highlights the importance of community engagement, sharing knowledge to improve team productivity, and being cautious of non-technical roles. Ultimately, sharing skills and fostering a collaborative environment are key to becoming a successful architect.
More Related Content
Similar to Career Advice for Architects
Career Advice for Architects
- 1. — Trisha Gee (@trisha_gee) JavaChampion & Developer Advocate Career Advice for Architects
- 2.
- 3. The hardest singlepart of building a software system is deciding precisely what to build. No Silver Bullet: Essence and Accidents of Software Engineering Frederick P. Brooks, Jr.
- 4. Everyone is anarchitect these days (Sorry)
- 5.
- 6.
- 7. Asking Questions Listen tothe answers!
- 8. “Good Communication Skills” Talkingto computers is the easy bit
- 9.
- 10.
- 11.
- 12. Be aware If youperform non-technical activities too well, you may be moved into a non-technical role
- 13.
- 14.
- 15.
- 16. 20% Time But actuallyuse it!
- 17. Community Support Give backto the community
- 18. Book Club With feedbacksessions
- 19. Internal Learning Sessions InternalUser Groups
- 20.
- 21. You don’t needto be In Charge to apply these Your responsibility as an architect is to share
- 22.
- 23. Backup and Redundancy Specialisationand silos are a risk
- 24. Increase Team Productivity Teach9 others your skills to be 10x more productive
- 25.
- 26. It helps youto learn …and it makes you look great
- 27.
- 28. Your key skillsare not technical
- 29. To scale yourskills, share them
- 30. Sharing makes youLook Good
- 31.
- 32.
Editor's Notes
- #2 Developer advocate is not just someone who advocates TO developers, but ON BEHALF OF developers - I have so much to learn off every one of you - Going to share my stories and lessons learnt from my experiences
- #4 This is a developer role Looks like an architect We’re all architects
- #5 Who’s involved in the process of decing what to build? - Analysts, developers, testers, ops We’re all architects because of this While the senior people decide exactly what to build, we all still do this to some extent
- #6 We’re all full stack polyglot devops developers / testers / business analysts / operations / management
- #7 Whether you have it in your job title or not Whether you are doing it now, or want to do it at some point Whether you’re business, development, testing, ops, management or in a glue-like role like mine
- #9 - What do you want? - Why do you want it? - What are the alternatives? - What happens if…? - What’s the impact of…? - Why was this done this way?
- #10 Talking to humans – your team, the business, another team, customers Writing emails Slack Pull requests / code reviews – giving constructive feedback Meetings – including listening to people and making space for them Teaching / explaining / documenting Presenting / demoing Even readable code requires good communication
- #11 - New libraries, frameworks, languages every day - New processes, people, mindsets - New domains, - Business changes its mind, customers change, evolve * No tabs vs spaces, no Kotlin vs Java * Different people, different teams, different domains, different times call for different approaches. * Don’t be dogmatic, it will reduce stress and improve team morale
- #12 Learning to say “no” - Prioritising your own work, helping others to prioritise - The business will always want everything P1 right now - Tech debt will never be high priority, neither will scalability until it fails * Time Management can help, windows of time can focus the mind * It’s not just about work time, it’s about you time * Always-on world. Make you time * Burnout
- #13 The ability to learn, and demonstrate, technical skills, sure But just having them? Not the hard bit.
- #14 None of these skills require you to move away from code But you might get pulled away from the code
- #15 20 MINUTES? We’re architects so we care about scaling our skills Scaling means: improving existing skills, learning new skills, and Getting More Done with these skills In addition, the following activities will all help the non-technical skills Note that you don’t have to be a leader here
- #16 - Not just with programmers - LMAX: learnt more in 6 months of pair programming than 10 years of experience - Learn about: domain, code, standards, tools, tips for using tools - Everyone levels up - Increase bus factor
- #17 Code archaeology Remember Wednesday night sessions to look through the code?
- #18 Lobby for it Suggest projects Evaluate projects
- #19 - Mandatory Stack Overflow time - Learnt about product, how the users used it - Improved the product based on this - Built up a lot of good will in the community Open Source - Good for developers - Improve the code for your use case - Good for the organisation’s rep - If we all do it, we all level up
- #20 - Physical books contain knowledge (often verified) - Split book into chapters - Assign to person/people - Get together to present on each chapter - If you do it at work, the stuff learnt for each chapter should be applied to your team/product/tech stack
- #21 - Can be formal or informal - Can be on a new tech you’re thinking of using - Can be on an area of the domain - Can shine a light on dark code - Can practice presentations * Benefits of user groups but on work time and at your location * Remember you should be focused on sharing there, present what you’re working on
- #22 - Attending is great to learn - Speaking is fantastic for your career, and makes your company look good - If you’re a woman you should really do it. I know you think you’re not ready, but you are and we will help you * User groups are lower barrier to entry * Good way to find real stories of people doing stuff * Good way to share your stories and get feedback from other practitioners Conferences and user groups are fantastic for recruitment
- #23 If you want to be a 10x developer help your team to learn
- #24 35 MINUTES?
- #25 In the olden days you ensured job security by being unique Now siloed knowledge is a risk Increase bus factor
- #27 Mentoring is great Learning is a big reason we do this
- #28 All the scaling activities help you learn other “soft” skills Teaching is amazing for your career
- #31 Distributed vs Bigger Box Don’t just collect new skills Share them
- #32 …and helps you learn new stuff too
- #33 Scaling by buying a bigger box vs scaling by going distributed Focus on this second one because: - Sharing helps you learn - Sharing makes you Look Really Good