Endurance

Transcript

1. Endurance This talk isn't necessarily the path for everyone, but it describes the path I personally take. It is my mantra–my manifesto for the work I do and how I think about it. It has changes somewhat throughout the years, but surprisingly slowly.
2. Improving I'm going to start with self improvement, because it's the most general and the rest of what I'm going to say builds off of it. Many of us start out with a very simple set of skills, and a desire to achieve things that will only be possible by improving our skills.
3. Priorities To improve yourself, it needs to be a priority. This may sound passé, but you may honestly not have time for it. If your 9–5 job doesn't offer you opportunities for improvement, you will need to find time. You need to honestly self-assess whether this is possible. You may need to find a job that prioritizes self-improvement.
4. The Edge of Your Capabilities Work on things that are slightly harder than what you already know how to do. If you do this relentlessly, you will be constantly pushing the boundaries of what you know. If you only ever work on something in your comfort zone, you can spend 10 years doing the same thing over and over again, and never really improve.
5. • Hack on Rubinius • Templating Engine Compiler • Library internals • Performance • Encodings • Ruby C extensions • Ruby Rust extension • Elixir web framework • Package manager • Build tools • Web standards
6. Comfort Zone
7. Open Source
8. Bootstrapping When I first started programming, I tried to improve by reading books and working on personal projects. But it doesn't really work.
9. Help & Mentorship You really need the mentorship of project leaders and help from other people who are climbing the mountain with you.
10. "Simple" Things Santiago warnings story. Getting a full build set up is harder than it looks for most projects. Separate "getting up and running" from your first hard task.
11. Grow by Teaching Eventually, you'll be helping and mentoring other people, which is another level of learning. Teaching is very humbling. It shows you the gaps in understandability.
12. Feedback Putting your code out there is a great way to get feedback.
13. Feedback & Criticism
14. Don't Ignore It Don't ignore criticism. It can help you identify places where people are getting confused or otherwise falling off the wagon. It helps you identify where your conceptual model doesn't map onto your users.
15. Grain of Salt But take criticism with a grain of salt. People don't always know what they're complaining about.
16. Friends and Long Walks
17. Diminishing Returns from Hacking When trying to solve hard problems, the type of problems you will need to work on to improve, you get diminishing returns from simply hacking. You need to step back and rethink the big picture of the problem.
18. Walk I personally walk about an hour a day with Tom these days to discuss issues that have been bugging us that we're stuck on.
19. • Technical • Social • Strategic
20. Low Times Having someone to talk to you when times are low is very important, especially in a field so dominated by the Internet. You need someone to remind you that unhappy users complain much more than happy users praise.
21. "Kernel of Truth" It's also useful to have someone with you to help you suss out the kernel of truth in the criticism you receive. Talking to another person lets you be honest with yourself without getting depressed.
22. Walk by Yourself I walk by myself often on the weekends in a park for a few hours. Disconnect (or listen to music). This will help you find coherence in things that have been tumbling around.
23. Hard Problems
24. The First Solution is Rarely the Right One
25. Research is Useful If you're working on a hard problem, do your research first. Understand the state of the art. Example: bundler and SAT solving
26. Put it Out There Ultimately, the only really good way to hone in on a good solution is to put something out there and wait for feedback. You should expect a lot of user complaints about the first thing you build.
27. big picture little picture experience experience
28. Early Criticism is a Gold Mine Focus on refinement! Bundler 0.8 Ember Router v1 Ember Data Don't get too connected to your first implementation. It will probably be completely replaced by the time you've collected feedback from early users. You need to be very open to changing large parts of your ideas, especially around the mental model that your users will have.
29. Meet People Meet people in person. You'll get far better feedback and criticism than on the Internet.
30. Dog Food Always use the software you write.
31. Dog Food, But Understand the Limitations But if you're writing something general purpose, don't assume that your use-cases are the only use-cases.
32. Synthesis
33. • Things that are the same • Things that are trivially similar • Things that are similar • Things that are different
34. • Things that are the same • Things that are trivially similar • Things that are similar • Things that are different
35. • Things that are the same • Things that are trivially similar • Things that are similar • Things that are different Don't reach too far
36. Turing Escape Hatches
37. Don't Give Up
38. It's Easy It's especially easy to give up if you only ever hear negative things. When doing the hermeneutic circle dance, it's also easy to forget that you're heading towards a conclusion, and not just running around like a chicken without its head.
39. Your Problems Take on problems that you have, but nobody is solving (or everyone is solving simplistically).
40. • Work at the edge of your capabilities • Work on Open Source • Have a Confidant • Circle Hermeneutically
41. Leverage
42. Thank you.