boliveira

As a software developer, the more you grow in your career, the more fuzzy the problems you're solving will become.

Ambiguity and fuzziness mean that the problems are too large to be approached in their current state:

• No clear-cut solution from the input: when describing a problem, it's expected that embedded within this description, an obvious, elegant and unambiguous approach will surface: this is the approach that delves deeply into the problem and extracts the core of it and solves it as elegantly as possible;

• No intermediate "wins": by breaking down a complex problem into many bite-sized smaller problems, it suddenly becomes easier to make progress. Having well-scoped, small tasks to tick off helps with keeping engagement high and following a structured approach;

By focusing on breaking things down, we can effectively allow for the force multiplier of working as a team on the same large effort in parallel to kick in:

• Breaking things down opens up opportunities for collaboration: the focus should be on breaking a large task in independent sub-tasks that can be tackled in parallel, as different teams or subsets of a single team will contribute towards the bigger picture;

• Room for growth: by allowing work to be distributed amongst all the members of the team, this allows for career growth of everyone involved: in managing complexity, by the person actually breaking things down and in seniority by the people who actually implement the smaller tasks that can ramp them up out of their comfort zone;

• Achievable milestones: when the tasks are smaller, every completed task feels like a nice milestone achieved in the completion of the larger task and it's a great way to keep everyone engaged and turn a large effort into a much more enjoyable one;

Practice breaking things down to grow in your career, deal with unknown factors, and learn that there's no single daunting task: the simplicity is there and we uncover it by delegation and breaking into independent sub-tasks!

Feedback is a very useful way to improve yourself and your career, and, chances are, if you work as a software developer, every quarter, or maybe every 6 months, performance cycles come into the picture.

A performance cycle is essentially a touchpoint-style moment where you align with your manager on your performance and expectations for the upcoming period of work, and, for the most part, that alignment is done by collecting feedback from your manager and your peers, so, there's a very high chance that you might have needed at some point to give feedback to some your colleagues.

If you're anything like me, this probably feels like a daunting task, right? It's never easy to find the right thing to highlight and it feels even harder when you know that there are things that should be improved, but, simultaneously, you don't want to alienate your relationship with your colleagues by appearing to be too blunt or too harsh.

In the book "Culture Map", by Erin Meyer, there's the idea that different cultures perceive feedback differently depending on whether people are from one of four quadrants: combining high and low-context and direct or indirect negative feedback.

The way people are either very explicit or hide their true message in-between the lines and either are very direct when giving negative feedback or more subtle (sometimes contradicting their primary form of communication) can cause some really tricky situations. However, there are ways to navigate this culture map that can make it easier for everyone:

• Always try to offer something positive: even if it's something small and it goes against the spirit of the general message you want to convey;

• Be honest in your assessments: don't try to be smug or too humble or kind if you don't mean it. Some cultures take that to heart;

• Always be willing to listen: never dismiss another person's opinion and abandon any preconceived notions you might have;

If you follow these small steps, you will come across as a more genuine person who delivers accurate feedback and receives it well in a multitude of scenarios!

Sometimes, no matter how much you test something, no matter how preemptive and careful you are during code reviews, no matter how much your test coverage goes up, no matter how many people look at an MR, there are the inevitable cases of logical bugs slipping through unchecked past all the walls and guardrails that are put in place, ready to wreak havoc in production against all the expectations.

Part of the problem is that during development time, during reviews, and during the usual back and forth between addressing review comments and adding the corresponding logic and tests, it's easy to become too embedded into the environment in such a way that some obvious inconsistencies can only be spotted later in the process, when the work is being used in production, which is just about the worst possible time to find issues.

End-to-end testing before hitting merge

A great way to overcome this is to do extra end-to-end testing before the code gets into production but, after the pipelines have been executed and coverage has been measured and review comments have been addressed.

Once this particular stage is reached, there is a mutual agreement between at least two people (author and reviewer) that the code about to go live is of good quality and solves the problem at hand in a correct and efficient way, so a big hurdle is seemingly crossed.

