Q&A: Compact Code


Won’t I have a hard time getting a job if I can’t write my code compact enough?

First of all, no. I don’t think you will have a hard time getting a job if you can’t write your code compact enough. Unfortunately, a lot of job getting is measured by being able to answer questions on a whiteboard that have no ability to predict whether or not you are a good programmer.

There are lots of jobs where you are only measured by your ability to produce working code, not by any metrics of quality. Of course, you might not want to work for these companies so much - the code you’ll face will be nightmarish and byzantine and you will hate everybody you work with all of the time.

There are lots of jobs that deeply respect code quality, and most of these jobs are aware that junior employees often need some guidance in this area, which is why they do pairing and code reviews in order to help guide your code towards elegance.

There are also lots of jobs that simply won’t hire you if you can’t produce good code. So those ones will be out. But at this point in your career you have a ways to go before that’s a real problem.

Second of all, “compact” is a bad measure. Code quality can be measured on numerous factors.

  • Clarity. Can an average programmer quickly understand what your code is doing?
  • Documentation. Can an average programmer quickly understand why your code is doing what it is doing, how to install your code, and how to use your code?
  • Testability. Can you prove that your code works the way that you claim it does?
  • Efficiency. Does your code solve the problem at hand quickly, and without wasting memory, disk space, or CPU?
  • Elegance. Do the data structures and abstractions that you have used to frame the problem at hand make the code simple to write and easy to understand?
  • Flexibility. If you needed to use this code again on a very similar product, could you?

On top of that, sometimes these goals are at odds - a hard-to-explain block of unclear code might be crucial for performance, for example. Some people have a real tendency to write code that can solve any problem (high flexibility) at the cost of being incredibly complicated to use in practice (low elegance), inspiring terms like KISS (“keep it simple stupid”) and YAGNI (“you aren’t gonna need it”)

So, “compact” is sort of a second-order indicator that the programmer has chosen a clear, elegant abstraction, but it is not necessarily true that code that is compact is code that is clear, testable, readable, or even sane.

Learning to write code that is good by all of these many measures is a lifelong project, and not something you’re expected to master in your second programming course. Most companies understand that young coders are not well-seasoned masters of this quite yet.