For this, our final task, please reflect upon your experience. Consider flipping back through the older threads to refresh your memory of the exercises.
When you do, please share what arises on this forum thread (or via email, if you prefer).
Constructive criticism, observations, ideas for the next cohort, key takeaways, and questions are all welcome.
I truly enjoyed running this course for all of you. Thanks so much for your feedback, and especially your enthusiasm. Your excitement was contagious, and made the work of producing the course feel light.
As promised, for those of you who committed to the challenge by participating in the forum and doing the daily tasks, here is a link to get a free Tuple swag item!
Thanks again for being part of this. This 30-day challenge is over, but let’s stay in touch. I’m @r00k on Twitter, and if you would like to know more about my company, Tuple, you can check us out here.
I loved the copy-pastable unix-y snippets! Things like find app lib -name "*.rb" | xargs wc -l | sort -rn | head, or unused --only-filetypes rb, or ag '\(.*,.*,.*,.*\)', or the git-churn snippet. People even chimed in with more cool commands like @julianrubisch with bundle exec derailed bundle:mem.
I am curious what other unix-y commands people here use to measure a codebase. For example one of the first things I do when assessing a new Rails app is cloc app config lib spec and/or rails stats.
Finally people posted some great reading suggestions like https://fs.blog/mental-models that I totally didn’t know about. I am curious what other books or articles this community enjoyed reading.
This has been a great experience. Thanks for doing this.
The 30 days a 20 minutes format is exactly right for forming a habit that helps give some steadiness in these insecure times. I appreciate the effort you folks (and I meen the tuple team and the cohort) put into this.
here are two direct, measurable outcomes for me
I got to know my editor a lot better. That’s something I always defer to later…
Some of my open source contributions, first and foremost StimulusReflex got a lot cleaner, which helps maintainers as well as onboarding new contributors.
I see myself returning to this forum a lot in the future, maybe even setting up recurring calendar items, to keep this in my work cycle.
Also, it got me thinking if I could set up a similar-minded challenge for the StimulusReflex crowd
This was a great experience! Even I wasn’t as active on the forum as I would like to due to being stretched across multiple projects.
@ben and @dorothy I can’t appreciate your efforts enough! I’m very thankful to you guys for running CQC.
My best takeaway bin/setup script that I finally completed along with meaningful db seeds so every developer (I hope) can now go zero-to-be-productive in one command.
But at the end of the day it took way more than 20 minutes
it’s worth to invest some time on a daily basis to build a good habit, that makes you more productive overtime and helps to write code of a higher-quality.
sharing experience in a forum environment increases motivation and outcome, sharing a small detail may help someone else, so it’s a multiplier.
It was fun! Can’t believe it’s been 30 days already now!
The little challenges were nice conversations starters as well. Even when you’re not sticking to a 30 day consecutive exercise. But I’m sure I’ll bring the occasional challenge from here to the teams I’m working with every now and then. Thank you for the inspiration!
And thank you very much @dorothy and @ben for organising and running it this month!
This was my first year taking part in the CQC and I couldn’t be happier. I learned a lot and realized just how impactful spending 20min daily on code quality improvements can be over time. Thanks, @dorothy & @ben for putting this together. See you next year!
This has been a great reflection on quality. My takeaway is that a series of small improvements
can refresh how I’m looking at the code, and have a positive impact on my team. Details matter.
Thank you to everyone who contributed, and to @ben and @dorothy for facilitating.
This is my second time through, and it was still great! Even with the repeat tasks there was still value. For example even when there was already a good readme, there was often something worthwhile to add or update. Even if the code hasn’t changed, sometimes the context around projects have.
As I said on one of the earlier days: taking time to work on a project with perspectives other than implementing a feature is so valuable. I’ve made a bunch of projects better for my future self and my partner. And a few days prompted interesting discussions within my team about our style or process.
Last year the themes in CQC inspired me to add themes to my months. When I’m working on strategic maintenance I now rotate through these perspectives: Documentation, Testing, Automation, Performance, Infrastructure, Dependencies, Dead-Code-Culling. Great when I can have all of these in mind when working on a feature, but also good to just go wandering around with one of those perspectives in mind, as we have done this month.
I want to thank everyone for the positive and constructive attitudes. The lack of drama was nice. And thank you @ben and @dorothy for organizing! Hope to see you here again next year.
Thanks Ben and Dorothy for organising and managing this challenge! There were a lot of great topics but the one that stuck with me was lesson 8: extract a compound conditional. It’s one of those thing you see and think why on earth haven’t I been doing it like that. Also lesson 24 is has a gem of a command for displaying most frequently changed files.
Not sure what could be done to make this challenge better. I also enjoy this forum software a lot. Works great. Keep up the great work, and thanks a lot for the free Tuple swag!
Day 30, we’re here! This is the second time that I’ve signed up for the CQC. I work in a different team now than I did last time, so it’s been nice to go through the tasks with some new projects to help tidy.
Personally I love the little nudges each day to do a small task, rather than one big list of things to work through. It also helps to build up the habit of taking the time to improve the projects I work on.
I’m not sure if it’s possible to change the timings of the emails being sent out? For me, they usually arrived towards the end of the day. It’s definitely not a big deal, and just meant that I had a sneak peak at what I would be doing the next day.
Thank you Ben and Dorothy for developing and managing this great method. Our whole dev team participated in this cohort and I have seen the fruits of it already in code pairing sessions:
“Do you think this method has too many parameters?”
“Can we brake this up in modules?”
“I’m not 100% happy with the name of this variable. What would you call it?”
etc.
So, a real culture change for the better. So thankful.
It was a really great experience, For me, it was something that pushed me to do things which I always procrastinated on. Hope I get the habit of it and fix my code before I need to refactor it.
I haven’t been great about posting here with a daily update, but I’ve been doing these with a newer employee as a pairing exercise and we’ve had some great conversations. I’ve heard the code quality thoughts come out more in his daily work, so entirely worth the investment in time.
