Programming is a skill that’s easy to start learning. You can head over to a site like Codecademy and get up and running instantly. But once you finish a few introductory courses, it’s not as easy to keep making progress. You need another approach.
How to Make Your Job More Interesting
Programming is creative work. Given a problem, you have to find a solution, then explain it to a computer in a way that humans can also understand. But unless you’re working on your own project, you don’t have total creative freedom. You have to use the tools and technologies that your team has selected, and your technical decisions are generally reviewed by other developers. On the other hand, it’s rare that you are told exactly how to solve the problem. If someone already knows that much about the solution, they could just implement it on their own. So it’s up to you to work out the details.
Proving That You Can Juggle Code
Peopleware is one of those books that show up on recommended reading lists for software development managers. Joel Spolsky was recommending it back in 2002. (It was written in 1987 and revised in 1999 and 2013). Chapter 16 (in the 3rd edition) begins with this vignette:
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.
Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.
Manager: Do you work with flaming objects?
Candidate: Sure.
Manager: …knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.
Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.
Manager: Well that sounds fine. I guess you’re hired.
Candidate: Umm… Don’t you want to see me juggle?
Manager: Gee, I never thought of that.
Asking for Advice is Easier than Taking It
We have good options these days for getting answers to programming questions. Stack Overflow provides answers to fact-based questions. They can be targeted questions like How to sort a Collection
As essential as Stack Overflow is for programmers, sometimes you need an answer to a question that doesn’t work there. For those types of questions, there is Quora. Although Quora does have mechanisms to maintain content quality, the rules are much looser. The advantage of this approach is that you can get answers to a wider variety of questions. The disadvantage is that it’s a lot harder to control quality. For example, Quora gets bombarded with questions of the form Is it too late for an X-year-old to learn how to program? But questions like How should I get started in competitive programming?, which would get closed on the Stack Exchange sites, can actually collect some useful answers on Quora.
There are other sources of programming information that people use for questions and answers. Reddit and Hacker News come to mind. They have voting and, in the case of Reddit, even an “accepted answer” feature. But in my experience, these sites are not as effective when used for Q&A. They are mainly designed to show a link to an article followed by comments from users. This can be adapted for Q&A, but it’s easier to use a site that was designed from the ground up for questions and answers.
Why is Java I/O Slow?
You can read a lot on Quora about the best language to use for competitive programming. Here are some of the points covered by those questions:
- C and C++ execute quickly, and their macro support can reduce the amount of code that you end up typing in your solution.
- A language like Java can be useful for problems with some specific requirements (such as integers that don’t fit in 64 bits, or calendar problems).
- The main contributor to execution speed is the algorithm that you use, not the language that you choose to implement it. But the language can provide a performance edge at the margins.
- Choice of language is less important for more recent contests, since problem setters have made an effort to level the playing field (e.g., by testing Java solutions to ensure that the time limit is sufficient).
I decided to use Java for Project 462, mainly because it’s similar to my primary language (C#), and I’m more interested in learning about problem solving and algorithms than learning a new language that I’m unlikely to use much outside of competitive programming.
One thing about the uHunt problems that I’m working through is that they draw from a database of contest problems going back to the 1990s. Competitive programming and programming languages have changed a lot since then, so what the problem setters were going for in the original contest may not match up with how a contestant sees the problem today. Modern contests tend to be more forgiving of the slower execution time of languages that aren’t C or C++, and they know about the fancy libraries that programmers have access to.
Last week I wrote about Solving UVa 11340 in Java, and covered some performance tips related to reading files that are larger than those typically found in programming puzzles. It turns out that the very next starred problem, UVa 12356: Army Buddies, is an even stricter test of I/O performance. And for this one, there is no particular hint in the problem statement that I/O will be an issue.
Once I came up with an Accepted solution for UVa 12356 in Java, I decided to do some more benchmarking, and use the results to update my solution template. Figuring all of this out once is educational, but I’d rather not be fiddling with I/O issues for every problem that happens to have large input or output requirements.
Solving UVa 11340 in Java
UVa 11340: Newspaper, despite being ranked at only Level 2 difficulty on uHunt, turned out to be rather tricky. Apparently others thought so too, judging by the 11 pages (151+ posts) of discussion on the UVa OJ message board. Many of the message board posts focus on the characters used in the test input. The consensus is that they are 8-bit characters (with values from 0 to 255). At a minimum, these characters need to be stored in an unsigned char data type in C++. Nevertheless, people seemed to run into problems even after getting that hint. I solved the problem in Java, which doesn’t have an unsigned char data type, but it has its own set of difficulties. I’ll cover the two issues that I ran into when solving this problem.
The Long Game
The theory of deliberate practice is a popular starting point for online article writers. I subscribed to an alert for the term, and I generally get a few results every day (of varying quality). Its popularity isn’t surprising. Deliberate practice offers a process that anyone can use to get better, assuming they are willing to follow it carefully and put in the required hours. Articles and books on the topic often provide examples of well-known experts who followed a deliberate practice process. Geoff Colvin’s Talent is Overrated mentions Tiger Woods pushing golf balls into the sand to make them harder to hit. James Clear writes about Kobe Bryant’s 800 jump shots before practice. But there are also examples of people who didn’t have coaches to steer them towards the right practice steps, but nevertheless achieved incredible results. I recently finished reading Masters of Doom, the story of the founders of id software. One of the recurring themes in the book is the incredible work ethic of John Carmack, co-founder, graphics engine developer, and all-around game programming legend.
Lessons from Competitive Programming 3, Chapter One
This post is part of a series of commentaries covering each chapter of Competitive Programming 3 by Steven and Felix Halim. You can find the rest of the posts in the series by visiting my CP3 post category.
Many of the problems in the UVa Online Judge are taken directly from past ACM-ICPC contest problems. If you’re preparing for this contest or the IOI (which targets a subset of ICPC content), it makes sense to be familiar with these problems. But even if you’re planning to compete on platforms like TopCoder and CodeForces, it can be useful to train using UVa OJ problems, despite the platform’s quirks. Competitive programming problems tend to cover similar topics regardless of the contest platform, especially when it comes to easy and medium problems. The difference is mainly about which topics are emphasized more.
Because UVa OJ has been around for a while, several books use its problems as exercises. One of these is Competitive Programming 3 (CP3), the companion book to the uHunt site. Last week I wrote about the Chapter 1 uHunt starred problems. This week I’m going to cover some highlights from the corresponding chapter in the CP3 book. I’m using the 3rd edition, but you can find similar (but older) content in the free 1st edition ebook.
Lessons from uHunt Chapter One
This post is part of a series that considers what can be learned from the problems in each chapter of uHunt, a tool for competitive programming practice. You can find the rest of the posts in the series by visiting my uHunt post category.
This week, I submitted the solution to the last of the 39 starred problems in uHunt Chapter 1. This is part of a learning project that I’m calling Project 462, after the 462 uHunt starred problems.
The problems in uHunt Chapter 1 are introductory and ad-hoc problems. They help uHunt users get familiar with the UVa Online Judge system, and they don’t require any specific competitive programming techniques to solve. Nevertheless, there were quite a few challenging problems in this chapter.
How to Attack a Programming Puzzle contains six tips for using UVa OJ. This post contains my remaining thoughts on solving the types of problems found in Chapter 1.
Productivity Habits
When you’re working on a serious learning project, especially if you’re applying deliberate practice techniques, it’s essential to have a set of core habits that you can rely on. Deliberate practice is intended to be a demanding process (see elements #4 and #5 from the linked post). This is good because it makes you push against your limits, but it can also make it difficult to maintain a schedule if you’re just using an ad-hoc process. Experimenting with habits and selecting a few that work for you makes it more likely that you’ll be able to continue working on your project for as long as it takes to complete it.
A productivity habit is something you do on a regular basis (often daily) to help you be more productive. Although the habit may have some value on its own, what’s more important is the effect it has on your work. For example, I find it useful to keep track of how long it takes to complete various tasks. Analyzing this data over time can uncover some interesting trends. But it’s even more powerful to use time tracking for setting time goals, like the number of hours per day that I commit to spending on a project.
Here are the habits that I have found to be the most useful as I work on Project 462.