Видео

please consider moving your coaching advertisement to a different point of the video next time. I respect you putting the advertisement in your free video, and I thankful for the content, but the abrupt cut to the advertisement middle speech was very disruptive. thank you

Great video! Thank you 🙏

When that test failed I would have rolled back (too dogmatic perhaps); you chose to self correct.

Very well explained, excellent communication skils and excellent technical content.

Very clean example, thank you! The pattern then would be: Refactor-Red-Green where this video stops right before turning the test Red which will then turn green very quickly, correct? If I may ask, why not write a failing test first? This could help maintain some focus on what you are trying to make working. You can still do the preparatory refactoring to turn it green. Maybe the TDD in the title is what is throwing me off though.

Preparatory refactoring is the secret power of TDD. I think it’s the bit newcomers miss, which leads them to think it’s just “write some tests”. Took me a while to stop breaking existing functionality when working on the next stage of development; TDD’s refactor step was a great lesson.

Super!

As a hobbyist, I really appreciate the free training!

Great demo, bad title. This is Java, not C#.

not gonna lie, the last part of inline variables after refactoring was pretty cool

So good!

Great video Emily :)

Hello dear, Thank you for sharing your insights. While I agree that LLMs are not traditional refactoring tools, I'm not entirely convinced that there's a point to prove here. As a fan of refactoring tools myself, I view Copilot as an incredibly powerful assistant in this realm. For instance, here are several ways LLMs can support refactoring of a huge unmaintable god class : 1. Class Analysis: They can suggest improvements by analyzing the structure of your code. 2. Unit Test Generation: Rapidly create tests to ensure existing functionality remains intact. 3. Work Breakdown: Help plan refactoring by breaking down tasks into manageable steps. 4. Assisted Refactoring: Offer code modifications aligned with best practices. 5. Automated Review: Ensure code adheres to standards and identify potential issues. LLMs can significantly enhance the refactoring process, acting as an advanced assistant rather than a traditional tool. LLM changed the game here, refactoring time on such classes is reduced from weeks to days, with increased quality and higher confidence than never before. I get the sense that you might not have explored LLMs in this capacity yet. It could be an interesting opportunity to see how they might enhance your work.

Thank you for this! Finally a description of mocks that doesn't mischaracterize the technique. Great job in describing it in relatively basic terms!

Thanks Emily, I love it! In Python I use Doublex a lot and it's a life saver if you work with Doubles (Stubs, Spies and Mocks), I'll give it a try to the kata!.

Both the demo and the explanations are excellent! Thank you.

Love this ❤

Please, keep doing Python katas if you can <3 agg I wish you had presentation mode ON

Nice refactoring video, but wouldn't it be cleaner to store the lookupTable into an static attribute which is built only once? Why building this table each time you call the getScore method?

I would recommend to throw the error if it does not contains the normalizedPoints and return without the else if (!lookup.containsKey(normalizedPoints) throw new IllegalArgumentException("Invalid score."); return lookup.get(normalizedPoints);

I would have removed the unnecessary else as well. :) Thank you for your great videos!

A few good names go a long way! Thanks :)

Haha!

Awesome video, thanks!

FizzBuzz implementation in incomplete or am I tripping? good video BTW

All the tenets of continuous delivery should be applied to continuous learning and development, which makes the argument for having a great technical coach on hand.

Nice video. This reminds me a lot of the 5 or 6 steps in the Dreyfus module of skills acquisition from the 60s.

Thanks.

I loved that you used the Rubik's Cube as the example. It also got me to think about how something like the commutators technique fits into this model. I do remember learning to solve the Rubiks cube, and it really frustrated me that if I wasn't practicing for a while I would forget one of the moves. At some point I learned a trick where you take 2 moves with certain properties and combine them by applying both and then applying both again but in reverse order. The two moves being combined are simple enough that anyone can figure it out by themselves, and once you know this trick you can basically figure out a solution for any twisty puzzle yourself. What I found interesting is that the deeper understanding of how moves are constructed allowed me to move through the stages faster. I think this is similar to how knowing the rules or practices can help you acquire a skill, but when you have the theoretical understanding you can often accelerate the learning process.

Hi Emily, I loved the model and your arguments! I do see the value of having a technical coach. But I'm still interested in finding how we can teach mob programming and TDD without technical coaches that are highly available. I think it's possible!

