00:00:11.430
Sylvain Abélard now.
00:00:19.220
Once all that lettuce, hi! I'm going to talk about messy humans and clean code.
00:00:25.250
This talk is mostly based on my own story because it's the one I know best. The problem is that change is hard, and during our journey to learning code, we encounter many pieces of knowledge that are actually dangerous.
00:00:33.290
So how can we avoid some of the pitfalls that I felt were easy to fall into, and what inspiration can we draw from this to both address our current problems and help beginners avoid these traps?
00:00:40.790
I'm French, and between the ages of 15 and 18, you have to choose one of three main branches of French education. ES is for business, which I didn't like. L is for literature, which I loved, but the problem is, if you annoy your teacher or have a problem with them, they could give you bad marks for no reason. I was quite pedantic and had a strong personality, so literature was not the right fit for me. I chose the S branch for science, which I also loved, and this eventually led me to learn coding.
00:01:07.430
At 18, I started learning to code, and it was pretty fun, but I knew nothing. As a beginner, what can you do to improve? Some easy ways are to rely on certain principles or to find quotes from people you admire. Sometimes teachers share these quotes, and you find them amusing. However, some of these quotes might actually be jokes, which is a problem because you might think they will help you code better, but they turn out to be useless principles.
00:01:30.129
If you take these quotes seriously, you may be disappointed later. Also, when you're young and inexperienced, it's challenging to fit everything into one brain; you don't have much experience, and you have to take little steps, one at a time. My approach was that, as a know-it-all brat, I didn't want to think; I just wanted answers. Of course, as time passed, I found that I rarely had the answers.
00:01:57.230
I appreciate the help I offered to beginners, but I often started with, 'It depends,' followed by a long story. Change is hard. Luckily, some people have paved the way for us. We first experience denial, then anger, followed by bargaining, and hopefully not too long in depression before reaching acceptance.
00:02:11.280
I chose coding because it was clean, logical, rational, and scientific—it felt perfect. In contrast, humans are irrational, and they often break things, which can be painful to understand and communicate about. However, I realized that even the best code could break, and that fallible humans can create amazing organizations with fantastic results.
00:02:43.360
What's the takeaway from this? It is about learning forgiveness, like Olivia mentioned in her talk. You can forgive the code for being bad and find ways around it. If humans are so outstanding at this, it’s because we derive reliability from the unreliable.
00:03:01.100
In life, I recognize that tomorrow I may have difficulty getting out of bed because I'm just too tired—or whatever reason. Therefore, if we approach processes understanding that anything can happen and build in fallback mechanisms, outcomes can improve significantly.
00:03:29.340
Initially, I thought I could just create very clean code with clever one-liners to showcase how smart I was. But after writing my concise calculator application, my elegant code expanded into pages and pages of error management, which I found inelegant.
00:03:52.420
This experience was one of many manifestations of privilege. I could afford to write very short and clever code because there was someone else managing error handling and fallback processes. I mistakenly assumed nobody would enter an invalid calculation, but of course, people can—and they did. I realized I couldn't blame the world for not accommodating my code; I had to adjust my code to fit the world.
00:04:18.489
The answer, I think, lies in user experience. It's okay to use metaphors when teaching coding to beginners. Finding a metaphor that you can reuse repeatedly helps simplify complex ideas.
00:04:38.100
We use metaphors to explain concepts, but once a metaphor becomes misleading, it's important to specify its limits. Over ten years of coding, I found two principles to be invaluable.
00:04:59.870
The first principle is 'YAGNI': You ain't gonna need it. It serves as a reminder that just because you can spend months coding something, it doesn't mean you need to. The second is 'KISS': Keep it simple, sometimes even stupid. Whenever I aimed to keep things very simple, I never faced issues. Thank you, Lucas, for discussing this.
00:05:30.860
These principles helped me achieve better code while still presenting challenges. The first is DRY: don't repeat yourself. The second principle, prevalent in early days, was to have skinny controllers and fat models.
00:05:58.790
Yet, I encountered advice at school that proved harmful. Often teachers suggested using design patterns blindly, leading to convoluted designs. We tried to map the patterns to the world instead of adapting the world to our code.
00:06:30.420
Design patterns should not dictate how to write your code; they should rather serve as guidelines. Understanding them correctly is crucial, as many principles can lead to dangerous misinterpretations.
00:06:57.960
I once misinterpreted principles like YAGNI and KISS. While they sound great, simply adhering to them isn’t always right. Instead, planning appropriately is more beneficial.
00:07:18.840
Drifting from established comforts can be challenging, and I discovered the importance of evolving my coding practices. It made me realize that many design patterns are language-dependent. When transitioning from C++ or Java to Ruby, you might find certain design patterns simplify significantly.
00:07:41.260
After uncovering the correct interpretations of design patterns and advancing from C++ to Ruby, I realized many design patterns greatly depend on the language in use. Best practices are not one-size-fits-all and can change dramatically based on language context.
00:08:02.509
I questioned what best practices truly entail. Often, they seem to equate to someone telling you, 'Just accept what I say—I won’t explain further.' Meritocracy, often misconstrued, can uphold the status quo and discourage questioning.
00:08:33.250
Consider this: principles are merely guidelines, not absolute rules. They should be employed as tools to become slightly better rather than something to exhaustively chase perfection over.
00:09:05.520
When coaching absolute beginners, whether at Rails or during any event, I like to suggest focusing on incremental improvement each day, rather than attempting to cover entire books at once.
00:09:38.230
When developing my skills, I found inspiration in diverse sources. Quotes like 'premature optimization is the root of all evil' resonated with me profoundly. However, I later discovered the second part of that quote: 'premature generalization is the other root of all evil.'
00:09:56.490
In my process of learning, I valued the classics, such as Kent Beck’s 'Make it run, make it right, make it fast.' If you run into issues with speed, benchmark first; optimize the parts that need focus.
00:10:20.999
I often misidentified certain quotes as guidance. However, I learned that many turned out to be jokes, memorable yet misleading. These jokes are effective in arguments but can detract from real mastery.
00:10:41.040
When we discard useless jargon, we start questioning programming languages within cultures that indulge in sarcasm. Upon reflection, I realized how dazzling it can be to navigate exclusive languages or principles in software development discussions.
00:11:06.060
I recommend beginners and mentors hold onto those memorable quotes. Store them in a draft, revisiting them later for reflection. Instead of merely accepting these quotes, assess their validity over time.
00:11:29.300
There are as many interpretations of simplicity as there are developers. It's enriching to explore varying opinions on what simplicity means in the coding community.
00:11:55.840
You'll find many popular quotes around the notion of 'failing fast.' Trending advice pushes developers and entrepreneurs toward rapid iterations. Yet, it's essential to consider the implications of failure, especially in high-risk environments.
00:12:21.180
While failure can provide valuable insights, remember that failure in a car or pivotal designs can have severe consequences. Failing fast in coding relies on obtaining solid feedback without chaos.
00:12:44.040
As managers, your responsibility lies in seeking frequent feedback. If you're coding, peer review what you’ve written meticulously to substantiate coding integrity and correctness.
00:13:09.490
For software architects, the goal is not to direct towards failure but to ensure your architecture remains viable and sound. Utilize tools such as testing frameworks to validate your implementations.
00:13:36.630
I can attest that maintaining a light-hearted approach and not taking oneself too seriously fosters a collaborative environment. In software, reassure your team: 'It's no big deal; no one will die because of your code.'
00:14:00.580
It’s important to bear in mind that software development can indeed have life-or-death consequences. From space missions to medical technology that can harm patients, a creator's role entails responsibility.
00:14:26.960
Casually dismissing stress with 'it's no big deal' is misleading. Instead, take a moment, breathe, and realize that the little details matter profoundly in software design.
00:14:49.290
In many cases, adhering to lower and upper bounds while coding can alleviate risks. Be cautious with floating point arithmetic and ensure that you're mindful when dealing with significant computations.
00:15:19.000
In finishing this thought, I presented a humorous yet cautionary note: make sure to evaluate your actions before proceeding, even when making decisions that seem trivial.
00:15:38.750
When all principles are set aside and you’ve begun searching for guidelines, take note of various useful acronyms, the most known being SOLID. However, every letter in SOLID can lead to misinterpretation.
00:16:06.230
In the Rails community, grasping UML or EIP might be overwhelming, so refrain from succumbing to the complexity. Remember; the goal is clarity.
00:16:29.520
It’s essential not to become lost in the search for truth and guidance amidst complexities. Instead, commence from the understanding of why particular software engineering practices were established.
00:16:57.990
Ultimately, the essence of good coding practices lies in asking questions. Recognize when to act, but also when to slow down and search for the right resources.
00:17:24.490
Coding demands thoughtful reflection. My advice is to consider what habits produce effective results in your workflow and observe those guiding principles before reinventing practices.
00:17:49.690
With coding, one must embrace established patterns but also adapt them to their practice. Find comfort in thinkers who encourage contemplation while solving complex problems.
00:18:14.550
After developing coding skills for several years, I've come to appreciate various perspectives on coding styles. Ideas surrounding Zen principles often do not insist on 'right or wrong' but rather focus on fostering inquiry.
00:18:35.030
As I traverse through programming logs and community discussions, I've encountered 'the Zen of duck typing' emphasizing flexibility and adaptability amidst coding standards.
00:19:00.140
Supplementing this, the 'Zen of Python' presents 20 guiding principles that can be beneficial to beginners without overwhelming them with intricacies.
00:19:25.400
I've also explored amusing tales such as ‘Code Less Code,’ weaving narratives of Buddhist monks engaging in Java programming—offering a fresh perspective surrounding best practices.
00:19:51.830
What I’ve taken from the plethora of writing featuring Zen is the invitation to engage with paradoxes—fostering a mindset of conscious awareness when making decisions.
00:20:16.930
Reflections on DRY (Don’t Repeat Yourself) can invoke challenges when attempted vigorously. While it’s prudent to avoid repetition, genuine information exchange often necessitates healthy duplication.
00:20:41.450
In practice, messages must emerge naturally. Rely on historical data while ensuring accurate logging patterns; these foster effective communication and collaboration.
00:21:04.360
Ensure that as you navigate through varied team dynamics, you simulate coding experiences across different applications. This increases collaboration and improves outcomes.
00:21:28.769
This leads to cultivating habits that yield fruitful results over time. Acknowledge that logs, development flags, and feature toggles will vastly elevate your productivity.
00:21:52.820
I emphasize that you should never avoid capturing critical information about your coding practices; continuous improvement should remain a fundamental principle.
00:22:14.450
One impactful design pattern I wasn't taught at school leads to efficiency checks. A circuit breaker pattern tracks attempts, discouraging repeated ineffective methods.
00:22:39.140
Its functionality logs attempts and manages failures. In settings where responses are numerous, this method ensures safety and streamlines the evaluation of coding effectiveness.
00:23:09.110
Through collaborative work, I was astonished by the competence displayed by peers while driving. Yet, the realization that human error can lead to fatalities is concerning.
00:23:33.350
My grandfather would say to communicate effectively, illustrating your plans to others will bolster accountability. By maintaining clear communication, you cultivate trust and transparency.
00:23:55.500
Furthermore, fostering a culture of constructive feedback benefits everyone involved. Distinctively, we should practice verifying coworkers’ plans—ensuring clarity at all stages.
00:24:15.750
One illuminating truth I’ve experienced is that logging practices substantially enhance performance insights. This approach is crucial for informing team members on iterative improvements.
00:24:45.240
Each team's awareness surrounding processes will help define positive outcomes and diminish negative patterns. Performance optimizations highlight the importance of focused efforts.
00:25:06.360
Through my coding experience moving toward optimization, I learned that often the solution lies in doing less, encouraging simplicity rather than complex designs or systems.
00:25:26.020
Behaviorally, ensuring efficiency remains pertinent. Remind yourself to focus on a single task at a time while maintaining productivity across an evolving workplace.
00:25:44.540
When faced with the dilemma of managing many projects simultaneously, it's more efficient to spread tasks across different timelines, settling each completion stage through smaller iterative efforts.
00:26:03.160
As we navigate competitive coding environments, preventing burnout remains critical. Comprehending how stress levels influence workflows will assist in ensuring quality outputs.
00:26:20.270
It’s wise to recognize indicators of growth opportunities; scalability often reflects product quality and user experience.
00:26:38.800
Throughout my journeys, I’ve valued bonds built with teams despite a growing organization. Working in larger capacities while managing code can be complex.
00:27:01.510
As I developed my skill set over several years, I found wisdom in merging practical experiences with gained insights. Transitioning perspectives cultivates resilience throughout the coding journey.
00:27:22.650
As my coding practices diversified, I uncovered resonating principles originating from those within proximity—notably the significance of interconnectedness.
00:27:40.200
Prominent figures advance coding ideologies catalyzing acceptance of ambiguous interpretations. These insights lay the groundwork for embracing uncertainty productively.
00:27:56.680
Ultimately, self-awareness emerges through challenges, leading to proactive solutions. Enabling others to improve requires showing them paths interestingly.
00:28:13.470
As my journey concludes, the encouragement to improve daily serves as a lasting maxim. Learning to embrace both challenges and joys will yield progress, both personally and professionally.
00:28:30.410
Remember, always be mindful of biases that shape your perspective. The subtle belief in your opinions can create unyielding attachments; remain open.
00:28:46.830
The traps are often easiest to fall into when you ignore voices and remain ensnared within complacency. Thank you for paying attention.
00:29:01.140
I invite your questions now.
00:29:16.750
Regarding my work experience, have I published a book or more? No, I haven’t published anything yet.
00:29:49.610
Perhaps I should consider it.
00:30:06.050
Thank you for your interest.
00:30:30.400
I want to express my gratitude towards Sylvain for co-organizing the Paris.rb Meetup. Our collaboration has been fruitful since 2011.
00:30:50.980
I appreciate the support and partnership throughout these years.
