DEV Community: Sara Inés Calderón

PR Templates For Better Documentation & Code

Sara Inés Calderón — Mon, 01 Aug 2022 19:02:32 +0000

How do you get the most out of a small team with limited resources?

While many folks may think of this question in the abstract, as someone who has been the lead engineer in teeny tiny startups for the past several years, and worked in non-technical capacities at media startups before my engineering career, I've had more than a decade to find out.

One of the main answers to this question is to prevent mistakes from happening. When you have too much to do and not enough hands or funding to do it, one of the first things to go is code review. You gotta ship product, not just sit around and talk about it. While that is definitely the sentiment in many places, I can speak from experience that this will more than likely cost you more time in the long run. Using a PR template can help you catch mistakes before they happen.

Another big issue when you need to ship features faster than you can fix technical debt is that you don't really have much in the way of documentation. That means when you encounter a bug multiple times, you may not remember what you did the last time to fix it. Using a PR template, at least in my version, can help you quickly find the info you're looking for.

Finally, when it's all-hands-on-deck, no one has time for a code review. So instead of making code reviews occasional events, from the get go you ensure that code is not merged unless it's reviewed. It seems like it takes up time, but when you're not having to stop what you're doing to do a hotfix, you'll be grateful for these reviews, which can be handled easily via PR template.

So, without further ado, check out the PR template I've been using for years and help yourself. Everywhere I go, I introduce this template and folks often adapt/change parts of it to suit their organization. I've literally had folks fawn over what a great documentary tool this template is, so I hope y'all can enjoy it.

TICKET

Link to ticket goes here

WHAT THIS PR DOES

(Summary of the PR issue & fix -- specifically list the steps you took to address the problem, link to Jira or design. Ex: 1.) Added props, 2.) edited styles...)

HOW TO TEST THIS PR

(Explain how to test the new features added in the PR, for example: "When you click the new icon you should go to the next screen, etc.")

ADDITIONAL INFORMATION

(Optional section to add info if needed, such as: blocked, don't merge until something else is merged, hotfix, etc.)

MERGE ORDER

(Add details here on whether this PR should be merged before or after another PR, or if it is blocked by another PR, etc.)

WHAT DOES "DONE" MEAN?

This PR has been:

[ ] linted
[ ] tested
[ ] functionality has been verified against designs or tickets
[ ] commented / documented
[ ] made sure you pulled latest, resolved conflicts & tested
[ ] peer reviewed at least once
[ ] reviewed again by someone else (could be current review)

Image courtesy Vijay Sridhar here

5 Tips for Easy to Update React Native Apps

Sara Inés Calderón — Tue, 19 May 2020 15:42:47 +0000

Working in React Native for the last three years I've learned so much -- not just about RN, but about how to build applications so that they're easy to update and change. Because, regardless of how great your first iteration is, there will be API updates, there will be design overhauls and you want these changes to be as easy on you, your team, and future developers as possible.

From when I started working in version thirty-something of React Native to now, it's a totally different ballgame in terms of the barriers you have to deal with in development. That said, there are a set of tools I have learned to depend on in every app that I build -- whether it's just for one platform, or both.

What these tools have in common is that they make app-wide changes very fast, save you time in the short- and long-run, are simple, don't require complicated tooling and can be easily learned by everyone who touches the code.

Make Your Icons a Custom Font
There are many benefits to using a custom font over images for icons in an app and I would encourage you and your team to take the time to do it. You can use third party services like Icomoon or Glyphter. Upload svgs, and they spit out font files like .ttf -- and then you install these fonts in your app. I've used and adapted version of this for several apps in order to display your new font as a component.

Since your icons are all Text components, instead of images, you can change the colors, sizes, background colors and positions the same as you would with or components, plus you don't have to carry around a bunch of image files in your app.

Use a Responsive Library for Width & Height
Trying to get everything to look right on iOS and Android, let alone on all the models of those devices, is a real pain. I'm a huge fan and have had great results with Marudy's responsive library.

I've used it on multiple apps and it translates really well, plus it's easy to use. What I usually do in practice is take the design element's width or height (say a button 75px wide), divide by the design's sample app width or height (say 375px wide) and come up with a percentage. Using that button as an example, if it's an iPhone X, which has a width of 375, your code will be: {width: wp('20%')}.

Create an App Text File
I've found that importing strings as variables all over your app, while sometimes a pain when you have to import eleven-ty-billion variables for a form, is ultimately clean, efficient and easier than using strings. For example, if you need to make an app-wide change a label or button, it's lightning fast because you only have to do it in one place, here's an example: export const NEXT = 'Next';

Create a Colors File
Similar to the app text, creating a color map that you can use for all your colors (which in my experience will inevitably change) will save you tons of time. I create a Colors.js file where I define all of my colors in an object either by hex or rgb values, then I import that Colors object into my file and use that to color text, buttons, backgrounds and everything in between. This way, when your shade of blue changes, you change it in just one place and it is reflected all over your app. Here's an example of the Colors.js file:

export const Colors = {
  black: '#000000',
  white: '#FFFFFF',
};

And here's an example of it in use:

textColor: {
  color: Colors.black,
},

Update React Native as Often as Possible
Even though upgrading React Native has gotten so much simpler (a huge shout out to all the contributors for making this happen!!), it can still be quite a task to change versions. Most recently I had a hard time moving from 61 to 62, so I urge you to keep an eye on the new releases of React Native, and bake in upgrading (both platforms) to your development cycle. If you don't, what will most likely happen is that you'll need to upgrade for one reason or another and you'll have to do it in a time crunch, and nobody needs that kind of stress in their life.

I follow various React Native folks on Twitter, including the official accounts, and periodically check the React Native blog to keep up to date on these releases. If you'd like more info on the folks I follow, or details on any of the suggestions above, feel free to ping me on Twitter, @sarachicad .

How to Learn React Native

Sara Inés Calderón — Thu, 28 Nov 2019 19:26:11 +0000

I enjoy the React Native ecosystem because of the opportunities working with this tech has afforded me to learn from, with and to build diverse teams.

When I started working with React Native in 2017 it was relatively new, so finding folks who had experience was not an option. Thus, I had the chance to train folks in React Native, which allowed me to work and grow with some of the most diverse teams I've ever experienced.

In the years since, I've started managing the React and React Native meetups for Women Who Code Austin and have enjoyed meeting dozens of folks interested in learning React and React Native. I wanted to put together this post to gather most of those tips, and also help folks who may be getting started.

Learn React or Javascript
React Native isn't going to make as much sense unless you've done React before, that said you can also probably skip this step if you are familiar with Javascript or another Javascript framework.

Learn Redux (Or Something Else)
More than likely, you're going to need to manage state on your app. Most commonly folks use Redux for this, though you can also try MobX, Context, and then you can use these with other libraries to deal with async stuff, Redux Thunk or Redux-Saga.

Read The Read Native Docs
Here. They are pretty good and have been improving lately, these will be your friend, get familiar.

Install These Things
React Native docs have good info on what you need to use the technology, but it can be a real pain that involves a lot of online sleuthing and reading of GitHub and StackOverflow issues, nonetheless, I recommend going here to the "React Native CLI Quickstart" section.

React Native Tutorial
I found this tutorial by Spencer Carli was really helpful to me and I always refer folks who are learning to try it out, check out the "React Native Basics" course.

Learn About iOS Things
There are a few core things about iOS that you need to understand to make your development on this platform easier. You won't be able to develop for iOS unless you have an Apple computer, FYI.

CocoaPods is a dependency manager for iOS learn more here.
XCode is the development environment for iOS, you will have to go into XCode sometimes learn more here.
It costs $99 a year to be an Apple developer, as in using iOS to distribute (publish) apps, learn more here.

Learn About Android Things

Android Studio is the development environment for Android apps, you will occasionally have to use it, check it out here.
Jetpack is an Android library and tool manager, learn more here, they are usually within the AndroidX namespace, learn more about AndroidX here.
It costs $25 for a one-time fee to become an Android developer and distribute your apps on the Google Play store, learn more here.
Gradle, you will need to know what the gradle is if you develop in Android. It's basically a build system, check out more here, here and here.

Learn About Fastlane
Fastlane will save you a ton of time and you want to know about it.

Why You Need To Go To Your First Hackathon, And How To Get There

Sara Inés Calderón — Thu, 21 Nov 2019 18:06:13 +0000

So you’ve heard of hackathons, maybe you even have friends who have gone, and you’re curious but haven’t taken the plunge yet — why not? I urge you to go as soon as you can, because if you’re interested in technology or a career in this sphere, you can’t afford not to go.

First off, a hackathon isn’t anything illegal and has nothing to do with “hacking” that will get you in trouble. It’s basically a contest or competition in which teams get together and bust their behinds to build a project in a short amount of time, usually over a weekend.

There is often prize money associated with hackathons, but it’s also a great chance to try new things, meet new people, test out some skills and get some more code or experience under your belt for that next job interview.

You need to go to a hackathon because, if you want to work in tech, hackathons are where you get a hands-on view of how tech sausage is made. It’s the extremely abridged version of what it’s like to work in a startup, gives you the chance to perform in several different roles (marketing, designer, coder, user experience, etc.) and whether or not you perform is entirely up to you.

At the end of this experience, you will have learned a lot about yourself, and if nothing else, you’ll know more about what you want to do in tech than you did before. For example, perhaps you think you want to be a coder but have never actually coded — going to a hackathon might help you realize you’re much more interested in design or project management. Maybe you thought coding was too hard for you, but when the judges call your name and you won, you realize that you can actually do this.

Go to a hackathon. Do it.

How do you find out about hackathons? I personally have Google alerts set up, but I also see them periodically on Twitter or Meetups, there are tons of ways to find out, but you have to put yourself in the pathway of discovering them. Follow people on Twitter that tweet about things like that, set up a Google alert, or ask around.

How do you prepare for a hackathon? Read up on what the rules/guidelines will be, if you can find a team of people you know, maybe organize ahead of time, and if you know what the APIs, tools or frameworks are going to be, brush up on those. If you have a team before you head in, start sketching out the basic idea of what you want to build if that’s allowed.

If you don’t have friends who want to go with you, think of this as an opportunity to enjoy being outside of your comfort zone. I’ve made some really great friends by just taking a chance and asking if they wanted to work together, or sit together, or hang out sometime. Get yourself a nametag, add your skills to it, and start glad-handing. Perhaps you’ll meet a team, or perhaps they’ll find you!

Most importantly, though, ask yourself why you’re going to this hackathon:

Do you want to meet people?
Do you want to win?
Do you want to flex your code muscles?
Do you want to make some money?
Do you need code samples for that job you’re applying to?
Do you want to network with a sponsor or showcase a particular framework or technology in a project?

If you can define a few of these goals for yourself ahead of time, you’re practically guaranteed to have a successful experience at a hackathon. You’ll always learn something and grow from a hackathon — but not if you don’t get started and attend your first one.

Good luck!

How To Build An Inclusive Engineering Organization

Sara Inés Calderón — Thu, 21 Nov 2019 18:00:16 +0000

I wanted to wake up every day excited to go to work.

It was June of 2017 and with three years of software work under my belt I wanted to work somewhere that made me feel included, excited and appreciated. When I met with musx and the opportunity to grow an engineering organization presented itself, I couldn’t say no — and the ensuing months have been among the most intense, hectic and beloved of my professional life. More than anything I love what I do because of the people with whom I’m doing it, and the way we’ve decided to work together.

As the inaugural engineer at musx I had a unique opportunity to think about what kind of team we wanted to build before we started building it. My experiences as a Latina engineer had informed how teams could be exclusive or make people feel uncomfortable — even without meaning to. What was exciting, and surprisingly difficult, to figure out was what a dream engineering team would be like: how it would function, and what to do to get there?

It’s easy to find women and people of color to staff an engineering team — if you’re looking. It’s like my grandfather would say, “Sí se puede, si se quiere” — you can do it if you want/desire to. I’d like to share some tangible ways that anyone can build a more inclusive technical team, while building a stronger team that has a better understanding of the code base, can communicate across departments in the company, and bands together to support each other when the going gets rough.

Like most things, it’s a work in progress. That said, in hindsight there were things we did before building a team turned out to be essential to creating the conditions for our success. There are things we do in the day-to-day experience that are important and surely every time we decide to bring someone into the organization we’ve made decisions geared towards keeping our engineering team inclusive. This is meant as a way to share our experiences so as to empower others to create inclusive engineering organizations that, hopefully make you excited to go to work in the morning.

Write It Down

Write out the way you would like your organization to function. This includes a general motto, and example is: “Be kind for everyone is fighting a hard battle with code”, as well as the policies and the procedures that you will implement to support this culture. A few examples that we used include: a PR template, code review guidelines, project management template, and an explanation of Storytime — our own version of in depth code review.

Writing things down gives you the ability to have a concrete vision, and allows everyone to be able to refer to that vision when needed. Additionally, you can open source this document within your organization, and everyone can buy in that way.

Keep Learning

Making a commitment to an inclusive engineering team means that you are willing to look outside of “traditional“ channels, which means people who may or may not have a formal computer science degree, from less traditionally “elite“ colleges, or even who are self-taught or learned from a bootcamp/code school. You should adjust your job descriptions accordingly. That also means that you need to make sure you create an environment of continuous learning.

Creating a learning environment can mean a lot of different things. Making sure you budget for conferences and courses, for example, encouraging people code review and pair program together, is probably the first place you want to start. The benefits here include a larger familiarity for everyone with the code base, as well as each other, and as a bonus you create a more trusting environment where people can pull together, and depend on each other, to solve the more difficult technical problems you’ll encounter.

Just as inviting people to collaborate on open source guidelines allows people to buy in, creating opportunities for collaboration and interdependence creates a culture where people are bought in to their team, and by extension the product they are building.

Change Small, Important Things

There are small, important things you can change that will make big, important changes in your organization. Do your job descriptions use the words “ninja” or “rockstar”? Do you require a CS degree? Do you ask for 5 years experience for an entry level role? A Masters for a senior role?

I invite you to reconsider if that’s the case. Do you want a ninja or a team player? Do you need a CS degree or familiarity with new frameworks? Do you need experience or hunger? Do you need a Masters or someone who knows your code base? All of these things are small and hard to change, but will result in vastly different effects on your company’s hiring.

The same goes for interviewing.

Do you ask the same interview questions you always ask but also expect different results? Why do you whiteboard in interviews — does that reflect the day-to-day? If not, why are you doing it? Are you asking questions that help you determine whether this person will be a good team member who works well with others? If no, then why do you expect your interview process to give you those candidates?

Review The Feedback Loop

If you’re bringing different people into your organization that means you need to be different, too — especially in the way you give feedback. I found it difficult myself to examine ways to give feedback that were not inherently masculinized: killing it, slam dunk, pinch hitter, and the like. When I asked, I found that people really want feedback that will help them grow — and that’s the hardest kind to give.

Feedback can mean everything from high-fives to asking for more in a code review (one of the ways we give feedback at musx is the DJ airhorn every time something awesome happens). Determine what your team needs/wants and find a middle ground to giving it to them. For example I’ve found that highlighting positively good work while also noting room for improvement — I suggest you write documentation / update tests / break this out into a service — is actually helpful to folks & results in real growth for them, and better code for you.

At the end of the day what all of this means is that you and your team will enjoy your work, and working together, more. And because you collaborate, there will be room for everyone to learn, so you don’t have to stick to a diet of white guys with CS degrees, and you may even learn new ways of doing engineer work, and you may get to a point where you smile for no reason because you didn’t know you could love going to work in a Monday so much.

I did.

If you have questions feel free to ping me on Twitter: @sarachicad .

My 1 Year Coding Anniversary: From Video Tutorials to Software Engineer

Sara Inés Calderón — Thu, 21 Nov 2019 17:50:47 +0000

(Originally published in September 2015)

A year ago I landed at the Ontario airport (outside LA) equipped with exactly two suitcases, one computer backpack and about a truckload of hope. I looked at the mountains, took a deep breath, and said to myself “Let’s do this.”

I had just dropped everything, put my life on hold and flown in from Austin to begin the the Sabio coding bootcamp, hoping that the JavaScript tutorials I had been taking online the past few months, plus my boundless enthusiasm and Sabio’s secret sauce would open the door for me to enter the tech world as a software developer.

I’ll ruin the suspense for you: it worked. I’m currently a software engineer in Austin, Texas working primarily with Angular and C# — both of which I learned through Sabio.

But let me tell you a little bit about how I got there.

One of my favorite sayings is, “La vida es dura, pero es bella,” which means life is hard — but beautiful. So it goes with my coding journey. Some folks’ brains are set up to receive the idea of code better than others, it’s almost a natural fit. To be truthful, I don’t feel like I fit into this category. Nonetheless, I did it, and am doing it, and it gets a little easier every day.

I had just been living in Austin for a few months before I went back to LA, lucked out and found a place to stay with a friend, and began a daily commute to Sabio’s class in Culver City. The days were long: after 8 to 11 hours of coding, I’d go home and put in a few hours of work work, make my lunch for the next day and pass out. On the weekends I’d try to visit with friends and family, and code, and work and try to sleep in a little bit, and maybe do something fun. It was exhausting.

From September to December of 2014 I worked the hardest I’d worked and pushed myself that hardest I’d pushed probably since I was an undergrad at Stanford University. But it was worth it.

Sabio had us coding on day one, and I would be lying if I said it didn’t produce a lot of anxiety because I literally had no idea what I was doing. And yet, I did it.

All throughout Sabio’s training — when I was struggling to understand classes and methods in C#, when I was fighting with the Google Maps API, when I was getting very little sleep at my first hackathon, when I started studying for my tech interviews — I felt like I didn’t know what I was doing, yet, when I had two job offers on my plate earlier this year I finally felt like, perhaps, I did know a little.

As I mentioned, I wouldn’t describe the process of switching careers to tech as “easy,” but I would said it was well worth every bit of frustration, nervousness, disappointment and anxiety.

Sabio changed my life by teaching me how to code.

My starting salary was the same as the highest salary I ever earned in media. And after four months I received a raise — so I’m now making the most money in my life — and that’s not even to mention the bonuses I get at my job.

Life is good, tech is good, and Sabio was the doorway to this life.

The funny thing is, although I wrote in detail about the 40 interviews and four months it took me to find my first tech job, I don’t even remember what that stress felt like because I’m enjoying the life I have now so much. I remember the good times, I remember things Gregorio (Rojas, the co-founder and primary instructor) and my cohort taught me, I remember the fun times we had joking in class, I remember the joy I felt when we won our first hackathon — good things. The bad things have faded away over time.

So, a year into my Sabio journey, I have organized a successful diversity hackathon as co-director of Women Who Code Austin (with 90 participants, most of them women, and a majority of winners who were coding newbies), started JavaScript and C# study groups with my friends and co-workers, am working towards certifications and am actively meeting people in Austin’s tech community. I have a new life, a great life, and one that I know will continue to provide financial security for my family and me for years to come.

So when I look back on my year of Sabio, and that first day at the airport, it makes me glad. Not only did I do it, but I’m still doing it, and don’t plan on stopping anytime soon.

4 Things You Can Do NOW To Improve Diversity At Your Tech Company

Sara Inés Calderón — Thu, 21 Nov 2019 17:40:57 +0000

The funny thing about diversity in tech is that it’s not hard to find—as long as you’re looking for it.

I’ve written before about the way folks explain why they can’t find diverse candidates in tech, and here I wanted to offer some tips that you could literally do TOMORROW to immediately make your workplace a better place for those “non-traditional” tech candidates you’re looking for.

1.) Make sure you’re offering LGBTQ & woman-friendly healthcare.

Shoot off an email to HR or ask in a meeting — Do we offer LGBTQ-inclusive healthcare? How generous is our maternity policy?

This is an action that will literally take you less than a minute, and can transform your company into a place that doesn’t just say things about caring about diversity, but institutionalizes them. (Note: you want to make sure that, after you ask the question, you work to make sure that you do offer LGBTQ-inclusive healthcare and offer generous maternity leave).

2.) Anywhere you have “entry level” or “BS Computer Science” written add “or bootcamp grad”.

Doing this will also take you, literally, a few minutes to accomplish and will open up an entire world of diverse candidates. Why? Because by asking for only Computer Science majors you are limiting yourself to a mostly white, mostly male set of choices. Whereas 16% of undergraduate Computer Science majors are women, this number is 36% to 43% for graduates from coding bootcamps.

These bootcamps are also much more racially diverse than CS programs.

So it’s pretty simple: if you want more candidates who aren’t white men, open your job posts up to bootcamp grads. Besides, they don’t teach the latest and hottest frameworks in most universities, but they almost always do at bootcamps.

3.) Go to recruit at universities that you haven’t before, such as Huston-Tillotson (HCBU) or St. Edward’s or Texas State (Hispanic Serving Institutions) — don’t just go to the big universities like UT Austin.

I’ll use Austin as an example because I’m most familiar with that area. Tech folks recruit at UT, but not necessarily at HT or St. Ed’s or Texas State. Is it because it’s easy, or because there’s an assumption that there’s “the best” and “the rest”? I don’t really know the reasons, but I do know that if you try something different you will probably see different results.

4.) Do one thing different every week you are looking for candidates: tweet at diversity groups in the area where you’re recruiting, send messages to Meetups, search events to see if there are any diversity panels or lectures going on and roll up to talk to people.

In other words, try.

Folks reach out to Women Who Code Austin all the time with no particular agenda, “Hi we wanted to see if we could support you,” “Hello do you need sponsors?”, “We have an event and we’d like to invite you,” etc. Usually what happens is that some of our members attend, and sometimes they end up working at these places — or at least interviewing there.

It won’t hurt to try, it will hurt not to, though.

There you go, I fixed it for you, some low-hanging diversity in tech fruit for you. If you have any questions or comments feel free to ping me on Twitter @sarachicad.

When Classism Is In Software, Setting up iOS vs. Android with React Native

Sara Inés Calderón — Sat, 08 Jul 2017 16:59:21 +0000

Technology is going to reflect the values of the people who built it. That's something I ran into recently when I was trying, like hell I might add, to get the Android simulator set up for React Native.
As a journalist-turned-developer one of the things that always blows my mind about technology is how dogmatic the people who grew up in this world can be. Folks are practically religious about their languages or preferences, which is strange to me, given that I come to this world from journalism and media, where you can use different tools to accomplish the same goals on any given day.
This attitude infects the technology itself over time, and trying to set up the Android simulator for the first time was exemplary of this.
Like most developers I know I have Mac laptop. So it was second nature to me to use the XCode simulator when I began developing in React Native. Once I got to the point where I needed to see how the code looked on an Android device, I ran into a series of problems that highlight the vast disconnect between people who make technology, and those who use it.
About 82% of people use Android, only about 18% use iOS, yet setting up an Android simulator was a nightmare. Think about that: trying to make technology for the vast majority of users has more barriers than making technology for a small minority of users.
In an industry obsessed with user experience, this makes no sense — unless you think about who's making the technology (people with higher incomes who can afford Apple products), and their experience using it, versus those for whom they are making it (people who make less money and buy Android products).
Seeing a React Native project in the simulator is as simple as a CLI command. Seeing an Android project in the simulator involves installing Android Studio with special instructions, making sure you have a bunch of files in your Android folder and on your machine, and ultimately giving up and installing Genymotion.
Shoutout to Chris Geirman, I couldn't have done it without you.
So what's the point? The point is that we have to think outside of our experiences, and at least try to think into the experiences of our users when we build technology. Otherwise your device won't work on people with dark skin or tattoos, you'll build health app that ignore women completely, or you'll tag people with dark skin as gorillas.
This stuff matters because we are imperfect beings, so we build imperfect things, if you don't stop and think about it, you're going to mess it up.