I am a budding software engineer (now a sophomore, major in CS) and I really struggle to understand other people's programs. I want to know if this skill (or lack of it) can be a handicap for me, and if yes, then how can I develop it?
It is essential.
The way you develop it is by writing your own code (lots of it), and yes, struggling through reading other people's code.
The problem, of course, is that not everyone thinks the way you do. I was in a first-year Java class a long time ago, and we were given an assignment. Contrary to what I believed (which was that the answers would converge on three or four common solutions), everyone in the class had a unique solution to the assignment.
It follows that you should be reading good code.
This is one of the reasons that Design Patterns have become so popular, and why you should study them. Design Patterns provide a common vocabulary for programmers to communicate with, and tune your mind for "better" ways to solve computing problems.
You should also study algorithms and data structures.
Corollary: You should always be striving to write code that other developers can readily understand.
It is very important.
Once you graduate and get out into the world, most projects that you will work on will already have code contributed by others. Lucky is the programmer that gets to spend all their time on greenfield projects!
It is a skill that is acquired through practice and patience, and in many cases, it's a skill that many people don't really get much opportunity to work on until after they graduate and get that first job. Relax!
(although if your school has a co-op program, that would give you pre-graduation experience to working on large projects that are mostly written by other people AND it gets you academic credits! Something to look into, if it's available)
It's a major skill, depending of the specifics of where you work, it could even be more important than writing code itself.
As other skills, practice makes perfect! Try to read other programmer's code, debug it and what helps me personally, it's to refactor or improve small bits of code and expand from there.
There are distinct skills in both reading and writing code.
- One is syntax. Knowing what a method declaration looks like.
- The other is intent. Knowing why the method is there and what purpose it serves.
As for reading vs. writing. Yes reading is essential.
A few maxims that help many of us with that are:
- Code is read 10 times (at least) for each one time it is written.
- Someone else's reading the code is often... me in the future reading the code.
- I wouldn't defend my code style from more than 1 year ago, it has improved since then.
OK. So that's all great. Now down to what you're probably experiencing.
omg, this freaking huge codebase with tens of thousands of lines of source code and classes that are hundreds of lines long with crazy dependencies and every time I try to follow something I have to keep 10 levels in my head, etc, etc.
Sound familiar? Yeah. Deep breath. Relax. It's normal. It's what production systems are made of. People survive (and florish) in these seemingly incomprehensible situations because:
- tests (hopefully) exist and they also help document the system.
- programmers pair and often it brings more than double the result.
- good programmer get good at saying they don't understand until they do.
- changes are frequently just one or a few lines of code helping to isolate what to test
- code bases take months and even years to become familiar with
Most of these answers focus on the importance of code reading to self-improvement. I wholeheartedly agree with and endorse it.
There is another angle to beware of - even if you were a prodigy who could not benefit from reading other approaches (impossible, but for the sake of argument....), you would still need to know how to read code because of a concept that basically doesn't exist in the university setting: the vast majority of industry projects are brown field projects (i.e. either in or integrating with a pre-existing codebase).
The need to read code just to understand the existing codebase and processes is real. It is always possible to ask another developer questions about code, but this can only take you so long. People leave, switch projects, or time just plain passes. The low-level details fade from memory and maintenance programmers apply patches. At some point, there is no single source of truth except the code itself.
Good code hygiene, style guides, code reviews and documentation help, but at some point the code is the source of truth for what happens and the only way to find the answer will be to go get it yourself. Aside from its uses in self-development, the ability to read code is a distinctly separate skill from writing it.
Understanding other's code is something which you can not escape as you will be most likely working in team even if not in team you will google different stuff and you will have to understand sample code. So yes it is a must.
What I feel is that everyone gets that feeling may be some less than other specially at starting, you understand your code better than others code as you spend much more time with your own code than someone else code as you not only read but write and structure it in your mind. If you start spending more time with other's code and first try to see what kind of structure/flow is being used, this will certainly make you understand the code better.
To make my point even more convincing if you have some code which you have written one year back, try to understand it again and I can tell for sure you will take more time but less than other's code as you have idea about how you structure your code.
Hope this help, don't get disappointed it's perfectly normal. Spend more time with code and you will eventually get it.
Well, I've just been given a project with about 100,000 lines of code written by a team in a different country, and I have to make some very significant changes to a copy of their code over the next months, while leaving as much code in common as possible.
You tell me how I can do my job without the ability to read other people's code, fast. If you can't read other people's code, you are completely, utterly stuck.