DEV Community: Borja Lorente

Fearless Code Review Checklist

Borja Lorente — Wed, 26 Aug 2020 20:50:51 +0000

Note: This content was originally posted in my blog, Beyond The Loop.
If you like it, head over there or follow the blog on Twitter (@BeyondLoop) for more!

This is a very long post, but it's worth reading! If you're in a hurry, I'll leave the condensed version of the list at the end.

Code Review is a fundamental skill for engineers.

Being able to read a set of changes and derive useful insights and constructive feedback will make you invaluable as a colleague. Plus, it will result in better code!

However, it can be very intimidating at first. It's normal to see your first Pull Request and not even know where to begin.

I had this problem when I first started, and so I did what's always worked for me:

I asked my senior colleagues about their thought process. How do they approach code review? What do they look for? What questions do they ask?

Taking all those answers into account, I compiled my own checklist. A series of questions I can use to guide my thoughts during a review.

Having a defined, repeatable process helps me break down the process of reviewing into smaller chunks, making it a lot less overwhelming.

This list has been invaluable for me over the years. I hope it will be valuable to you as well.

Step 1: Read the description

Reviewing code is the act of finding out how well it solves a problem.

Before you jump into any code at all, you need to have answers to some questions. It's important to do this before even reading the code because it's really easy to get lost in the nitty-gritty of code style and micro-optimization, forgetting to think about how these changes affect the big picture.

In fact, most of the value of a code review will come from answering these questions, not from reading the code!

What problem is this change trying to solve?

This is a vital question. Every PR should solve one (and only one) problem.

The problem could be "We need this feature, and it's missing", or "There is a bug, and we need to fix it".

Reviewing a PR is the process of finding out how well it solves a problem. Therefore, a deep understanding of the problem is a vital first step.

Make sure you understand the problem, how it manifests, and how it affects users.

I've used the word "problem" a lot, but that's because it's important!

How would you solve this problem?

Before learning how the author solved the problem, take a moment to think about how you would solve it.

It doesn't have to be a full solution, just the general idea of how it would look like. You'll be surprised at how quickly you can come up with the general structure for it!

This is useful for two reasons:

It will tell you whether you really understand the problem. If you can't come up with an idea of a solution, it's very likely that you're missing some context, and should find out more about the parts of the codebase involved with the change.
Having a fresh set of ideas on the problem can lead to a completely different, better solution! If this is the case, that's great! Talk to the author, and discuss the new solution.

When you have your idea for what a solution would look like, the next question is:

What solution did the author present in this change?

This should be clear from the title and description. Remember, we haven't even looked at the code yet. Make sure you understand (and agree with) the solution and all its pieces.

Asking this question often results in us realizing that:

We don't quite understand some piece of the solution: If this happens, you need to figure out what exactly you don't understand, and read existing code and documentation until you do!
We don't agree with the solution: If this is the case, stop the review, and focus on discussing this with the author. Present your concerns, add some alternatives, and find a solution that satisfied both you and the author!

Do you agree with the effects of the solution?

In most engineering problems, there are tradeoffs. A more complicated solution might run faster, but be harder to maintain down the line. It may require more memory than a slower solution. On the other hand, a simpler solution might be slower, but a lot easier to maintain, and it may not be performance-critical.

Before jumping into the code, we need to make sure we understand what the tradeoffs are, and we agree that those are the right tradeoffs to make.

You made it!

If you made it this far, it means you now have a deep understanding of the problem, and agree that the solution is the right one.

Great!

This thought process alone will make your reviews incredibly impactful because you will be identifying big problems first, and not getting lost in the minutia.

Now, with this deep understanding, we're ready to dive into the code.

Take a deep breath, and let's get into the nitty-gritty!

Step 2: Read the code... several times

... we're going to go through the changes multiple times, answering a different question each time.

Let's jump into the code!

Now... where do we start?

It can feel very intimidating to just jump into the review page and start reading. It's overwhelming! Where do you even look?

The main problem here is that we're trying to think about everything at once. I don't know about you, but I can't do it.

When we're reviewing code, there are many things we should look for:

Does the code actually implement the solution described in the description?
Are there any performance concerns?
Is the code well-tested?
Does the code conform to formatting and style standards?

