philippebourgau

I love that you suggest that adults can still learn as children! There is a lot I can relate to in your post.

Regarding learning and teaching:
- I noticed too that having a TODO list / mapor a mikado-method graph while pairing helps people to understand and 'feel' this way of working.
- With fellow colleagues, also we noticed that Code Katas in TCR forces people into doing nanosteps, which with enough practice, leads to chunking.

Another thing we have noticed is that chunking can also happen in a mob! As the team chunks refactoring steps, the 'smart driver' of the strong-style pairing can take over more and more work, leaving the rest of the mob to focus only on high-level design issues! (I wrote about this in 3 compounding benefits of mob programming that make it cost-effective

Finally, I definitely agree that Deliberate practice leads to confidence, less resistance and better results. I'd also add that it leads to calmer and safer lives, something I believe too many of us programmers struggle with!

Thanks for your insightful post. I'll definitely look into your micro-katas, I've got the intuition they would be very well suited for effective gamification!

1 reply

jbrains

I haven't practised TCR much, mostly because I did something similar in the mid-2000s which, I believe, gave me similar benefits. Maybe I'm merely too old and I like my way more. :)

Indeed, chunking happens during ensemble programming and maybe even more effectively, because more people spend more time reflecting and allowing ideas to move from System 2 to System 1. Moreover, the "intelligent input device" approach encourages programmers to articulate what they're thinking as a summary, rather than merely translating from the picture in their head into detailed text in an editor. This articulation provides opportunities to practise that lead to chunking.

Thanks for visiting! It's nice to hear from you.

1 reply

philippebourgau

Thanks!

DirkSteinkamp

I love you bring in chunking as a main idea here. Your suggestions focus on the relevance chunking plays in developing the ability of refactoring.
I'd like to add the perspective of using chunking as one key driver in envisioning the desired output of many (yet not all) refactorings: in legacy code the first thing I encounter is usually a mixture of various levels of abstractions in one intermingled piece of code: from low-level bit-wise checks of something to broader steps. My goal then is to transform it into chunks that live on the same level of abstraction, so lets say a method is then reduced to an expression of a line of thought that can be easily understood at the first glance (max. 7+-2 chunks of steps, following the famous article on the magical number seven -- yet preferably much less, like 2 or 3). And the first thing to do often is extract method. Achieving this usually tells me when to call my first iteration of refactoring done, and move on to some other code.
Quite some other refactorings for me might make me do all sorts of tricks but in the end they serve the same purpose: producing chunks of code easier to grasp. Even refactorings like "replace branching with inheritance" follow the same goal for me: create resulting code that is properly chunked in the key expression of e.g. an algorithm.
Well ... at least that's my current state of evolution in my learning of refactoring ;-) ... I'm curious what will emerge for me the more experience I gain.
Usually I'm already happy when the parts of code with the highest level of abstraction get some proper chunking level. I might go down one or two more levels and refactor there, too. But often I leave less-than-perfect-code on "lower levels" for the next boy scout visiting the camp ground another time (which might be me ;-)...).

1 reply

jbrains

Indeed, we have an example of self-similarity: the chunking process that helps us understand the code also helps us improve our refactoring skills. Abstractions help us chunk as we understand the design of the system. Patterns like Composed Method leading to Template Method often help us by allowing us to focus on smaller parts of the system at once, even at every level of abstraction of the system, from the entry point to the lowest-level libraries. As I've written before, many programmers think that they want less abstraction, when truly they are objection to indirection without abstraction. With strong abstraction, we hide irrelevant details and draw attention to what matters. Now I would say that this works because it helps us to chunk.

Now some new central questions emerge: How do we notice the difference between (mere) indirection and abstraction? What do we mean by "relevant" and "irrelevant" details? How do we behave when our judgments about relevance change?

1 reply

DirkSteinkamp

