💡 Engineering lies not just in what we solve, but in what we optimize and streamline. Sometimes, the most elegant solution is the one that eliminates unnecessary complexity and conserves resources.

🌟 Think about it: every line of code, every component, and every feature carries a cost. By identifying what we can omit or simplify, we not only save time and resources but also reduce the risk of bugs and maintenance overhead.

In the process of building a robust solution, consider these key ideas:

1️⃣ Minimalism: Embrace simplicity. Trim the fat. Achieve more with less.

2️⃣ Elegance: Seek elegant, efficient solutions that elegantly address complex problems.

3️⃣ Resource Efficiency: Optimize your solution for scalability and performance.

4️⃣ User-Centricity: Ensure that every feature adds genuine value for your users.

5️⃣ Agility: Build with flexibility in mind. Adapt to changing needs without excess baggage.

6️⃣ Future problems: Avoid addressing issues that haven't arisen yet.

Remember, engineering isn't always about creating something entirely new. It's about finding better ways to solve problems, and sometimes that means focusing on what we don't need to build.

Let's embark on the journey of creating solutions that are not only robust but also lean and efficient. By doing so, we not only drive greater impact but also reduce the burden of unnecessary maintenance, allowing us to focus our resources where they truly matter.

Subscribe now

I came across the concept of managing up and if you look at it in Google you’d get:

The statement above can be broken down into two major pieces

1. Being a self-manage person

2. Delivering value

So let’s start with the first one.

Being a self-manage person

It means that you know what you are supposed to be doing, you know what would be the next thing to do and more importantly, you know what you should NOT do.

So if you need to ask your boss what you should do, it’s a clear indicator that you can improve in that area.

Let’s look at examples of what things you can do depending on your role within the company.

Bad 🚫

If you’re a junior developer that completed a ticket in the sprint and you ask your manager what else you can work on?

Why is bad? Because you gave the manager more work to do, now he/she needs to go and see what ticket to assign you.

Good ✅

If you’re a junior developer that completed a ticket in the sprint, then ideally you look at the top things in the backlog and tell your manager, “Is ok if I pick the ticket XYZ?”

Why is good? You looked for something to work on next and also informed and ask for approval from your manager.

Bad 🚫

If you’re a mid developer and during the standup call someone else, maybe a junior developer said that’s block and that needs help …but you don’t offer to help

Why is bad? The manager needs to find someone to help the developer get unblocked.

Good ✅

If you’re a mid developer and during the standup call someone else, maybe a junior developer said that’s block and that needs help and you offer to help?

Why is good? First, the manager starts to notice that you’re actively involved in the meetings and that you proactively offer to help others. And secondly, that’s a good opportunity to start mentoring other developers.

Bad 🚫

If you’re a senior developer that only brings problems to the table.

Why is bad? Because you gave the manager problems and he/she might need to find ways to solve them

Good ✅

If you’re a senior developer that only brings problems to the table with a set of possible solutions.

Why is good? With your expertise, you identified problems and went beyond and also looked for possible solutions to work on and fix those problems

Delivering Value

The whole point of delivering value is to genuinely help your manager with the tasks he/she does and ideally automate them if possible. So you’re targeting to help your immediate manager.

The second thing it’s to identify problems worth solving and for this, you can ask your manager for a 1-1 and openly offer your help with different tasks that might consume his/her time.

For example, if the manager needs to create reports manually, you might help on automating the report. If the manager needs metrics about something, created them, etc, etc.

And finally, once you know what you can help your manager and you get permission, you need to do it.

Conclusion

If you’re still thinking about why this would help you grow, your manager has a huge influence on whom or not gets promoted, and certainly by helping your manager you’d ease the work and you’d become a key member to help the team be self-managed.

Also, since it’s a collaborative environment being excellent only at writing code is just a small piece, you certainly would need more skills to become a Senior, Staff, etc.

If you’re interested in what other skills to improve you can read this as well.

The essence of SRP lies in the principle that a piece of code, whether it's a class, file, or module, should have only one reason to change. In other words, it should respond to modifications initiated by a single actor or a single kind of change.

🤿 Let's dive deeper into the concept:

1️⃣ Responsibly managing change: SRP advocates for separating concerns, enabling us to isolate and encapsulate parts of our code that are likely to change due to different reasons. By assigning specific responsibilities to each component, we ensure that changes initiated by one actor or reason do not affect unrelated parts of the codebase.

2️⃣ Enabling maintainability: Embracing SRP fosters maintainable codebases. When each component has a clear, well-defined responsibility, it becomes easier to understand, test, and modify specific parts of the system without unintended side effects. This promotes modularity, reusability, and reduces the risk of introducing bugs when making changes.

3️⃣ Promoting code readability: SRP improves the readability of our code. When each class, file, or module has a single responsibility, it becomes easier to comprehend its purpose and functionality. This enhances collaboration among team members, simplifies debugging, and contributes to the overall quality of the codebase.

🚀 Implementing SRP effectively:

✅ Identify potential actors of change: Analyze your codebase to identify the various actors or reasons that might initiate modifications. These can include business requirements, user interface changes, performance improvements, etc.

✅ Encapsulate responsibilities: Once you've identified the actors, encapsulate their responsibilities into separate components. Each component should have a well-defined purpose and handle changes initiated by a specific actor or reason.

✅ Balance granularity and cohesion: Strive for an appropriate balance between granularity and cohesion. While it's important to have focused components, overly granular ones can lead to unnecessary complexity. Aim for cohesive components that encapsulate related responsibilities.

✅ Embrace iterative refinement: The SRP is not a one-time process; it evolves with your codebase. Regularly review your components, ensuring they adhere to the principle and refactor as needed. Iteratively refining your codebase helps maintain a healthy and adaptable architecture.

Let's dive into an illustration:

Imagine we're developing an educational application that involves a user model representing individuals who interact with the app.

Later on, a new requirement emerges, asking for the ability of certain users (teachers) to create new courses.

At this point, you're faced with a critical decision. If you fail to ask the right questions, you may end up extending the user model to accommodate the new requirement for teachers.

As time passes, the application grows, and we encounter another type of user, students. Unfortunately, we end up including them in the user model as well.

While you might convince yourself that you have different functions performing distinct tasks for each user type and that you're adhering to SRP, it's actually incorrect. The user model can change due to various actors, such as admin, teachers, or students, leading to an improper application of SRP.

This situation worsens when the company expands, and different teams oversee different areas, like admin, teachers, or students. Since everything is consolidated in one place, two main problems arise: making a change that only affects teachers but unintentionally alters the behavior of other user types, or encountering merge conflicts when working on code influenced by requirements from different actors.

However, this scenario shouldn't be surprising, as it's what we're used to. So, let's reconsider the same scenario with the correct application of SRP.

In our educational app, we have the user model and a new requirement arises to handle teachers.

Instead of directly incorporating the code into the user model, you pause and ask yourself:

1️⃣ Are the user and teacher related?

2️⃣ Could a new requirement apply solely to users or teachers?

3️⃣ Does changing the user impact the teacher, and vice versa? Is that desirable or undesirable?

4️⃣ In terms of the user interface, should we treat users and teachers identically?

If, at this point, you determine that they are distinct or that multiple actors can influence the code, it's a clear indication to separate them.

After answering these questions, you decide to split the teachers into separate classes, files, or modules.