That's a lot to think about! So, instead of trying to answer all of these the first time we see the changes, we're going to go through the changes multiple times, answering a different question each time.

This will reduce the scope of what we're thinking about to just one question.

For instance, let's see how we'd answer the following question: "Is the code well-tested?"

Well, there's a clear path forward: We know we should start with the tests, and see if they cover all the cases we think should be covered. It's definitely not as intimidating!

The trick is to do the same for each question:

Pick one question.
Go through the code changes to validate that question.
Leave comments.
Go to 1.

We want to check performance? If we understand the pieces involved, we should have a good idea of which ones are sensitive to being slow (because they run often). We should focus on those first.

We want to check formatting and naming? We can forget about what the code does, and just read the words and symbols.

You should build your own list of questions to ask the code, but here's mine:

Does the code implement the solution described?
Does it have conscious performance tradeoffs?
Does it have unconscious performance inefficiencies?
Does it conform to the naming and style guidelines?
Is it well-tested?
Are there any hard-to-understand parts? Do they have to be there? If so, are they properly isolated and documented?

One More Time From the Top

I promised a condensed checklist, so here it is! I'm planning on making this into a free infographic that you can print, so subscribe to the mailing list to get notified when that happens!

**Before Reading Code**
These should be checked by reading the description and existing code, not the changes themselves!
- [ ] I understand the problem this change is trying to solve.
  - [ ] I understand and agree with why we need this feature or bug solved.
  - [ ] I understand all the pieces involved in causing the problem.
- [ ] I have a general idea of how I'd solve the problem.
- [ ] I agree with the solution proposed.
  - [ ] I agree with the performance tradeoffs presented in the solution (if the change is perf-sensitive).
  - [ ] If not, I have talked with the author until we've reached consensus.

**When Reading the Code**
We should make one pass for each of these questions.
- [ ] The code implements what's actually described as the solution.
- [ ] The code doesn't have unintentional inefficiencies.
- [ ] The code conforms to naming and code style guidelines.
- [ ] There are no unnecessary hard-to-understand parts.
  - [ ] The ones that are there are properly isolated and document.
- [ ] The code is well-tested.

A review that looks at all of these things will be invaluable in generating better code!

The End

That's it!

Code Review Checklist: Done!

Granted, this is a very time-consuming process. But keep in mind that your first 5 reviews will be about learning to review correctly. Code Review is a skill, people are expected to take some time to learn!

And the good news is, once you get the hang of it, it gets a lot faster.

After those reviews, you start asking questions one by one unconsciously, and you develop an intuition of where to start.

After dozens of reviews, I rarely go step by step in the checklist anymore, but I'm glad I have it for those tricky reviews!

What's on your checklist? I'd love to know either via Twitter @BeyondLoop, or email.

Note: This content was originally posted in my blog, Beyond The Loop.
If you like it, head over there or follow the blog on Twitter (@BeyondLoop) for more!

5 Non-Technical Tips to Improve Your Technical Interviews

Borja Lorente — Fri, 14 Aug 2020 16:29:12 +0000

Note: This content was originally posted in my blog, Beyond The Loop.
If you like it, head over there or follow the blog on Twitter (@BeyondLoop) for more!

Technical interviews!

We all hate them, we all have to live with them!

They can be incredibly nerve-wracking! After all, you’re gambling your future job on coming up with a clever solution to a complicated problem on the spot!

Well, not quite.

While having a sound technical profile is very important for a candidate, there are other equally important, non-technical things that a candidate should do.

I’ve been on both sides of the interview many times, and I believe that there are things that most people are not doing enough of.

Here's a list of tips that:

Anyone can start applying today, regardless of skill level or seniority.
Will significantly increase your chances of finding a good job match.

These tips do not replace technical knowledge. You still have to know about algorithms and data structures.

Rather, they complement that knowledge and help you present it in the best way possible.

Without further ado, here are the tips:

🎭Prepare stories to showcase yourself

Show, don’t tell.

- Cinema wisdom

It’s all well and good to tell the interviewer that you are a hard working team player.

However, you’ll make a much deeper impression if you demonstrate those traits with real stories.