However, performing an e2e test with yet another person, exercising the code in the same way as it is intended to be used in production can reveal a lot of details that are buried underneath all the green checks in the pipelines: insert a specific entry in the DB fails, a consistency check that is filtering too much should be removed, etc.

Only after these details have been fully ironed out and experienced in an e2e testing scenario should we have the full confidence to hit that merge button.

Extra testing is awesome. Do a lot of it!

I've just recently started reading the book "The Culture Map" by Erin Meyer and even though I've just read the first few pages, the insights gained are already huge!

Cultures have a way to embed and define our relationships with our coworkers, friends, partners and even with ourselves.

According to the author, there is a set of eight key scales that map to areas along which cultures differ from each other and to which managers of international teams, for eg, must pay attention if they want to ensure that the communication and expectations both from and within the team are framed in the right context. These focus areas are the following:

• Evaluating: direct negative feedback vs. indirect negative feedback

• Persuading: principles-first vs. applications-first

• Leading: egalitarian vs. hierarchical

• Deciding: consensual vs. top-down

• Trusting: task-based vs. relationship-based

• Disagreeing: confrontational vs. avoids confrontation

• Scheduling: linear-time vs. flexible-time

• Communicating: low-context vs. high-context

By looking over different cultures and countries, it is possible to establish how different people will perceive each other across each of these axis and this will equip you to make better judgements or even nudge you in the direction of improving your own actions or you frame certain things to other people by knowing what and how to say it.

Relative scale is what matters the most

The final lesson from these first few pages and one that definitely stick with me is the fact that what matters most is not really the absolute values of say, how deciding spanish people are, but, what truly matters is how and who they are interacting with that can share different values for this particular scale: if collaborating with german colleagues they can be seen as more consensual people since we can postulate for the sake of example, that germanic people are more of a top-down style. And germans can be seen as spanish in the eyes of for example japanese or russian people who have a complete opposite set of values on the same axis.

By focusing on these values and looking at the relative scale between cultures you will gain a lot of insights!

Software developers thrive on hard skills and working within complex settings: the business logic is complex, the code needs to be understood, written, rewritten and debugged and these tasks take the most effort and time from developers.

Since these tasks are inherently technical, it's expected from developers, during interviews and in the first few weeks after getting through the door, to leverage their hard skills to prove themselves.

The first impressions that colleagues and managers will have of you will be mainly influenced by your technical skills and showcasing them should be your number one priority: you will display understanding of the codebase, you'll show that you can work over tickets and maybe have the opportunity to work with and understand infrastructure like pipelines and how it all links together to land your changes in production.

These first few weeks (or months) will be the time where your hard skills should be at the front and they should be your priority.

However, after a while, once you are more integrated into the process and with the team, you'll feel more at ease and tasks that before were hard and took a lot of effort become routine and you'll start feeling more comfortable.

After this threshold is reached, you can focus on leveling up within your company and in order to do that, your soft skills will be critical: interacting with your manager to define expectations for your growth, interacting with your direct colleagues to work on features or solve bugs and even interact with other teams to align on cross-cutting concerns.

The most important is to listen, to make your point reach across with other people, to be respectful and kind to others and these will be the skills that can take you further away in your career!

A lot of the modern web feels like magic. With so many indirection layers piled on top of each other and with the prevalence of web frameworks as a vehicle to increase productivity, a lot of modern software has actually become a black box in the sense that when we leverage them, we are essentially acting as consumers of a specific API that encapsulates what can be very complex abstractions beneath the surface.

I think that in order to become a more effective engineer, it's critical to actually put in the time and effort to go and read the code. At a deep level. Not only the top API layer but at least one, preferably two layers down.

By reading the code that is powering the frameworks we are using we can get more knowledge and gain more flexibility because we can better understand and leverage some things at the top levels that we otherwise wouldn't be able to grasp.

There are several strategies to accomplish this and it's worth noting that they aren't mutually exclusive, so, in fact, we can apply them all in combination to extract the maximum benefit from this approach:

