Five Lines of Code: now versus later

[bryant rob]

Hi Christian,

As a new student to computer programming I would like to know do you think your book would be a good companion to learning a programming language? I realize that I am not going to learn anything more about Java, my language of choice by reading your book, but do you believe that someone like myself just four months in  to starting my java journey would benefit from reading it? The underlying tone by so many on this forum that has helped me has been to think in the abstract and write good code. With that being said it sounds like I would benefit even at this early stage to get a copy. What is your opinion?

[Christian Clausen]

Hi Bryant,

I think as long as you are comfortable with loops, methods, and objects you could pick up refactoring if you want to. The book aims to be very accessible, and there is often side-by-side code to show what to do, and also a github repo where you can compare your code to my solution at every section, so you don't veer too far off course. However, picking up a new language -- no matter how similar -- is bound to cause some frustration, so be prepared for that.

[Campbell Ritchie]

Is this a case of, “the sooner you learn it the better”?

[bryant rob]

Christian Clausen wrote:Hi Bryant,

I think as long as you are comfortable with loops, methods, and objects you could pick up refactoring if you want to.

Christian thank you for replying. At this point, I am very comfortable with loops, methods, and objects. The main problem I am having learning Java at the moment is keeping track of which methods are being are being used to call which methods and not get lost or tangled up with all the different calls. This is why I started looking at refactoring early in my learning phase. I believe for the most part a lot of code can be written better.

Christian Clausen wrote: However, picking up a new language -- no matter how similar -- is bound to cause some frustration, so be prepared for that.

You are absolutely correct here. I have gotten frustrated lots of times before but I am a very challenge oriented indidual. Plus, I have my friends here on coderanch that will keep the explanations coming as long as I have the question, and they never let me down.

Lastly, you stated that you learned to program at an early age. At the moment I am working with my 11 and 14 year old sons on learning python, and they seem to lose interest. They don't see the end game yet. Do you mind providing some guidance as to how you were able to keep it fun enough when you were young to maintain the interest?
Thanks.

[Christian Clausen]

For me the steps are: First get it to work, any way you can, it doesn't have to be pretty. Then refactor it, before delivering/deploying it.

I think the learning journey should be the same. Focus first on learning to write code, and don't mind good vs. bad. Once you can do problem-solving comes a lifelong journey of improvement. But as long as you don't get obsessed with trying to write good code in one try I think sooner is perfectly fine.

[Christian Clausen]

Sure, it is about playing into the interests and goals of the child. For me, I wanted to start a toy store, so my dad said "what about an online toy store". I agreed, he showed me how to open notepad and gave me a few basic HTML tags, and then I was off. Every time I wanted to do something but didn't know how he helped me out, so I was never stuck for long. Until static pages wasn't enough for me, at which point I had to learn actual programming. This was slower, but I had my end goal in sight and I felt like I was getting closer.

I also remember him showing me how to implement Pacman in C, he asked if I had any suggestions, and then I was hooked, so when he asked whether I would write the code I gave it a shot.

Bear in mind I didn't program intensively. But once in a while when I got some idea I tried building it. For me, the important ingredients were: doing something with my dad, getting me invested, and it was always very visual.

[Junilu Lacar]

Christian Clausen wrote:For me the steps are: First get it to work, any way you can, it doesn't have to be pretty. Then refactor it, before delivering/deploying it.

I hope that doesn't mean "write all the code first to get it to work, then refactor in the end" because it can surely be misinterpreted that way.

I like the premise of "five lines of code" and honestly, that's what I always strive for. To get to that, however, requires a lot of practice and skill, in my opinion. If you don't refactor as you go and end up with 50 lines of code in one method—something I see all the time in real life—it's much harder to refactor that down to 5 lines than if you had kept extracting/refactoring along the way in the first place.

Edit: Got to section 1.3 Culture: When to Refactor? and understand where you're coming from. Makes me grimace though. I kind of get why you want to avoid coupling TDD and refactoring too tightly but I still think that advocating the "refactoring before delivery" approach is going to get a few frowns among seasoned practitioners of refactoring. If not test-driven, I hope you at least advocate for constant/continuous testing while refactoring.

[Christian Clausen]

The important point I was making was: don't try to write perfect code in one go. Write imperfect but working code, then improve it once it is working.

However, I don't mind having to refactor 50 lines. The more code you have the more evidence you have for the structure the code is taking.

My personal opinion is I like automated testing, and I think a lot of people could benefit from doing it more. However, that is for team themselves to decide, I don't want to preach, I want to enable.

[bryant rob]

Christian Clausen wrote:For me the steps are: First get it to work, any way you can, it doesn't have to be pretty. Then refactor it, before delivering/deploying it.

Prior to joining coderanch I did not think like this. To me, as long as I got the code to work I didn't care what it looked like and I was moving on. Now, even at the elementary stage that I am in I am thinking about the code I write...Firstly, I need to get it to work. Secondly, I am thinking what can I do to reduce duplicate code, and place code in separate methods where it makes sense to. Then this way if I need to post some of the code here for help in something I at least feel that I have given it my best in presenting the best code possible. I sort of liken it to my penmanship. My wife is an English teacher and is always trying to better her students handwriting.

