Object-Oriented Programming

Summarized using AI

What if Clean Code is a Scam

Michał Taszycki • March 11, 2015 • Wrocław, Poland

The video titled 'What if Clean Code is a Scam' features Michał Taszycki discussing the concept of clean code and the need for critical questioning within software development practices. Taszycki challenges the acceptance of popular programming paradigms and charismatic leaders in the tech community, arguing that we should not take their opinions at face value. Key points of his talk include:

  • Questioning Authority: Emphasis on the importance of questioning the validity of popular ideas in programming, such as clean code and the opinions of influential figures like DHH (David Heinemeier Hansson).
  • Charisma and Leadership: The role of charismatic leaders in shaping beliefs and practices in the tech industry, and the tendency to follow them without questioning their views. Taszycki notes the benefits and drawbacks of being opinionated in the software development community.
  • Balancing Doubt and Certainty: His personal stance of being skeptical rather than opinionated, advocating for exploration of diverse perspectives on coding standards and practices.
  • Programming Methodologies: Mention of contrasting views within the community regarding features and practices such as Test-Driven Development (TDD), assertions, and large rewrites. He illustrates these points with references to game development practices and opinions from notable developers like Jonathan Blow and John Carmack.
  • Diversity and Perspectives in Tech: A call to investigate diversity within the tech industry and reflect on differing viewpoints. His provocative closing question about the representation of women in his talk emphasizes the need for inclusion and awareness of diverse voices.

Taszycki concludes by encouraging developers to remain curious, avoid emotional attachments to methodologies and tools, and continuously seek knowledge from a range of sources. He highlights the necessity of engaging thoughtfully with different perspectives and embracing personal growth through critical questioning.

What if Clean Code is a Scam
Michał Taszycki • March 11, 2015 • Wrocław, Poland

wroclove.rb 2015