• if using open-source libraries, prefer to use an editor like IntelliJ and a build system like Maven where you gain navigation capabilities to navigate directly into the internals of any library or framework you are using as if it would be your own code;

• explore official repositories available publicly at GitHub, for example, to learn the motivations behind certain design choices and how they can shape up the way you will think about your code, this is also a way to get to know the maintainers which is always a great plus!

Next time you need to use a new library or framework, remember to go deeper than before anf you will be surprised with just how much you can learn!

As a developer, and, in general, as a person, I am what most people would say a 'yes-man'. There is some inherent value in always saying yes to most opportunities that come our way:

• opens up more opportunities for growth: the more diverse things we choose to work on, the better positioned we will be to grow and learn things we otherwise wouldn't, especially, when some of these opportunities lie outside of our sphere of immediate colleagues;

• fosters collaboration with other people: opportunities to do cross-team collaboration are a great way to establish yourself within your team and company and at the same time, it allows you to learn how the organization functions which is always valuable;

• usually can nurture relationships of trust which in turn make more work come your way in a vicious "good" cycle;

However, there are several drawbacks to always saying yes as well. When things don't go as well as expected, it can be tough to be held accountable, and the feeling of "maybe I should have said no, to begin with" starts kicking in.

Besides being a tricky situation when things go wrong, even when they do go right, time is lost due to having to work on multiple tasks at once, or at least more than if we were more selective on what to say yes to.

The trick is to learn how to say no:

• prioritize what is more important to you and focus on those things first;

• accept that you can't control everything and that not everything is your direct responsibility, even if you are familiar with it;

• decide when it's better to redirect people towards more relevant colleagues who know more than you about a given subject;

By learning how to say no, you can better manage your priorities and control your own time!

As software developers, it's common to spend too much of our time in several meetings. Some are routine, some are sporadic, like announcements at a company-wide level for example, and, others yet are the really important ones, like how to ship that new feature that's just ready, or how to gain clarification at the start of a new project.

It's important to know which meetings are worth your time, and focus most of the energy on those, while some of the others can be seen as optional and are better skipped to enable the space to do deep work. But, after all, what does constitute a good meeting, and how to differentiate a good meeting from a bad one?

What makes a good meeting

For a meeting of any kind with any number of stakeholders to be relevant, it's important that its relevancy is showcased just when the meeting itself is being planned and subsequently auto-added to all of the invited peoples' calendars:

• a meeting should have an agenda: if there is none, than, what exactly will be discussed and in what fashion is it going to benefit all the people involved?

• clear inputs: what is expected from the participants who will be attending as well as from the organizer. The most important thing is to ensure everyone joining is in the same page;

• expected outputs: just like knowing the inputs to a meeting is key, it's peraphs even more important to know the outputs: what is expected as the result of the meeting? This can be a document written by a previously appointed person, can be gathering the thoughts of people involved and structure them into a coherent set of notes, or it can be talking to someone;

• timeboxed: nobody likes appointments which drag longer than initially expected. Same with meetings. Timebox them and wrap up when the desired outputs have been reached;

Next time you will need to decide whether to attend a meeting or plan one yourself, keep these aspects in mind and you'll run better, more successful meetings!

In tech, nowadays, there are very little things being done in a completely greenfield style environment. Many of the work being done by developers working in product companies usually builds up upon a set of tools and abstractions that have been experienced and tried out by others. Not only at a technical level (i.e. frameworks or work methodologies) but also at a product and market fit level.

People have studied and seen approaches that work, that don't work, and, many of these people have detailed their findings in extensive blog posts and newsletters.

This is an entirely new body of knowledge to learn from and as developers, that should be our main focus to accelerate our growth.

Advantages of learning from others

The biggest advantage of learning from others who are more experienced than us and have seen more environments, is that we can build upon their knowledge in order to stretch our own boundaries and finding out new directions in which we can grow that we wouldn't otherwise consider. Essentially, learning from others allows us to shift our perspective:

• considering different opinions, especially ones we might not agree with is a way to grow out of our comfort zone;