Junilu Lacar wrote: If you don't refactor as you go and end up with 50 lines of code in one method—something I see all the time in real life—it's much harder to refactor that down to 5 lines than if you had kept extracting/refactoring along the way in the first place.

Junilu, 50 lines of code...how could anyone keep track of what is going on with that type coding. I get lost with 5 lines of some code.  In the real world would how would or could a a dev team, supervisor, or project manager allow this type of coding to take place in the first place.  I can remember just like it was yesterday when I posted some code that I was actually very proud of and Campbell replied real quick https://coderanch.com/t/732745/java/Sorting-array to let me know that a certain few lines of code belonged in a different method. To be honest I actually was kind of embarrassed at first... But, I realize it was not his intention to embarrass me, so I put on my coders face removed the code and created another method to distinguish between sorting and swapping. It made sense.   Junilu, I know I've stated it before but thanks for your posts and support.

[Liutauras Vilda]

Christian Clausen wrote:For me the steps are: First get it to work, any way you can, it doesn't have to be pretty.

I personally find such approach counterintuitive as it makes problem more complicated to solve than it could be otherwise. Think about it, if we find that solving problem in a quick and dirty way is more natural and simpler, then what is the value in attempting to have a cleaner code (i.e. no more than five lines of code per method), because sounds like any way one can (I parse it as dirty) is found as an easier way to understand and solve the problem eventually. That isn't my experience lately.

For sure I don't write perfect code, but I don't attempt to write any way I can just to get something to work. The refactoring part is also seems more likely to happen on a basis of better code, because you don't need to rewrite everything potentially. And we all heard "let's merge it for now, we'll refactor later".

For me, refactoring isn't a conversion from bad to good, but more like from good to a better (that "good" of course depends on individual's experience at a time).


Congratulations on the book, looks interesting

[Junilu Lacar]

bryant rob wrote:Junilu, 50 lines of code...how could anyone keep track of what is going on with that type coding. I get lost with 5 lines of some code.  In the real world would how would or could a a dev team, supervisor, or project manager allow this type of coding to take place in the first place.

Ah, to be young and idealistic again instead of being old and jaded

When you get out in the real world of programming, you'll soon find yourself thanking your lucky stars if the longest you have to deal with are 50-LoC methods. At one workshop I conducted, we refactored a 300-line method (production code) down to about 75 lines and the programmers were happy. It's not uncommon to find yourself waist deep in a 200- to 500-line method on a daily basis in some code bases. I spent 8 years maintaining a legacy system where this was the norm. I started with a full head of hair and by the end of my "tour" I had no hair. I'm not even counting the 1000s of lines long stored procedure that generated HTML markup in the Oracle  that nobody would touch.  Yes, there are more developers out there who will do this kind of crap than there are who won't.

It's just a matter of statistics really: about 25 to 35 percent of professional developers are reasonably competent, about 10-20 percent are at the top of their game, and the rest are anywhere between "totally incompetent" and just muddling through and making things "work." (I can't cite any official stats on that but if you look at your average bell curve, that's pretty much what you'll see, with 70% being "average performers")

This is why a book like this is extremely important and why my comments might seem a bit harsh and critical—I just think the message is of utmost importance and that newbies need to get the right impressions and the right ideas out of it.

[Junilu Lacar]

bryant rob wrote:To me, as long as I got the code to work I didn't care what it looked like and I was moving on. Now, even at the elementary stage that I am in I am thinking about the code I write...Firstly, I need to get it to work. Secondly, I am thinking what can I do to reduce duplicate code, and place code in separate methods where it makes sense to. Then this way if I need to post some of the code here for help in something I at least feel that I have given it my best in presenting the best code possible. I sort of liken it to my penmanship. My wife is an English teacher and is always trying to better her students handwriting.

I like the penmanship analogy. But it's more than just penmanship and legibility (readability). It's about semantics, structure, cadence. I liken it to trying to tell a story (or rather, Kent Beck does and, through personal experience, I happen to agree with him). My basic rule of thumb is "Does it make sense?" I'm thinking about cognition and coherence. Because if it doesn't make sense, the fact that "it works" doesn't help the next person who has to maintain the code much. And that next person could very well be me.

Here's one of my favorite quotes:

John F. Woods wrote:Always code as if the guy who ends up maintaining your code is a violent psychopath who knows where you live.

[Junilu Lacar]

Another related perspective comes from Ward Cunningham. In this video, he explains how/why he coined the Debt Metaphor to explain the refactoring work he and his team were doing on a project. It's a short video, less than 5 minutes long, but many of the ideas behind refactoring and "debt" have, unfortunately, gone through what Martin Fowler refers to as "semantic diffusion."

I think we all would benefit from being reminded of its original intent and meaning once in a while. Basically, Ward says that it's in your interests as a programmer to keep the code as well-factored as you can at all times so that it best reflects your current understanding of how the program works, even if that understanding is only partial.

