Ruby Video
Talks
Speakers
Events
Topics
Leaderboard
Sign in
Talks
Speakers
Events
Topics
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
By, Justin Searls You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff! But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem. But doubt lingers: what if they're right? After all, the more thought we put into a bit of code, the more information that code carries. Others must extract that embedded meaning, either by careful reading or shared experience. Sometimes boring code is better. Let's figure out when to be dull.
Date
Summary
Markdown supported
The video titled "Sometimes a Controller is Just a Controller" by Justin Searls at RailsConf 2015 explores the dichotomy between complex and simple code, emphasizing the importance of clarity in programming. Searls discusses how developers often fall into the trap of writing clever, convoluted code that may impress but ultimately complicates understanding for teammates. Key Points Discussed: - **Complex vs. Boring Code**: Searls illustrates the contrast between impressive code and straightforward, boring code. He argues that while complex code might look attractive, it is often less readable and maintainable. - **Investment in Presentation**: The speaker reflects on the time spent on crafting his presentation slides, highlighting the importance of clear communication, akin to writing good code. He notes that while he aims to impress with his slides, the ultimate goal is to convey his ideas effectively. - **Understanding Good Code**: He posits that good code is characterized by two main attributes: it performs a function and communicates its intent. While functionality is easily measurable, effective communication is subjective and varies per audience. - **Self-Doubt and Evaluation**: There is an exploration of how self-doubt affects programmers. Many developers question the quality of their code, often feeling insecure compared to others. This can lead to difficulties in team dynamics and code quality evaluation. - **Empathy in Team Settings**: Searls emphasizes the need for empathy among team members to bridge gaps in coding styles and preferences. By understanding each other's approaches, teams can achieve better collaboration. - **Culture Fit and Monocultures**: He discusses the dynamics of "culture fit" in teams. While teams with similar coding styles may work faster, this can lead to blind spots and lack of innovation. A diverse team that engages in differing perspectives might be slower but is likely to create a more robust codebase. - **Indirection Analysis**: Lastly, Searls proposes a concept called "indirection analysis," which seeks to evaluate how well code communicates, considering aspects such as the number of dependencies and complexity of code paths. Conclusions and Takeaways: - There is no universally accepted definition of good code; rather, it is context-dependent. - Simple, clear code is often more effective than complex solutions, fostering better understanding and collaboration among developers. - Cultivating empathy and open communication within teams can enhance code quality and team morale. - Acknowledging that personal insecurities can impact coding practices helps to create a more supportive working environment.
Suggest modifications
Cancel