• gain new insights: sometimes, all it takes to gain a new insight or make a breakthrough with something which was on our minds, is to see it framed differently. The same idea, when seen through a different lens can open many doors;

• we can add new skills to our own toolbelts by learning from others and, when we can combine those skills with our own existing knowledge to form new opinions, that is where growth happens;

• makes us to be more well-rounded people on a given subject;
  

Conclusion

If you know who to learn from and how to incorporate their own knowledge in your vision of the world, you will be able to reach unique insights that will make you become a more versatile person more open to discuss new ideas and fostering collaboration environments over adversarial ones.

Everybody knows that exercising is good for you! There are endless studies that state benefits not only for your body but, also for your mind.

I work as a programmer which is a type of job that actually combines two things that can be quite harmful in the long run:

• it's mentally exhausting;

• it's extremely sedentary;

Doing work that is mentally exhausting while not being physically active can really affect your health: you will be more likely to gain weight, overeat, order more takeout food due to working long hours, and, to top it off, the fact that you will feel mentally drained after your working day, will translate into very low energy levels and, if you make this into a daily routine, you have the perfect cocktail for not feeling motivated enough to exercise. However, the benefits are significant.

Benefits of exercising

Exercising is a great way to fight against the more sedentary lifestyle imposed by your job and even perhaps your daily routine with the lockdowns imposed by covid restrictions.

The benefits go much beyond only improving your physical health, and, while that can act as the primary motivator and is, in fact, the main drive to exercise for a lot of people, I've found that there are a series of other, very useful benefits that I personally experience since I've started running 3x a week:

• focus increases: I feel more focused after working out and can do deeper work for a long time, since running clears my mind and acts as a reset from my current task before I went running;

• helps me build a healthy habit: building habits is the key to having a more successful and balanced daily routine. By relying on your habits you can effectively do more work while expending less mental energy;

• it gives you something to look forward to in your days and that acts as a great motivations boost;

Remember to take time off your daily routine to work out, even if it's only once or twice a week, the benefits will quickly compound and you will feel better about yourself!

What is a topic you think you can speak about for 30 minutes without any preparation? What truly engages you in a way that you can simply choose to speak about it on an impulse and maintain a nice, rich conversation about it for a good half-hour?

Doing some introspection about what these topics are to you and deliberately working on them can constitute a good exercise in developing your own self-confidence and broadening your horizons:

• you will know where your genuine interests lie;

• you can further expand on topics you already like, which can enable you to discover new related topics that you wouldn't otherwise know about;

• you will know more about these topics than the average person which makes them good topics for ice-breaker chats and social occasions;

Diversify your own interests

Once you have done some self-reflection, you will be able to identify a few topics (say 2 - 5) on which you can speak without preparation. This essentially gives you a lot to talk about and each topic can be seen as an avenue from which all other conversational topics can emerge, so, in essence, they are like hooks for you to steer your conversations towards topics you want.

Here's a tip to grow in terms of your culture and expanding your own horizons:

Diversify the style and thematic of the topics you can discuss at length off-handedly

By doing this, you will force yourself to leave your comfort zone and will be able to grow as a person since you will discover new interests and shape yourself in the process of learning more about them.

Conclusion

By focusing on topics you are knowledgeable about and interested in, you can find adjacent topics that can allow you to broaden your horizons and become a more well-rounded person with more to offer when it comes to having and maintaining meaningful and engaging conversations.

Most people look at frameworks as a way of doing more with less. It's easy to look at frameworks as a bootstrap mechanism that abstracts the way most common work is done in software projects.

The problem with this view is that frameworks enable you to express your own domain ideas in a more streamlined manner. They aren't black boxes exclusively but, are, instead, ways of codifying your domain in almost a mini-DSL kind of way:

• Persistency layer is abstracted way behind common patterns like the Repository pattern;

• Services can encapsulate business logic;

• You can manage domain concepts as first-class citizens "embedded" in the framework;

More than just abstraction - a mind map

