Forget About "Lines of Code"
As a developer, you'll hear a lot of crazy, unbelievable theories about what "lines of code" signify. Believe none of them. Lines of code is a ridiculous metric to base decisions on. In very rare cases it tells you something, in all the other cases, it tells you nothing. Using lines of code to make decisions is like rating book quality by number of pages.
Some might make the case that the fewer the lines of code there are in an application, the easier it is to read. This is only partially true, my metrics for readable code are:
- Code should be consistent
- Code should be self descriptive
- Code should be well documented
- Code should utilize stable modern features
- Code shouldn't be unnecessarily complex
- Code shouldn't be un-performant (don't write intentionally slow code)
The moment reducing the number of lines of code interferes with any of those, it becomes a problem. In practice, it will almost always interfere and thus is nearly always a problem. But here's the thing, if you strive to meet the above criteria, your code will be the perfect number of lines, no need for counting.
Languages aren't necessarily "Good" or "Bad"
I see people say stuff like this, all the time:
C is better than X, because performance
Python is better than X, because conciseness
Haskell is better than X, because aliens
The notion, that a language comparison could be reduced down to a single sentence is almost insulting. They're languages, not Pokemon.
Don't get me wrong, there are definitely differences between languages. It's just that, there are very few "unusable" languages (although there are many outdated/dead languages). Each language brings it's own unique set of tradeoffs. In that regard, languages are similar to tools in a toolbox. A screwdriver can do what a hammer can't, but would you ever say a screwdriver is better than a hammer?
obviously the hammer is better
Before I talk about how I evaluate languages, I want to make something very clear. There are very few cases where the language choice actually matters. There are things you can obviously not do in some languages. If you write frontend code, you don't get a language choice. But in general, language choice is usually one of the least important issues for a project.
Here are the core aspects (ordered), that I believe should dictate your choice of language (these are it's Pokemon stats)
- Density of available online resources (StackOverflow density)
- Development Velocity (vroom vroom)
- Bug proneness (eeek)
- Quality and breadth of package ecosystem (yea npm, it says quality)
- Performance characteristics (more dots)
- Hirability (sorry COBOL)
There are also some strong couplings that are out of your hands. If you're working in data science, you realistically need to use Python, R or Scala (maybe Java). If it's a hobby project, use whatever will make you happiest. There's only one non-negotiable rule I have. I refuse to use languages that don't have most of the problems I will encounter, directly solved on StackOverflow. It's not that I can't solve it, it's just not worth the time.
Reading Other People's Code is Hard
Reading other peoples code is difficult. Robert C. Martin talks about this in "Clean Code":
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.
For a long time, I assumed that I just sucked at reading other peoples code. Over time, I realized that it's something almost every programmer struggles with on a daily basis. Reading other people's code almost feels like reading a foreign language. Even if you're comfortable with the programming language choice of the writer, you still have to adjust to differing styles and architecture choices. This also assumes that the author wrote consistent and reliable code, which can be hit or miss. This is a really difficult one to overcome. There are a few things I've found helped a LOT.
Reviewing other peoples code will improve your code reading skills immensely. In the past two years, I've reviewed quite a few Github PR's. With each PR, I feel slightly more comfortable reading other peoples code. Github PR's are especially great for these reasons
- Can be practiced anytime, just find an open source project that you feel like you want to contribute to.
- Practice reading in a scoped context (driving feature or bug of PR).
- Attention to detail required, which will force you to evaluate each line.
The second hack which can help you read other peoples code is a bit more unique. It's a technique I came up with, and it's really reduced the amount of time it takes for me to feel comfortable in a foreign codebase. After looking at the style of the code I want to read, I first open up vi and starting writing code in the style used by the project. When you write code in the new style, it will also improve your reading skills. The style will feel less foreign, as you've actually experienced it. Even if I'm just browsing a random project on Github, I'll quickly do this. Try it out.
You'll Never Write "Perfect" Code
I was a "lone wolf" developer for 4 years before I started working on a team. For most of that time, I just had this assumption that every programmer in the industry wrote perfect code. I figured it was just a matter of time and effort before I also wrote "perfect" code.
It's something I used to feel really anxious about. Once I joined a team, it quickly became clear that no one was writing "perfect" code. But the code going into the system was almost always "perfect", what gives? The answer, code reviews.
I work with a team of really brilliant engineers. These are some of the most competent, confident programmers money can buy. Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code. Even if you think you're the next Bill Gates, you will make mistakes. I'm not even talking logical mistakes, I'm talking typos, missing characters. Things that your brain tunes out and will never pick up on. Things you need another set of eyes for.
Strive to work with others that are attentive to detail and willing to criticize your work. Hearing criticism is difficult at first, but it's the only consistent way to improve. Do your best to not become defensive during a code review, and never take any comments personally. You're not your code.
When I'm reviewing someone else's code, I just Google search every choice they make and see if it differs from strong popular opinion. Often times, looking at the same problem with a "beginners mind", can catch things the person would have never gone back and looked at.
Working as a Programmer Doesn't Mean 8 Hours of Programming a Day
This is a very common question, but people never seem to give a clear answer.
Very few people are writing code for more than 4 hours a day
People who disagree with this are either the exception to the rule or work at companies that should treat them better. Programming is a mentally draining, focus intensive task. It's entirely unreasonable to expect anyone to write code for 8 hours a day, 5 days a week. There will be rare cases where you need to meet a deadline or pull a little extra for a stretch, but those are few and far between. When I say "rare", I mean almost never. Do not tolerate a workplace that abuses you and makes you work overtime due to poor planning/under-hiring.
For the record, it's not even in your companies best interest for you to be actively programming for 8 hours a day. Your boss might think that's the case, but it's shortsighted and ignores the longterm implications, on productivity and mental health.
Just to be clear, I'm not suggesting that you only work four hours a day. The other four hours are usually best spent:
- Researching, both work related and non-work related topics
- Discussing your work with a colleague
- Helping coworkers who are struggling with their own work
- Planning your future work
- Code Reviews
- Meetings
I also highly recommend taking regular breaks during the day, and exercising (even if only briefly). The benefits of exercise on mental fatigue are well documented. I've personally found that exercise especially helps if I'm having trouble focusing.
Update: /u/terriblesarcasm suggested that I add what a developer should be doing in the 4 hours they’re not programming. I added a section addressing that.
Conclusion
These are a few of the things I wish they were teaching at university instead of pure theory. In the process of writing this, I came up with a ton of other items but those will have to come in the next post!
Top comments (32)
"The notion, that a language comparison could be reduced down to a single sentence is almost insulting. They're languages, not Pokemon".
Thats so fucking true! Thanks for that!
BUT...I GOTTA CATCH EM ALL.
Well, the rating of books by number of pages can actually work quite well in Samuel Clemens' sense of it - I wrote you this long letter because I had no time to write a shorter one. Pretty much the same with code - each new line of code is a liability, not an asset. That would be indeed something good to teach right from the start though I'm not holding my breath for it to happen.
Re languages, there are some that are the "anti-tool" - instead of supporting your thinking, they burden you with more and more. Whether that's bad or good might depend of course on your measures and ultimately on your ethics, sure. But speaking of things to teach, I'd say it's very useful to get to know the difference between "it feels fast" and "it is fast". Not as easy as it sounds though, granted.
That's a good point but I think even between languages it may not be true. I think that unless 'lines of code' is specifically relevant to the context of the discussion, it should be avoided.
I think popularity filters these out for the most part. Obviously there are obscure unusable languages (like brainfuck), but those aren't going to be a common part of your day.
I would consider myself a "low level expert" and I'm not even sure how you could generically learn such a thing.
Thanks for contributing so many new ideas to the discussion. Glad you liked the post!
(Hm, how do I cite a part of your comment? )
Re "popularity filters these out for the most part" - how do you figure this?
I'm genuinely curious about this because in my experience popularity is more of a counter-indicator really (as a well-known example think qwerty vs dvorak keyboards, to take this on more neutral ground). And if anything, I'd add to the list for teaching precisely this: stay away from today's popular unless you really are more into fashion than into building up a lifelong career.
:thumb:
"popularity filters these out for the most part" doesn't really explain JavaScript.
But I guess that's the "for the most part"... part ;)
Diana,
Your comments are very wise.
However, considering popularity to be a counter-indicator to the ability of the language to support your thinking process is, in my opinion, an extreme view. That doesn't mean you can't find exceptions.
Totally agree with the "StackOverflow density" metric of language evaluation. If someone says "language X is better than Y because StackOverflow density" it's perhaps the only such sentence I'd take into consideration.
StackOverflow density has really become a metric for the success of a software product. Glad you appreciated that part! Thanks for reading.
Spoken like a true Blub programmer... 😉
-- Paul Graham, Beating the Averages
A problem that I see a lot when giving talks in Asian universities is teachers making their students learn languages off by heart.
For instance knowing all the functions on the String object and the parameters they can take. In my opinion this kind of teaching brings a fundamental flaw to those students. They are never taught to do any type of problem solving. They do not get any programming tests most of the time but only off by heart tests about the languages.
This brings a serious lack of understanding on how to code and when interviewing some new candidates for our company, many couldn't solve simple programming dilemmas.
I think you should remember to always try to think outside of the box and to understand basic concepts such as loop, comparisons and more.
I don't understand how the title connects with the article at all. If you professors thought you the opposite of what you said here... where in the world did you study?
I've never had anyone tell me that lines of code matter in a sense that it makes software better or worse, or that we're supposed to type code 8 hours a day. That's literally the experience that people told me they had in bootcamps, not in the university.
I went to the rank 2 CS university (at least in the states, but I think world at the time), University of Washington.
I believe that this is key when working with other programmer/s.
edit: also, thanks for your post Ryland!
according to my point of view, the student should learn VCS like git or something so that he can preserve his code. I personally miss the programs I created in my initial days of college.
Version control is on my list for the next post.
Generally good article. But the assumption that language choice in most doesn't matter is opposite to how I see that. Agree that languages are full of tradeoffs, and that is why some languages are better for one and other for second. I would never choose for example PHP for anything more than web server app, I would never choose Scala for Android development as it has very low support there. Also languages have specific concepts of design, for example writing FP in JavaScript is full of problems, writing FP in Elm is build into root concept of the language, and working with it is just brilliant.
In Summary - language choice is very important and has many implications, so it is very important decision
While lines of code are being abused a lot, I disagree with the fact that you should forget about them and not learn about it in college.
The number of pages of a book is actually a pretty decent indication (or at least a relevant factor) when looking at how much time it took to write the book, how much space it will occupy on my shelve and how much it will cost. Of course, these apply as averages - individual books will always stand out. Similarly, lines of code gives a very useful indication (or is a relavant factor) of how long it took to write the system, and how much time/money it will cost to maintain the system, or how much time it would cost to rebuild it. These may not be relevant for day to day programming work, but as an architect or team lead, these do come in handy.
Even if you look at quality, which you single out, it turns out that many software quality metrics correlate strongly with lines of code. On average, a larger system will be more complex, have more code duplication, etc. (relatively speaking, not just absolutely). And that's not just a "crazy, unbelievable theory", but has been tested and observed looking at a large volume of systems. (I used to work at a company investigating this - read this book if you're interested).
There are of course many caveats when using this metric - comparing lines of code in different technologies can be very troublesome if not done well, for example. Such difficulties contribute to the lines of code metric often being abused and, in turn, derided or despised. But then again, that's not really different from any other metric you'll encounter. If those using it don't understand and use them properly, it's pretty much useless. And that's actually a lesson I wish I had learned in college...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.