1. 21

A few weeks ago we had a thread asking how an intermediate programmer can improve. The book Peak and deliberate practice was mentioned, so I purchased and read the book. Like most self-help books, it has a lot of fluff, but I came away from it believing in the idea of serious, tough, continuous practice over a long period of time with the aim of always being a bit outside your comfort zone. The importance of feedback and guidance is also mentioned, but I’ll naively assume forums and chat can take the place of a mentor.

What would that look like for a programmer? There are many “areas” of programming, so I thought Lobsters would like to brainstorm what a programmer can do to improve their thinking and problem solving skills (and any other skills you’d like to improve) with daily practice for a handful of years.

  1.  

  2. 11

    I committed myself to daily practice a couple years back. I decided to not break my github streak. Every day I do at least 20 minutes of katas, books, or building something outside my comfort zone. It’s been revolutionary. I’ve worked through SICP, Programming Languages, Let Over Lambda, Land of Lisp, Algorithm Design Manual, Clojure Programming, a good chunk of Data Scientist’s Toolbox, Learn You A Haskell, F# 3.0, Real World Haskell, most of @haskellbook, and I’m currently working through Software Foundations in Coq. I built, deployed, and support a school attendence suite in Clojure. I’ve done countless katas, TDD practice sessions, and little helper programs.

    All in all, deciding to put in 20 minutes a day and tracking it on GH has completely and drastically changed my skill in just four years. I believe if you set yourself the goal of writing something, anything for 20 minutes a day, you will find plenty to keep you busy and interested. You will see your skill rapidly improve. You will get bored of things in your current comfort zone, and so you’ll have to learn new things to stay focused. I can’t recommend it enough. I just crossed 1355 days of streak, and I intend to do it as long as I write software for money.

    1. 6

      I agree with the “20” minutes. But I disagree with covering such broad subject matter, and so shallowly (perhaps he meant something different).

      I think you’ll learn a lot more by doing things end to end, and start to finish. Figure out a small idea for a program you want to create. It should be highly relevant to you or someone you care about. Build the whole thing, including the UI, the backend, the database, tests, deployment, monitoring, etc etc. Use it. Polish it and make it robust. Don’t stop putting time into it until it’s actually done.

      I think perseverance is what makes expert programmers so unique. They can hit problems they’ve never seen and push through without getting discouraged. The only way to learn that is by finishing whole projects, not starting new ones.

      1. 5

        I’d say we are in agreement then! I finished almost every book and course, and the attendance site I built from scratch they are using it to this day. However, I disagree that fully completing SICP and Let over Lambda as shallowly covering Lisp and FP. Completing all 350+ exercises in SICP was one of the hardest things I’ve done and stretched my skill immensely.

        I’m actually curious completely because I want inspiration, if what I do is a shallow study, what does your personal study of it look like? I left out a lot of the books I’ve read that don’t have homework (so I don’t count in my 20 minutes a day) like Domain Driven Design, Clean Code, Code Complete, Pragmatic Programmer, Working Effectively with Legacy Code, Growing Object-Oriented Software Guided by Tests, Death March, Art of Agile Development, Planning Extreme Programming, Extreme Programming Explained, Design Patterns, Implementing Domain Driven Design, Patterns of Enterprise Architecture, Refactoring, Peopleware, Managing Humans, and Becoming A Technical Leader. Those are all fine, but can’t really be practiced so I often don’t recommend them unless the person has mastered more tactical skills.

        I do agree that perseverance is the biggest thing. When stuck and hopeless, I am at my worst when I give up, and at my best when I take a deep breath and look for alternate solutions.

        1. 2

          I want inspiration, if what I do is a shallow study, what does your personal study of it look like?

          What I would suggest is trying to find people who share your passion but have non overlapping skills to review your code; and do the same for them. You want to try to constantly refine and improve the code so it is better than what any of you could do alone.

      2. 3

        How do you balance reading a chunk of e.g. SICP and then coding, presumably something relevant, in 20 minutes? How much would you typically read? Does this only work because you do it every day? Or is it because the texts come with relevant exercises, so you don’t have to come up with your own projects?

        1. 4

          Those books all have exercises along with the text. I usually will read for a few minutes, then write some samples to see what’s up with what I just read, then start on the exercises. If the exercise is hard, I’ll have a few sessions of writing some unit test cases, playing with the api, and then finishing the exercise. At first each time I sat down I’d spend 10 minutes just remembering where I was, but after a year or so I got pretty good at just “jumping in” and can sit down and be typing/reading in under 30 seconds.

        2. 2

          What did you think of Data Scientist’s Toolbox? I’m curious how resources there feel. Did you have an applied math background going in?

          1. 2

            I had effectively zero math going in, but a lot of various programming languages. It was fine, I enjoyed it. I think I’d want to do it a second time without the deadlines, those really bum me out and demotivate me.

          2. 2

            The book Software Foundations came up when people were talking about learning to do stuff like seL4. I noticed it’s Coq where seL4 and many good projects are Isabelle/HOL. Curious if you or anyone else can tell me if Software Foundations' material also covers most of knowledge or skill needed for HOL, too. It plus a HOL-specific tutorial or articles. Or is it and Coq’s approach different enough to need a whole different book?

          3. 6

            I was also inspired by the thread OP mentioned and also picked up Peak. I’m about half-way through the book, and my gears have been turning about this exact question. I don’t really have a succinct answer to what a deliberate practice routine would look like, but here are a few of my thoughts on what might help:

            • Identify experts - read their code, do they describe their mental representations? Do they describe their own practice?
            • Find an open source program written by someone with more expertise - read and understand one chunk, and then try to rewrite that chunk from memory. Start small with single functions and work up to modules and eventually whole systems. (This would be similar to the game that Benjamin Franklin played with articles from The Strand)
            • Peak repeatedly highlights the importance of having a mentor - it would help to have someone who can give good feedback on code, push you to improve, and help motivate you by celebrating achievements.
            • Submit code to an open source project - you would want to work on something that is just out of your comfort zone. If your code is accepted with little to no review it is either below your comfort level or the project isn’t as demanding as you need. PR rejected once or twice is probably the sweetspot.
            • Pick an objective measure for a piece of code you are working on and try to continually improve that measure.

            One of the key distinctions that is made in the book is between knowledge and skill. Knowledge can only go so far toward improving your skill, and only practice can actually help eventually. I think because our field is mental we overvalue knowledge, and so repetitive (often boring!) practice is pushed aside. It is liberating and unsettling to read this book. Anyone can become an expert, but it’s going to take practice outside of your comfort zone.

            I think this is a really interesting topic, so I look forward to hearing more about how other Lobsters practice.

            1. 5

              Over the last 4 years or so I’ve learned a lot of abstract algebra. This is pretty much the fad in certain FP communities nowadays, but not everyone gets around to just digging in and reading the math books. I recommend MacLane’s Algebra, his Mathematics: Form and Function. I’d recommend Axler’s Linear Algebra Done Right and Aluffi’s Algebra: Chapter 0. I’d also recommend Lawvere’s Conceptual Mathematics and probably Awodey’s Category Theory (though I’m reading Riehl’s new book now and liking it a lot).

              None of this applies directly to programming, but it’s all very much a practice in working out similar muscles. Familiarity with this sort of mathematics can be a powerful tool for rapidly recognizing patterns and angles of deconstruction of problems that can help you along. It also gives you a nose for certain design patterns which are very powerful.

              It’s all “impractical”, but as a form of deliberate practice I think it’s very nice.

              1. 4

                Author of that blog post here. There were a number of useful comments in that thread, as well as some discussion on /r/programming.

                Some of my initial takeaways from the comments and my reflection on them:

                • Being a mostly creative medium with an abstract, immeasurable definition of programming skill, deliberate practice for programming can’t exist in the same way or to the same extent that it can exist for something like learning an instrument or a sport.

                • Building mental models for programming comes from learning data structures, algorithms, design patterns, and best practices. One can’t apply a pattern or algorithm that they don’t know exists.

                • A comment I saw numerous times was that learning and doing things outside of programming (reading science fiction, writing comedy, etc) can help one become better at analogy-forming and outside-the-box problem solving. As someone who first came to programming as an adult, my own experience confirms this, but I had not thought of it in that way until reading these discussions.

                • Some aspects of programming have a clean, short feedback loop that can be used for self-study. Learning about algorithmic efficiency and applying the right algorithm and data structure to the right problem can be easily practiced and refined through doing contrived programming challenges, although some are much higher quality than others.

                • Most aspects of programming have no analogue for programming challenges.

                • Programming is still a very young skill, and best practices and techniques are still emerging rapidly. This means that you won’t easily find a “coach” for programming like you will for something like baseball or violin. A top baseball coach or violin teacher can give you weekly feedback and new things to work on based on years of training the best in the field and sharing techniques with other top coaches. A programming mentor just will not have this track record of successfully training top programmers and the learning techniques will be more conjecture than evidence-based.

                I’m working on figuring more of this out still. That blog post isn’t that last you’ve heard from me on the subject :)

                The main question I’m looking to answer is this: Given a programmer of intermediate or higher skill level (strong knowledge of at least one language and generally self-sufficient) with a strong desire to improve, how can they become the best version of themselves over their next 100 hours of dedicated practice, and how will they know they’ve improved?

                1. [Comment removed by author]

                  1. 2

                    “Ant colonies, metal softening, movement of schools of fish… what the hell do these have to do with writing scheduling software!? I must have gotten stuck with the dumbest instructor in all of CompSci!”

                    Source: Fictional student later amazed at how much value came outside of the box(es).

                2. 4

                  I’ve thought about this a lot and still haven’t come to any conclusions. But one aspect of deliberate practice that hasn’t been mentioned yet is tracking your bugs (like Knuth’s error log) and building conscious exercises around avoiding them in the future.

                  As a trivial example, if you see you make a lot of off-by-one mistakes, you could try to solve many problems particularly prone to this, like binary search, parity, and boundary-related problems. Is there something that you notice when writing these programs? Do you pay closer attention to bounderies, or reason about them differently?

                  It would be interesting to see if this kind of exercise, done dilligently, has any empirical effect on bug rates.

                  I think testing could also be deliberately practiced in a related way, and this might yield other productivity gains, but I need to actually try it instead of just speculating.