Think of the last time you needed to encode concepts of your domain into the code. What did you do? How did you leverage your framework to help you do that?
Most likely, you embedded concepts of your domain into the code and combined them together using the building blocks the framework provided you.

Use the abstractions built for you at the right level

Once you start combining the framework API with your own domain concepts, you will end up creating a mini-DSL "implemented as the language" you're writing code in, but, you will be able to see all the concepts of your domain right as first-class citizens in your language while leveraging the framework to its full potential:

• repository of Orders;

• lists of Discounts, Products, Customers;

• methods to retrievePremiumUsers, etc.

Build your own mini-DSL

When you manage to integrate concepts of your domain into the language you are writing code in, and, simultaneously, use the framework abstractions to combine both ends of the abstractions at play, you will create your own mini-DSL where you can effectively express business logic and requirements in code, in a way that people who will read the code, will immediately be able to map what they read to your business. That's the power of frameworks!

Modern software development requires careful testing in order to "bake in" quality both during development time as well as deployment time, usually by running a pipeline on every commit, where unit tests are executed to make sure that the code being deployed is of high quality and contains no defects.

Let's look at some properties of unit tests and how to make sure they are leveraged to their full potential.

Properties of unit tests

Unit tests have some properties that must be followed so that they can be run as frequently as possible during development:

• fast: unit tests need to be fast while running. Because each test is very self-contained, there can be dozens of thousands of tests within a project, so, speed is a priority for unit tests;

• deterministic: it should be possible to run test suites locally as often as desired, and the results must be the same every time, because, if the underlying code implementation does not change, the tests should yield the same results;

• self-contained: ideally, in a unit test, we want to test an atomic unit of code, i.e., a method, in such a way that all the required dependencies for that method are mocked such that only a very specific flow is under test;

• complete: for maximum confidence in the test suite, we should have tests covering both the expected flows as well as unexpected ones, positive and negative cases, empty lists, single elements, etc.

JUnit in modern Java projects

JUnit can be used in modern Java projects, either using plain Java or frameworks like Spring or Springboot.

All it takes is to add JUnit as a dependency to your project and then tests can be declared as a separate class file.
As a quick tour, we can setup up methods to run before each test (or before all tests) and after, and tests are declared using a special annotation, as indicated below:

@BeforeEach / @BeforeAll

@AfterEach / @AfterAll

Finally, a test is declared as follows:

@Test void test() { .... }

Sometimes, it can be useful to execute specific commands against a running Docker container, especially in test contexts.
Once a container is running, it can be useful to, for example, execute a certain SQL script to populate a DB container with test data.

By leveraging this capability, you can enrich your containers at runtime with crafted data to cater to any test scenarios you might think of.

In fact, TestContainers makes this task very easy which is one extra reason why leveraging it to its full potential is a good idea. Let's see how:

Define a specific script to run from within a DB container

Let's say we have a script, in our machine, dummy.sql

containing some dummy data to populate a table.

What we want to do is to execute this SQL script against the running docker container database instance. For this, we can use the exec command from docker.

Using the exec command from Docker

We can use the "vanilla" docker CLI utility to load this file into the container by calling the command directly, in a fashion similar to:

docker cp ./dummy.sql <container_id>:/

docker exec <container_id> /bin/sh -c 'mysql -u root -ppassword </dummy.sql'

Here, we first copy the file into the container and then run the exec command against the running container.

Doing it via Testcontainers

The approach above can be replicated in any language that supports Testcontainers and relying on the execInContainer method supported by the library.

This command essentially mimics executing the docker exec but via an API specific to Testcontainers that interprets the output of the command as UTF-8.

If our running container is called testContainer, here's what executing a command in Docker via Testcontainers would look like:

testContainer.execInContainer("/bin/sh", "-c","mysql -u root -ppassword </dummy.sql");

Like this, we see how we can leverage the Testcontainers library to execute commands in a running container programmatically!

Why 1-on-1s can accelerate your career

Many tech companies promote the practice of having managers regularly syncing (weekly, bi-weekly, or monthly) with developers in 1-on-1 meetings.

