Expect everything to change...

If you woke up one day resolved to be a great writer, you’d hear two simple pieces of feedback: write a lot, and read a lot.

In software, nearly everyone falls short on the latter. Early in your career, embrace reading code. Read widely and read often.

Why read code?

Great writers are a function of the writers they’ve read. Similarly, seeing diverse coding practices lets you expand your own palette when it comes time to write your own code. It exposes you to new language functionality, different coding styles, and important dependencies.

Reading your dependencies will make you a more productive programmer. You’ll know what the full functionality your dependencies offer. You’ll know exactly how they work and what tradeoffs they’re making. You’ll know where to debug when things go wrong.

Being comfortable reading code reduces the likelihood that you’ll have a “not invented here” mindset. The more you read, the more comfortable you’ll feel depending or augmenting someone else’s code, rather than building your own.

Cultivating regular reading will teach you tools and products widely different from your day to day work.

As a web engineer, reading a small part of a raytracer’s codebase will expose you to a wholly different set of constraints and user needs.

The more you read, the less scary it’ll be. Developing a strategy to read code then becomes a virtuous cycle.

How to “read” code?

Approaching a codebase like you would a book— reading from start to end—is a recipe for failure. Any medium-sized codebase is impossible to read linearly. Instead, “reading” code requires a substantial amount of active work.

I use this four-party strategy for approaching any complex code base (RSDW for short):

•  1) Run: compile, run, and understand what the code is supposed to do

•  2) Structure: Learn high level structure and review key integration tests

•  3) Deep Dives: Follow key flows and read important data structures

•  4) Write: Write tests and prioritize simple features and bug fixes

When you’re starting to read, be humble. A common mistake for early engineers is to weigh their code as “good” and that of others as “bad.” Instead, have some empathy for the styles of others and the uneven process that leads to the birth of most new software systems.

As a new developer, when you notice missing things, especially documentation and poor test coverage, help out. This is an exceptional way to learn, and will endear you to the others who develop the codebase, whose support will speed up your journey to learn a new codebase.

Second, reading new code is exhausting. You are intricately retracing code flows and trying to hold tens of new data structures and functions in your head concurrently. Be aggressive about taking breaks when you’re approaching a new code base. When I’m starting on a new complex codebase, a few good hours of reading is all I need to feel productive for the rest of the day.

With the right frame of mind, it’s much easier to go through the active process of digesting new code.

1) Run

The first step in reading code, isn’t to read code. It is to use the software.

Do not read code without understanding exactly what the software does and what functionality it offers. During this stage of reading, you should be able to make a summary of the code and have an understanding what the inputs and outputs could be.

Using the software forces you to get it to run. This means compiling the code (in some languages) and pulling down the dependencies. This is also the time to run the tests and review the output messages. If you have trouble getting the system running, this is the perfect time to document what it actually takes to compile and run the software.

2) Structure

Next, identify the most critical parts of the code. This is the part that is most different from reading a book. Instead of beginning at the beginning, you identify the key nexuses in the code.

Start with understand the structure of the code. At minimal, use tree | less and cloc to figure out the languages and files of the codebase.

To identify the most important files, look at the most modified files (git log --pretty=format: -name-only | sort | uniq -c | sort -rg | head -10^[2]) and use other advanced tools. Review the most important integration tests, listing out the functions that are called. Flag these tests for later.

There’s a cheat code for this process too: find someone who’s worked on the code before. understanding the structure is a good first task for a whiteboarding session.

3) Deep Dives

Once you have a lay of the land, dig in.

Programming languages revolve around two fundamental paradigms: functional (when actions are primary) and objects (when objects are primary). Similarly, when reading code, you should look at code flows (seeing the actions that are being created) and look at data structures (where the results of actions are stored).

Pick 3-5 few critical flows you’ve found from key integration tests or your review of the source files. Then dive deeper. Start at the top of a specific action and trace the code through. Some developers swear by debuggers that let you step through. Others prefer building UML diagrams or flamegraphs. If you decide to manually follow the code, make sure your editors is setup to let you use “go to definition” and “find all references” for quick navigation.

For data structures, review the data types and when key variables are being set. Use the debugger to interrogate these data structures at critical moments.

I also keep two markdown docs open for these deep dives. The first is a “level up my coding” doc where I list out new syntax I’m seeing and code patterns I find interesting for my own learning (others call this a glossary). This allows me to return for further investigation. The second is a doc that lists out key questions I have for the developers of the codebase. At this stage, I also add to the documentation when I notice gaps.

Deep dives are especially powerful in pairs with someone who knows the code. If I have limited time with a developer on the project, I always have them trace me through a few key flows.