By the time the student features are introduced, we already have a code structure that encourages placing them in different locations. Even if you're uncertain, you can repeat the process of questioning whether more than one actor can potentially change the code you're considering placing in the user model, and proceed accordingly.

🤝 By embracing the true essence of the Single Responsibility Principle, we can enhance our codebases, promote maintainability, and foster collaboration among development teams.

So let’s start by examining some KPIs that leadership might be looking at to determine if your team adds value!

1. Productivity: This KPI measures how efficiently the team is working.

   1. Track metrics such as the number of tasks completed.

   2. Bugs created/fixed.

2. Quality: Quality is an important KPI for any team that creates a software product team.

   1. Bugs found in testing

   2. Customer satisfaction scores

   3. Feedback from stakeholders to determine the quality of the team's work.

3. Time to market: This KPI measures how quickly the team can deliver products to market.

   1. The time it takes to release a new product

   2. The number of product releases per year

   3. Speed of feature delivery

4. Innovation: Innovation is an important KPI for teams that are working on new products or features.

   1. Product ideas generated

   2. The number of successful new product launches

   3. Product/features adoption.

As you already identified some of those KPIs would be dependent on what the Product Manager decides to build, the time it takes the development team to build, and if they add value to the user and business.

Now let’s say that you don’t collaborate with your PM and he/she can come to the team with a solution to be built. This carries a lot of problems like:

1. What if a solution for those ideas cannot be made by the current team's capabilities?

   1. For instance, what if we need AI experts?

2. What if the idea takes months to be built?

   1. Delay time to value.

   2. Risk of shifting business priorities and in the end the team didn’t deliver anything.

3. What if it’s an unfeasible idea?

4. Does it depend on external teams/vendors?

5. What if the proposed solution doesn’t solve the problem?

If you already reach this point, let me tell you. They added you too late in the process!

Collaboration between product managers and developers is crucial for the success of any software development project. Product managers and developers have different roles, but both play important roles in creating and delivering high-quality software products.

There are two actions you can take to improve this situation:

1. Define clear roles and responsibilities

   1. Product managers should focus on defining the product vision, goals, and requirements, while developers should focus on designing and building the product. Clearly defining each person's role will help to avoid confusion and ensure that everyone is working towards the same goal.

2. Ask the PM to involve you early in the process.

   1. Developers have valuable insights into the technical feasibility of product features and can provide feedback on the design and implementation of product requirements. Product managers should involve developers in the product planning process to ensure that the product requirements are feasible and to get their input on the best way to implement features.

3. Communicate regularly

   1. Effective communication is essential for successful collaboration. Product managers and developers should communicate regularly to ensure that they are on the same page. Product managers should keep developers informed of any changes in product requirements or priorities, and developers should provide regular updates on the status of development.

4. Emphasize teamwork

   1. Collaboration between product managers and developers should be based on teamwork. Both parties should work together to achieve a common goal and should be willing to compromise and make adjustments when necessary. Teamwork fosters a sense of shared ownership and accountability, which can lead to better outcomes.

5. Develop a product mindset

   1. Start to wonder if the things you build provide value to the end user and how much time it would take. how are you going to roll out the features? and so on.

Ideally, when the PM involves you, there is a clear problem statement and business constraints.

With that information, you can provide input in any technical constraints.

And once you have all of that information and it’s crystal clear, all parts can start to brainstorm solutions for the problem.

• If you work on a solution and the problem is still unclear, it’s a red flag you should raise because things can go wrong!

You can define a Value/Complexity matrix to identify what to build https://productfolio.com/value-vs-complexity/

Once you have a clear what to build the next thing you need to work together on is how to break down the solution and provide deliveries at a maximum of 6 weeks.

If a project/feature takes a quarter it’s too risky, since you would not get any feedback from end users, which means you can be building something that can provide zero value or it’s the right solution at all.

In conclusion, the success of a software development project relies not only on the product manager's responsibilities but also on the collaboration and influence of developers, especially regarding factors such as feasible solutions, time to delivery, feature rollout, and user adoption. Therefore, a strong partnership between product managers and developers is crucial for achieving success in software development projects.

Nowadays computers have multiple CPU cores that help speed up the different applications we run, usually by running tasks in parallel and relying on threads.

But when we talk about Python & even if you’re explicitly defining a thread, your code might not take full advantage of all CPU cores, and that’s where the GIL comes to play.

Let’s review the following example:

We run the slow task from the main thread and with a thread.

The slow task does a loop for 5 seconds before completing it.

As you might expect, it takes roughly 5 seconds

But if we dig deeper, we’d see that the execution is being switched between the main thread and the thread we created.

…and that happens because:

1. The GIL can be held only by one thread at a time.

2. The thread releases the GIL every 5ms by default.

We can arbitrarily tell Python to release the GIL every 10 seconds by running the following code

So, let us run it again, but let python release the GIL every 10 seconds and see what happens

Now the total duration is 10 seconds because we are not letting python make progress in each thread every 5ms.

Crazy right, but here is what you need to remember

1. The switch back and forth between threads lets us make progress in all threads, but not at its full potential.

2. There is no guarantee that a thread is going to release the GIL every 5ms.

3. If a thread holds the GIL, other threads can’t run until the GIL is released.

4. Libraries that rely on CPython require the GIL.

5. Use libraries that use the GIL correctly or rely as few as possible on the CPython.

   1. For example Numpy

6. If you write a long-running task, make sure your code does not hold the GIL.

As a general thought, don’t try to optimize “vertically” if you aren’t facing the problem yet, in other words, if you want to speed up a task with parallelism, and if you aren’t getting the expected results, now it’s a good moment to unveil your GIL knowledge and start to measure how the code is being executed by relying on tools like https://viztracer.readthedocs.io/en/latest/index.html to generate graphs and analyze the execution of your code.

Do you know what’s printed in the console after running the following code?

If you don’t know the answer or if you tried it on your end, you might be surprised by the output you get. But there is a fundamental reason behind it and if you’re thinking it’s a gotcha of Javascript …no, you can replicate it in other programming languages.

In this post, we are going to unveil why the output of the previous snippet is

History

We all know that computers only understand binary. So every character has assigned a number and before Unicode, there were many different systems called character encodings.

Have you struggled with typing the ‘@’?

At some point, we all used the shortcut ‘alt + 64’ where ‘64’ is the number to represent the ‘@’

There were characters, punctuation, and English/Spanish letters represented in the widely used character encoding called ASCII which used 7 bits to represent those characters, but later on, an Extended ASCII version that used 8 bits to represent 256 characters was created.

But ASCII lacked support for pictographic languages like Chinese/Japanese which introduced Unicode, the universal character encoding used nowadays to represent things like the emojis I presented at the beginning.

Unicode can represent around 150k different characters.

To recap, Unicode was created to represent and standardize every character and its corresponding number.

Now before we dive into answering our initial question, let’s review some terminology

Terminology

Code space: a set of numerical values ranging from 0 through 10FFFF called code points

Unicode plane: is a range of 65,536 Unicode code points. The entire character set is split into 17 planes.

Basic Multilingual Plane (BMP): plane 0 which contains the most commonly used characters like numbers & the alphabet.

• U+0041 represents the letter ‘A’

Astral planes: planes 1-16 are named astral planes or supplementary planes. It contains historic scripts and symbols like Egyptian hieroglyphs and emojis.

Character: is a unit of information used to organize and represent textual data.

