Talks
Keynote: How To Program
Summarized using AI
Keynote: How To Program
by Justin SearlsIn the keynote address at RailsConf 2017, Justin Searls explores the theme of how to effectively program by examining the underlying processes and mindsets that facilitate coding. He argues that traditional education and boot camps fail to teach programmers how to think critically and solve problems, focusing instead on methods and tools without fostering deep understanding. Searls suggests that programming is a philosophical activity primarily done in one's mind, and this lack of foundational skills leads to immense insecurity among developers.
To address this gap, he emphasizes the importance of creating feedback loops—both in coding practices and personal reflection—as a means to improve and refine our programming skills. Searls introduces playful concepts like the 'Searles Briggs Type Indicator', relating personality traits to programming inclinations. He encourages programmers to reflect on their actions and emotional states while coding to devise better thought processes and methodologies for problem-solving.
Key points include:
- The Ineffectiveness of Current Programming Education: Traditional structures often neglect teaching critical thinking and problem-solving skills.
- The Importance of Reflection: Analyzing one's thought processes can lead to better understanding and performance.
- Feedback Loops: Establishing personal and professional feedback mechanisms helps in ongoing development as a programmer.
- Programming as Communication: Searls describes code as a form of communication with future developers, thus advocating for clear, clean code that others can understand.
- Approach to Coding: He shares his experiences with different programming styles and encourages adapting one's thinking to mitigate fear and complexity in coding tasks.
Searls concludes by urging his audience to adopt a mindset of introspection and continual improvement to make programming practices more inclusive and accessible. The takeaway is that by understanding how we think and work as programmers, we can better convey this knowledge to others and improve collectively as an industry.
00:00:12
Hello everyone. My name is Justin Searls, and you can find me on Twitter under that same name. Feel free to call me either.
00:00:18
This is what my face looked like in 2011, and thanks to how social media branding works, I'm now stuck with it forever.
00:00:25
I work for a company called Test Double, a software agency on a mission to improve how the world writes software.
00:00:31
You can learn more about us at our URL. The title of this presentation is "How to Program," and it's a rumination on the word 'workflow.'
00:00:37
This two-part word—'work' referring to the structure and behavior of programs—will guide our discussion.
00:00:43
I often find that we reprogram our thoughts and actions throughout our programming journeys.
00:00:51
When I reflect on my experience as a computer science student, I recognize that I was taught data structures, P versus NP, big-O analysis, and cryptography.
00:00:59
However, very little attention was paid to how to think or how to work effectively as a developer.
00:01:06
Boot camps today often focus on practical skills like web standards and frameworks, but they still overlook critical thinking.
00:01:12
We may admit the role of thought leaders in the community, but they often discuss work activities, not how to think through problems.
00:01:18
As programmers, we should ask ourselves, when and how do we learn? Who teaches us how to think?
00:01:25
If you're fortunate, you might stumble upon a productivity tip during your career. Usually, it's the 20-minute work and 3-minute break technique.
00:01:35
However, it can feel a bit like gaining a $4 plastic pin after 10 years of hard service. It's somewhat insulting.
00:01:43
Still, we all learn what programs do, but I dare say most of us were never truly taught how to program.
00:01:50
Just looking at search results for 'how to program' reveals a lot of poor teaching methods.
00:01:58
The traditional method involves starting from nothing and showing a finished example, leaving students to figure it out on their own.
00:02:05
My experiences in computer science mirrored that of drawing a cartoon owl: starting with two circles and nothing more.
00:02:12
I spent entire weekends in labs, staring at blank screens, having no idea how to write code.
00:02:19
This realization led me to the conclusion that programming is largely a philosophical activity occurring in our minds.
00:02:27
In recent years, we have seen evolution in computer science education, breaking down complex ideas into manageable parts.
00:02:35
However, explanations rarely convey the necessary thinking to make concepts real.
00:02:43
It may take years to replicate an application from a book, and I believe this is an act of imitation, not learning.
00:02:50
In our profession, we are inundated with how questions, like when to create a new method.
00:02:58
Simple advice we receive, such as 'messages should be three lines long,' reflects a lack of sophistication.
00:03:05
For instance, when my wife was in first grade, her teacher told her that sentences should be two lines long.
00:03:12
She followed this guideline without question until she was corrected years later.
00:03:20
It's amusing because here we are, as adults in the programming world, with simplistic guidelines influencing our work.
00:03:29
In spite of these limitations, let's say you eventually write a great program that you're proud of.
00:03:37
If I were to ask you about the productive or unproductive actions that led to this success, could you answer?
00:03:45
Most of us would likely struggle, which leads to rampant insecurity in our profession.
00:03:54
The reality is that 99% of the work I've done as a programmer has been about transferring spreadsheets to the Internet.
00:04:02
Yet, it took me a decade to feel confident as a programmer, which indicates something is wrong with how we teach.
00:04:09
Despite this industry being around for 60-70 years, we still look for quick fixes.
00:04:15
We think the next language or framework will make programming easier, but it seldom works out.
00:04:23
When environments are chaotic and uncertain, brilliant people often thrive, while those without validation struggle.
00:04:30
Imagine walking into a room full of programmers and not fitting in; it's truly a daunting experience.
00:04:38
Unless we resolve our issues with teaching, programming remains a terrifying endeavor for many.
00:04:46
Thus, if we want to promote diversity and inclusivity in this industry, we must address how we teach programming.
00:04:54
As it stands, the industry seems disconnected from understanding how software truly works.
00:05:03
Often, it analogizes software development to construction, design, or manufacturing, which is misleading.
00:05:10
Instead, we ought to focus on understanding how we think and solve problems as software developers.
00:05:18
So, how do we begin solving this issue? By introducing feedback loops, as programmers already use them to establish progress.
00:05:27
Let’s practice reflecting on our actions in our development processes today.
00:05:36
By doing so, we can improve our performance and emotional states through introspection.
00:05:44
Spoiler alert: we can also think about our thinking in order to optimize our productivity.
00:05:50
This concept leads us to what I call 'programmer enlightenment', but we must start from scratch.
00:05:57
In team environments where emotional immaturity exists, initiating conversations about feelings can be challenging.
00:06:05
Often, we resort to ineffective personality tests, like the Myers-Briggs Type Indicator, which oversimplifies human behavior.
00:06:14
It assigns people into arbitrary categories, implying there are only 16 types.
00:06:22
In reality, we know human complexity is far greater than this system accounts for.
00:06:31
Today, I present you with the Searls-Briggs Type Indicator instead.
00:06:39
Instead of asserting that there is a singular magical way to program, I'll share my personal journey.
00:06:47
Let's use an example feature to explore my thoughts and emotions throughout my career.
00:06:56
At Test Double, we've always been a distributed company, but we're learning that distribution doesn't imply equality.
00:07:05
In a flat organization, one might expect spontaneous collaboration, but that's not always the case.
00:07:13
We've experienced times where team members want to learn new technologies and have no means to connect.
00:07:21
This sparked an idea for virtual coffee chats among team members to facilitate conversation and collaboration.
00:07:29
It's akin to a handshake problem in mathematics, which calculates the number of potential relationships within groups.
00:07:39
We discussed assigning people randomly for short 15-minute chats, with the expectation that connections would grow.
00:07:48
Let's explore my approach and the first question to ask ourselves about emotional intelligence: Are you sensitive or fearless?
00:07:56
I personally prefer hearing all requirements upfront, but that overwhelm can be daunting.
00:08:05
Complexity often paralyzes me when staring at a blank screen, leading to doubt about my skills.
00:08:13
This sensitivity affects how I approach programming projects, as I'm often nervous about the unknown.
00:08:19
I focus on creating pairs, which sounds simple, but involves a decent amount of logistical effort.
00:08:27
To overcome this, reflect on the problem, keeping the core idea in mind rather than getting overwhelmed.
00:08:36
In my past, I embodied bottom-up programming, but I’ve transitioned to a top-down approach.
00:08:44
By defining the problem at a macro level, I can keep the end goal clear, allowing for better coding decisions.
00:08:52
This perspective encourages the minimization of wasted work and the inclusion of essential guard clauses.
00:09:00
Being sensitive often feels like a double-edged sword; while it encourages caution, it can lead to paralysis.
00:09:09
The act of rushing into coding without clarity can cause overwhelm because the details feel burdensome.
00:09:17
I found myself stuck at points, unsure of what to tackle next because of the lack of decomposition in my work.
00:09:26
Transitioning to discovery testing was a game changer for me, as it helped break down larger issues into manageable tasks.
00:09:34
Working through top-level concerns and methods allows me to see progress toward project goals.
00:09:40
Next, explore the inventive versus aesthetic side of programming choices.
00:09:48
When building software, I believe it's more important to construct the right thing than simply to build well.
00:09:56
I often find myself prioritizing implementation work rather than getting caught up in beauty or neatness.
00:10:05
That said, I still strive for visually appealing code, being mindful of syntax and symmetry.
00:10:12
Consistency across coding standards is crucial, but many find it boring digging through similar code.
00:10:19
As developers, we need clarity and understanding of our craft, so we avoid stubbornness in our practices.
00:10:29
This discourse highlights a fundamental truth; aiming to comprehend programming as a communication medium can yield better results.
00:10:36
Take feedback on your code seriously; it can highlight your biases when writing for yourself instead of others.
00:10:44
After all, our audience is other developers who will read what we've produced.
00:10:52
This realization shifted my approach toward making my code more approachable and discoverable for future teams.
00:10:59
Instead of the directed graph approach, I began organizing my code in a tree structure.
00:11:07
By separating value objects and functionalities, I could keep my code clearer and actions predictable.
00:11:14
Contrast becomes clear when we explore which methods serve specific functions and clarify interactions.
00:11:22
As a minimalist, I prefer to limit clutter in my code. The clarity increases my productivity as a developer.
00:11:31
In this pursuit, I considered how styles can introduce unnecessary complexity by encouraging inconsistencies.
00:11:39
To maintain productivity, I decided to minimize those unnecessary decisions upfront.
00:11:47
This way, I avoid falling into the rabbit hole of making arbitrary choices that lead to confusion.
00:11:55
My vulnerability led to identifying how better organization can create clarity and foster collaboration.
00:12:03
The last aspect is exploring the balance between economy and thoroughness in programming practice.
00:12:11
Quickly shipping code can be a good strategy, yet it sometimes leads us to neglect thorough testing.
00:12:18
In fact, most teams would benefit from deepening their understanding of code dependencies.
00:12:26
The reality is many developers don’t fully grasp how their code interacts within larger systems.
00:12:34
Encouraging separated coding styles may lead to siloed development, which hinders teamwork.
00:12:41
Some developers gravitate towards the lowest common denominator, resulting in mediocre outcomes.
00:12:49
As programmers, we should lean into normalizing clarity in our projects, urging collaboration and deep understanding.
00:12:56
Be aware of the complexity that arrives during coding. Sharing knowledge fosters better performance across teams.
00:13:03
Earlier, I mentioned the importance of pausing to reflect on our actions to enhance programming performance.
00:13:11
This practice will lead to more insightful questions, which will help us invest in our personal growth.
00:13:17
The true key to effective programming lies in understanding ourselves—our motivations, our feelings, and our reactions.
00:13:24
As we venture into this complex field, we develop systems to help articulate new ideas and solve bigger problems.
00:13:32
Programming is more than just writing code; it's about fostering understanding, collaboration, and creativity.
00:13:40
Henceforth, I encourage all of you to reflect deeply on your unique approaches to programming.
00:13:48
Thank you so much for your presence today. If you’re seeking a company that supports self-improvement, please check out Test Double.
00:13:57
Feel free to come up and take a commemorative edition of my printed material.
00:14:05
Also, we have a Test Double sticker for you if you'd like one. Your time here has been appreciated.
Explore all talks recorded at RailsConf 2017
+105