DEV Community: Camila Lenis

I graduated, now what? Camila Coded in 2022

Camila Lenis — Mon, 07 Mar 2022 03:26:12 +0000

Hello world, I'm Camila Lenis, a software developer from Colombia 😁 and just as you I have a story to tell...

How this began?

I can't even remember when I felt in love with tech world. I was so young. Then, I started in collage when I was 17, with many insecurities and many dreams.

I can't deny that beign the only woman in the room was so intimidated. But instead of telling you about all the times I felt lost, I'll tell you about the times I felt I had a place in this world.

My biggest technical achievements are…

I had the opportunity to work in a start up since I was in collage. That lead me to meet the most amazing and talented people I've ever met. But it also taught me that to have a place in the world I had to raise my voice.

This is a memory of one of my first webinars in Colombia for the anniversary of a community called CaliSharp. Being the only woman in the middle of so many people with so much experience and feeling that I also had something valuable to say taught me that just as I can learn from them, they can learn from me.

My biggest technical goals are…

A few days ago I graduated from college. Now I want to learn as much as I can in an early stage start up and improve my backend development skills.

I pledge to break the bias in tech by…

Content creation.

One thing that helped me to feel that there were more women like me in the world was social networks. I met a lot of communities of women who were not only technically good, but were moms, athletes, artists and whatever they wanted to be.

I share my journey in the tech world so that more women can see that they can do both and more! You can find me here

Throughout my career, I have overcome…

Sexist comments
Discrimination
Depression
Mansplaining

And the list could continue.

Advocating for myself looks like

Self love is not hot baths and masks. It's getting up every day and doing what you know is best for you to become the person you want to be.

I pledge to support women, non-binary folks, and other minorities in tech by…

Using my voice to tell you that you're not alone. And of course to clap them in their success 👏🏼

I’m excited about

The challenges that I hava this year in my new job in a Brazilian start up.

And I'm excited to hear about you! If you ever been told that you don't belog here, let me tell you that you deserve a seat in the tech table. Period.

The Code Review Guide

Camila Lenis — Tue, 06 Oct 2020 22:24:34 +0000

Code reviews are a common pratice in tech industry. When you do a Pull Request / Merge Request someone has to review it, give feedback, and approve it when it’s ready to be part of master branch - if that is the branch to which the PR is directed, of course -

When it’s your first time being a reviewer, maybe you’ve already learned a little from the comments you’ve received. Don’t be scared, it’s not a big deal. Code reviews are also made to learn. You’re not attacking your teammates, it’s not a personal thing. You’re questioning their code, looking at how to improve it.

Remember that code reviews are not just for looking at what’s wrong, but for learning from others.

With this mindset let’s see how to do that:

Have context

Every PR has a purpose. It could be part of a proposal, a bug fix, a new feature and so on. Make sure to read and understand the caption of the PR before looking at the code.
It will give you better picture of what you are going to review. You can help by looking at which files were modified to give you more context of their scope.
Make sure that the modified files are part of what that PR is supposed to do (maybe they suddenly uploaded a file by mistake)

Ok, we already know what the PR is suppose to do. Let’s see the code. You can review it by two approaches: readability and functionality.
No matter what approach you choose, always keep these two questions in mind:

How could I improve that?
What could go wrong?

Reviewing by readability

Maybe this is the most superficial way you can begin to review it, but it ensures that the code is easily maintained over time. If you can’t understand that code now, in one year you won’t get it either.

Every piece of code you write has a price: maintenance. Do others a favor and check carefully.

These are some of the things you can review:

Look for typos -they happen all the time- in variables and functions names, in comments descriptions or even in files names.
Class and functions are well-named. The responsibility of the function goes according to the name.
Descriptive and well-written comments. This does not mean it should be long, be assertive.
Consistency. The code is not written as an isolated piece in the repository. Make sure it is consistent with the practices. Try to make sure that the code you are reviewing is in line with the rest.

For example, it happens with case styles:

// camelCase
// PascalCase
// snake_case
// kebab-case

See that all the code has harmony and that the piece they are going to add doesn’t make noise.

No print statements. Maybe they forgot it while debuging.
Avoid unnecessary nested statements.
Return early whenever you can If you see code like this:

var myVar = "I am a variable"

if strings.ContainsAny("a", myVar){
   return myVar
}else{
   return nil
}

You can refactor it doing this:

var myVar = "I am a variable"

if strings.ContainsAny("a", myVar){
   return myVar
}

return nil

Suggest anything you think is necessary to make the code better understood.

Reviewing by functionality

As a reviewer you’re also responsible for the quality of the code that the company ships to production. Please pay attention to the detail, scalability and especially security.

Does the flow makes sense?
Are there innecessary validations, loops, whatever?
Single responsability for methods and classes. So testing can be more atomic.
Is it susceptible to failure? For example, make sure that it’s checking the length of the array before accessing it. Or at least ensure that it will not end up in an error -NullPointer alert-
How would I have done it? Is it my way better? Could that logic improve the current one?
Tests are not changing without a reason. For example, if the test was used to validate that the function is not throwing an error, but then it’s validating that the function throws and error, ask why. Maybe there will be breaking changes that affect the operation.
Don’t delete tests without a reason. Ask why if you don’t get why the test has been deleted. Isn’t it necessary anymore? Why?
The tests are enough to fulfill the impact of the change. And also, review that tests are asserting what they should.

What should I do when I don’t know the language of the code?

This is a classic. You don’t know about a certain coding language or technology and you have to review it.
First, don’t be scared. Make sure that the other reviewers know the language just because they can detect things that you can’t. And ask them if it’s necessary.
A good starting point is the superficial review: look for typos and well-name of variables.
If you want, you can search for other code in the repository of the same language and try to discover patterns. Remember that you can ask if something isn’t clear.

And the most important advice: Don’t follow the “Best Practices” blindly. Always think first. Each piece of code is trying to add value to the product. Think how it could add value and make life easier for the developer who will maintain that code later, maybe it’s you.

This article was first posted in Medium
Thanks for reading :)

Two Soft Skills That Are Not That Soft

Camila Lenis — Thu, 16 Jul 2020 03:07:27 +0000

Soft skills are the hardest ones to develop. They make you stand out in your team, either because you own them or because you are missing them.

And most of the time they are not a gift that you were born with it, but skills that you can learn and apply.

This time I will show you two essential soft skills that are tough enough to make the difference between an assertive person and a sloppiness one.

Straight Talk

Communication is the key. If you are not capable of saying things in a way that other people can fully understand your concerns, you are lost.

Your message has to be clear, transparent and direct. A formula that people often use to develop clear communication is to build the sentence like

Context + Problem + Request

You don’t have to build an entire talk to request something. That’s a waste of time, omit intro, get to the point. That doesn’t mean that you have to be petty and rude, people will thank you if you give their time the value that it deserves.

Give direct feedback

When you are giving someone else feedback give it in a way that they completely understand the message. If you are trying to minimize their chances of getting better by not making them feel bad, you’re not helping them.

Remember that truths without empathy are only cruelties. Give clear feedback with the intention that others grow, don’t take away their mistakes. Be honest and assertive, you won’t gain anything if they just feel dejected.

Grit

If you are going to make something, do it great. That means there could appear problems, obstacles and questions, but you have to be strong enough to take them and build a stairway to your goal.

When you quit a task just because you don’t know how to solve it yet, you are missing the opportunity to learn in a potential way.
The more productive people are well learners. The time that you invest in searching for a solution today may be time saved on a future task. You can’t avoid them all your life.

Soft skills may not be that soft but they are transversal. They will not fit in a job profile because they don’t depend on your career, they depend on you. Become a better version of yourself.