What Every Developer Should Learn Early On
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”
Except for php, just kidding. Source
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 its 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. There are also specific contexts where performance is important and X language just won’t do, those situations are quite rare. 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 start 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 reviewing code, if the author made a choice I’m unfamiliar with, I’ll immediately Google to see if their choice differs from strong popular opinion. It’s not that the popular opinion is always right, it’s just that the popular opinion is the default choice. If someone chose to not adopt the popular choice, that’s fine, I just want to know that it’s justified. When reviewing code, it’s critical that you understand the rationale behind the decisions that have been made. Additionally, looking at the same problem with a “beginners mind”, can often 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. How long does the average developer, or a “great” developer, spend writing code each day?
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 long-term 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
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.
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!
This blog post originally appeared on Ryland’s personal website and on Dev.to. You can find more of his writing on both sites. If you would like to contribute articles to the Stack Overflow blog, send an email to firstname.lastname@example.org.Tags: bulletin, coding, learning, software development
> If you write frontend code, you don’t get a language choice.
I believe this is not true. The only language the _computer_ speaks is machine code, but it’s unreasonable to suggest that programming in VB, Haskell, Prolog etc. means you are actually writing assembly 🙂 Same goes for JS, which is de-facto “assembly language” of the web: while Typescript has a design goal of being consistent with JS, there are many languages which compile to JS but maintain their completely different semantics.
So if I write c# (blazor) am I writing WASM? Doesn’t matter they compile in the same language, the environments are so different. You do get a language choice unlike the article stated.
That’s kinda like saying the only languages a machine speaks binary. If you write assembly, you are limited to the processor whether is ARM, x86, or MIPS.
Doing fine with Dart in Flutter Web. I never liked frontend because of HTML/CSS/JS, but loving it now.
There is NodeJS, so you can run js outside of broswer too
Wasm doesn’t end up as js.
Dart is intended to be compiled to JS
Check Flutter Web
in .net technology razor engine support .cshtml or .vbhtml. if you try
Well, with a such approach it is worth mentioning also VBScript, ActionScript, and Java 😉
Of course, Frontend doesn’t really mean “Web programming”. I write Frontend in Swift.
The point I really miss about pros & cons of languages is bug prevention. Most modern languages will catch a lot of bugs at compilation time (the tradeoff is usually longer compilation time) which is a very very good thing. That’s not necessarily about languages but the modern languages are a bit smarter about their design that allows for better compilers.
Thanks for writing this, Ryland. Great read and I enjoyed it.
So glad to hear. Thanks for the kindness.
Newbie programmer here, and this is incredibly helpful and inspiring. Thank you!
I love to hear that. Thank you for the positivity!
Posted to https://news.ycombinator.com/item?id=20640941
i gotta nitpick here. maybe programming language is not directly a matter of success or failure. but which paradigms you choose to use can make solving the problem easier or much harder. and different languages support different paradigms with varying degrees of success.
I have seen too many projects adopt a language and platform based on business comfort level without relevance to the actual problem. it doesn’t necessarily doom the project but results in much more complicated code than necessary and makes life hard for everybody.
I feel like I represented this pretty well in the article. All languages are different and therefore come with their own advantages and disadvantages. I’ve seen far too many projects fail because people spent exorbitant time trying to optimize for a language/framework selection.
Thanks for the constructive criticism, much of what you said I agree with.
Actually my initial crankiness aside, this article is really well constructed and stays focused on positive practical advice. makes me want to check out what else you have to say on your blog.
I think you are spot on with this article. Thabks for sharing. I appreciate it and enjoy reading it.
English — in which I misspell ‘recruiters’ as ‘recriters’. I blame the iPad crappy hunt-and-poke on-screen touchy keyboard. 🙂 Is there a way to edit your comments on here? After you’ve posted them with stupid things that need correction? Thx for any advice.
Fixed it for ya
“If you write frontend code, you don’t get a language choice.”
Um, what? I’ve written frontend code in BASIC, Pascal, C, Java, and C# – and that’s just counting the GUIs.
By ‘frontend’, he was implying ‘frontend for websites’
WPF, WebForms etc is techincally software frontend/GUI but I think the author meant for the web, for which we are limited to JS.
Can you clarify what you mean by “If you write frontend code, you don’t get a language choice”?
WASM cannot currently access the DOM directly.
A great read, thanks!
Maintainability is missing from you list.
unless,it is hidden in:
> Development Velocity (vroom vroom)
But many (especially junior) developers will confuse that sentence with ‘initial’ development speed.
Just as you spend more team reading code than writing it, you will spend more time maintaining your code than writing it… a lot more.
So maintainability should be among the the top items on the priority list.
Great article! Makes me feel a bit better.
Meetings may or may not also be a time waster. If you are talking about the usual daily check ins people have in the morning and/or after the work day ends, that’s fine, but meetings may also hinder the progress of the work being done, as developers need to stay focused on what they are doing without interruptions. But, in today’s modern age, that shouldn’t be too much of a problem if teams are using strong communication and project management tools
I simplify some of your suggestions with “code is write once, read many, so act accordingly”
Great read! Thanks!
This is honestly one of the most helpful guides ive seen. I’m fairly to new front end developing, looking for ways to get my foot in the door while I’m still in school. So I appreciate articles like these. Thanks a lot!
What every developer should learn early on: binary and hex. Before writing a single line of code.
Do you think there is a language which is better to learn how to program? Or better question still, to start gaining overall programming knowledge? Also, what about the future of the language, isn’t that relevant?
I am speaking from the point of view of a hobbyist and someone who solicits software/automation to further grow or improve a business operation.
Very good article, refreshingly free of the usual cliches. I was particularly interested to see you say that language choice largely doesn’t matter, which is something I’ve gradually come to realise; although its true you can make some really bad choices out of idealogy, any of the popular options people talk about for the kind of task you’re doing will probably work fine.
Although when you’ve got an existing team, choosing a brand new language and platform might cause you to lose a far bit of time up front becoming familiar with it. So I’d put “existing people’s familiarity with the language/tools” as near the top of your list.
Nice article mate, thanks for the info (mostly the workplace tips as i’m still studying).
Great article with valuable content. Thanks for this.
Great article, as a programmer with 40+ years of experience I agree with most of what you said. Regarding your remark about “un-performant” code, I’ve seen too many programmers try to be too clever in their code in a misguided attempt to make it faster. Also, there seem to be a lot of programmers who write code with short, non-intuitive variable names. Apparently, they think that short variable names will somehow make their code faster. This made some sense back when I first started programming (memory and CPU was very limited), but there is no need for this now. These kind of practices only make the code harder to understand and rarely improve performance. If they ever looked at how their code is compiled or translated to opcodes, they would see their foolishness.
Try to write code that is consistent, straight-forward and clear. Don’t worry about trying to optimize it on the first iteration. This is especially true for websites, where most of the perceived slowness is rarely caused by unoptimized code, but is usually caused by I/O delays, network issues or poorly-chosen database indexes.
For most of the performance issues in my own code, the code that actually caused the problem was usually different than what I suspected when I wrote it. As Donald Knuth said, “Premature optimization is the root of all evil”
I’ve also found automated code review tools to be quite useful. There are a lot of good tools available for various languages to help you to maintain a consistent style, spot common errors, duplicate code, etc. Manual code reviews are useful, but the automated tools avoid the personal issues, differing opinions and hurt feelings that can result from human reviews. They’re not a complete substitute for a review by an experienced programmer, but I’ve found them to be a useful addition.
This article was brilliant. Thank you for taking the time to write this!
Great article. I am not getting the part “Researching on non-work related topics”. Why do we need to research on non-work related topic in work time.
That was a nice article, telling plain and clear what we were learning when arriving in the company I’m in today. I join your point: companies would not lose this time if schools were more accurate with students on what a real “developer” is.
FWIW, we’re endeavouring to integrate some of these principles in a program I’m involved with at a Top20 university.
The teamwork thing in particular. The 2nd half is harder to teach, but breaking out of the “lone-coder” mentality is certainly something we’re trying to encourage at the end of CS/SE degrees.
They’re getting there with repo-hygiene, but it takes time.
Great read, ty
Some other simple things you can also do:
Keep your class sizes small, if it’s large, chances are you need more classes.
Keep your function sizes small, if it’s large, changes are you need more functions.
Keep the number of parameter arguments low, chances are if you are passing in more than 4 arguments, it may be better to pass in a object.
If a class has an Interface or abstract class, try to use that first, if it doesn’t work evaluate why so you can make an informed choice.
Use statics code analysis tools, they really help improve your code and help you learn.
You talk about ‘lines of code’ as a metric for a program.
Lines of code for a program is like weight (before loading), for an airplane,sometimes you go to have it, but you want to avoid it whenever you can.
> The notion that a language comparison could be reduced down to a single sentence is almost insulting. They’re languages, not Pokemon.
Are you saying that Pokémon aren’t complex, multi-dimensional creatures made for more than just Pokémon battles and Smogon tier lists?
A screwdriver will only drive screws that were made to fit perfectly to it. There’s a few “McGyver” uses, but that’s it, basically.
A hammer can bang anything into anything.
The logical conslusion, obviously:
Hammer > Screwdriver.
(Yeah, I probably took your analogy too far :D)
The notion that a Pokémon comparison could be reduced down to a single sentence is almost insulting.
Good read, though! I agree that lines of code, by itself, tells you very little.
Awesome read, thanks!
VBSript works in Internet Explorer. Not that I would recommend using it, but it’s there…
Awesome article! Glad I read it. As an artist and self-taught programmer, I appreciate you confirming some of what I have begun to realize…i.e. that programming isn’t just writing code, it’s solving problems and requires research and deep though at times and that reading/understanding other peoples code isn’t always so straightforward. I also picked a few good tips that I will try out, such as working to understand other people’s code as a training exercise and also writing in their style. Those two things will help me tremendously. The other thing I appreciate that I hadn’t really considered was checking the volume of answers on stack overflow. That would have been helpful on the project I’m working on currently. That being said, do you have recommendations for projects where you are breaking newish ground and you’re looking for answers to questions that haven’t been asked very often?
On readability I would add to the list: Code is modular.
Just kidding on the php comment? You disappoint me there. It’s a hideous language. But then again so is Python and many other languages. C (and assembly though it’s been a very long time ago now…) are aesthetically beautiful but of course many find C difficult (I say they’re making it harder than it needs to be especially in regard to pointers).
You say outdated languages exist but according to whom? And which systems?
‘would you ever say a screwdriver is better than a hammer?’
Yes. Yes I would.
As for reading other people’s code: I find it varies. Depends on their style and also my frame of mind at the time. There are other …variables. Including variables themselves of course. Modular code helps.
Another way of learning to read code? Figure out how obfuscated code does what it does e.g. winning IOCCC entries. (Better yet win it 🙂 – shameless bragging yes but it’s actually true). And as for C there’s also ‘The C Puzzle Book’.
I personally don’t think I could tolerate writing in another style that’s not my own. It would feel very very wrong and be very uncomfortable and possibly throw me off. But hey if it works for you that’s great.
It should also be remembered that although there is this stereotype that programmers are terrible when it comes to documenting their code (I am quite guilty of this I must confess) – it’s not just for other people but you yourself. Several years back I did something in a specific way but after a long while I looked at it again and it seemed completely wrong. I wondered what I was thinking when I wrote the code. So I obviously ‘fixed’ it. And then.. It segfaulted when that code was run. So I made a comment about why it was done that way. I even took the piss out of myself with it. And then of course I eventually did it a completely different and better way.
Code is never perfect? Indeed. Because nothing is perfect. You should of course be improving as time goes by (unless maybe you’re not actively programming). When I look back at some of my old code… It’s ugly and if it wasn’t for the fact it’s about learning I would feel shame and disgust. Actually some of it does disgust me but I don’t think I feel shame (hard to say for certain though).
On time spent per day programming. One reason it might not be easy to get a clear answer is it varies by person to person and project to project. It also depends on the stage of development, inspiration and so many other things. Also what one means by ‘work’ can change the answer. So can the fact that programming is an addiction (or at least it is for me).
I agree that taking brief breaks is a good idea. The same with not overdoing it but of course the trouble is when you have to be clear enough to realise that you shouldn’t be doing what you’re doing. But if you can do you should remember that there is another time and even though you might not get what you want to done before the day is over you will probably have a better idea the next day on how to go about it. You also may very well prevent making a terrible mistake. For example..memory corruption that does not go way out of bounds and so it segfaults long after the bad code has been reached.
As for uni – and those who learn there – much of the things you write come from experience and even if you’re told some of these things it might not be believed or full appreciated until you actually have enough experience. In fact some of these things you discuss apply to much more than just programming: life on a whole.
Anyway good essay/post/whatever you want to call it.
You are so right on taking a break. About ten years ago I was working at a place and on more than one occasion I would come across a problem that was just beating me I would spend hours trying to figure it out. It would seem simple, but my solutions were not working. So 5pm would roll around I would get up from my desk, walk out to my car, start driving, and would just be getting on the freeway entrance ramp when the voice in my head would go, “If we just did x and y then solved.” This was always just as I got on the ramp. It would never happen in the break room, it seemed exercising another part of my brain would allow the stalemate to be broken. In fact one time it bugged me so much I took the next exit and went back just try the solution. This happened enough I decided just walking around outside would for a few minutes whether I needed to or not would go along way in helping me to think. I took up photography and would take pictures on my walk as a way of forcing myself to get into a different mindset.
I find also that when I don’t want to take a break is when it will most help. Fortunately, my body demands a few trips to “the Thinking Room” every day, which is where I always find answers.
Thank you, enjoy reading it!
I’m recommending this article to my two co-devs, and all the students I teach who will listen! So many good points.
It’s always a bit depressing to see how “popular” and “default” are always “most-liked”. Perl remains a good language choice for many applications – after the recent sad death of my third co-dev I just inherited a live Perl-based site from the 2000s that functions swiftly and perfectly.
Although I’ve not touched Perl for awhile he was a great programmer and the code is pretty easy to read. He migrated to GoLang before his death, which then became his language of choice – there’s another legacy system he wrote in that language I will also have to get my (mostly JS and front-end) head around at some point.
Hey Ryland, thanks for the article. I enjoyed it and I agree in general. There is however something that annoys me in the following paragraph:
> 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.
It is funny to see that statement in Stack Overflow because I feel that it encourages people not to get engaged with new/immature technologies and as a result not to create relevant content in SO.
I feel that it kind of disrespects the time people put behind providing content in SO or other similar communities.
Regarding a person’s personal growth I would argue that one should learn and experiment with new languages in non critical tasks whenever possible. Pet projects and non work related stuff are usually pretty good candidates for doing so.
The most different the language is to what a person has already experienced the bigger the gain that comes from learning/using it.
I totally agree though that *in work related projects* one should go with the choice that would produce the best outcome in the fastest way. To do so one has to know of course the available choices and be able to pick the best for the task at hand 🙂
I never comment, but thought this article was great. I also thought that everyone else had perfect code. Also, avoided applying for roles as a developer because never fancied a daily marathon of coding. May consider it now.
Great Inputs in a simple manner. Thank you Rayeld
My own personal favorites. Code should be self-descriptive. So well descriptive that it’s self documenting. Except for edge cases where it’s hard to understand, then a few code comments come in handy. LOL. No idea how hard it is to read my own code. Try to make it so that it is “impossible to misunderstand” is also a hint I learned from teaching seminary classes. 🙂
Also “There are very few cases where the language choice actually matters” is untrue, you need to be able to hire programmers to “replace you” and “maintain your code” and some programming languages have a tendency to lead you to poor programming practices and thus less readability (maintainability). Ever tried to read a terse perl script? Also some languages result in the potential for “bug proneness” (your bugs, or bugs in the compiler) and those bugs can suck a lot of your time. Also some languages are “just faster” for programming in, you can get more done in less time. But it’s also true that sometimes banging out a prototype in PHP is just as good, business-wise, as doing it somehow else…see also http://www.paulgraham.com/avg.html “You were also safe if they said they wanted C++ or Java developers.”
Good one.. enjoyed reading it.
This is great and love the humor qwerks injected in every other paragraphs .
I love these, but I always feel alien reading a lot of stuff on stack overflow blogs and even on programmers SE, I must have worked at companies for 6 to 7 years, and all of them had the mind set of treating a programmer as a code spitting machine…
Where does this amazing companiesthat treat devs like human beings are?
” Mindset of treating a programmer as a code spitting machine…”
This article is worth sharing for, thanks a lot for these tips. Will surely put this into practice.
Thank you for sharing your thoughts and knowledge on this topic. This is really helpful and informative.
This blog is way too much informative for young developers. I am glad that this blog came into my sight! It states many of the issues I’ve faced and after reading this I can relate those very clearly. such as – “Do your best to not become defensive during a code review, and never take any comments personally.” However I don’t get in which perspective you thing – “You’re not your code.” because I strongly believe my code represents who am I.