To do that, think about a trait you think the interviewers will find desirable. If you're applying for a junior role, it can be ability to learn quickly and respond well to feedback. If the prospect role is more senior, it can be the ability to provide good feedback and mentor people.

Then, think about a time in your life where you exhibited that trait. It doesn’t have to be around coding, the point here is to display your personality.

Here are some examples:

You had a conflict with another person, which you de-escalated until you reached an agreement, and both parties were happy.
Two parties had a conflict, and you helped mediate between them and come to agreeable terms.
You wanted to learn something, but there was no good documentation online. You did the research, figured it out, and improved the documentation!

Got the story? Great!

Now, tell it to someone a couple of times. We don’t want it fully memorised, but we don’t want the nerves of the interview getting in the way!

Walk into the interview ready to share that story, and I guarantee you’ll have at least one opportunity to tell it.

Take advantage of this to show your best side!

🤝️Show them you're great to work with

For the interviewer, an interview is the chance to decide whether you’re somebody they’d like to work with.

Think about that for a second. What qualities would you like your coworkers to have?

Sure, you’d like them to be technically capable, but what other qualities would you like from them?

Maybe you’d like them to ask politely for help in difficult situations, or maybe you’d like them to adapt gracefully to changing requirements.

Whatever your list is, I recommend you write it down. Then, read it before heading into the interview.

These are things that you need to display, and things that you expect your future coworkers to have.

Try to convey each of those things through your speech and actions! Show them how fun it is to work with you. And don't forget that interviews are a two-way street. Look for these same qualities on your interviewers!

🦻Listen to the interviewer

The interviewer is not there to make your life harder.

Well, that’s not true.

The interviewer is making your life a little bit hard on purpose by putting you on tough spots, but they’re not doing it to see you suffer.

They’re doing it to see how you react.

It’s completely normal to get stuck in an interview, to find the problems hard to solve. The interviewers expect this. They designed the wustion hoping that would happen!

However, they will usually have a list of hints to give if they see you’re having a hard time. That's expected, because it tests how well you listen to feedback, and how a normal code pairing session would go with you.

But you have to listen carefully to pick up on them!

Therefore, every time an interviewer tries to say something, assume they’re guiding you towards the right answer, and listen carefully!

If the interviewer is trying to help, and you’re not listening, what does that tell them about their potential interactions with you at the job?

Assume the best intentions from the interviewer, and make an effort to listen as though they were a close friend.

🗣Think out loud

Good interview questions are designed to put the candidate in tough spots, so that the interviewers can see how they react to them.

In an ideal interview, the candidate works through a problem they haven’t seen before, and the interviewers can see how they work through the problem.

The question will be tough, which means there will be times where you will be tempted to stop talking and think. Resists that temptation as much as possible!

As we said before, the interviewer is not there to be mean, or to see you suffer. If they see your thought process straying too far from the right path, they will try to help!

But, for them to see you’re veering off the right path, they need to know what you’re thinking!

So, do your best to think out loud, even if you’re not sure about what you’re saying!

💡If you don’t make it, ask your recruiter for feedback

This one is pretty straightforward.

We're not going to get all the jobs we apply for. That's normal and expected!

However, we can debug our own approach to interviews. As with everything in life, we can learn to become better candidates.

In order to learn, you need to know what you could have done better. Sometimes, it’s pretty hard to know that!

At least, for us as the candidates.

For the interviewers, they know exactly why they said no. In fact, they probably had a detailed discussion about it, where the recruiter was present!

Take advantage of that!

The company would have loved to see you succeed so that they can stop spending time in the hiring process. They want you to grow into a good candidate for them.

For this reason, after an interview, it’s very reasonable to politely ask the recruiter for feedback.

Most recruiters will give you a lot of the context that went into the hiring decision.

That way, you can know exactly what to work on for next time!

💃Have fun!

I know this one is probably the hardest.

But, think about it this way: If you’ve made it to the in-person round of interviews, you’ve made it pretty far (~85% of the candidates don’t make it)!

Chances are you’ll get a job soon.

So, instead of seeing the interview as this frustrating trial by fire, try to see it as an opportunity to talk about an interesting problem with a very knowledgeable person.

An interview is an opportunity to have a conversation about an interesting problem with a very knowledgeable person.

Try to (gasp!) enjoy the experience, and even to learn something along the way!