These can serve many purposes for managers:

• align on the status of a project;

• gauge how happy a developer is with the current work;

• raise concerns about team dynamics and/or individual performance;

• ...
  

However, from your perspective, as an IC, a meeting of this style can be an amazing opportunity for you to take hold of your career progression and steer it in the direction you want. Let's see how.

Taking control of your career by leveraging 1-on-1s

The best way to propel your career forward is by ensuring that the right topics are discussed during a 1-on-1. These are the topics that are of your own interest when you're looking to move your career forward:

• how can you help your manager: asking simply how you can be of help to your manager can unlock amazing growth opportunities that would never materialize otherwise;

• how can you get to the next level: what are the expectations people in management and/or HR have to place you at the next level? Remember you can only get there by walking the walk, and the first step is to know which direction to take;

• what will come next in the roadmap/where are the biggest growth opportunities: sometimes, knowing what to work on is more important than being impactful at your current tasks. Choose wisely;

Conclusion

In order to leverage your 1-on1s in the best possible way for yourself, remember to ask exactly what it is you want from your career and how you can steer the conversation in a direction that suits you:

• set your own expectations and define exactly the goals you are pursuing;

• voice your concerns and propose approaches to reach a solution together with your manager;

• think if going the extra mile is doable for you and manage your workload accordingly;

Most people believe that in order to be more productive or efficient there's this notion of working harder and doing more.

The problem is that since people have limited capacity for focus and for performing deep work, wanting to be more efficient by doing more is actually counter-productive and that's where the notion of adding by subtraction comes into play. The main focus of this idea is:

• You do less concurrent work at the same time;

• The work you do take on can be done in-depth;

• You become more efficient by doing less:

More work means less focused work

If you are juggling several different tasks at once, chances are, you will never be at the top of your capacity on any of them. The trick is to do less work, but, to go more in-depth in it:

• if you laser focus on a single task, you can be much more productive, as you focus all your power into it;

• less context switching also makes for more deep work;

Block your availability to new work

Here's what you can do right away to improve your amount of focused work:

• own your own time: block your calendar when you need to do deep work. This signals to others (and yourself) that you are taking time to focus at a more deep level on a single task;

• limit your own WIP: sometimes, it's inevitable to take on more work than it's possible to handle. Try and enforce a hard limit on the number of WIP items on your plate;

Get better by owning your time

Do more, by doing less.

When you block your own time and commit to working on fewer items, your focus on the items that you are currently working on will naturally be higher than if you'd be taking on multiple things at once. This will enable you to do your best work!

Gone are the days when only Tech Leads or project managers were responsible for leading software projects or large features. Nowadays, especially from a perspective of career progression, leading or taking part in the design of large epics as an IC is extremely important.

Why it matters to lead a project

Leading a project is very different from simply collaborating in one as a normal contributor, as it teaches you all kinds of skills:

• you see the bigger picture: when leading an effort, it's easier to see the bigger picture of how this effort fits into the organization's roadmap or within the team's work for the quarter. Being knee-deep in technical work makes this harder;

• interacting with people: keeping tabs on even one other person besides yourself is a great way to practice leadership skills without actually being a leader. When you manage a project, you end up checking in with your colleagues a bit more frequently and can exercise soft skills more easily;

• career progression: as one climbs the career ladder, the higher the steps, the more is expected in terms of being an "integrator": you need to speak with stakeholders in different teams, manage more moving parts, and essentially work at a more impactful level than as a single IC.

Gaining experience

At first, it can be scary to lead anything if you've never done it before, but, the experience and mettle you gain are invaluable in moving you further in your career and increasing your confidence for future similar efforts:

• you develop your own style and can learn what works and what doesn't;

• your interactions with other people improve the more you do it;

• paradoxically, you become a better developer after being on the "other side" - you understand certain trade-offs and decisions better and can apply them to your daily work!

So, next time you have the opportunity, seek to lead an effort and you will learn and grow a lot!

