DEV Community: Raisa Gandi Putri

Learnings from my First Year as a Software Engineer

Raisa Gandi Putri — Mon, 26 Apr 2021 23:31:59 +0000

This was originally a text message for a friend where I shared my experience in my first year as a software engineer. Since that text message grew too long, I turned it into a blog post. If you’re about to enter the tech industry, I hope these points are insightful! Although there are a couple tech-specific points, most of the contents in this post are geared towards soft-skills and developing your attitude, which I think are the most important to hone and are useful in any industry.

Point #1: Company size makes a difference

I have worked at two companies - a large company and a startup that got acquired by a large company.

In a large corp, there's definitely more structure. Onboarding is so much more organized - you get a mentor to help ramp you up, a list of things to install and learn, etc. I had the privilege of a proper onboarding process on my first job out of school.

In a smaller company, you'll need to have initiative to ramp up properly. There's nobody to spoonfeed you, so you have to be super organized and reach out when you need help. The onboarding experience wasn't organized when I joined the smaller company, but I told my manager on Day 1 that I was overwhelmed and felt like I needed to catch up (new programming language, new processes, etc) so he made an effort to help me ramp up.

In a smaller company, things are usually more fast-paced and there are more learning opportunities. Since working at the smaller company, I’ve worked all across the stack (backend and frontend), and I’m really happy!

Point #2: Teamwork skills

This is probably the most important skill you can learn in your first year.As a software engineer, you want to be easy to work with. (Skill comes second, attitude comes first IMO). Everyone in the team has their own strengths (you do too; no matter how new you are - you were hired for a reason!), so try to learn from your teammates.

Be dependable, help your teammates when you can, and ask for help when you need it.

When you're mentoring an intern/new person, have empathy and help them out.

Give kudos to your colleagues when they are doing great (i.e. getting promotions, completed a project).

Also, try to get to know your colleagues over lunch, coffee, or during happy hours. Having good relationships with colleagues will make your job super enjoyable.

Point #3: Relationship with your manager

This is very important for your career!

A good manager will want you to thrive and be happy, even letting you move teams if that's what makes you happy.

If know your career goal or you have an area that interests you (e.g. if let's say you want to work on more server side projects, or you're interested in a different area such as frontend dev), you should tell your manager so they can help you get to where you want to be.

If there are some areas in which you are struggling, let your manager know! Whether you’re struggling with learning a specific technical topic, not sure on how to navigate your career, or struggling with burnout/mental health issues, your manager will be there to help you.

You'll have 1:1s with your manager regularly to talk about your progress and how happy you are with your career.

Point #4: Tech career progression

There are two tracks: technical and management. As you can guess, the technical track is coding intensive and you can become an expert in the technical side (coding, software architecture, etc). Management is more people-focused: helping the team succeed, taking care of your teammates.

However, a person can be both a manager and an expert in technical matters.

Point #5: Learn how to write clean code

You can learn this from checking in code (pull request) and getting feedback from the senior engineers. Or you could read technical blogs / watch technical youtube videos in your spare time.

Point #6: Be confident and humble

I suffered really bad impostor syndrome throughout college and early in my career, but I'm fortunate to have such a supportive team in my current job, so I no longer feel like an impostor anymore.

I actually talked to my manager about my personal struggle where I tend to compare myself with others (you can read this or this blog post where I shared more about my journey of social comparison), and my manager gave me a useful piece of advice that I carry to this day:

There's always someone better than you in anything you do, so define your self worth not on your output, but on the amount of discipline and effort you put in every day.

You'll need to be able to handle feedback from other engineers (especially as a new employee), and not get defensive about your code. If you do have questions or want to debate about something technical-related, feel free to do it though! A healthy team culture should encourage debate!

Point #7: Be honest and kind

