DEV Community: Bryan Azofeifa Borbon

Top 10 mistakes Junior Devs do

Bryan Azofeifa Borbon — Mon, 08 Aug 2022 00:51:29 +0000

Are you a Jr dev trying to get better?

I have been working with a lot of Jr 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 responsability.

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.

My Journey: 14 years of writing code

Bryan Azofeifa Borbon — Sat, 30 Jul 2022 01:23:02 +0000

Believe it or not, this is how I started my journey as a developer:

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 something that's a reality:

It's likely that your company doesn't appreciate how valuable you are.

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:

Even though at the beginning I was totally lost, I focused on learn to learn.
Read is one of the most valuable habits I have.

You're going to get behind if you don't keep learning!
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 ❤️
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

Bryan Azofeifa Borbon — Mon, 18 Apr 2022 01:23:53 +0000

During my 10+ years of working as developer, once in a while I wonder about

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.