Disengage yourself from the result, and try to get the most out of the interview regardless of whether you get the job.

And this is not just for your benefit:

If you are enjoying the experience, chances are the interviewer is enjoying it as well. And coming back to the second point: Who doesn't want to work with someone that makes hard problems fun to work on?

So: Relax, and have fun!

Conclusion

These are all things that everyone would benefit of doing more of.

If these have been helpful at all, I’d love to hear from you! Nothing would make me happier than contributing to someone getting a job, even a little bit!

Why learning Rust is great... As a second language

Borja Lorente — Sun, 09 Aug 2020 16:29:08 +0000

Note: This content was originally posted in my blog, Beyond The Loop.
If you like it, head over there or follow the blog on Twitter (@BeyondLoop) for more!

So, you've taken your first steps into programming. Welcome!

You've taken some courses and built some amazing things. You've caught the programming bug. Congratulations!

Maybe you started with Python, doing some neat data analysis. Maybe with CSS+HTML+JS, creating beautiful projects. Maybe something else.

Whatever the case, you're now comfortable with functions and loops, and your Googling has decreased considerably.

What's the next step? What can you get into that will be exciting and interesting?

I believe, for most people, the Rust programming language is a great answer to that question.

By the end of this post, I hope you will too.

If you are, stick around for some resources on getting started with Rust!

What is Rust?

Let's start from the beginning. What is Rust?

According to the official webpage, rust-lang.org Rust focuses on 3 things:

Let's break it down:

Reliable software: Rust, by design, will help you think hard about your software, and figure out where it can fail. This will make you ask yourself questions that you didn't even know to ask. It will train you to think like a great software engineer.
Efficient software: Rust makes efficient code easy to write. Usually, the simplest way to do something is also the most efficient way.
For everyone: Rust takes inclusivity very seriously. The community cares deeply about everyone feeling safe and welcome. This shows in every interaction, from the great culture around tutorials and documentation to the very friendly meetups organized all around the world.

With that alone, it sounds like a great language to me!

Why second language?

Okay, so if Rust is so great, why learn it as a second language?

Well, here's the thing: Rust achieves these goals by giving you full control over your computer's resources. You decide exactly how much space everything takes, down to the byte level. Other languages that do the same are C, C++ and Assembly.

Now, as we all know:

With Great Power Comes Great Responsibility GIF from Spiderman GIFs

When you're first learning to code, you don't need that much power. Your projects will be small, so most computers will run them without issue. They don't have to be super reliable, either.

Therefore, you shouldn't take that extra responsibility. It will end up getting in the way.

But, once you're ready to take the next step and work on bigger projects and applications, you will need to learn many of the things that Rust helps you think about.

So. What does Rust teach you?

Rust teaches you to read (and understand) the output of your tools

Rust will try to catch and fix a lot of your bugs before it runs your code.

This is great because it means that it will teach you to think about things that you weren't thinking before (more on that later), but it also means that it will produce a lot of error messages.

In fact, programming in Rust is often described as "a conversation with the tools", where ask the tool "is my code alright?" and the tool responds with great error messages.

Inevitably, this means that you'll need to get into the habit of reading error messages carefully. Rust's error messages are thoughtfully crafted to be informative and actionable.

Sometimes, Rust will even guess what concept you need to understand to solve the error, and point you to the right documentation!

Let me repeat that.

Rust will see the bug, catch it, guess "this user doesn't quite understand X", and it will give you a link to it!

If you get into the habit of carefully reading and understanding error messages, your productivity and learning will skyrocket.

Now, let's dive into some more concrete things Rust will teach you.

Rust will teach you about types

Let's look at the following example in JavaScript:

function add(a, b) {
    return a + b
}

What are a and b? Are they numbers? Letters? Lists?

It doesn't matter. As long as the + operation makes sense for them, you don't have to know anything else about a and b.

Languages that beginners tend to learn first don't enforce types. And that's a good thing! In small applications, types can end up getting in the way.

However, as you start working on bigger and bigger projects, you start to realize that types have one benefit:

They give you information about other parts of the program without having to read it. If used right, types teach you how to use a function without having to read the body!

Let's look at the same function, in Rust:

fn add(a: i64, b: i64) -> i64 {
    return a + b
}

