Developer Experience (DX)
Mind of a Hacker
#hacking
#object-oriented-programming-oop
#developer-experience-dx
#ruby
#programming-techniques
#software-development
#simplicity
Mind of a Hacker
by Ryan DavisIn the keynote presentation titled 'Mind of a Hacker' delivered by Ryan Davis at the LA RubyConf 2015, the speaker shares his personal journey and insights into the hacker mindset, emphasizing creativity, curiosity, and continuous learning. Davis opens by discussing his love for food and cooking, using it as a metaphor for his approach to programming and hacking. He highlights his extensive experience with various programming languages and the importance of understanding the underlying techniques in coding rather than just following recipes.
Key points discussed include:
- Hacker Mindset: Davis cites Stephen Levy's definition of a hacker, advocating for an insatiable curiosity about how things work and a delight in problem-solving, contrasting it with the routine work of a 'day-job programmer'.
- Learning Models: He introduces concepts such as 'Shuhari' and the Dreyfus model of skill acquisition, explaining how individuals progress from novice to expert levels.
- Simplification and Prioritization: Emphasizing Einstein's principle of simplicity, Davis shares his approach of minimizing complexity in both coding and design, favoring clearer, more efficient outcomes.
- Real Artists Ship: This mantra resonates with his commitment to sharing work and contributing to the community through gems and packages in programming.
- Passion for Problem-Solving: Examples from his experiences with various projects illustrate the drive behind his work, underscoring the importance of maintaining curiosity and passion in coding.
The session concludes with a call to action for attendees to embrace their inner hacker and continually seek innovative solutions while keeping things simple and efficient. Davis encourages maintaining a data-driven approach, learning from feedback, and experimenting to foster growth in coding practice.
00:00:06
So...
00:00:24
I think that was enough intro for me. Other than the fact that I am one of the Seattleites speaking today.
00:00:30
By my count, Seattle is ruling today; we have a majority here.
00:00:37
I am the last surviving founder of the Seattle Ruby Brigade, which is the oldest Ruby group in the world.
00:00:45
Thank you everyone for being here and for sticking it out through the entire day. This is a fantastic conference. Thank you to Kobe and everyone else for organizing it. Let's get started.
00:01:02
I like to set expectations; it keeps people adjusted correctly. Except this is my first keynote, and I didn't really know what that meant.
00:01:13
I talked to Aaron about it, and we basically came to the conclusion that it was supposed to be fluffy, feel-good stuff.
00:01:23
What that means, I don't entirely know. I've got 170 slides and an unbounded time limit, so who knows how many slides per minute that is.
00:01:28
Yeah, I'm last and you're stuck with me; deal with it.
00:01:34
Let's just get this out there: when it comes to talking about myself, I hate it. And when I say I hate it, I mean no, really, I hate it.
00:01:46
Unfortunately, I was watching a TV show called 'Mind of a Chef' a lot when this came up, and I came up with a quippy title before I realized the implications that I would be talking about myself.
00:02:00
So I'm kind of stuck with it. I still hate it, though.
00:02:06
Food. I love food. And almost more than I love food, I love to cook. Between my mom, who is a fantastic cook and one of the best I know, and my formative years in Louisiana, I've been surrounded by good cooking and good cuisine my entire life.
00:02:22
So you could say I love cooking. Pretty pictures; those are all mine, so no credits given.
00:02:28
Once in a while, I cook something damn good. This was so good that I actually experienced cognitive dissonance while eating it. I had a hard time convincing myself that I was the one who just cooked it.
00:03:02
I was putting it in my mouth and going, 'What the hell happened between here and there?' Because this was not my dish, and I actually made it. It made me feel a bit like this guy. Unfortunately, cooking is not genetic, and more often than not, I feel like this other guy. However, increasingly, I find myself somewhere in the middle.
00:03:35
True to the theme of unexpected surprises, I have to include something out of left field. This is my anteater. I love this slide so much that I could not leave it out, even though it has no meaning here whatsoever.
00:03:46
Like most cooks, I love my knives and my tools. Pro tip: the sharper your knives, the less they hurt. This can have negative consequences, however.
00:03:59
If you wind up bleeding into your food before you realize it, this does help with the pain part and it actually delays the bleeding quite a bit.
00:04:12
Unlike many cooks, I don't love recipe books. They tell you the 'whats' and not the 'whys.' There's no creativity in them.
00:04:30
While the end result may taste great, that's not why I cook. Instead, I love technique books. I like to know how aspects of cooking work at a higher level. Some books that exemplify this are 'On Food and Cooking' by Harold McGee and 'Think Like a Chef' by Tom Colicchio.
00:04:56
One of the things he taught me that I really liked was to turn down the heat if you have gas until you can hear the fruit cooking. Then, use your ears to cook.
00:05:21
I also enjoyed books like 'Cook Wise' by Sherri Corriher, who is quite often on 'Good Eats.' Just look at her! Who doesn't want a spiky-haired grandma with a southern accent who knows chemistry and can make really good food? She's delightful.
00:05:42
She can teach you things like the science of asparagus pee, and I truly wanted to adopt her as my grandma.
00:05:47
I also love cooking shows, specifically technique shows. Originally, that was with 'Good Eats.' The first episode I saw was about artichokes.
00:06:09
One of the takeaways was that to get even cooking, ensure they are submerged at all times. The host put a large pot filled with enough water, but little bastards float. So, he placed a UFO-shaped steamer upside down on top of the artichokes and put a rock on it.
00:06:34
I learned about cooking rocks, and now I have cooking rocks. When I refer to them, others often say, 'Cooking rock!' But yes, cooking rock.
00:06:49
I also love the show 'Mind of a Chef' so much that I would rather have this as my title page, but I do text from my title pages, so this is just in the middle.
00:07:02
A little bit about the path that I have walked.
00:07:07
What makes me tick? Well, whether they are electronic, mechanical, or made of meat, I love understanding and I love pushing buttons.
00:07:23
Quick painful history. As painful as it may be, this gives the highlights of the path that I walked down. I was born in 1972, when computers weren't exactly on everyone's radar.
00:07:39
I began using computers in sixth grade, where I picked up my first computer but also my first programming language, which was Logo. I then moved to BASIC.
00:07:51
In junior high, I continued learning and in high school, I got into advanced placement computer science in Pascal.
00:08:02
I started branching out into C, aware of the object orientation trend that was just beginning, but unlike today, there was no internet to research this knowledge.
00:08:18
I relied on paper resources—many of which were terrible. During my college years, I picked up Smalltalk and had my object-oriented epiphany.
00:08:30
I picked up ten to twenty programming languages because I was eager to learn everything I could.
00:08:46
Professionally, I went on to work at GemStone right out of school. They worked with object-oriented databases, and I engaged with implementations of Smalltalk and Java.
00:09:01
Eventually, I moved to Amazon, where I picked up Ruby, and the rest is downhill.
00:09:15
By the way, I've worked at big companies and small ones. I'm now an independent consultant in Seattle.
00:09:28
So what is a hacker to me? This is exemplified by a book by Stephen Levy called 'Hackers.' It details the start of the hacker mindset that began at MIT.
00:09:44
I won't read the long quotes on the slides; I hate lots of words on slides. I will focus on the important parts.
00:09:59
When you grow up with insatiable curiosity about how things work, the delight found in discovering something as elegant as circuit logic is profoundly thrilling.
00:10:10
The wild pleasure taken in mere involvement is called a hack. For me, insatiable curiosity resonates to my core.
00:10:29
This is the difference for me between a hacker and a nine-to-five, day-job programmer.
00:10:39
For me, the emphasis is really on making. I want to understand, but I need to create.
00:10:53
I was raised surrounded by artists. My mother can't help but paint, my father can't help but photograph, and my brother can't help but draw. Apparently, I can't help but code.
00:11:16
Some of you may have read some of my code, so you know that it's not exactly art. But it is one of my main creative outlets.
00:11:28
What isn't a hacker? There are some overlaps with these groups due to forms of self-selection.
00:11:42
I'm not talking about crackers, script kiddies, or anything that comes from the mainstream media. We certainly don’t hang out with Angelina Jolie.
00:12:01
This movie is a prime example of the misconceptions in the media about hackers. The poster promotes a horrible film.
00:12:15
It was really bad, and I saw it in the theater, which was awful.
00:12:30
What type of stuff really turns me on? What am I most interested in?
00:12:37
Of course, long walks on the beach, but also cranes that put up cranes.
00:12:43
These cranes are amazing. I become like a six-year-old boy whenever one of these goes by.
00:12:59
I find it incredible how they drive themselves, put their little legs down, and level themselves. Another truck comes with weights to stabilize themselves while they build.
00:13:18
I care less about the building itself; I love when the first crane unpacks itself and drives off. It's amazing.
00:13:38
I also love surprise machines that make machines and implementing a language defined in itself, which is called bootstrapping.
00:13:57
This refers to the mathematical or computer science sense of the word, not the business sense.
00:14:04
I love being a developer's developer and thinking about thinking, which is similar in nature.
00:14:28
Now, let's think about learning for a second. There's a concept called 'Shuhari.'
00:14:36
It describes the stages of learning in Japanese martial arts, but for me, it's just a bit too woo. There's a more formalized model called the Dreyfus model of skill acquisition.
00:14:58
This model is complex and illustrates varying levels of progress through a skill, from novice to expert.
00:15:14
I prefer the Four Stages of Competence, which maps to a two-by-two table. I am slightly addicted to mapping things to two or three dimensions for understanding.
00:15:42
The progression starts at unconscious incompetence, where you don't know what you don't know. You move to conscious incompetence, which means you're aware of what you don't know but aren't good at it yet.
00:15:58
Then, as you start to get good at it, it takes work, and eventually, it becomes effortless.
00:16:09
This may seem a bit wordy, so to simplify: there's wrong and right, intuition versus analysis, which maps the same way.
00:16:29
You can easily use this tool to consciously level up either yourself or someone you're teaching. Mapping skill levels allows you to assess any ability at any level of granularity.
00:16:53
For a slightly more concrete example, this is me as a 2x2 table. Honestly, I know very little about R, having tried three times but still can’t write a line of it.
00:17:10
However, I know about five percent of Mathematica, which covers a lot. It's a huge field, and I'm unable to navigate it well.
00:17:27
When it comes to Scheme, or more specifically, Racket, I am competent at it. I've released a package in Racket and I'm conscious of the effort involved.
00:17:42
In Ruby, I can get by, so the next step is figuring out where you are in those models. One model provides more granularity and description, making it easier to use.
00:18:01
Prioritizing what’s important to you helps create a plan to level yourself up efficiently.
00:18:24
When I first did this talk, I wound up with 250 slides, not knowing how much time I had or the pace I wanted to maintain.
00:18:38
So, I'm going to give you my top six priorities, depending on time; I might have a few more.
00:18:56
Unfortunately, my balloon's a little deflated, but that's fine. My favorite quote that drives me is 'Real artists ship.' I've got over 90 gems under my belt and a few Racket packages.
00:19:10
This quote resonates because I want to ensure my work is shared for others to benefit. It exemplifies priorities.
00:19:29
Along these lines, the 'Cult of Done Manifesto' has a few principles I'd like to highlight.
00:19:37
Here it is; I don't expect you to read everything immediately, but I'm just putting it out there.
00:19:52
My favorites are in red. I keep reminders to simplify and design for essential content.
00:20:07
Again, I find that simplicity leads to more flexible and useful outcomes than anticipated.
00:20:19
Relating this, I borrow from Ward Cunningham of Extreme Programming. The overlap in our talks helps me stress my values.
00:20:34
I apply this quote whenever I write code, which succinctly states that of two competing theories, the simpler one is preferred.
00:20:56
This is part of a continuous loop of learning and minimizing complexity in code, designs, and products.
00:21:11
It's best exemplified through my experience with 'MiniTest,' as I'm happy with version 5. But now, I have no idea what to plan for version 6.
00:21:29
Einstein's quote echoes this: 'Everything should be made as simple as possible, but not simpler.' This warns against oversimplifying.
00:21:46
Cunningham noted that simple designs come after projects have matured, and you'll notice that with each iteration, you tend to simplify.
00:22:02
The goal is to focus on the task at hand—make the system do what it is designed for.
00:22:13
The act of codifying this organized thought process makes it easier to maintain and align with our intentions.
00:22:34
We conduct many small experiments to ensure precision while managing cost and efficiency.
00:22:48
I envision many systems, software, hardware, and human aspects as variables within a formula.
00:23:01
The more unknowns we have, the more fluctuations and chaos ensue. Removing variables is key.
00:23:17
Striving for maximal signal and minimal noise leads to clearer and more understandable projects.
00:23:31
As a dorky example, my uniform simplifies choices based on temperature, reflecting a focus on essential needs.
00:23:49
Though it’s a silly practice, it saves my mental energy for more critical matters.
00:24:02
This relates to the philosophy of 'You Ain't Gonna Need It'—avoid unnecessary developments.
00:24:11
Pair programming drives me insane when faced with overly cautious programmers who dwell on hypothetical edge cases.
00:24:29
Dr. Paul McCree advised treating problems with ridiculous simplicity: the time saved on 98% of issues allows resources for the other 2%.
00:24:45
This correlates with the Pareto principle, where the bulk of our work often stems from a minority of system variables.
00:25:00
To enhance productivity, focus on essential coding needs rather than spending energy on minor checks.
00:25:16
Look at the simplicity of the Gossamer Albatross, the first human-powered vehicle to cross the English Channel, and notice its efficiency.
00:25:32
Simplification defined his approach in design and manufacturing, leading to innovation.
00:25:54
Be objective in your endeavors whenever possible. Measure consistently—measure twice, cut once.
00:26:06
Improving requires objective metrics; even subjective data can aid your process.
00:26:22
My tool, a complexity metrics tool called Flog, helps analyze source code, though its numbers serve more as relative comparisons over time.
00:26:38
Please don't take a single score from one application and compare it with another; that's meaningless.
00:26:53
Most importantly: benchmark first, optimize later.
00:27:09
Humans in the code room often underestimate the costs of code and impact.
00:27:23
Your gut instincts about needing to cache certain components are often incorrect.
00:27:36
So, measure—it's easily overlooked, yet important.
00:27:51
Aaron began with Rails after discovering the inefficiencies of ActiveRecord; he delved into foundational aspects to improve functionality.
00:28:08
He aimed for a faster feedback loop, synonymous with fail fast methodologies, prototyping, and continuous deployment.
00:28:24
Get your work out as quickly as possible to gather constructive feedback and address bugs efficiently.
00:28:40
Utilizing tools that provide immediate feedback, like MiniTest and Autotest, amplifies productive coding dynamics.
00:28:58
Ultimately, always scratch that itch.
00:29:11
I said in my earlier talk you should foster feelings about your code: love it, hate it, or better yet, love to hate the bad code.
00:29:26
Without passion or insatiable curiosity, you risk becoming a day-job programmer and burning out.
00:29:39
Aaron embodies this with Nokogiri, motivated by the weaknesses of previous tools; his curiosity pushed him to innovate.
00:29:54
The graphics gem arose from frustrations with Ruby SDL, offering a cleaner approach for novices and facilitating simpler visualization.
00:30:04
Vlad was created due to my discontent with Capistrano and Net::SSH, leading to a straightforward solution.
00:30:18
I collect vast amounts of data about my physical health, utilizing exponential averages for tracking.
00:30:33
Last year, I observed dramatic changes, triggering a thorough research process, hypothesis testing, and experimentation.
00:30:51
Ultimately, laboratory tests validated my self-experiments, showcasing the importance of data-driven approaches.
00:31:04
Without numbers and that hacker mindset, I would be in trouble today. I’d love to discuss this further.
00:31:15
So please, embrace your inner hacker and hack everything to enhance processes and maintain simplicity. Thank you.
00:31:33
I did have something else that was relevant.
00:31:35
Thank you all for listening. What other questions do you have?