If you mess up or make a mistake, tell your teammates about it! Don't hide or cover up your mistakes or your struggles. Transparency is key in a team - by sharing your mistakes, your teammates can help you and also learn from the mistake so no one repeats it again. It also ensures that everyone (engineers, product managers) has the same level of information - for instance, if someone were to ask 5 people on what caused the production bug last night, those 5 people will say the same thing.

Additionally, if you have an issue with your teammate, address it maturely with them. It is okay to point out mistakes, but do not blame and point fingers at people. A great team will foster a blame-free zone with psychological safety where people are encouraged to ask for help or make mistakes.

Lastly, please don’t go around talking negatively about another colleague behind their back. Gossip is a catalyst for a toxic culture, and it doesn’t solve any problems. If your teammate makes a mistake, it will be more productive if the team rallies around them and helps them solve whatever problem is at hand.

Last remarks

Work hard, be kind, ask questions, have an open mind, and good luck in your tech journey!

And if you know someone who’s about to start their journey in tech, please share it with them!

Image from here

Understanding Dependency Injection with Chicken Cutlets

Raisa Gandi Putri — Sat, 05 Sep 2020 17:55:59 +0000

The Backstory

So I started a new job. I'm learning a new programming language and framework. And my brain is fried.

As a form of stress relief, I spent the entirety of my lunch breaks obsessively watching Nigella Lawson's cooking shows - without the intention of following her recipes, of course! During this past week, I also needed to understand the concept of dependency injection to complete my day-to-day work. By doing both things at the same time, I ended up understanding dependency injection by frying my brain... and some chicken cutlets.

Let's Get Cooking

At a minimum, I'll need:

2 chicken escalopes
1 egg

Well, I could get these ingredients by farming some chickens and harvesting eggs in my backyard. But, what if I suddenly decided to cook with another breed of chickens? I can't just trade my whole flock of chickens for another! That would be a disaster!

Instead of farming my own chickens, why don't I buy some chickens from the farmer's market? I'm now free to switch between chicken breeds whenever I like! Plus, I don't have the hassle of rearing chickens in my nonexistent backyard.

In the programming world, this concept is called inversion of control, or IoC for short. I don't have control over growing my own chickens, because I hate the idea of opening a chicken farm. Instead, I'm delegating that task to other farmers, so all I have to do is buy their produce. I make sure to only do one thing: cook the chickens.

Dependency injection, in this example, refers to the act of buying chicken escalopes from the farmer's market and then "injecting" that ready-made ingredient into our cooking, instead of making it from scratch.

And that's it! Now, it's time to eat.

Acknowledgements

Pictures from here and here
Credits to Nigella Lawson's chicken cutlet video for inspiring me to write this post!

A Microservice as a House

Raisa Gandi Putri — Mon, 17 Aug 2020 20:28:08 +0000

Introduction

I started working on my first ever microservice during my summer internship after my junior year of college. Back then, I had no idea what a microservice was.

At the end of my internship, I gained some understanding on the topic, but I put my work on pause to complete my college education. I picked it up again as a full-time employee, with the aim of pushing it to production.

After deploying that microservice to production and going through the entire software development life cycle, I thought I'd share some insights around what it means to build a microservice from zero to hero!

Although some explanations might pertain to Golang (which is the programming language I used to build my microservice), this article is targeted to anyone new to microservice development!

Here is a good intro to microservices for those unfamiliar with the concept.

Let's Get Building!

We'll start with the premise that a microservice is a house.

How do we build a house? Here are the high-level steps:

Architecting
Building and inspecting each part iteratively
Final inspection

Let's explore each phase!

Step 1: Architecting

First, what kind of house do we want to build and why? Is it a beach house designed for vacation? A small house for a couple? A mansion for the royal family?

The answers to this question would define the use cases for the project, and the complexity of the project's architecture.

Linking back to our house analogy, an architect's house plan would translate to a software developer's design diagram.

Second, are there any houses similar to what we want to build? If so, don't try to reinvent the wheel. Grab a similar template, move forward with it, and modify it for your own needs. Then, document what components are needed and how they relate to each other.