4) Write Code

Unlike passive reading in literature, a critical part of “reading” code is writing code. The two easy ways to “read” is to write tests and address simple features/ bugs.

Writing tests is an active form of reading, forcing you to pay attention to the actual inputs and outputs of a particular interaction.

Writing tests is when you realize that you’re still missing important details. Writing tests imprints the code in your memory in a way that reading alone cannot. Unit tests are an easy way to start, and once I have some base mastery, I move over to integration tests that force me to understand increasingly larger parts of the codebase.

The other easy way to write early code is to write simple features or address easy bugs. Both these tasks don’t demand complete knowledge of the codebase, but force you to confront the code. They also provide quick wins that increases your confidence and motivation.

What code to read?

Early in your career, 60% of your time should be spent reading code. Maybe half of that should be code outside of the direct codebases you actually build on top of. That’s an awfully large amount of time to fill, so what should you read?

The easiest way to get started reading and the highest ROI is to learn your dependencies. Internalizing how your dependencies work lets you more easily debug and reason across your entire system.

The other high ROI path is to pick an important system at your company that you interface with, and read through it. Not only will this be valuable in your work, but professional codebases are different from open source codebases. They are written closest to how your team’s engineers feel is the “right” way.

Beyond the direct systems you interact with, cultivate an openness to reading widely. Early on in my career, I recommend putting aside an hour in the morning or evening to read through code outside your day to day work.

To start, pick a few easily understood codebases. Redis is known as a popular starting point in C. Famed codebases — say reading Vim — are more complicated with lots of nuance, but an easy way to start is to read a specific subsystem.

Try to actively read tools widely different from your day job. If you’re used to high level abstractions, learn an abstraction level (or three) down. If you work in one language, pick another language to read in your free time.

Find coders you respect or want to mimic and follow them on Github. Read a few of their other codebases. Stay up to date of their most recent work.

Create a reading group, a code club. In Stockholm, I heard great things about “The Classical Code Reading Group of Stockholm,” where they read classic codebases (I used to join at an affiliate run by Thoughtbot in NYC).

When you first start reading code, uour focus is not simply to learn a codebase, but to develop a mindset that will pay long term dividends.

Links

Articles on reading code

•  Ask HN: How do you familiarize yourself with a new codebase

•  Ask HN: How to understand the large codebase of an open source project?

•  Strategies to quickly become productive in an unfamiliar codebase

•  What's the best way to become familiar with a large codebase?

•  Tips for Reading Code

•  Software Engineering Radio: Software Archaeology with Dave Thomas (Podcast)

Books

•  Code Reading: The Open Source Perspective

(book)

•  Working Effectively with Legacy Code (book)

Codebases to read

•  Good Python codebases to read

•  Good Go codebases to read

Source

this article is taken from a post on a forum which can be found here
https://news.ycombinator.com/item?id=19431874 https://hackernoon.com/one-secret-to-becoming-a-great-software-engineer-read-code-467e31f243b0

Learning & Improving

The best way I know of to excel in software is to keep a growth mindset. The more you can learn and improve, the more career options you'll have.

Improvement can be broken down along two lines: input and output. I've tended to go through phases in my career where I've done more input than output, and (less often) vice versa, but I've found both to be essential for improvement.

Input

There are innumerable ways to gain knowledge: articles, books, papers, MOOCs, conversations, experimentation, project documentation, access to experts who are willing to answer questions, and many more. Quality and efficiency vary across these

Personally, I've gotten a ton of value out of reading books and applying what I've learned. concentrating your reading more on classic books that'll help you throughout your career. Book authors have spent many months, maybe years, distilling their years of experience into a well-crafted format that you can inhale over a few weekends.

I'll mostly stick to broad areas here rather than specific book recommendations, but you can check out my Goodreads profile for more specifics if you're curious.

Learn about software career development. For broad career development issues, I'll make an exception in this post and highly recommend Apprenticeship Patterns, The Pragmatic Programmer, and The Passionate Programmer. Bluntly, if you were to stop reading this post right now and go read those three books instead, I'd think you made a wise decision.

Learn about code. Again, I prefer books to blog posts.
Learn about the specific languages and frameworks that you're concentrating on.
Learn about software design & architecture principles and patterns.
Learn about test-driven development and refactoring.
Learn about the platform you're deploying to.
Learn about foundational computer science concepts.

Learn about communication. There's a lot of material out there, both in the software space and outside. The way you communicate is a crucial part of the way others perceive you, whether it's in conversations, in emails, or in documentation. Learn about logical fallacies, cognitive biases, and nonviolent communication. Look for materials on communicating in effective writing, presentations, and difficult conversations.

