Even Experienced Programmers Can’t Alway Decipher Other’s Code, Experience Shows

In the intricate world of software development, proficiency in coding is often equated with the ability to craft efficient algorithms and produce clean, error-free lines of code. However, even the most seasoned programmers sometimes find themselves grappling with a seemingly counterintuitive challenge: understanding another developer’s code. We dug into Quora, and found that many experiences resonate with this specifics.

It might be tempting to assume that an experienced coder can effortlessly dive into any programming project, instantly grasping the logic and nuances. Yet, many find that reading and comprehending another person’s code presents its own set of unique challenges. Why is it that even veteran programmers sometimes stumble when faced with another developer’s work?

Readability & Formatting

Many Quora users echo a common sentiment: readability matters. One individual recounted a personal experience:

“I found code recently that I apparently wrote three years ago that I couldn’t read.”

The complexity of the code, mixed with the unpredictable use of tabs and spaces, made it nearly incomprehensible, even for its original creator. This story underlines the importance of consistency and the hazards of mixing styles and formats, which can make code puzzling for future readers—or even for oneself in retrospect.

But is it solely about readability and formatting? Another user opined that while clean code matters, context is equally crucial.

“Programming code is about implementation details; it doesn’t give you a big picture… To get that general idea, you need software specification.”

Hence, while well-structured code helps, a comprehensive specification that offers a bird’s eye view is indispensable.

Different People, Different Codes, Different Competency Levels

Still, the onus isn’t solely on those who write the code. As many users have pointed out, diving into unfamiliar territory—whether it’s a program, book, or any form of content—always requires some adjustment. One person remarked,

“No matter what your level of experience, if the source code is not readable, you’re going to have some struggles with it.”

The process can be “painful,” as you grapple with unfamiliar logic, a desire to rectify perceived flaws, and the overarching pressure to not disrupt a working system.

Yet, some criticisms are more scathing. A number of users highlighted the endemic problem of insufficient comments, unclear variable names, and the sheer magnitude of poorly crafted code that underpins many modern systems. Citing Weinberg’s Law humorously, one individual remarked,

“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”

This is more than just a joke for many—it’s a sobering reflection on the foundations of our digital age. With over half a century of experience, another programmer shared:

“Most programmers do a poor-to-terrible job of documenting programs. ‘Spaghetti code’ is not simply a figure of speech.”

They stressed that maintenance, which makes up a significant portion of programming work, often sees many rounds of updates without consistent documentation. The dissonance between evolving code and stagnant documentation is another layer of challenge.

How Do You Go About Reading Code Written By Someone Else

We’ve all been there—staring at a screen filled with lines and lines of code written by someone else, trying to make sense of it. For many self-taught coders (STCers), understanding their own code is one thing, but delving into someone else’s code can feel like entering a maze without a map. And this isn’t a singular sentiment; it’s one shared by countless developers worldwide.

The truth is, reading and understanding someone else’s code isn’t just about ‘deciphering’ it. It’s about building comprehension skills that will aid not only in understanding other’s work but also refining your own. Here’s a method we’ve found could work:

1. Start at the end, find one thing you know the code accomplishes, and trace those actions backward.
2. Like unraveling a chain link by link, this process helps you see the big picture, one segment at a time.
3. It’s analogous to being in a dark room and gradually illuminating sections until the entire space is visible.

Using this method, you’ll soon identify patterns like the organization of the code, the style of coding, and even get an inkling into the coder’s thought process. This approach is a testament to the fact that behind every piece of code, there’s a human trying to solve a problem. As you repeat this process with different codebases, you’ll begin to recognize common patterns and structures. Just as in the peculiar yet enlightening example of ‘chicken sexing’, where individuals can determine a chick’s gender through repetitive exposure, a programmer’s ability to discern and understand code nuances improves over time. This process hones their intuition and allows for quicker comprehension and problem-solving.

So, the more code you expose yourself to, especially high-quality code written by expert programmers, the better you become not just at understanding but also at writing. As you consume and understand more and more code, you’ll find that your own coding improves. Your references will be understood faster, past code will be comprehended at a glance, and your overall programming experience will become more enjoyable.

Conclusion

In sum, reading another’s code isn’t just about decrypting lines of programming—it’s about navigating a web of past decisions, understandings, and, often, shortcomings. The stories and perspectives shared by these individuals serve as both a cautionary tale and a guide: a call for clarity, thoroughness, and consideration for those who might tread the paths we’ve paved.

Related

A*Help Insights - sign up for our Newsletter

Sign up

Thanks for signing up!

Something went wrong. Please try again later.

Follow us on Reddit for more insights and updates.