Edit: Ok, so I guess he doesn't say "at all times" -- that's just me.

[Junilu Lacar]

Christian Clausen wrote:The important point I was making was: don't try to write perfect code in one go. Write imperfect but working code, then improve it once it is working.

Absolutely agree with you on that. (BTW, your TDD is showing but I won't tell anyone if you don't)

However, I don't mind having to refactor 50 lines. The more code you have the more evidence you have for the structure the code is taking.

Yeah, sometimes. It depends. 50 lines of code isn't too bad. In fact, I wouldn't be too put out if that's all I had to refactor. The part where you write about comments on sections of code is very real-world -- that's one of the markers I teach people to look for to identify candidates for extraction.

[Junilu Lacar]

bryant rob wrote:I can remember just like it was yesterday when I posted some code that I was actually very proud of and Campbell replied real quick https://coderanch.com/t/732745/java/Sorting-array to let me know that a certain few lines of code belonged in a different method. To be honest I actually was kind of embarrassed at first... But, I realize it was not his intention to embarrass me, so I put on my coders face removed the code and created another method to distinguish between sorting and swapping. It made sense.

I'm really glad you mentioned pride, embarrassment, and intent in the same paragraph. Nobody here will intentionally embarrass you. Actually, if you feel embarrassed about code that you posted proudly, you should be happy. Feeling embarrassed about criticism of your work is a sign that you care about what you wrote, that it's important to you to do a good job. But it also means that you learned something: you learned that what you thought was good may not have been so good after all. This is a normal thing for programmers. In fact, if you don't find yourself thinking or say "Doh!" at least once while you're coding, you should ask yourself what you've done wrong and why haven't you realized that it's wrong.

To Christian's point, you're hardly ever going make code work and be well-factored the first time around. Or even the second or third time. That's why the advice to get it to work before you refactor is good advice. The difference there with my approach is that I don't wait until everything works to refactor. I'll make sure things work little by little, as I add functionality because I have found that the longer I spend writing code without refactoring, the longer I tend to spend refactoring when I do get around to doing it.

However, if I write a little code (like 5 lines of code), then refactor it once I see that it works, then write another small chunk that works and refactor it, I find this incremental and iterative way works out better for me. Don't get me wrong though, sometimes I will write a lot of code before I refactor but I always try to be conscious about how long it has been between refactorings and when it gets too long (over 10 minutes or over 30 lines of code), I start to worry.

[Junilu Lacar]

One more thing I'll share here: when I first joined this site almost 20 years ago (I'm really aging myself now), I used to get embarrassed a lot. I would literally feel my face and ears turn red when I did something dumb that got called out. Once I realized that being wrong was an opportunity to learn and grow, however, that feeling of embarrassment started to diminish. I'll still have my "Doh!" moments once in a while but now it hardly ever bothers me much.

Programmers are a prideful bunch but as a programmer, you have to learn how to make pride work for you instead of against you. Certainly, strive to produce work that you can be proud of but also have the humility that you're not always going to write the best code and that's Ok. As long as you can recognize mistakes and do something to address them, it's all good. That's the kind of mindset you need to have to learn how to refactor well.

[bryant rob]

Junilu Lacar wrote:
To Christian's point, you're hardly ever going make code work and be well-factored the first time around. Or even the second or third time.

What I find myself doing at this point with some of the code that I am learning to write,  is just trying to understand the "how it is working." Then most of the time I just go back and write that same code over and over until it is stored into a memory slot in my brain and I can write it line for line in my head. Then and only then can I can I begin to think about how I could possibly refactor the code because now I somewhat understand how I am accomplishing my goal.

[Junilu Lacar]

Thanks for sharing that. It's not a bad approach; in fact, it aligns with common learning patterns like the Dreyfus model and ShuHaRi. The key is to recognize that this approach is not the end, it's just the beginning. As you gain more skills, you'll rely more and more on "principles" and lessons you've internalized to guide your thought process rather than context-free rules that you relied on when you were first starting out. This is the next level where you have a deeper understanding of the underlying ideas behind the rigid rules. That's why I keep pointing out that Five Lines of Code is kind of a "gateway" rule -- it helps you quickly determine a course of action without necessarily understanding the underlying reasons.

For an experienced programmer like me, the FLoC rule becomes more of a limiting rule, one that I use to gauge when I've done enough refactoring. Sure, it helps me to quickly identify good candidates for refactoring but once I see a Long Method, I quickly go down deeper in my bag of principles and practices to smells like "multiple concerns" and "multiple levels of abstraction" to guide my refactoring decisions. I've seen some interesting things in Christian's book that I might add to my repertoire but some of them I already know by different names or are just different takes on essentially the same kinds of problems.

Follow-up edit: That's not to say that Christian's takes are not useful. Like I said, there are some interesting takes on problems that I probably never thought to consider before. It's always good to have different ways of looking at the same problem because I think that opens up more possible choices for ways you can go. You may arrive at the same place in the end but the way you get there is where all the fun and learning happens.