In order to change your life, you don't need to overhaul it completely. Your habits shape a lot of who you are and who you become, and it's now well-known that when you change a few key habits, you can actually change your entire life as a result of that small, key transformation.

• Exercise regularly and you manage your stress better;

• Write daily, and your focus increases;

• Change your environment, and everything follows;

Transformations are a result of compounded small changes, not large one-off attempts

Nothing happens overnight. You can't run a marathon without training first.

Focus on starting small, and practice that key habits to make them percolate to the rest of your life. The key is to be consistent and focus on small wins:

• Put in the work every day;

• Trust the process;

• Measure your progress to stay motivated;

By putting in the effort and trusting the process, you will improve much more than what you thought to be possible!

Choose a single habit to change in your life

The most important thing is to choose and stick with a single habit that is known to be transformative. For example, working out 3x a week.

If you shift your mindset to workout 3x a week and focus on that process, you will realize that your life will improve as a whole: more energy, more focus and you will feel happier.

Only key habits matter

Remember, by focusing on key habits you have the power to change your life and become a better person, and, it doesn't take much. All it takes is the commitment to stick to one thing and trust the process, and, slowly, over time, you will start to see the results of your investment in yourself paying off huge dividends:

• You control who you can become through your habits;

• Makes you believe in yourself;

• Transforms you into a better person;

It's very easy to fall out of habit. Be it sticking with an exercise routine or writing or eating healthy, etc, it's very easy to not trust the process and give up.

This often happens when we're too focused on short-term results and ignore the bigger picture.

When you stick to the process, you grow as a result and forge your identity while doing so.

Ignore short-term results. Aim for the long run.

Every soccer team wants to win, but, players don't spend the game staring at the scoreboard.

When people favor the short-term results, they often do it in a way that is simply based on desires or needs, like wanting to win the game. But, in order to do so, a framework needs to be in place to make winning the most likely scenario.
Aiming for the long run means winning the game during practice: by training and ingraining good habits in the players and the team, winning becomes easier.

Let's see how to stick with the process.

#1. Ignore the end goal

Don't focus on results, focus on the process:

• practice a new attacking routine;

• improve your team mates position without the ball;

• focus on ball control by playing mini games;

By focusing on little wins, you can stay motivated longer.

#2. Be relentlessly consistent

Big difference between pros and amateurs?
The pros will put in the work, day in, day out, every day, whether they feel like it or not.
By being consistent, your small wins will have a compounding effect on your motivation.

#3. Be specific in your goals

Have small, but specific goals in place to keep yourself in check: avoid 2 attacking plays from team mates during training, score 1 more header next practice, etc. Specificity matters for accountability and measuring progress.

So, remember to stick with the process and don't fret over the end goal too much! Everything will flow naturally!

Reading code is rarely emphasized as much as writing it. However, this imbalance can be harmful because developers spend much more time reading code than writing it, so, getting good at reading code can be a huge force multiplier.

Emphasis is on creating, not maintaining

Most online resources focus only on creating things or writing new code, instead of advocating for reading it. Why?

• Feature work requires writing code;

• Productivity is still correlated with writing code;

• Culture is centered around creating and innovating. Reading is passive;

By focusing your efforts on reading code, you will become better at writing it too.

Step 1: Search for an entry point

When you start reading code, it's a good idea to search for a couple of key areas that act as entry points for a certain flow you want to analyze: a specific class, method, or package. When you've identified these, move to the next step.

Step 2: Always prefer DFS over BFS when reading code!

Essentially, always go as deep as possible after following a thread from a starting point. This allows you to get an "end-to-end" view of a given flow which can increase your understanding. It also gives you a good overview of test coverage across layers and how things are structured.

Step 3: When possible, read the tests, if not, add them

Finally, the last important point to make: having code covered by tests, either unit or integration (preferably both) can greatly increase your understanding by allowing you to focus on atomic pieces of logic and understand the expectations for each of these in isolation. It also helps when refactoring code as it can give you extra assurances that the underlying logic is left unchanged!

By focusing on going in depth-first, you can more easily understand the code as you read it and with practice, this will become easier over time!