Read open-source code. My experience is that reading OSS code is most effective when you've got a specific purpose in mind. But it can also be instructional to clone a repository from GitHub, run the tests, try and reproduce issues in the issue tracker, etc. At worst, you get an idea of how someone else codes and what's easy or hard for you to understand. And at best, you'll find yourself leaning over into the output side of things, which we'll discuss next.

Output

Write code. This isn't necessarily the most important skill you'll need in your software career, but it's certainly the one that's most unique to the role of a software developer. There are lots of ways to practice writing code, but my personal favorite is doing code katas.

Code katas have a couple of main schools of thought, and I like both of them for different reasons:

• Repetition. By solving the same problem many times with the same or similar solutions, you get to understand the problem really well. This gives you a sense of mastery, which I've found to be great for my emotional well-being when I'm mostly frustrated by programming problems. You can treat these as either a meditation, where you're thinking deeply, or as a race, where you're honing your skills with the tools. Some folks even treat repetition katas as a performance, with or without musical or spoken accompaniment.
• New problems/solutions. The idea here is that most of the coding part of the job is about thinking about and solving new problems, ones that might be related to ones you've seen before but aren't identical. With new problem katas, you're intentionally putting yourself in the uncomfortable position of not-knowing, where we each need to learn to be OK as we're moving toward solutions. You can find lots of examples of bite-sized katas—many have ridiculous names, but they can still be great exercises to work through.

Katas are typically fairly constrained problems compared with "the real world"—more on the order of a single sitting, though some can get quite tricky and take much longer.

Breakable toys are much more realistic and larger-scope projects than katas, but they still aren't mission-critical.So it's OK if they get broken as you're learning. Having a breakable toy lets you see how different ideas work in the long term, which is super-helpful in the work world.

Open source software can be pretty intimidating to get into, but there are a few reasons I still think it's a good idea to look at. First, you can get practice learning a new codebase. Second, for many (not all) open-source projects, the level of code quality is pretty high. You'll get a chance to see how experienced folks approach problems and solve them, by browsing issue and pull request history.

Learn to use the project really well if you don't already. This will force you to go through the existing documentation, and you'll probably find some low-hanging fruit: typos, grammar issues, hard-to-understand explanations, etc. I've also heard good things about OSS issue aggregators like OpenHatch and Up for Grabs for finding projects that fit the bill here.

Practice empathy and communication in your daily interactions. When little misunderstandings occur, ask yourself how they happened and what you can do in the future to prevent them. And how can you get past the misunderstanding with everyone feeling better afterward than before. When you're talking, ask yourself what your audience needs from you—do they need all the details, or do they mostly care about the highest-level bits? These skills are among the most crucial for any job that requires collaboration.

Managing your time

decide what your goals are at a high level, and find ways to move in that direction incrementally. One idea is to take a tip from agile project management: take your big hairy audacious goal (product), figure out the first step or two towards it (releases), break the first one down to the first few medium-sized goals toward it (epics), and break those down into goals that you can knock out in a single sitting (stories). In this way, you can fit learning into the space that's available, rather than having to rely on luxuries like wide-open nights and weekends.

Find mentors

We all need feedback. Without feedback on how we're progressing, it's easy to divorce our own self-assessment from reality, and to think that we're doing much worse or better than we really are.
try to find at least one person who can help guide you in your progress. My first real mentor didn't have a formal mentoring role, but he was the developer in the next cube, he was a few years ahead of me in experience, and he understood how to communicate the basics. Between his direct feedback and the books he told me to read
You can find mentors outside the workplace, too.

• CodeNewbie is a Twitter chat, podcast, blog, and community with tons of great ideas about breaking into and excelling in this industry, with participants at all levels.
• Social media: Despite its [my] faults, I've found Twitter to be particularly well-populated with software experts sharing tips, links, and stories. And some people are willing to answer questions directly—others have too many folks jostling for their attention, so don't feel too bad if they can't make time for you directly.
• User groups: If you're in an area that has them and you can make the timing work, user groups can be a great place to meet other folks who are excited about software. Check out Meetup for topics you might be interested in. Introduce yourself and make connections—if you're like me this will be hard, but you might just meet your next employer here.
• Open source software: The people reviewing your pull requests are already giving you direct feedback! Maybe not career-level stuff, but they might be up for that too as you contribute more.

the name of the relationship isn't all that important—what you really want here is to get external feedback and make progress toward your goals.

my thanks to this fantastic blog post:
https://8thlight.com/blog/colin-jones/2017/10/24/advice-for-early-career-developers.html