Finding the "right" level of abstraction probably is in a constant state of flux -- depending on experience with the technical system, the domain one is working in and the vision where the project might go.
I usually struggle when I'm confronted with abstractions that make the learning curve too steep to quickly get a foot on the ground when new to the system. I'm happy if I find a system (let's say a library) that makes implementing mundane simple tasks easy, so I can assess if it's a good fit for my requirements without spending weeks, and allowing me to gradually learn how the system works, and then move forward to look behind the scenes, and tap into the power of whatever the system is presenting, if I need more power.
If I'm building abstractions myself it helps to have the other people on the project in mind, and ask myself how I can make their life easier. I recently had the situation with a little team of 2 java newbies (who actually were participants in a running seminar I was facilitating in the department), and we were asked to implement a webservice that should get fetch some data out of a database in a flexible manner. Interesting enough the deadline was way ahead of time - our seminar had barely touched JEE, and we had not explored JPA. JPA was somewhat what others in the company considered the way to go, but I felt it to compromise our project success if we need to scrape our data together in an SQL tool first, then translate it by the "human brain transpiler" into JPQL (or even criteria api), find some mistake there, go back and forth between it ... and stumble and fall.
And we also had the requirement to be able to add flexible where-conditions to our queries.
We ended up being quite pragmatic: inventing our own little framework that simply takes a single sql from a file, does some primitive "parsing" to split it into SELECT/FROM/WHERE/... parts. Having this adding any flexible conditions can be hidden behind the abstraction that modifies the WHERE-clause, and we also have an automatic mapping of the database-values to pojos (TOs). Besides that we integrated getting data from another data sources (a DMS), and created a mechanism that adds in data from other tables or data sources if we explicitly tell it to (thus reversing the JPA-idea of automatically fetching a whole object graph, dealing with lazy fetching, etc.).
The SQLs can easily be executed for exploratory purposes in the db-tool of your choice (or even in the IDE), and are nicely separated and maintainable.
It resulted in a kind of cookie-cutter-architecture, and my two java newbies could focus on the business requirements, while I was more in the role of the "tool maker" -- whenever a new requirement arose that couldn't be handled with our current framework it was my job to make adjustments that would enable it to make handling such a requirement easy.
I sometimes felt a little bad about it, as I feared the two newbies would get too little exposure to the java jungle to learn enough, but the resulting system was ready for production in a short amount of time, and the frustration level for the newbies was minimal. Having "abstracted away" many repetitive details also allowed us to easily change certain things in a single location, and even to optimize some slow requests for performance quite easily.
In the end I was quite happy with our approach -- and I'm thinking about retrofitting another project to use this approach, too. I somewhat felt "bad" and insecure by not doing it "by the book" (=JPA, where's that book?), as a sister project does it, but the more projects I see that have to work around the specialities of JPA, the more happy I feel to be an outlaw ;-) ...
So, I'm rambling here -- sorry, if that's not appropriate.
To get back to your initial questions: "relevant" and "irrelevant" details for me are related to the understanding of the business requirements, the prospected path they might develop, and the skill level of the developers involved.
When our judgment of relevance changes -- well, we change the code ;-) ...

1 reply

jbrains

Thank you for providing a concrete example of the issues related to abstraction and specifically why many programmers worry about bad abstractions.

I have found that my life improved when I began to feel more comfortable _changing_ abstractions as our collective understanding changed. I also found that my life improved when I started routinely writing documents that illustrated how to put the abstractions together into a working example. Some of those documents are tests and some of them are roadmaps/summaries. If I have trouble writing them, then I don't understand the abstraction enough and I need to change it. When someone complains that they don't understand it and my explanations don't help enough, then we need to change it.

In exchange for this, when the abstractions fit the people reading the code, it feels like magic. I ignore the parts that I don't need to know about. It feels very freeing.

1 reply

DirkSteinkamp

Resonates with me :-).

And thanks for pointing out the crucial role that other people (real or imagined as in writing illustrating documents) play in putting one's work to test -- and actually helping to drive it forward.

Reminds me of one of my favorite essays by Heinrich von Kleist: Über die allmähliche Verfertigung der Gedanken beim Reden. Here's an English translation: http://www.ias-research.net...

So the idea is not new ;-) ...