Notes from our discussion:
- what makes a "senior" software dev?
- you know how to find the answer to what you don't know
- deep language familiarity is not necessary; faux-senior
- predictable, reliable problem decomposition
- think about the problem fundamentally; know what tools you have
- pattern matching: "I've seen this sort of problem before"
- strong network of other experts to ask
- maintainable, readable code
- good at design
- and know when to not over-design
- have the experience of doing things wrong
- context informs how you write code (performance?)
- willing to be wrong
- shares knowledge and learning effectively (write-ups)
- tips
- keeping a language guide open
- using docs is OK
- evolutionary design
- continuous learning
- ownership
- to learn design errors, you have to build a system and then live with it for 6+ months (through changes)
- antipattern: architects that don't live with their decisions
- resources
- Martin Fowler's refactoring book (2nd Edition)
- Robert Frost books and talks on youtube - Clean Code
- breadth of knowledge: YouTube talks
- Pragmatic Programmer
- Fowler's blog
- Beyond Legacy Code
- The Art of Agile Development; jamesshore.com
- Pairing/mobbing + collective ownership
- Meetups
No comments:
Post a Comment