The signature of the function (add(a: i64, b: i64) -> i64) tells us exactly what the function does:

If you give me two numbers (i64 is a type of number in Rust), I will add them and give you another number back (-> i64).

This is much more descriptive than the other example!

Eventually, you're bound to come across types in your programming career, and Rust will teach you all you need to know!

Rust makes you aware of mutability

Most popular programming languages are mutable by default. In both Python and JavaScript, a function can change its parameters. In other words, this is reasonable code in most languages:

function doSomething(list) {
    list.push(5)
}

When a function changes one of its parameters like that, it's called a side effect. Side effects are generally best avoided.

There are many examples of why this is generally a bad thing, but it's not something I want to argue in this article. There are many great articles out there arguing for it. Search for "immutability".

In Rust, you need to say which of your variables are expected to change. Let's look at the same function, written in Rust:

fn doSomething(number: &mut usize) {
    *number = 2
}

Notice the little &mut after the parameter name: It tells you that the function is allowed to change the parameter.

As you can see, you always know whether a function will change what you pass to it, just by the first line!

Yet another piece of information that Rust gives us to guess what a function does without reading it.

Rust will teach you about memory management

Let's take a look at this code:

var hello = "Hello World!"
console.log(hello)
console.log(hello)

For this code to work, the computer has to remember what the value of hello is, all the way until the end of the program. In other words, it has to store it in memory.

A computer has a finite amount of memory or things it can remember at any given time. Incidentally, this is one of the reasons why your phone closes background apps, or why your whole computer becomes slow when you have too many tabs open.

For small applications, this is not really a concern. There aren't that many things the project needs to remember.

However, it's not uncommon for big applications to have to remember several Gigabyte's worth of data at once, which can quickly become a problem.

Let's say we want to represent a 2D point in JavaScript. We could write the following:

var p = {
  x: 0,
  y: 0
}

How much memory do we need in order to remember p?

Trick question, the code doesn't tell us.

Rust, however, lets you choose exactly how much memory it takes to remember something and how long the computer needs to remember it for.

Let's see how we can implement that same point in Rust:

struct Point {
  x: i64,
  y: i64,
}

let p: Point = Point{x: 0, y: 0}

How much memory does it take to remember one p?

Well, a Point has one x and one y. They are both i64. An i64 takes exactly 64 bits of memory. So, a Point will take exactly 128 bits of memory.

Most types in Rust can be broken down this way. Thinking about code this way will make you aware of when you're remembering too much!

Now, there is a lot more Rust does about memory management that I won't get into here. Suffice to say that it's a great language if you want to learn about it!

Sounds great! Where do I start?

These are just a few reasons why I think Rust is great as a second language.

If I've convinced you and you want to give it a try, check out these resources!

The Rustlings Course: An open-source series of exercises that guide you through setting up your Rust environment and writing your first lines of Rust! If in doubt, start here.
The official website has a Learn Page with the most popular and amazing resources.
Rust has an amazing community that is more than ready to welcome newcomers. Check out the official website's Community Section for more links.
If you're an experienced developer coming from another language, check out intorust.com. It's a series of videos explaining the fundamental differences that Rust has with other languages like C++ or Java.

Conclusion

Rust is an amazing language, and I personally love it. I wouldn't recommend it as a first language, but it's a fantastic tool to guide you in those next steps beyond the beginner phase!

What do you think? Whether you agree or disagree, I'd love to hear from you!

Reddit for programmers

Borja Lorente — Thu, 06 Aug 2020 08:14:16 +0000

Reddit is an amazing resource for beginner programmers. It's a goldmine of references to valuable materials and a place where a lot of great folks gather to give each other feedback.

It has helped me throughout my career and, in this post, I want to explain how you could be engaging with Reddit's communities to skyrocket your engineering skills.

Why Reddit?

At its core, Reddit is a place where communities live. These communities, or subreddits revolve around a particular concept. For instance, r/cpp is a community of people that know about the C++ language, r/gamedev is about developing videogames, and r/learnprogramming is about... well... learning how to program.

There is probably a subreddit for everything you can think of, no matter how big or small.

The key concept here is community. A community is a place where like-minded people get together to talk about something that interests them.

Communities are incredibly valuable when developing your skills. They can give you direction, encouragement, and great advice!

Unfortunately, communities are sometimes hard to come by, or difficult to get into.

This is what makes Reddit such a good resource. The communities are already there, ready to help! It's the perfect place to ask questions and find people who have walked the same path as you.

How Reddit?

Hopefully, I've convinced you that Reddit is a valuable asset to have for your career.

Now, how can you leverage the power of these great communities? I've found that there are three main ways of benefitting from a community:

Reading their curated resource lists.
Seeking feedback from the community.
Giving feedback to other members.

Let's go one by one.

The sidebars and FAQs are golden fountains of knowledge. Use them!

Most subreddits get a lot of beginner questions. Eventually, most of these questions start repeating over time. To help with that, most subreddits have compiled answers and resources in their "about" or "FAQ" pages. The size of the "about" page depends on the size of the subreddit, with the largest subreddits having fully-fledged wikis! (like this one, from r/fitness)

Whenever I want to learn something new, like a new tool or a new language, my first instinct is to check the sidebar of that subreddit.

These "about" pages (also called sidebar) have one advantage over Googling things:

All of these resources have been useful to real humans with the same problems as you're likely to face.

Plus, nobody makes any money with these resource lists, so there's no incentive to advertise products that are not genuinely useful.

These lists are pure gold. When a new hobby piques my interest, the first thing I do is to check the sidebar for that hobby's subreddit.

It's the same with programming. Whenever I want to learn something new, like a new tool or a new language, my first instinct is to check the sidebar of that subreddit.

I don't know how else to put it. Go check the sidebars!

Seek feedback from the amazing community

We all need people who will give us feedback. That’s how we improve.

-- Bill Gates

Good feedback is the cornerstone of learning. However, good feedback is hard to come by, because it requires someone to give you their thought, attention, and careful consideration. The good news is, most subreddits are full of people eager to help!

Subreddits are amazing to get some expert eyes on your work. There are only two rules that ensure that you have a good interaction with a subreddit:

Read the subreddit's rules. When you post a question or a request for feedback, you are essentially asking for people's time. Treat that time with respect by reading the rules and doing your best to fulfil them.
Write thoughtful questions to get thoughtful answers. If someone wants to help you, you need to give them as many details as possible. Make questions concrete, and give enough context so that the reader can immediately understand where you're coming from. This is easier than it seems since most subreddits have very good guides on asking good questions, like r/learnprogramming.

Most subreddits are full of knowledgeable people willing to help. As long as you are respectful of their time, don't be afraid to ask them for answers or feedback!

Note that there was no rule about how experienced you need to be to post a question. Even if it can feel intimidating to post a question and look dumb, it helps to keep in mind that a moment of looking dumb now can save you months of struggling. From this perspective, not posting is much worse than posting a "dumb question".

That said, most subreddits have a mindset of "no question is too dumb", as long as you follow the second rule and put some real effort into asking the question properly. So ask without fear!

Now, there is another great kind of feedback you can get from a subreddit: Code review.

If you're working on a personal project, chances are you're not too sure of what the right way to do something is. Showing your work to a subreddit is a great way of getting the feedback you need to ensure you're on the right track.

Here's an example:

When I was in college, I wanted to learn the C++ language. I was able to write some code that worked, but I didn't know if what I was writing was "the right way" of writing C++ code (also called "the idiomatic way").

I posted my code in r/cpp_questions, asking specifically for that kind of advice. The response was amazing!

I got lots of great advice that it would have taken me months to figure out on my own:

Reddit post: So I made a CHIP-8 Interpreter as my first production-level C++ project, any advice?

One more time: Most subreddits are full of knowledgeable people willing to help. As long as you are respectful of their time, don't be afraid to ask them for answers or feedback!

Help people in the subreddit to develop your code reading and communication skills

I hope this doesn't come as a surprise, but these two skills are the mark of a senior engineer:

Senior engineers can navigate a codebase they've never seen before efficiently without much direction.
Senior engineers can communicate technical concepts effectively to other engineers of any level.

If someone is seeking people to review their project on Reddit, this is a great opportunity to develop both of those skills!

Reviewing someone's project forces you to tackle a codebase you've never seen before, so you train your code navigation muscles.
If you get stuck, you can always go back to the post and ask the author questions or clarification! Chances are they are delighted to answer them. After all, that's why they posted in the first place!
Reviewing that code may expose you to techniques and technologies you've never seen before.
After reviewing someone's code, you need to formulate your feedback in a way that's useful for them. This will train your communication muscles.

Don't be afraid to give your feedback, especially if you're still starting out. We all want to write readable code, and your feedback and questions can help the author realize where the author could make their code more approachable!

Sidenote: There is not a lot of good material on learning to approach new codebases, but I'm working on a manual to help with that. If you're interested, subscribe below so that you don't miss out when I announce it.

On top of it all, you're contributing to the well-being of the community and helping another fellow programmer, which is always awesome.

Recap

I hope I've convinced you that Reddit is a good place to find growth as a programmer, and give you some useful pointers to use it effectively.

What are your experiences with Reddit?

I'd love to read your comments here, in my Twitter account @BeyondLoop or in the place this was originally posted: Beyond The Loop.

What's your favourite git command 🖥❓

Borja Lorente — Mon, 03 Aug 2020 21:18:19 +0000

Mine is git rebase -i, you can do almost anything with it!

Context: This is research for future posts in beyondtheloop.dev

3 Programming milestones towards mastery - and how to accomplish them!

Borja Lorente — Mon, 03 Aug 2020 15:11:43 +0000

Note: This content was originally posted in my blog, Beyond The Loop. If you like it, head over there or follow the blog on Twitter (@BeyondLoop) for more!

I recently had a great conversation on Twitter with @svpino and others, about the line between beginner and advanced programmer:

Beyond The Loop

@beyondloop

@svpino I'm curious: How do you know when to switch from "beginner" to "seasoned"?

Getting over the middle part was the hardest part of my dev journey.

15:34 PM - 01 Aug 2020

0 3

That got me thinking: At some point, one stops being a beginner. And that point is not very clear.

In this post, I outline 3 programming milestones that made me realize that I had levelled up, and resources to achieve each one.

Every engineer I consider "advanced" has reached these milestones, so I think they are worthy goals for anyone.

If you are interested in any of these goals but would like advice or direction, don't hesitate to contact me on Twitter: @BeyondLoop. I'll be happy to help however I can.

Milestone: You are mindful about workflow friction

Our most important resource is mental energy. Optimizing it is key to good engineering.

Our mental energy is limited. Experienced programmers don't have more energy than beginner programmers, they just use what they have more efficiently.

They intentionally invest in making their workflow seamless, so that they have as much energy as possible to solve hard problems.

For instance: While Googling things is perfectly normal and great, Googling the same thing over and over again is a waste of time and energy. Every time we Google something, we're forced to stop our "flow", which costs a lot of mental energy!

Here are some of the ways I've improved my workflow, that can help you too!

I have a big Google Doc of knowledge: Every time I learn a complicated concept, I write my explanation into it. It's been going on for a couple of years, and it's about 50 pages long.
I got comfortable with the command line. It's an incredibly useful tool if you can use it correctly!
I have a shortcuts repo, where I keep command-line shortcuts for commands I use often. git add -p becomes gap, ./bazel query --output build is bqb, etc. Seconds of typing matter!
I have learnt some keyboard shortcuts for most of the popular text editors. Editing code without breaking your train of thought can save you a lot of mental power!

All of these are gradual, and built throughout a whole career. Don't worry if you don't have the perfect workflow now, worry about making it 1% Better every day!

If you improved your workflow by 1% every 3 days for a year, you'd be twice as good at the end of the year.

Now, not every workflow is worth being automated. You should focus on finding the sweet spot of "easy improvements that save me large amounts of time over years".

If you're not sure about whether it's worth it, check out this graph by XKCD:

Resources

CodeNewbie Podcast, Ep. 7x2: How do I Level Up? The CodeNewbie Podcast is a great all-around resource to learn from. In this episode, it
Upcase: The best resource for levelling up as an engineer. Tutorials on Vim, Bash and Git are great to improve your workflow!
The 1% Better Tag in this very blog is a collection of workflow improvements I've found over the years! Browse it to see if any are useful, and Subscribe to get notified whenever there's a new one!
Getting Started With Dotfiles: An introduction to one of the best ways to automate your workflow.

