Red-Green-Code: 2016 in Review

NM Desert

Year two of this blog has come to an end. Let’s review the topics and posts from 2016.

UVa Online Judge Problem Editorials

As I work through the uHunt starred problems, I’m writing editorials for the ones I find interesting. Here’s the list from this year:

Competitive Programming Topics

It’s important that discussions of competitive programming be grounded in specific problems, like the ones in the previous section. However, I also write about topics that apply to competitive programming in general.

  • A Git Workflow for Programming Puzzles is a basic Git tutorial. It also describes a Git workflow that maps to the steps for solving a competitive programming problem.
  • Command-Line Tools for Competitive Programming describes the tools I use to automate parts of my problem-solving process.
  • Recursion: See Recursion is an introduction to recursive algorithms, with an example of using recursion to generate permutations.
  • Visualizing Binary Search is an illustrated guide to binary search, with an implementation in Java.
  • When to Peek at the Solution: Learning competitive programming is a process of solving problems that others have already solved. What’s the best way to use other people’s answers?
  • How Long Should You Spend on a Problem?: There are more competitive programming problems out there than you can ever solve. Here are some ideas about how to spend your time on problems and solutions.
  • 4 Lessons From a Competitive Programming Problem: I wrote an editorial for UVa 12192 (see above), but I found that it also offered some good examples of general competitive programming advice. That’s the topic of this post.
  • How Many Problems Do You Need to Solve?: As with the infamous 10,000 hours, there’s no magic number of problems that you need to solve to be proficient at competitive programming. But it’s worth having an order of magnitude estimate of how many problems successful competitive programmers have solved.
  • Why is Competitive Programming Hard?: Competitive programming is generally considered to be difficult, even for programmers with many years of industry programming experience. Why is that?

Online Resources for Competitive Programming

There are a lot of places to find competitive programming information online. One way to keep track of them all is to consult Awesome Competitive Programming, “A curated list of awesome Competitive Programming, Algorithm and Data Structure resources.” Jasmine Chen started the list in January, and I wrote a review of it in November.

The Open Courses section of the list has an entry for How to Win Coding Competitions: Secrets of Champions, an edX course launched in October. I took the course and wrote a review of it when I completed it in November.

Q&A sites are an important subset of online competitive programming resources. I wrote about these sites from a few different angles this year:

Deep Work and Deliberate Practice

Moving on from specific competitive programming topics: 2016 saw the publication of two books for people who want to master difficult subjects (like programming).

Deep Work

In January, Cal Newport published Deep Work, which advocates for a style of working that requires intense concentration, but in exchange produces distinctive results.

Deep work requires some solitary contemplation. However, it also allows for collaboration with others, which is a necessity in most jobs. Starting from the information in the book, I wrote some suggestions for combining deep work and collaboration in software developments jobs.

Deep Work offers advice for increasing work efficiency by working more intensely. In Rules for Working Intensely, I discuss how to manage both your work time and your work intensity.

Deliberate Practice

While deep work applies to job-related activities, deliberate practice is explicitly not for “activities directly motivated by external rewards.” It instead applies to “activities that have been specially designed to improve the current level of performance.” So although both deep work and deliberate practice involve planning and concentration, they have different goals.

Psychologist K. Anders Ericsson defined deliberate practice over twenty-three years ago in a 1993 paper. In April of this past year, he and co-author Robert Pool published Peak: Secrets from the New Science of Expertise. I wrote four posts based on the information in the book:

  • Mental Representations for Competitive Programming Practice: The authors argue that experts’ superior mental representations play a significant role in their superior performance.
  • Achieving Peak Performance in Competitive Programming: I review the three types of practice described in the book, and how to construct a competitive programming practice routine that follows the principles of deliberate practice, the most effective of the three.
  • Competitive Programming Training Tips: One of the requirements for deliberate practice is that it must be based on methods that an expert has used to achieve expertise in the target domain. This post reviews training suggestions from some of the competitive programming experts on Quora.
  • Getting Past a Competitive Programming Plateau: In Peak, the authors propose a way to get past a learning plateau, the point at which a learner stops getting better at a skill. The key is to break the skill into parts, and then target the parts individually. In this post, I suggest a set of competitive programming sub-skills that you can target for improvement.


Competitive programming is, for most people who try it, a means to an end. Students who are serious about competitive programming in college go on to get jobs in industry or academia. Even those who continue to participate in contests after they graduate tend to also have programming jobs. It’s rare to find a full-time professional competitive programmer. With that in mind, here are the posts I wrote this year about software development careers.

  • Finding Your Ideal Job Using Career Values: A good way to find a rewarding career is to think about what is important to you in your work, and then look for a job where your colleagues and leaders will also value those things.
  • What Makes a Good Programming Job?: An example of how to match a programming job with a set of career values.
  • Skills for Programmers: The job skills that programmers need, and how to choose one to focus on.
  • Programmer Skills (and Salaries) According to Stack Exchange: The company that runs Stack Overflow has published their own list of skills, and how proficiency in these skills translates into salaries for their employees.
  • What Problems Should You Work On?: Another way to approach the search for a programming job is by considering what types of problems you’ll be working on. The answer to that question will define what capabilities you’ll be able to build in that job, and therefore what you’ll be qualified to work on in the future.
  • Learning From Local Experts: One key to succeeding in a software development organization is knowing how to leverage the skills and knowledge of the people you work with.
  • A Career Skill: Organizing Information and Write Your Own Manual: While Stack Overflow has information that is widely applicable, it may not have answers about the specific system that you’re working on. If you’re good at collecting and communicating local information, you can become a more valuable member of a software development team.
  • Three Perspectives on Coding Interviews: A good way to understand programmer interviews is by considering the perspectives of each of the three stakeholders in the interview process.


One way I approach this blog is by finding general advice about the best way to learn, and adapting it to the specific task of learning programming, with an emphasis on the problems found in competitive programming contests.

  • Learning How to Learn Competitive Programming: The Coursera course Learning How to Learn provides a summary of current research on learning techniques. This post suggests how the key ideas of the course can be applied to learning competitive programming.
  • A Summer Learning Plan: If you have a few months and want to get started on learning competitive programming, here’s a process you can follow.
  • The Trouble With Books: Despite the online resources that we now have access to, books haven’t disappeared. Here are some things to watch out for when you’re learning from books.
  • The Benefits of Demystifying Tacit Knowledge: On the other hand, it’s possible to be too pessimistic about books, and therefore give up on trying to publish certain types of knowledge in book form. With some effort, I believe that many types of tacit knowledge (knowledge that is difficult to learn from a book or lecture) can in fact be explained in written form.
  • An Ultralearning Approach to Competitive Programming Practice: Scott Young has been writing about an approach he calls ultralearning. This post suggests a way to apply this approach to learning competitive programming.


No matter how solid your understanding of a topic, or how sophisticated your learning techniques, it’s hard to succeed without thinking carefully about the processes you use to organize your time. That’s the topic for the final section of this 2016 review.

That’s All for Now

For a summary of posts from 2015, see Red-Green-Code: 2015 in Review and Summer Review (for the first half of 2015). For a monthly review of blog activity with some extra commentary thrown in, subscribe to my email newsletter.

See you all next year!

(Image credit: I’m spending this week in southern New Mexico)