00:00:16.000 What if clean code is a scam? Sounds radical, right? It's actually only the first sentence of the abstract of my presentation. However, it's not the most important part of it. Let me add some context to show you what I want to focus on.
00:00:25.199 The talk is about exploring the subject of how we tend to follow charismatic leaders and accept certain rules without questioning them. For instance, we might ask, 'Is clean code a scam?' but we should also question whether something will genuinely improve our code. Did I check it? Does it work for me? Maybe DHH was right, but he is also a charismatic leader.
00:01:12.880 The abstract, especially the first and last sentences, was supposed to catch your attention, and it did on Twitter. A couple of days ago, I saw a tweet quoting my abstract, which stated that I usually tend to avoid conflict but wanted to discuss what was happening. I liked that reaction; it was exactly what I was aiming for. However, the person responded with 'Thanks, but no thanks. I can do without the opinions of someone who thinks DHH is charismatic.' This response struck me as a bit unfair.
00:02:07.280 I was quite dumbfounded. As a non-native English speaker, I checked the meaning of 'charisma' multiple times to ensure I wasn't misunderstanding it. Charisma is a rare personal quality attributed to leaders that inspires devotion and enthusiasm. If that doesn't describe DHH, then I don't know who it does. But I'm not here to make fun of that person. I understand that context matters, and they were likely upset about something unrelated.
00:03:28.800 This conversation is relevant to my talk because the person didn't ask any questions. They didn't consider that perhaps my abstract was just link bait or a provocative statement to challenge conventional wisdom. That's okay; one doesn’t always have to question everything. But I do like to ask questions and want to promote that perspective.
00:04:49.800 When we talk about DHH, we can describe him in many ways, but one word I particularly like is 'opinionated.' The Rails framework he created is also opinionated, which is part of its appeal. Being opinionated comes with benefits; it helps us get things done quickly without stopping to ask too many questions.
00:05:29.760 For example, DHH has strong opinions, and others can challenge him on those. There was a situation where DHH criticized a behavior he saw on YouTube, and a manager defended it by saying, 'If you don't like it, just delete it.' Someone then pointed out that DHH had used the same argument for CoffeeScript. So, you need to be prepared to defend your opinions, but this also shows that even DHH recognizes boundaries.
00:06:18.360 I personally don’t like being opinionated. I prefer being doubtful. If I were to describe myself in terms of Dungeons and Dragons alignment, I would be either neutral good or chaotic good. I believe in surrounding myself with a diverse range of opinions and ideas, challenging myself, and stepping out of my comfort zone. I find those who are strongly opinionated to be somewhat suspicious.
00:07:13.680 I had the privilege of working in the video game industry before, and for the past several years, I've been working with Rails and its surrounding technologies at Gunpowder Labs. Yes, we do practice clean code. So, I’m not outright opposed to Uncle Bob’s ideas, at least not all of them. I also like to delve into low-level topics. For instance, I recently rediscovered Commodore 64, and I’ll even be launching some screencasts about it soon.
00:08:06.400 This all ties back to my default stance, which is to remain doubtful. However, just like being opinionated requires boundaries, so too does being doubtful. You can’t question everything, literally everything, as that wouldn’t be constructive.
00:08:49.560 Reginald Brewe, a speaker here a few years ago, captured the essence of wisdom in a tweet: 'Wisdom is figuring out which old successes are now cargo cult legacies and which old failures are brilliant disruptions.' Perhaps clean code is a cargo cult legacy, and maybe the Rails way is a new brilliant disruption. Not exactly new, but maybe it's disrupting things again.
00:09:41.240 Just half a year ago, I met Uncle Bob in Wrocław. He gave a fascinating talk titled 'Lost Years of Software Architecture.' I admire Uncle Bob and agree with many of his points. However, one moment during that talk struck me deeply. Toward the end, a young developer asked him how to manage delivering features quickly while still maintaining good development practices.
00:10:11.680 Uncle Bob didn’t really answer that question directly. Instead, he created a metaphor comparing feature delivery to a life-saving procedure by a doctor. His point was that questioning the doctor about the operation is unreasonable. The audience largely accepted that argument, but I found it concerning.
00:11:14.760 You could easily apply the same metaphor in a different scenario. For instance, if I go to a doctor for a sore throat and they want to operate on my stomach, wouldn’t I be right to question that? What if they prescribe antibiotics without examining my throat? When I was at the talk, I didn’t challenge this metaphor; I accepted it, as did many others.
00:12:08.760 My point is that we need to be cautious when we accept arguments that come from authority without questioning them. It’s essential to dig deeper and understand the reasoning behind certain opinions or arguments. I want to share some tweets and conversations from people you might not usually follow, especially from the game development industry.
00:13:00.720 For instance, there’s a tweet by Andre KDA, one of the conference organizers, who stated that if a method doesn’t fit into a tweet, it’s too long. Some might consider this opinion radical; would you agree? In Ruby, we tend to prefer smaller methods, but then again, Jonathan Blow, a renowned independent game developer, has a very different approach.
00:13:54.800 Jonathan works primarily with C++ and believes that a medium-sized file is about 2,000 lines, considering 5,000 lines to be just fine. I think his style contrasts significantly with the common Ruby approach. This clearly illustrates how coding standards can vary greatly between different domains.
00:14:12.560 Yet, my point is that when you encounter opinions like these, take the time to ask questions. Dig deeper and seek to understand why people hold their particular viewpoints. For instance, John Carmack, creator of Doom and Quake, takes a similar approach regarding code size.
00:15:12.760 He feels that files containing more than 10,000 lines of code are too large. But coding style isn’t the only aspect we can explore. Handmade Hero, started by programmer Casey Muratori, features a development project done live on Twitch, where he builds a game entirely from scratch without using engines or libraries.
00:16:01.920 He codes for an hour each day over five days a week, and it's fascinating to watch. Game developers often share pretty radical opinions, but sometimes they unearth gems of wisdom. For instance, a recent discussion sparked about naming conventions for singletons.
00:17:02.360 A suggestion was made to prefix singletons with 'the', which is indeed a clever idea. But do we have singletons in games? I hope not. I have prepared a few links that I will share after the presentation, which provide resources worth exploring. These links cover flat programming styles and shed light on the perspectives of different developers.
00:17:39.520 The first link is an article, and the second is a presentation that focuses on alternative metrics for programming. Jonathan Blow, for instance, has spent five years optimizing his programming methods to produce games more effectively. It’s intriguing to see game developers often favor functional programming as well, despite their background in low-level C programming. Carmack champions this approach as well.
00:18:43.600 Now regarding refactoring, some game developers believe that testing is a measure of the complexity involved in their projects. However, not everything should be convoluted. There is an algorithmic way to effectively refactor code without breaking existing functionality. Still, certain refactorings can be complicated, to say the least.
00:19:35.520 Jonathan Blow is currently designing a low-level programming language that aims to alleviate the complications associated with refactoring in existing languages. His goal is to create abstractions that allow for higher-level concepts without sacrificing performance.
00:20:29.680 However, let's talk about a touchy subject: the big rewrite of your codebase. DHH famously stated that big rewrites are the worst thing you can do to a project, whereas others in the game development community have conflicting opinions, asserting that they can actually work.
00:21:11.880 My suggestion is that when you encounter these conflicting opinions, take the time to dig deeper rather than dismissing them outright. Test-driven development (TDD), for instance, does have dissenters in the community, and some have convinced themselves that TDD does not scale in large projects.
00:22:09.920 Game developers often rely on assertions within their code base for quick error identification, while not emphasizing unit tests as much. Assertions can be seen as a simple way to handle validation without going through the overhead of formal testing, which some developers argue can introduce unnecessary complexity.
00:22:56.320 There’s a continual debate surrounding version control in game development. Developers using SVN sometimes face issues that they have investigated thoroughly and debated about the merits of switching to Git.
00:23:43.760 For example, when Jonathan Blow tweeted about the slowness in SVN’s delete function, he was overwhelmed by countless replies telling him to switch to Git, which shows how emotionally attached we can get to the tools we use. It’s critical to stay open-minded and challenge our methodology for the sake of improvement.
00:24:38.800 In this context, I encourage you to explore different perspectives, compile evidence, and ultimately become more informed. Avoid becoming emotionally attached to specific tools, methodologies, or charismatic opinions. Look for a wide range of viewpoints and strive to maintain a healthy curiosity.
00:25:24.400 I want you to think about a recent situation surrounding diversity in tech. There was a misunderstanding at a recent conference regarding the proper focus on diversity. People’s stances often conflict, and it’s common for different communities to reach identical conclusions from different perspectives.
00:26:26.280 I suggest that you investigate more into diversity discussions in tech. Try to read widely, from feminism to codes of conduct. Talk with others and reflect on how your opinions align with varying perspectives. Engaging thoughtfully with differences can lead to personal growth.
00:27:16.480 Before I close, let me pose a question: Did you notice how many women I referenced in my talk? In fact, there wasn’t a single one included. Now that you are aware, does it bother you? Should it? I want to leave you with food for thought, encouraging you to take those opposite ideas and consider them deeply.
00:28:20.960 Lastly, I want to share a song from a Polish rapper that resonates with the themes we discussed. While I won’t sing it for you, I believe the lyrics convey the essence of understanding diverse perspectives and questioning our own views.
00:29:37.920 [Lyrics perform by the artist]
Explore all talks recorded at wroclove.rb 2015
+6