• Every character has a name. For example Latin Capital Letter A it’s used to represent the letter ‘A’

Code point: a number to represent a Unicode character.

• Their format is ‘u+<hex>’

  • U+0041 represents the letter ‘A’

• A code point is encoded as code units.

Code units: a bit sequence used to encode each character within a given encoding form (to represent the abstract characters) in physical bits.

• For instance, The letter A has a code point U+0041, and given the UTF-16 encoding, the code unit is 0x0041

Character Encoding: transforms abstract code points into physical bits: code units. In other words, the character encoding translates the Unicode code points to unique code unit sequences.

• Popular encodings are UTF-8, UTF-16, and UTF-32.

• UTF-8 uses 8-bit code units.

• UTF-16 uses 16-bit code units.

• UTF-32 uses 32-bit code units.

Code point, unit & character Encoding Recap

Grapheme or symbol: a distinctive unit of writing depending on the writing system. In other words how the character is drawn.

Combining mark: is a character that applies to the precedent base character to create a new grapheme.

• For instance, in the next snippet, the first console.log represents the character ‘o’ and the ‘´’, but in the last console.log when combined they represent the letter ‘ó’

Encoding UTF-16

UTF-16 is commonly used in Javascript. And since now we know all terminology around Unicode. Let’s introduce surrogate pairs.

Since UTF-16 uses 16-bit code units and encodes the code points in this way:

• The BMP is stored in one code unit because each plane can store 65,536 code points.

• For the remaining planes (astral planes) we would need around 20 bits to store them.

Since we can’t store code points from astral planes in 16-bits, there is a surrogate mechanism to store each code point in two 16-bit code units as follows:

• The first (high) surrogate is a 16-bit code value in the range U+D800 to U+DBFF.

• The second (low) surrogate is a 16-bit code value in the range U+DC00 to U+DFFF.

For example

• Code point 0x0061 ‘a’ is in the BMP and can be represented by a single UTF-16 code unit: 0x0061.

• Code point 0x1F970 ‘🥰’ is in an astral plane and represented by two code units: 0xD83E and 0xDD70.

The solution to the trivia!

If you’re still here, know we have all information needed to explain the trivia!

Let’s start by reviewing the length of the emoji 👨‍👩‍👦

Then we get the hex code points for each character

But wait for a second, why are we getting 5 elements if the length of the emoji is 8?

Remember that Astral plane code points are encoded using two code units of 16-bit.

The elements at indexes 0, 2, and 4 are astral codes, so the sum of their length is 6 + the elements at indexes 1 & 3 gives us a total of 8!

Now let’s view what each code point represents

And because we know about combining marks we know it’s possible to build something like

But maybe you’re still wondering what that 200d is about. That character is called Zero Width Joiner used to combine characters. And this brings us to some curiosities and final thoughts about the majestic world of Unicode.

Curiosities and final thoughts

• There are characters like Zero Width Joiner or Zero Width that can cause you a lot of trouble when copying & paste things from the internet.

• Independently if you work with a high-level programming language or low-level one, knowing how Unicode works are fundamental since it’s used by everyone.

• In Javascript, characters from the astral plane have a length of 2, for example:

• In applications like Twitter when the 140-character limit existed, astral codes could cause unexpected problems in terms of space. Since the user doesn’t care about the size of a character.

• In Javascript, you can use the surrogates or the code point to represent a given character, for example

  

• Another example of combining marks is the use of skin tones

I hope you enjoyed the article and if the next time you are working on a code, where two texts have the EXACT characters but when checking they aren’t equal, remember that Unicode has some crazy things like Zero Width characters where a hidden character could be messing everything up.

If you come from Javascript you should be familiar with the Event Loop to prevent the website from being frozen by different tasks like fetching something from the backend.

…But did you know it’s just one of many concurrency models?

Yes, and there are more concurrency models that we will explain later, but let’s start with the basics.

What’s concurrency?

Concurrency is when two or more tasks are executed simultaneously. But simultaneously is not necessary at the same time.

Event-driven

Let’s start with the Event loop since it’s what we are familiar with. If you don’t know anything about the event loop I strongly recommend you watch this video.

Threads & locks

The idea here is simple, we span several threads to execute multiple tasks, but this approach is known for several problems like deadlock where thread A cannot complete because it’s waiting for thread B to finish, but thread B is waiting for A to finish.

Functional Programming

FP has several principles like immutable state & side effects should be minimal which helps against the problems that threads & locks have.

Also, FP could be used in multithreaded environments without carrying much about any locking strategy.

Actors

The actor model focuses on how the components of a system interact with each other and how it should behave.

Actor

Is a fundamental unit of computation, it can perform actions like:

• Create an actor

• Send a message

• Define how to handle the next message

The actors are isolated from each other, in other words, don’t share memory. And each actor has its own “mailbox”.

The mailbox is used to receive messages and each message is processed sequentially.

Erlang uses the actor model.

Communicating Sequential Processes (CSP)

Channels are used for communication and synchronization. Processes are coupled to the channel.

A channel writes is blocked until a reader channel reads it. This is an advantage because the channel would hold only one message

Go (programming language) implements CSP

At this point, if you were to leave this post, just keep the following three points:

1. The event loop is just an implementation of the event-driven concurrency model

2. Things to consider when working with different concurrency models:

   1. Sharing state

   2. Consistency/inconsistency.

   3. Locking strategies

   4. Deadlocks

   5. Race conditions

But before we talk about what you should do in order to improve your react apps. Let’s understand what’s wrong with React.

Disclaimer: I love the react community & its main contributors. Here are just my two cents on what’s wrong and what you could do to make your code cleaner.

Simplicity

For good or bad, I think the root cause of spaghetti code it’s that they decided to provide a simple library and let the user solve a million questions on their own, for instance:

• What routing to use?

• How to fetch data?

• Where to store the state?

• How to store the state?

• …and so on

So eventually every React project has its own decisions, in contrast, there is a concept of Convention over configuration (popularized by Ruby on Rails) where the idea is to provide answers for a lot of those things out of the box.

In the end, this is a battle between being flexible or standard, but lately, I’ve seen it’s hurting the community, because it overwhelms the developers, not everyone can configure the tools in a safe and proper way which only brings more problems down the line.

Prematurity

This is a clear complaint with “hooks”; they introduced them and got an outstanding adoption but lacked documentation. Then soon enough they started to see their usage and how people overused it or didn’t use it correctly, so they identified many scenarios that could be corrected with proper documentation, Thanks for the new beta documentation (Check it out).

But that was a mistake they did since they deliver hooks and IMO they didn’t even have a clear idea of what was the correct way to use which eventually caused a lot of tech debt.

Reactivity

I’m the least capable person to talk about reactivity but keeping in sync the state & the DOM it’s a complex problem to solve, but it’s even harder to expose an abstraction to all developers that’s easy to use.

React with a bunch of hooks/effects make the code hard to read and fully understand the execution because one simple change can result in quite a few executions of the Component Function. So it’s easy to lose track of the flow because we are never in control of it (which sorta makes sense).

In contrast, there are other alternatives that have nailed it like Svelte where they abstract that code from the developer which results in more readable and clean code.

Performance

There is no doubt that React is fast, but the problem is that most of the frameworks focus a lot of effort & discussions around how performant their libraries/frameworks are, but seems like they are putting on the side how easy & scalable writing code with their tools is.