I didn't like the video the analogy doesn't work in my opinion. I'm talking as a 15years of experienced profesionnal developper who also solves rubik's cube. About the video: it's 11minute long and at the 3 minute mark you had basically said nothing, repeated 3-4 times what you intended to do in the video yet still hadn't. I almost stopped there, but I was really curious about the title so I kept going. I feel like the only goal of the whole argument is to justify that "you need someone to coach you in learning a new skills", I'm willing to bet you sell coaching/mentoring. The title states "From Rubik’s Cube to Code: A Step-by-Step Guide to TDD Skill Mastery" but nothing in the video is about TDD, it's all about a method of learning a new skills, I don't know how good this method is, it feels very broad and generic in my opinion but like I said I don't know. Maybe a title like "The Hartman method to learn a new skill: applied to learning the rubik's cube" would be more honest. A bit about my personal experience (which will not apply to everyone I know), I learned the rubik's cube on my own when I was ~10 and I developed my own method to solve it, no need for any mentor, noone needed to help me, the only thing that was required was practice and logical thinking. I'm fairly certain that writing code using any method, TDD or otherwise, is the same, it's mostly practice, no need for a mentor, you need to get your hand dirty and do it, and figure it out. Paying a mentor is basically giving money to someone to look at you while doing it.

It's been a long time since I solved a Rubik's cube. Must have been last century. But I did do some TDD recently :)

I can see where the Hartman Model will help me plan training for others outside of coding. Great reference.

Really nice explanation!

I so love how you use the Rubik cube to demo my skill acquisition model! I am humbled that it had a lightbulb moment for you to apply to your work 💜

Wait, I practice TDD but I'm too dumb for Rubiks Cube. Would you like to tell me anything? 😂 I got you on LI!!!

Awsome! Thank you for another very usefull video!

I was working this morning on preparing a workshop on refactoring the kata for theatre actors and I was just listing the techniques you use, Emily. And I'm eating, thinking I'm going to watch her latest video and then I see that you're explaining one of these techniques - variable cutting - what a coincidence!

Thanks to do it in java too with intellij, I struggled to find some non equivalency you shown previously with rider. It's weird to see intellij does not automatically update the visibility to protected when pushing down the getSpeed method and force to solve it in this conflict view (not very user friendly imho), then relaunch again the refactoring to make it works :/

Hello Emily. First of all, thank you for bringing attention to this area of software development. Technical coaching is a vital component of the competency of software developers. I experienced first-hand in the past how this type of training elevated my productivity and that of my teammates. But before a problem can be solved, one must know it exists. In your encounters with HR and other decision-makers, is there an awareness that technical coaching is a thing of immense value? Have you encountered resistance from software developers themselves to the mindset shift required to make this engagement successful? Software developers are generally expected to learn independently - rightly or wrongly, and I do say wrongly. Most other professional disciplines acknowledge the need to upskill their talent and prioritize time and resources. So, how do we change this perspective and thus elevate the value proposition of onboarding a technical coach? Thanks

I was listening to the original conversation just yesterday and was thinking during that particular exchange that it might be a great opportunity for you two to pair/ensemble on an example to provide more clarity. I’d love to see that, but this definitely helped provide me with more insight. Thanks!

Is that "NN usages" provided by a standard IntelliJ plugin? Thanks

This is very insightful ❤

Thanks for stepping through the process of solving a Kata. I came to Cyber-Dojo from Exercism, and was confused by the hiker files that had nothing to do with the problem description. Why they don't have a video on how to use the platform is beyond me. That said, since the student is writing their own tests, there is no guarantee that they solved the problem correctly, and covered all the use cases in the problem description. One can leave the initial hiker files in there, change the answer to 6 * 7, and call it good. If this is indeed the case, the session is only as good as the student's skills, which seems to be orthogonal to the goal of this platform.

- "How the heck did this code become this messy and long?" - "One if-statement at a time."

Great video, I learned something again. Just a technical remark, I found it quite distracting that you micis in the frame with your face, would look much better it it was hidden

Legacy Code.... brrrrr.... :D

agree, pull request are not a right way to review code. But sitting with a whole team infront of a big screen once a month for a few hours and then go deeply into the code. Not to review juniors code especialy. But giving tips can never be wrong. But more about explaining design decisions and start discussions

We do code reviews for everything. Haven't had a bad experience so far. Seems like a company culture problem. We usually work in very small teams, often enough just 2 people. So it's pretty standard that even a junior reviews the CTO. Haven't encountered any ego problems, yet. If your company has toxic people, maybe start working on that or look for a different job.

Lest not forget that we're dealing here with enlarged egos and programmer divas most of the time, rendering all these "techniques" and "suggestions" useless.