In my case, my service was a Pulsar subscriber that sends events to the Amazon cloud, so the architecture is straightforward. It's similar to a subscriber service that my colleague has written, so I had a template to move forward with. However, my service has more dependencies than my colleague's. So, having a reference template doesn't mean I can't modify it for my own needs!

Note: learning design patterns also helps prevent developers from unnecessarily reinventing the wheel.

Step 2: Building each part

For simplicity, I'll separate the house into components such as the living room, bedroom, or kitchen.

Each room needs to be carefully built.

First, it needs to have good foundations (pipes, walls, floors, insulation).

Second, the room needs to look pretty.

First, the room needs to have good foundations (pipes, walls, floors, insulation).

A Golang microservice consists of packages, and each package does one task. In the house analogy, a package is similar to a room.

For example, my microservice has a package for subscribing to message, and another package for handling a message.

After working on each part, I need to make sure that my code does what it's supposed to do, which is where unit testing comes into play. More on this in Step 3.

Second, the room needs to look pretty.

Why? We want our rooms to be habitable at the very least. Aesthetic, cozy rooms are a plus.

To start with, the definition of "pretty" is subjective.

But most people would agree that a cluttered room is not pretty. Generally, we don't want five king beds in a small bedroom, and we certainly don't want clothes all over the floor.

Like a house, an application is built by humans, for humans.

A developer wants other developers to understand what they wrote, hence they need to write clean code.

Writing clean code means writing a function (or a library) in place of duplicate code. It also means commenting code where appropriate, and following the coding language's best practices.

Step 3: Inspecting each part

One afternoon at home, I found water dripping on my toes. There was heavy rainfall for the past few days, and the roof was leaking.

Ideally, we should make sure that the roof is water-proof before having anyone live in the house.

To prevent anything like this from happening, we should test an individual part after building it, also known as a unit test.

Moreover, homeowners don't want burglars stealing their stuff. Thus, they may install home alarms that get triggered when an intruder opens the window.

In the coding world, we throw an error when something bad happens.

Back to the house analogy: whenever a burglar tries to open the window, we should make sure that the alarm screams loudly.

Thus, unit tests should also verify that the appropriate error is raised when certain events happen.

Step 4: Repeat Steps 2 and 3

In application development, steps 2 and 3 are done concurrently. Build a part, test it. Then, repeat.

Step 5: Final inspection

Let's say the house is completely built. We've tested each individual part.

In the app development world, there are extra stages to go through before going to production.

I'm going to explain these next steps with house analogies, some of which may not be realistic, but it would be cool if they were!

Functional test

We want the user experience to be seamless.

Functional tests ensure that the sum of the parts work as a whole, without caring how the individual parts work.

For example, we want to make sure that the house entrance and the kitchen are functional.

Thus, a homeowner should be able to open the door with their key, come in to the house, and then cook a meal in the kitchen without anything bad happening.

Security review

Homeowners want a house that is safe.

We want to make sure that the house meets health and safety standards: windows are bulletproof (if need be), the doors have locks, the house is earthquake-proof, and that the home alarms are working.

Load test

This means testing that the house is standing strong under heavy load. Some possible scenarios:

A house party, with more and more people coming inside the house
Simulating rainfall, and gradually increasing its intensity
Simulating earthquakes, and gradually increasing the scale

Recovery test

We want to try to break the house by breaking itself and other things it depends on, and then make sure that the house recovers. An example can help clarify this.

For instance, we could change external factors that adversely affect the house price, like putting the house in a sketchy neighborhood.

Once we see that the house price drops, we return the house to its original location. The house price should return to its normal price.

Now, we can finally put the house for sale!

Thank you!

This is my first ever technical blog post, so feedback is more than welcome!

Thank you for reading, and I hope you enjoyed my first blog post!

Illustrations from: