For RPG and fantasy lovers, there's a well-known rule that shall always be followed: don't split the party NEVER stole a treasure from a dragon's lair - not while the dragon lives.

The Dragons in Fantasy

For those not so familiar with it, I'll tell you that some kind of dragon has the cool hobby of growing piles of treasure. Unfortunately, they don't work 40 hours/week to buy their preciousness, neither jump into a quest for the king in exchange for a bag of gold. Instead, they generally get it from the cities they attack or from adventurers that dare to enter in their lairs. They like to keep their treasure in the very core of the lair, and the tales tell that they are aware of every single piece of gold that lies within their halls. They create some kind of connection with their treasure that allows them to recognize and track down even the smallest copper coin that's miles away from them. And they HATE to the most losing a piece of their piles of treasure.

Now imagine you, a naive (or greedy) adventure that gets in the dragon lair to try to take something from there. No matter how smoothly you walk away, the dragon will know you've been there, and he will know which treasure you're carrying with you - and now you have to be prepared. He'll hunt you down with no cease until it smashes you to the ground.

TL;DR if you touch a dragon's treasure, you are in really big trouble

Starting the analogy

Ok, now that I've introduced you to the dangerousness of touching a dragon treasure, and how the dragon is aware of everything around its lair, let's move the topic.

I want you to think of it in another way now: you are the dragon and the codebase you're working on is your lair.

Welcome, adventurer, to the Coder Lair.

You must be aware of everything that comes in and out of the codebase. Every corner. Everyone who touches it.

But why would I like to do that? You might be asking. Well, I'll tell you that by completely understanding your codebase you can achieve lots of benefits that I'm going to explore more in this article.

The Coder Lair

You know that dragons have a strong connection with their lairs and their treasures, right? They can even cast special powerful spells when fighting inside its lair. All of that due to the knowledge and connection with the environment. So maybe we could say you can become as powerful as a dragon by knowing YOUR environment (the codebase)?

TL;DR the environment brings power, rule yours

So let's list a couple of powers you might get from the Coder Lair:

1. Support your peers
   If you know the details of how things are working, you're more likely to be able to help others on troubleshooting, problem-solving, and time-saving. That's a huge value for you and for the team.

2. Raise your seniority
   The more you learn from the codebase, the faster you'll be in your deliveries, and you might start making fewer mistakes since you've seen similar working solutions a couple of times.

3. Find patterns
   You'll get more likely to reason about the code structuring and it'll become easier to think about solutions

4. Reuse code
   Since you know have large visibility of what's going on and how everything is connected, you'll be able to recognize codes that can be reused in different places. It saves a lot of time and makes sure your code is less error-prone.

5. Predict possible bugs
   You're more aware of what works, what doesn't work, and what could be refactored. So you are more likely to know where the code can fail and fix it before the client gets it.

6. Find quicker solutions and debug faster
   Your troubleshooting skills will be sharper. You'll be more likely to know what caused an error only by its message. You'll probably get a better idea about where to add breakpoints or logs and what the possible state that has triggered it since you've read that code a lot.

7. Feature insights
   Since you have a nice overview of what your code delivers and its flaws, it'll be easier for you to think about improvements and features you can add to it.

8. To know current limitations
   Never fall again in that pitfall of "this is going to be quick". You know what are the limitations of your current code and you can raise a flag to the team before something "easy" that can't be handled yet is suppose to be addressed.

9. Estimate tasks more precisely
   You know if the task requested has a similar solution somewhere else that maybe you can copy from, or if you'll need to write it from the scratch, or even if there's not enough data structuring to handle it. When you have an idea about it you might be able to estimate better your efforts to complete the tasks.

10. Prevent regressions
    You know that bugfix you addressed that broke another page you even didn't know it existed? Well, that's a lack of knowledge in your lair. If you have a complete overview of it you might introduce fewer or no regressions to your code.

"If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle." Sun Tzu, Art of War

And you want to know the Almighty Dragon Breath move? It is that you can apply most of these items from a team perspective. Not only being careful about your code but also from your peers. And we're going to talk more about it in the next topic.

Into the Coder Lair

Now let me share with you a few tips that might help you get into your Coder Lair:

1. Read the codebase as much as possible
   When you get a task to work on, avoid just touching your single line and read the entire code instead. Try to understand what this code is doing, what are the relationship with the other files, think in a way of how could you explain it to someone else if you were asked to. Little by little you'll get a nice overview of the entire project.

2. Adopt a design system
   Adding a design system to your codebase will help you and the team to make sure everything is written following the same pattern. You'll reason faster about the code and move faster in your product.

3. Adopt a git flow or similar pattern
   This is important to make sure things are getting into the code by following some strict rules, it gives you a lot of control of what's happening.

4. Review every single PR
   Just like the dragon knows when a gold coin is put or removed from its pile of treasures, you must be aware of everything that's coming and leaving the codebase. Review even merged PRs that you couldn't do while it was open.

5. Understand what problem the PR is solving
   This gives you an overview of what's going on, where the product is going to, and if that's the proper solution.

6. Understand how the PR is solving the problem
   This is a crucial step in the code review process. You must understand how that code is fixing the problem. You'll learn a lot from it.

7. Volunteer to work on the hardest tasks
   Your muscles only grow when you lift heavyweight. You can't expect to keep sharped if you only take quick wins. The more complex a task is, the more you'll learn from it

8. Prefer working on bugs over features
   Okay, this one I know many people will disagree. My point is to add new features you may not need to know the codebase, you can just write everything from scratch if you want (I don't recommend it!). If you don't have a strong review process, it's mostly liked your team doesn't even notice it. But to fix a bug, generally, you'll need to keep the same pattern as the already written code, you'll need to read more the code, and think about debugging and regressions. And you can always learn from the features by doing code reviews as item #4 suggests.

9. Write and read tests
   Testing code is an efficient way of getting to know it. You can get an overview of what is expected from it to do, how it should work, and how it shouldn't.

10. Enforce type-checking
    Similar to tests, type-checking is a strong ally when it comes to understand and maintain the code, making it way more clear to reason about why something is written the way it is.

11. Talk about the code with your peers
    There's no omni-knowledge. You will never know everything and you can always learn from every team member, from the 10 years senior to the junior that just got its first job. You should be open to talking about the code with your peers, hear their opinion, and share knowledge.

12. Do the impossible
    Man! Are you nuts? I have limited hours and I got too many tasks to deliver, how would I be able to do all these things? How will I remember all the codebase? Ha! You must be kidding!!! This article is totally bullshit!
    Just take this for your life: the close to the impossible, the far from the mediocrity.

Final thoughts

Well, that's it for now. I know it's a quite hard work to do it, I even don't do it as much as I'd like to, but it's always something I'm willing to in my work time. Some thoughts that inspire me and northern my career to try keeping better than I was in the past.
I hope this article helps at least 1 person to become that fearsome and Almighty Dragon! 

Feel free to share thoughts about this topic and what you use to do to control your Coder Lair!

Twitter: @tiagocsouto