This point tights back to the complex abstractions and missing some of the conventions over configuration ideas.

There are also some gotchas with some patterns that are advocate like the following:

High-order components (HOC)

were so popular but they could shadow other properties.

In the following example, does “isLoading” it’s referring to withLoadingUsers or withLoadingFriends?

So you might think, nobody is going to do this, since it’s pretty obvious, but when you have separate files, and ship features in different sprints, it’s easy for a developer just add another HOC wrapper which might cause more issues.

Hooks

React components could become huge, so it’s a good practice to move a lot of that logic into their own hooks, but that just means you’re moving code to other files and eventually have highly couple hooks with your services because there is no such thing as dependency injection.

Enough talk about what’s wrong, if you haven’t read Clean code, go and read it, that’s the first step to writing code in any language/framework you use.

For React, I’m not going to answer any of the initial questions because you could be using React Context, redux, redux-saga, etc, or Apollo client, react-query, etc.

But in terms of writing cleaner react code, you can start by:

1. Read the beta documentation here

2. Create small components

3. Use single responsibility principles with hooks.

4. Use React Context instead of props drill down.

5. Minimize the use of useEffect/memos/callbacks until you really need them.

6. Decouple business logic from React.

7. Augment or create models around your objects. For instance:

   1. Let’s say you get back a user object with firstName & lastName and you need to render the full name

      

      The problem with the above snippet is that probably that’s not the only place you’d need to display the full name, so eventually, you end up repeating the same code, but what if there is no last name? or whatsoever? you’d have inconsistency because you might not be fixing or handling different cases the same way.

      A preferred option would be to augment the objects with either new properties or a helper method

      

It’s common to work on code bases that are built wrong, but the main idea is to challenge what’s the convention and investigate ideas of how to make it cleaner and more readable. As a follow-up action item would be to explore different design approaches like DDD or patterns that could help you make better choices in the future.

At this point, you might disagree with me but the idea of this post it’s to help you surf the Typescript wave! 🌊🏄‍♂️

Typescript’s like a tsunami that’s powering most of the new projects and companies are even migrating existing projects.

But you might be wondering why everyone it’s using it. So the answer is popularity and all benefits of being strongly typed.

In our community, once something is popular it becomes the default, what everyone uses, what’s asked during interview questions, and so on.

Another concrete benefit is strongly typed, but if you haven’t used it in another programming language you might be skeptical at this point. So from now on, I’d tackle each point that you could benefit from being strongly typed.

1. Explicitly

   There is a phrase in Python’s Zen:

   Explicitly is better than implicit

   Let’s look at the following snippet

   

   Just by reading the code, you can’t determine what each movie has. This means you don’t have enough context and eventually would need to exercise the endpoint to know what’s available or not.

   On the other hand, let’s look at a Typescript example:

   

   It’s clear what movies are and what properties can be used.

2. Intellisense

   Following the previous example, now the editors have more hints to let us know what properties to use which would speed up our coding and minimize the errors we could introduce by silly things like mispellng

   

3. Spot errors during development

   It’s quite common to introduce code refactors, change code around, or add new functionality.

   These are things we are used to doing daily and is likely that at some point we do something wrong, and could introduce a bug that lands into production 🫢

   If you are unfamiliar with the following image, let me present the cost of finding a bug in the different stages.

   

   So, it’s clear that the sooner we spot errors the better and that’s a key advantage of using Typescript over plain Javascript.

   Typescript would give you feedback as you write code like the following example:

   

Like any tool, if you don’t use it properly it just becomes useless. For that reason in the following section, I’d share with you common mistakes I’ve seen during the two years of writing Typescript at my current company

1. Ignoring errors

   The easiest way to tackle a typescript error is just to ignore it. But soon enough it could become the norm and you see comments like the following spread all over the code base.

   //@ts-ignore

   Solution: be strict with its usage & request the developers to properly handle them. If they can’t fix it, probably it’s a lack of knowledge rather than it being impossible to fix.

2. Overuse of “any”

   Any is the same as having no typing in your code, so it becomes useless to have Typescript if your source code is full of any.

   Solutions:

   1. Set the “noImplicitAny” true in the typescript configuration

   2. Encourage the team to NOT use any since it’s a bad practice.

3. Repeated types

   We are all familiar with the DRY principle but seems like people tend to forget about it or they are just lazy to either look for places where a type could already exist or refactor the code to elevate a type to a common folder/place.

   
   For example, let’s say you develop a user table and define a PaginationType, then another developer works on another table somewhere else and also defines a PaginationType.
   At this point, we have the same type in different places, we aren’t following the DRY principle and eventually could create inconsistencies.

   Solution:

   There is no recipe for this particular problem but one thing you could do it’s to define global types where generic things would live, like types for the user, pagination, filters, etc.

To recap, definitely Typescript is something you are currently using or soon enough you’d be working on a project where you have to use it.
If you have some experience with strongly typed programming languages, you know the drill, otherwise, I’d recommend you dive deep into the Typescript Documentation gain experience and learn how to use it appropriately.

Have you seen parents complaining that their kids aren’t receiving the necessary education at school? Or that they don’t behave correctly because of their teachers? or any other random comment to excuse themselves?

If you’re one of them… sorry but you as a parent are the only one responsible for your children's education.

The same happens for us as employees, maybe you’re complaining that you can’t grow at your current company, there is no room for improvement, that you’re the smartest person in the room, etc.,

All of these bring us to the first step towards leveling up in your career

1. You’re the only one responsible for your growth.

Don’t put your future in the hands of your manager or company. You should take time to learn new stuff, reinforce what you already know, learn from your mistakes, etc.

Take time to learn the fundamentals, and learn things agnostic to specific technologies, companies, etc since that can be transitory.

Use deep and shallow learning, if you’re a Javascript engineer, learn Javascript deeply and learn other things you might not be using more shallow like AWS, microservices, databases, and so on.

If you don’t know how to get to the next level look for a coach. It’s used in sports, you see people with personal trainers, mentors, and coaches.

The same could be applied in your professional career and get guidance to focus on the right things.

At some point, I was doing Front end stuff HTML. CSS & JS and there was no room for working on backend projects, but instead of complaining to my boss, I dedicated time to learning it and eventually landed a better job where I could use my new skill set.

2. The title is not correlated with the knowledge

Every company has a different standard of what level a Junior, Senior, etc should be.

And usually, when you get a new promotion you don’t change what you’re learning, for instance, it’s different going from Mid developer to a tech lead, or from a tech lead to an engineer manager.

So if you have been doing tasks from the next role you can aim, or if luckily the company promoted you to a particular role without you having the experience, it’s your responsibility to research, study and apply the responsibilities for that role.

I have seen many Sr Software engineers with 3 or 5 years of experience, but quite often they are Seniors because they moved between different companies so quickly that they became Senior based on the salary range they were in, instead of their skills. (At least in Costa Rica).

And they keep working as usual without doing things like mentoring Jr devs, improving the overall quality of their code, learning how to manage people, etc.

3. Challenge your own assumptions

If I ask you, do you know how to use booleans in your favorite programming language? Your answer would be yes. In the end, booleans are super simple, it’s just True or False.

So if you know how booleans work, you aren’t going to take time learning new stuff around it because you know everything. But what if I ask you, what are boolean traps? (if you don’t know read this).

The whole point is to make a conscious assessment, identify areas you can improve, and even reevaluate the things you think you know.

4. It’s not a race…

When you enroll in a race, your goal it’s to be #1.

But not at work, it’s a collaborative environment which means you can’t just pretend to grow on your own, sabotage your teammates and get the desired promotion.

This means you should talk with your team, and try to grow together, by setting a shared commitment, it can be taking a course on Fridays, learning & sharing knowledge, or asking for help & constructive feedback.

They as outsiders can point you towards areas you should improve that you might not even be aware of.

Also, it’s not running faster than the person behind you, it’s giving them a hand to overcome their challenges “Be the Senior dev you wanted as Junior”. You’d learn a lot when trying to explain things to them. Teaching is harder than you might expect.

Have you tried this and nobody got involved? Talk to your manager, and ask other members outside your team that might be interested.

5. … it’s a journey

At the end of the day, companies, roles, titles, and trendy technologies are gone, and what’s left it’s your knowledge and the relationships you make.

Since it’s a long ride, you should enjoy it to make sure you’d keep working hard, so you must start making habits for being a lifelong learner, help others along the way and surround yourself with people that go in the same direction.

To finalize, getting better in your profession is the same as being healthy, you need to measure your current shape (assess your skill set), eat healthily & work out (learn & apply the knowledge).

And at the end of the day the key to success it’s to enjoy the ride!

Do you agree CSS is awesomely hard? yeah we all think the same, but it shouldn’t be that way! everything it’s going to be different once you master the fundamental concepts around CSS, those concepts would help you understand why and how the browser renders the elements on the screen.

Clarification: Knowing CSS wouldn’t make you better at creating beautiful pages. It would help you convert the designer's work into web pages efficiently.

Box model

CSS treats all elements like boxes. The browser would determine the width & height of the box by computing the props (Content box, Padding box, Border box & Margin box). As shown in the following image

The browsers apply user agent stylesheets to each HTML element. For instance, most of the elements have a style of display: block; meanwhile, the <span> have a display: inline;

Every box would be rendered based on what display property value has, for instance, when using the “inline” box, all box properties except the border would be ignored.

Interview Question: What is the difference between a div and a span?

Answer: by default the user agent renders the div using the display as a “block” meanwhile the span is rendered using “inline” and most box properties have no effect in an “inline” box.

Selectors

Selectors are used to “select” the element(s) you want to apply the style. There are many selectors, the most commons are:

• Element Selector: p

• Class selector: .some-class-name

• Id selector: #unique-id

• Data attribute: [data-key='some-value']

You are capable of nesting selectors, for instance:

In the previous snippet, the browser would get all elements that have a “div” and one of the parent element has an id of “unique-id”.

🚨 The browsers read the selectors from right to left! 🚨

Here you can check the full list of selectors!

Cascading

It’s possible to have different CSS selectors applied to the same element. So there are four rules that determine what CSS would be applied.

For instance, do you know what background color is going to be used?

If you don’t know the answer, don’t worry. Here is all you need to know about cascading!

First, it’s what’s the selector order and position in the source code, the answer for the previous example it’s blue because the latest appearance predominates.

Secondly, we have the CSS specificity, but we have an entire section to cover it.

Third, it’s the origin of the styles

And lastly, the !important rule that would overwrite more specific selectors.

Specificity

Each selector has a scoring, and based on it the browsers determine which one has higher relevance. But, a picture is worth a thousand words, so here you can check the score for the different selectors. (Image borrowed, the source is in the caption)

Layout

The main goal of learning about layouts it’s to know how to arrange the different boxes on the screen. By default, the browser arranges the boxes from top to bottom, left to right, but you’re capable to change the behavior.

We briefly talked about the display property and the values “block” and “inline”. Besides those two, we have “inline-block” that lets multiple elements be in the same line, without breaking the content in a “new line”.

And more recently Flexbox and grids are at your disposal, the key difference between the two of them is that Flexbox lets you arrange boxes only in one axis, either horizontally or vertically. Meanwhile, grids let you arrange the boxes in multi-axis.

You can learn Flexbox here (it’s a game! 🎮🔥)

You can learn Grid here (can you guess it? oh yeah, it’s another game)

There are two more ways to change how the elements are arranged on the page: by using floats, and as the words said, you can either float the element on the left or right side of other content.

The other option is by using positioning. All elements are default positioned “relative” to their parent element. But you can use other values like “absolute” that lets you move the box around by using (top, right, bottom, left) properties, where the box would be moved based on the closes ancestor with relative positioning if the browser doesn’t find one relative element it would use the body element.

Lastly, have you ever visited a site where you scroll down and the header sticks at the top? The CSS that handles that behavior is a fixed positioning that would always display the box even if you scroll throughout the page.

Conclusion

I bet you still think that CSS is hard, but the key takeaway for you should be to learn the fundamentals, once you have a good understanding of how things work, you would easily develop, take decisions and solve problems because you know why things are behaving in a certain way.

You could apply this advice to everything in your career. If you want to learn something in depth let me know in the comments.

Do you want to learn how to program, but aren't sure what tools you need?

I’d walk you through all tools you need to know for writing code. So, let’s dive in!

1. Code Editor

Certainly, you can write code in a simple text editor, but an editor with the following features would make you more productive:

• IntelliSense (code completion, parameters info, references, code usages, etc)

• Debugging tools

• Plugins to integrate with another tech like Databases, Docker, terminal, etc.

• Linter & auto-formatting.

The choice is going to depend on what programming language you’re using. But the main options I use are:

Visual Studio Code (free):

You can use it for a variety of programming languages like Javascript, Node.js, Python, Go, Rust, etc

Download it: https://code.visualstudio.com/

Webstorm, Pycharm (from Jetbrains):

If your company can afford it, it’s worth trying them. Webstorm is for web development, and Pycharm is for Python.
They also have for .NET & Java.

Download it: https://www.jetbrains.com/

Now that you have an editor, the next step would be to actually create a project. In technologies like web, node.js, or Python, usually we create a folder that contains a bunch of files written in that particular programming language. That’s it, there is no rocket science in this part.

The following image is an example of a personal project, where you can see the project folder called BLOG with a bunch of folders to separate concerns (on the left) and a given file opened (on the right side), the file edit area.

2. Choose a programming language

Then you need to decide what programming language you’re going to use.

• Web project: Nowadays would need to download node.js. All of the toolings used to run the server locally, process the files, etc are done with node.js.

  • Download it from here: https://nodejs.org/en/

  • When installing node.js, npm is installed as well (see package managers)

• Python project

  • Download it from here: https://www.python.org/downloads/

  • When installing python, pip is installed as well (see package managers)

Package managers

Package managers usually are installed along with the programming language and their main goal is to let you download third-party libraries to reference from a given project.

For javascript/node.js all dependencies are specified in a package.json file whereas in Python you should add them to a requirements.txt file.

Why do we use it? Imagine you’re new in the team and need to set up the project, it would be a nightmare to go file by file identifying all dependencies and installing them. So it’s easier to keep track and install them from one central place.

3. Version Control System

Have you heard of Git & Github (free for personal usage)? If not, these tools help us keep track of the code, see who changes what files, what were the changes, when the changes were introduced, etc.

Controlling this is critical in a collaborative environment where many people might be adding/editing/removing multiple files.

Also, have you ever lost some work that you had on a computer? Maybe you didn’t save the files and you spill some coffee on your computer and you were not able to recover them.

If that is the case, when you use a VCS, it’s guaranteed that there would be no loss, so your code would be safe.

We aren't going to cover Git here, but you can follow this guide https://www.freecodecamp.org/news/git-and-github-for-beginners/

4. Virtual Environments

Years ago, I worked on a Java project that used SDK version 7 and everything was working fine until I tried to access my Bank Account, the site was using Java and the page didn’t load because I didn’t have the newer SDK. So I updated it, did some transactions, and head back to work, but to my surprise, the project didn’t load because I had a newer SDK version!!

In programming languages like Node.js & Python, you can use nvm or virtualenv in order to have more than one version of the programming language on your computer without any collision like what happened to me.

The key benefits are:

• Your computer can remain “clean” without globally installed packages.

• You can have several projects using different versions of the programming language.

Resources:

https://github.com/nvm-sh/nvm

https://docs.python.org/3/library/venv.html

5. Tools for kick-start projects

There are many tools that help you create a scaffolding project. For instance create-react-app, Django (python), Yeoman.

Those tools would create a folder with configuration files and commands to execute and build the code.

Resources:

https://reactjs.org/docs/create-a-new-react-app.html

https://www.djangoproject.com/start/

https://yeoman.io/

6. Execution

Did you write the code and want to try it out?

If you create a simple website you could install a server on your machine https://www.npmjs.com/package/serve and serve the folder directly.

If you created a python file you can run ‘python filename.py'

At this point, if you feel overwhelmed by how many things could be involved in writing code, I suggest you start with scaffolding, usually those projects have a README.md file with all instructions needed to set up and run the project locally.

Shoot me a message if you need help setting up your first project! 🔥

Introduction

HTML stands for HyperText Markup Language. And as I wrote in this programming paradigm article it’s declarative.

When you visit a website, the server always responds with an HTML file that it’s processed to display the content, usually, this file is named index.html

If you haven’t written HTML, don’t worry, we are going to learn the basics, so let’s go deeper and understand how’s the syntax.

HTML is made of elements that have semantic meaning to represent things like headlines, images, links, paragraphs, ordered lists, bullet lists, and others.

Each element is wrapped with angle brackets <> and called “tags”. Those tags have the following structure:

1. Opening tag: in this example p is used to represent a paragraph.

   1. Each tag element can have zero or many attributes. Here, we used the class attribute

2. Content: that could be text or more HTML elements

3. Closing tag

There are other tags called self-closing tags and have the following structure:

1. Self-closing tag. Pay close attention to the “/” at the end

   1. Each tag element can have zero or many attributes. Here, we used the class attribute

Html content structure

<html> is the top level of an HTML document, also known as the root element. You can specify a language attribute that tells the idiom used in the content.

The <head> tag includes metadata that is not rendered on the page like the <title> tag:

It also includes Javascript, CSS, description of the site, or any other media information used when sharing a link, for instance, When we shared a link on any site like Twitter or Facebook, we see information related to the page because we specified Open Graph meta tags, like the image below. (You can learn more about Open Graph here)

And finally, we have the body where all content we want our page to display would be inside the body tag.

Now that you know the basics of HTML, we can learn how the browsers process the HTML, and depending on how you structure the HTML elements you could slow or speed up your site's first render.

How does the browser process the HTML?

When your site loads, the first file that the browser download and processes are the HTML. The browser receives the bytes, convert them into characters, creates tokens from those characters and generates nodes to create the DOM (Document Object Model) tree.

Ideally, the first line it encounters it’s the DOCTYPE like the following:

<!DOCTYPE html>

This line tells the browser to follow the relevant specification and also specify what HTML version to render, in this case, HTML 5.

The moment the browser encounters a CSS tag <link> it blocks the render and triggers a request to obtain the CSS file. Once the CSS file is retrieved, it starts to construct a CSSOM (CSS Object Model) tree, similar to the one that’s being created for the DOM.

The browsers get both trees (DOM & CSSOM) to generate the Render Tree, in other words, what’s finally rendered on the page.

💡 Since the CSS blocks the rendering, we need to make sure to deliver it as soon as possible. For that reason you should consider the following suggestions:

1. Import the styles in the <head>

2. Use media attributes media="(min-width: 640px)" /> This is only downloaded for bigger screens.

3. Defer non-critical CSS

4. Determine what’s the critical CSS and inline it in the HTML head. Use automated tools to do this process. This is going to depend on what technologies you’re using.

The browsers continue processing the HTML, constructed the CSSOM, and find an image tag with a URL to where to get the image from.

It triggers a request to obtain the image WITHOUT blocking the rendering and continues processing the HTML.

Then it continues and right before finishing the processing of the entire HTML file it encounters a <script> tag referencing a Javascript file.

So the browser BLOCKS the render again because the browser knows that the DOM or the CSSOM can be modified within Javascript and we didn’t tell the browser otherwise. So the Javascript file is retrieved, interpret, and executed the code with Just-In-Time compilation. This whole process takes time, so we should be thoughtful with where and how much Javascript we instruct the browser to download in the first render.

💡 These techniques would help you speed up Javascript assets:

1. Put the script at the end.

2. Use attributes like defer or async.

3. Apply code splitting techniques. Do not send a huge bundle file.

4. Use lazy load with code splitting.

Takeaway

Everything you put in the HTML would determine how fast users would access your site. There are studies that show that if a page takes more than 2 seconds to load is likely the user would leave, in other words, first impression matters!

If you’re trying to improve the first render review start by reviewing what you send in the HTML.

Single Page Applications don’t send the entire HTML, so you might want to do Server-Side Rendering to boost the first load.

The fewer assets you send with your HTML the better.

Research how the users are accessing your site if they are using smartphones, and check metrics like the First Contentful Paint, also test the site using slow connections or use your mobile plan instead of a reliable and fast wifi connection to see how fast or slow the page is.

Bonus Question 🎁

Have you seen websites that look odd and suddenly they look pretty?

The reason is that they might put CSS at the bottom of the HTML, so what happened was that the browsers render most of the HTML and at the end, the CSSOM is created and applied to the rendered tree.

Can you make a website, but you don’t know how people around the world can access it? 🤔

Or maybe you haven’t had the chance to build a website from zero to shipping it to production? or maybe someone else it’s responsible for the configuration and deployment like a DevOps person.

If you are identified with the above comment or just want to know more, in this article we are going to learn all pieces involved with delivering a site when you access it from your browser, like google.com or facebook.com

Before we talk about how a website is shown, every website uses a client/server architecture where different clients like computers, smartphones, etc can communicate with servers and these are in charge to fulfill a user request, in our case, showing a website.

The key piece here is the communication between a client and a server, this is achieved by using certain communication protocols. The protocols more used in web development are:

1. HTTP/HTTPS: EVERY time you type a URL like google.com an HTTP request is made and usually the content that the server sends back it’s the index.html file stored in the server.

   

2. WebSockets: these are used for real-time communication. For instance, when you join Facebook live, everyone is connected to the same event and able to send and receive messages/reactions almost instantly.

3. RTMP (Real-Time Messaging Protocol): this one is used on sites like Twitch for streaming video content.

Now you know about the web architecture and the most used protocols for communication and we can dive into what you SHOULD know if you are a web developer.

So let’s answer some basic questions

How someone can access my website?

First, we as humans are better with letters & words than numbers. On the other hand, computers are better with numbers. For example, it’s easier to remember Facebook.com than their IP address 157.240.233.35

So, when someone Facebook.com there is a process that converts it into an IP address that let the client communicate with Facebook’s servers and eventually serves the site.

This process is made using DNS (Domain Name System). You can think of DNS as the old telephone directory or your contact list on your smartphone, where you look for someone’s name to make a call or send them a message.

Once the client has the site's IP address, there is a back and forth between the client & server to establish a connection.

Once the connection is made, the server sends the HTML and the browser it’s in charge of processing the HTML, CSS & JS to show the content on the screen.

Demystify domains

If you’re thinking of buying a domain, you should think primarily about two things, the site name and the TLD (top-level domain), for instance, a “.gov” if the site belongs to the government, there are other many TLDs for countries like “.us” or “.org”, the famous “.com”, etc.

google.com is the main domain where the name is google and the TLD is .com

Now, when we buy a domain we can register as many subdomains that points to different sites by using CNAME. For example, sites like drive.google.com and photos.google.com are subdomains for google.com

Where are the websites hosted?

If you’re looking for a place to host your site, you have many options, from hosting it on your computer (make sure to have a public IP address), using hosting services like GoDaddy or DreamHost, or more complex providers like AWS, Google Cloud, etc.

In the end, the decision is tight to your budget, what technologies you’re using, and other things like SLA (the promise of uptime for the servers).

What do we host?

Independently if you use a Library/Framework like React, Angular or even jQuery, in the end, what’s generated is HTML, CSS & JS along with other static files like images.

Bonus! 🎁

1. When you access a site for the first time, the DNS resolution is stored in different cache layers, so the next time you access the site, we resolve the IP address as soon as possible. These cache layers are:

   • Browser’s cache.

   • OS cache.

   • Your router’s cache.

2. There are other architectures besides client/server, for example, peer-to-peer that’s used in apps like BitTorrent

3. In the following article we are going to dive deep into different types of communication between clients and servers like:

   • HTTP Push and Pull

   • Ajax Polling

   • Long Polling

   • WebSockets

   • Server sent events

   • Message queues

Programming paradigms are ways to solve problems or tasks.

Programming languages may stick to particular paradigms, for example, Haskel was built around functional programming or languages that are multi-paradigm like Javascript.

Many paradigms can be broken down into two major categories Imperative Paradigm or Declarative Paradigm.

• Imperative Paradigm: the focus is on HOW to give a set of tasks/instructions to change the system. Can be divided into using:

  • Procedural

  • Object Oriented Programming

  • Structural

• Declarative Paradigm: the focus is on the WHAT the task is or the what’s the expected outcome. Can be achieved using:

  • Logic

  • Functional

For example, let’s say you want to make a pizza where the main actions are:

1. Make the base.

2. Make the sauce

3. Roll out the dough

4. Top and bake

Imperative

We do one task right after the other.

Object Oriented Programming (OOP)

The idea of OOP is to represent real-world objects into classes within a given programming language like Pizza, Oven, Client

Functional

Functional programming follows the same idea of mathematical functions, where functions are first-class citizens, pure functions, etc.

Declarative

If you use HTML, React, or SQL, you declare what you want, not how to render or the approach to get the data in the case of SQL.

This is pure educational knowledge that can take you to a whole different world where you can view crazy programming languages like Prolog, which is a logical language that changes the way how you think about problems and solutions.

If you’re looking for getting started with writing code but you know absolutely nothing about it. This post is for you.

I’d give you an overall idea of the minimum stuff you should know before writing a line of code.

First at all, any device (computer, smart phone/watch, etc) works with electricity where 1 represents presence of energy and 0 the absence.

Since those are the only two numbers a device understand, it’s called Binary system (1 or 0). In the other hand we (humans) use the Decimal System where the number go from through (0-9). Also in order to communicate we use idioms like English / Spanish / etc. But any device use something called “Machine Language”.

For example, when you click like in this post, that’s converted into a set of machine instructions (impossible for a human to write/understand) that are executed by the devices and the result is persisted. I know, you might be scratching your head, but bare with me and let’s answer the following question:

How do we write websites like Google / Facebook or applications for your phone if it’s impossible to write machine language code?

Some clever people create high level programming languages and those languages have characteristics like:

1. Are human readable

2. Easy to understand

3. The language knows how to convert the human readable instructions we write into machine code that any device can execute and produce a result.

4. Can follow one or multiple programming paradigms (Here we talk more about paradigms)

If you still don’t have an idea of what those programming languages are? Imagine them like learning a new idiom, if you learn Spanish, English or something else, you learn the alphabet, start creating words and eventually full sentences that another person can understand.

A programming language is the same story, you learn to write sentences (instructions) to communicate with a device.

Now let’s do something exciting!, we are going to get our hands dirty and write our first line of code 🔥

1. Visit this link

2. In the JS tab, write or paste this code:

   alert("Hello World")

Did you see the following alert?

CONGRATS 🎉🎉🎉! You just wrote your first line of code instructing the browser to display an alert saying “Hello World” exciting, right? now lets break the code down

1. We wrote a line of code in the programming language named Javascript.

2. The language has a keyword "alert" that instructs the browser to open a modal.

3. "alert" is a function that shows whatever message you pass in, like "Hello World".

For now let’s move on and dive into file extensions, when you save an image or an audio (the old days) or write a word document, excel file, etc. have you notice the file extension that’s added to the file?

If you haven’t, don’t worry. Each one of those files have an extension like png or mp3 or docx, we use them to represent what kind of file they are and how to process them.

The same happens with programming languages where each file have its own extension that let you identify the language it was written with. For example

If you want to write a website, Javascript, CSS, HTML are the technologies you’d need to use in order to create it and their file extensions are .js .css .html respectively.

If you want to build a mobile app, you might use Swift (.swift) for Apple devices or Java (.java)

Since the list of programming languages is huge, you are not going to learn all of them. My goal is to help you learn to write code and solve problems independently of the programming language, so if the market change you’d be able to adjust and be attractive.

In the following article we are going to know more about programming languages and what paradigms are!.

Are you a Junior dev trying to get better?

I have been working with a lot of Junior devs and through the time I identified 10 common errors they made.

Read them and let me know if you identify with some of them. But remember

My goal with this list is to help you become better than you were yesterday.

1. Misreading errors.

This seems to be pretty obvious but it's wa...y to frequent that a dev reaches to me asking for help because they are stuck ...and when I see the error my immediate question is

Did you read carefully the error? If so what's the error about?

For instance, simple errors (😅) like:

Of course, there are times when the error message is not clear and it's ok to ask for help, but please read and try to understand what's failing.

2. Write code as soon as possible.

When you're going to work on the next task, check if you start coding ASAP, because that's something you should improve. There are many things you should do before hand to make sure you deliver what's expected, for instance:

• Read and understand the scope of the ticket.

• Clarify ambiguity with your Product Owner/Team Lead.

• Look for areas in the app that might be impacted or at least you need to test.

• Etc

3. Misunderstanding of the ticket's scope

This can go in two ways:

• Un-fulfillment of all acceptance criteria. In other words, doing less than what was expected.

• Adding things beyond the scope of the ticket. Doing more than needed.

4. Mixing new code with refactors.

Just with experience you'd know how risky is to introduce new code while refactoring the same area.

Aim to deliver things separate and if you want to refactor some code because it's awful or any other reason, make sure you know the code well or at least have a decent set of tests before doing the refactor.

