The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 (Category Leadership)
Interesting. speech Daniel Thurhorst-North (presentation, too available)In which he shared his observations on what makes a good programmer great. In fact, he divided all observations into three categories. 1) Getting the job done 2) Choosing the right tool 3) Caring about the team
Part 1 - Getting the job done 1) Just start In order to get the job done, it’s important to get it started, and for many engineers perfectionism prevents them from doing it.)
- Resist procrastinating Sometimes perfectionism turns into procrastination to fight.
- Know you don’t know The first version does not have to be correct or good, it will still be rewritten.
- Iterate wildly It’s about testing and learning and learning from experience. (Try, fail, learn, repeat) 2) Build a product We don’t just write code, we create products. - Invest in the outcome In fact, there should be some goal and attachment should not be to the code, but to the achievement of the result. - Study the domain It is important to understand the domain and speak the domain language. - Watch your users The best way to get feedback from users is to spend time with them. So you can understand what is stopping them and fix it in the product. 3) Solve for now - Learn to see what is really there It is important to learn to see deeper. - Solve the real problem It is important to solve real problems, not those that seem to be. - Strive for simplicity We need to strive for simple solutions, not create complexitty.
Part 2: Choosing the right tool 1) Choosing the right tool for the product, not the team! The choice of tools should be based on the product and situation, not the team’s preferences. - Teams can learn! There are engineers who can learn new things:) - Do the simplest thing, not the easiest Choose the tools that are best suited to solving a specific problem. - The ‘right tool’ may change over time Here is an example of Scala to create the first version of a trading system and then replace it with another language. 2) Make the change easy - Minimise blast radius To simplify the changes, it is necessary to limit the radius of their damage:) - Reduce, reuse, recycle It is necessary to build a modular system so that individual components can be changed. - Then do the same with production code! Dan recommends simplification and production code (refactoring) 3) Be a polyglot It is important to be a universal developer. - Explore languages, tools, paradigms - Dan often helps with that. Advent of Code - 25- a daytime puzzle game. - Be ‘full-stack’ - about the front, back, API, mobile - Be really full-stack - here about engineering processes, iron and questions about why we do the task at all:)
Part 3: Caring about the team 1) Caring about others - Find joy in helping others learn Leadership, teamwork, mentoring and coaching are important. - Send the team home! - No recycling. n - Be kind Assume that the people around you are doing the best they can, and work on psychological safety as a team. (detail spoke This is what Google's Project Aristotle is all about.) 2) Caring about staying current - Join communities Contribute in the community and meet new cool people - Try new things - but approach it with healthy skepticism - Practise, practise, practise To be a good engineer, you have to practice. 3) Caring about yourself - Have interests outside of programming - We need an outside hobby.) - Go home on time - Don't forget the house. - Be kind to yourself Be kind to yourself and behave as you want others to behave.
Totally. Our job is to create useful products, not to write programs. Choose the right tools for a particular situation. Take care of your team, yourself and your development.
P.S. Daniel has other performances I've talked about.
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking