Stress and insecurity: a newbie’s first remote dev team experience

Eunice Park
Chingu
Published in
7 min readNov 17, 2017

Before the title scares anyone off, I’d like to assure I’m writing this article in the hopes of convincing people to join Chingu Voyage and experience working in a remote dev team.

To backtrack a little and explain how I came here, I come from a non-technical background and started learning to code with freeCodeCamp’s curriculum in May. I had first heard about Chingu from one of the “I got a developer job” threads on Reddit, but didn’t make the leap to sign up until I encountered it again in freeCodeCamp’s forums and saw how popular it was.

Since then, I’ve been part of two voyages (a voyage is a six-week sprint to build a project with a small team), and have finished two projects: a web app with weather, time, quotes, a to-do list, and customization settings, and a Chrome extension with similar features written in React, plus features using the Chrome API.

Both experiences have been amazing, but it wasn’t all roses and sunshine. As the song goes, it was about 80% pleasure, 20% pain, but also 100% reason to do it again. Since most people have talked about the rainbows and unicorns of collaborative development, I’ll talk about the sh*tstorms and chupacabras, and why I’ll participate in Chingu again.

PART 1: LEARN ABOUT YOURSELF

Learn to respect yourself

My Chingu Voyage experience has truly been a voyage, a voyage of learning about myself and learning about working with others. In my first voyage, I was paired with a more advanced partner, so I was eager to “prove” myself. I also have a tendency to want to please other people. These two desires lead to me overextend myself because I didn’t want to “disappoint” my partner.

I completed all my tasks, but I realize I could have done so without racing like a hell-bent greyhound, and that there was no need to “prove” myself. I needed to have faith in myself and realize that I could make meaningful contributions without running myself to the ground. All I owed my partner was hard work, responsibility, and timely communication.

I learned how to calibrate my coding-life balance, which I think is good practice for when you get a developer job and need to balance work and life.

Learn to deal with roadblocks and deadlines

We’ve all had experience with deadlines in school and other areas of life. But dealing with deadlines in coding is a bit different, because what do you do when you’ve spent hours and hours trying to squash a bug and remain just as in the dark as when you began?

For my second voyage, while my teammates had built functioning notes and to-do list components in React, I was still struggling to change the style of a selected tab. It was a crushing blow to my self-confidence and one of the lowest points in my coding life.

Because I was afraid of falling behind, I desperately copied and pasted snippets from StackOverflow. In retrospect, I would have made faster progress if I had stuck to one resource and analyzed it until I understood every line, instead of giving up and searching for an easier, faster solution.

I learned in this situation to not panic, go back to the basics and docs, stick with one good resource, and the solution will unearth itself like a dazzling diamond. (It turned out my struggles were due to a lack of understanding of scope and closures).

I may learn slower than others, but if I trust myself and stick to my course, the puzzle pieces will fall into place. If not, I can ask my teammates for help, which I will go into in a later section.

PART 2: LEARN ABOUT WORKING WITH OTHERS

Learn soft skills

While reading articles introducing Chingu, Chance McAllister, the founder of Chingu, mentioned the importance of soft skills. I consider myself a pretty friendly person and thought, “Hmm… but I already know how to get along with others.”

Well, when working in a team with deadlines, situations may arise in which you need to to deal with grace. For example, a teammate might make a mistake which you have to fix. On the flip side, you might make a mistake, and have to ask others for understanding.

So how do we avoid friction and bad juju in teams? I learned that by using soft skills, I can contribute to creating a positive, healthy team environment. Chance wrote an article summarizing Dale Carnegie’s soft skills principles. The ones I find most useful are:

  • Give honest and sincere appreciation.
  • If you are wrong, admit it quickly and emphatically.

If you’ve ever worked behind-the-scenes, you know how dispiriting it is if no one notices your efforts. So whenever I noticed that my teammates improved something, I let them know how much I appreciated it. When you encourage others, it spreads positivity, and the positive feedback loop reaches you as well.

If you’re not a project manager, you might not have a chance to make wrong decisions. But I apply the second principle to my social interactions by being self-aware of any ways I might have inconvenienced others, and take responsibility by being quick to apologize. See the log in your eye before seeing specks in others’ eyes. This can help prevent any possible dissatisfaction from building up.

Learn to ask for help

Most of us are learning to code on our own. We’re independent, self-reliant, and confident we can solve problems on our own. Knowing how to get things done on your own is important, but asking for help can be an amazing opportunity to learn. It’s also a way to break the ice, because your teammates might also be secretly feeling like imposters.

There’s no such thing as a dumb question; everyone has been at the place you’re in. For example, a teammate hesitantly asked how to define variables and functions inside a class component. It was a good question because I realized I was blindly using classes without fully understanding what they were.

Asking for help can also be an immense time saver. It’s amazing how fresh eyes can spot problems we’ve overlooked. I was struggling for hours trying to figure out why my component wasn’t re-rendering after a state change and tried in vain to solve it with functional setState and callback functions. However, a teammate pointed out that I hadn’t passed it down as a prop!

So eat a little humble pie, don’t be afraid of looking dumb, and ask for help. Early on, I made the mistake of withdrawing from my team chat when I was struggling with React. Thankfully, my project manager scheduled mandatory weekly meetings, and once I confessed I was struggling, a weight was lifted off my shoulders. Admitting you’re stuck is only hard the first time. Don’t isolate yourself.

The Chingu community is an amazing resource to ask for help. Everyone here is passionate about learning and eager to help others. There’s an active help chat where people help each other out. And there are professional developers volunteering their time to answer questions or give advice, such as JavaScript extraordinaire Francesco Agnoletto, and P1xt, author of the famous P1xt guides.

CONCLUSION

Because I was teamed up with extremely motivated individuals, Chingu Voyage was a very intense, bootcamp-like experience. Enthusiasm is contagious. You’ll wake up eager to code. And you’ll definitely level-up.

Without Chingu Voyage, I wouldn’t have learned the basics of React as quickly as I did. Coding a project without a tutorial showed how shaky my grasp on React concepts was, and I probably would have given up if not for my teammates.

The advice I’d give is to study beforehand the technology you want to use in your project. Having a firm foundation of concepts will definitely save you frustration and hair pulling later.

For my next voyage, I know I’ll experience the highs and lows all over again, but the satisfaction of completing a project is priceless. So I know I’ll keep coming back for more.

I’d like to thank Francesca, Thor, and Pai for being the best, kindest, smartest, and hardest working teammates I could ask for 💕.

Also, any feedback on our Chrome extension would be much appreciated!

--

--

Eunice Park
Chingu
Writer for

Aspiring front-end developer. Perpetual state of mental breakdown.