So, reduce friction in your workflows! Next milestone:

Milestone: Git is intuitive for you

Every senior developer I've come across has a deep, intuitive understanding of Git

If you're going to be developing code professionally to any extent, you're probably going to come across Git. When you do come across it, you might notice that it's not the most intuitive of tools.

Note: If you haven't come across Git yet, I'd advise you to read one of the Many. Great. Tutorials out there. It's a great tool to keep track of changes on your code!

I used Git for many years without really understanding what I was doing. I learned 4 commands (git add, git commit, git pull, git push) and asked my git-savant friend @AlvarBer for help whenever I got stuck. Which was often. I felt that Git was not very user-friendly.

Okay, fine: I thought it hated me.

However, one summer I was introduced to a new command: git rebase -i.

The specifics deserve a whole separate post, but after a very frustrating weekend fiddling with it I had a realization:

Git sees a repository as a series of atomic immutable changes (called commits) that can be copied, but not changed, moved or deleted.

Note a few important bits in that sentence:

Commits are atomic immutable changes: Once you create a commit, it cannot be modified. If you want to change a commit, you need to create two new commits.
Commits can be copied: Operations like git cherry-pick and git rebase may seem daunting at first, but once you understand them as essentially copying operations, they become very intuitive and useful.
Commits cannot be moved or deleted (except very intentionally): Git is designed to make it hard to lose work. Once you commit something, it's really hard to delete it. Therefore, don't be afraid to experiment with Git commands, as there's always a way to go back! Even if you think you've messed up, there's usually a way to recover your work.

If you get in trouble, feel free to reach out on Twitter @BeyondLoop.

Once you understand that, you deeply understand the rest of the commands (and even some of the error messages!).

With time, you develop an intuition for Git that allows you to do complex operations in a short amount of time, such as:

Re-writing the commit history so that every commit makes sense independently of the others. This will make you an amazing Open Source contributor!
Experimenting with different versions of solving problems in different branches, and easily pick from one and the other.

Every senior developer I've come across has a deep, intuitive understanding of Git, and for good reason. Spend time to learn it well, and it will reward that time tenfold.

Resources:

Git For Ages 4 and Up: The best Git tutorial I've seen to date. An in-depth explanation of what I've written here:

GitHub's Curated List of Tutorials: GitHub is the biggest service that hosts Git repositories. They have extensive documentation to learn about Git.

And last, but not least:

Milestone: You don't think in terms if/for statements anymore

Experienced engineers know what details to ignore to look at the big picture.

Learning to program is very similar to learning to speak.

When you first start learning to code, you struggle with the syntax of languages. You struggle to communicate simple concepts to the computer, such as if the colour is "red", then stop.

As you become used to the syntax, you also start finding it easier to express those concepts. They become second nature, you don't have to think about them anymore.

Now that you are comfortable with expressing simple concepts, you can compose them into more complex ideas, like functions.

When you master those more complex pieces, you can use those to compose bigger and better things, like whole applications.

This cycle continues for your entire career. Experienced engineers have deeply mastered many, many concepts, so they can form very complex systems without being worried about the details of every small piece.

Advanced engineers have a very rich vocabulary of programming concepts at their fingertips.

The more advanced you are, the bigger picture you can see.

Resources

While practice is the most important factor to develop this intuitive understanding, here are some books that teach essential concepts:

Clean Code: It's a great handbook for solid Object-Oriented Programming. Whether you like OOP or not, it has some great notions on how to keep OOP code neat and tidy.
The Pragmatic Programmer: The best programming book I've read, by far. It outlines best practices for engineers and how to achieve the deep understanding I refer to in this book. I want to write a full review soon, so subscribe if you're interested!

Conclusion

These milestones have been consistently met by senior developers around me, so I think you can benefit by working towards them!

However, keep in mind that these can take years to accomplish! These are career-long goals to strive towards, it's expected that they will take time!

I'd like to hear from you. Have you met any of these milestones? Which one are you going for next? Was this article helpful?

Don't hesitate to contact me on Twitter @BeyondLoop, for questions or feedback. I'll be happy to help in any way I can.

Until then, happy journey!