5. Not taking time to learn your tech stack.

If you're new in a company, it's maybe your first job, you want impress your coworkers, so you do your best to deliver as many tickets as possible, but in the long run you aren't going to increase your velocity and you'd be stuck with silly issues because you didn't learn the stack enough.

Here is one the best quotes that illustrate the idea.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. — Abraham Lincoln

Take time to learn your stack, if you work with React, read the documentation & understand what's going on, learn Javascript well, take courses, ...keep learning!.

Eventually something that could take you a couple of days to complete, you'd be able to do it in a matter of hours.

6. Focus on delivery not on quality.

Usually the devs I worked with try to finish the tickets ASAP and grab the next one. but I always tell them:

I prefer if you deliver one ticket with zero or few bugs instead of delivering 10 tickets full of bugs.

7. Not asking questions

First at all, if you work on a place where you don't feel welcome to ask questions you should tell your manager or move to a different place.

A lot of times I get into a meeting with the team, we discuss a new feature and we ask if someone have any questions and the room goes quiet, so we finish the meeting.

But later on and countless times Jr developers ask me directly questions of things they didn't understand during the meeting.

So I go ahead and explain to them that asking those same questions during the meeting is more valuable because we can consider even more things and that their input is always welcome.

8. Getting stuck

This is related to the previous one, if you're stuck with an issue, it's better to raise your hand and ask for help rather than getting block the entire day.
But as I said in point #1, make sure you read carefully the error and if you don't have a clue of how to solve it, ask for help.

9. Having the same errors all the time.

If you have an issue and ask for help, make sure you learn what happen, why it happened and how to fix it.

Because the next time you face the issue, you can solve it in own, and even better, eventually you can help teach someone what happen, why it happened and how to solve it 🔥.

10. Quality is a QA department responsibility.

It's quite common that developers rely on the QA to guarantee that we aren't introducing bugs or breaking the app.

If you get rid of that mindset, and start caring about delivering features with high quality before they reach the QA person, you'd be miles ahead of the others.

Conclusion

You should be honest and assess yourself. Don't feel ashamed if you have identified with one, two or all of them.
Everybody was a Jr dev at some point and I have to admit, I got better at some of them when I get into Senior positions.

The key is to identify them and be better than yesterday ❤️.

I hope you enjoyed! Did you identify with some of them? Let me know in the comments

Also you can follow me on twitter where I share more tips to become a better dev.

In 2008 with 19 years old, during the first day at the university I had to fill out the registry form and I didn't have an email address, so I had to go to an Internet Café and ask someone to help me create one.
I didn't even know that Internet was a thing and of course I thought that I was going to learn how to fix computers 😂.

I remember the first programming class where the professor created a simple Hello World program in Schema, ran it and magically a window was opened with the "Hello Word" text in it... and to be honest that blew my mind.

During those 5 years (yeah I did horrible in a Calculus class) I did well in the programming courses, but struggled with Math and English (yes, as you probably found in the article I'm not a native speaker).

Then in 2012 I had my first job and the company I worked was known to hire recently graduated students, which was great because all the stuff I learned didn't match the technologies the company used.
Soon enough I realized I had to get up to speed and the only way was through reading. There was no Udemy/Coursera/etc back then.
We used some 🔥 technologies .NET, Javascript & jQuery.

Node was getting traction and Javascript was being more popular and I decided to learn Javascript well.
For my fortune, Javascript became really popular, a lot of devs used it but didn't know the language well (it was a "joke" language), so I was able to transition to other companies, get a better salary and work on exciting projects.

Moving forward, I used to work for outsourcing companies offering services to US companies, so I kept growing my communication skills along side the technical area. You can read my post on how I became a better developer

From moving between companies I learned in the hard way that, it’s likely that your current company doesn’t value you until you get a new job offer.

And by that I mean, it's easy to get into a new company with a better salary and position than growing where you are.
At least that happened to me over an over 💔.

To keep the story short I'm currently working for an US based startup with a good environment and salary 🔥

And these are the key points that took me to that place:

1. Even though at the beginning I was totally lost, I focused on learn to learn.

2. Read is one of the most valuable habits I have.

You're going to get behind if you don't keep learning!

1. There is always going be people with less experience than you. So help and teach them, you're going to learn what areas you dominate and which ones you need to improve.

I genuinely love to help other devs get better with their craft ❤️

1. Treat others well, they might help you, recommend or bringing you into new and exciting companies.

I hope you enjoyed! You can follow me on twitter and share experiences.

How to become a better developer?

Before we dive into the things that help me grow, this question is quite subjective... anyways I want to share with you a retrospective of what works for me

Understand the technologies you use.

Everyone agrees that reading code is a good way of learning, but you should go an extra mile and try to understand why and how the code you are reading works in the first place.
- Start small by reviewing your team mates PRs carefully and if you don't know something, ask!
- Read the official documentation e.g. React docs, nextJS, Django, etc.
- It's ok if you only have a high level understanding, e.g if you work with Javascript you should know how the Event loop works, but not the nitty-gritty details.

Go beyond copy & paste Stack Overflow solutions

I have seen many times developers that have CORS issues and grab the first thing that works from internet. This is terrible because you aren't going to learn why the issue happen, if the first solution you grab is the best one for your specific scenario, etc.
- This takes us to the point #1.

Care about the code quality

Some years ago I thought the QA team was in charge of the overall quality of the product... until I worked for a company with ZERO QA's. (I almost panic!!)
From that point I started writing unit tests and once in a while I try to do TDD but it could be difficult. If you're like me and also have hard time writing TDD, a good starting point for me was the following:
- Before I fixed a bug, I try to reproduce it with a unit test and then fix the code.

Errors free mindset

If there are many errors causing noise in the linter, monitoring system, etc, at some point people are going to start ignoring them. You should strive to have a culture of error free and when an error arises the default thinking should be, let's fix this!
- Do not let anyone commit with lint errors.
- If you work with React, console warnings should be fixed.
- If your team is in charge of monitoring, encourage fixing any alert triggered.

Constant learning

I categorize the things I want to learn in either new technologies like React, GraphQL, NextJS, etc or fundamentals like patterns, principles, etc, and I typically learn about the two of them for instance:

• I learnt react, Apollo client, but also learnt about TCP, HTTP, handshakes, etc and how those fundamental protocols affect the web development.

• I learnt Django and also learnt about ORM patterns like Active Record, Data Mapping, etc.

As general advice, I try to be knowledgable in the different technologies I use on my daily basis and how they interoperate. For instance I don't know that much about networking but I have an idea of how HTTP works, what's latency, bandwidth and how that affects web apps.

Quality over velocity

I have worked on corporates that moves really slow with releases every quarter and startups with weekly releases, and in both cases there is no point to deliver many tickets per sprint if they cause new bugs or regression issues that impact the end user.
The points that I already described are things that initially might slow you down if you're not used to, but the overall outcome it's likely to be with high quality.

"When one Teaches, Two Learn" - Robert Heinlein

Lastly, this is what helped me the most, I always share the new knowledge I gather, this forces me to learn more about certain topic and look for easy ways to explain concepts. You might be surprised of how hard is to explain something you think you know.
- Once you explain something, ask for feedback, if someone doesn't understand a given concept that gives you a hint of an area you might not know neither.

Thanks for reading! You can follow me as I continue sharing tips of how to become a better developer.

Subscribe now