Forem: Jennifer Tran

Reprogram Your Mindset

Jennifer Tran — Mon, 15 Mar 2021 16:04:06 +0000

Coming into learning with false notions can make the task harder. On my journey to leveling up, these were a few things I needed to reprogram in my own mind:

programming should be easy → programming is not easy
mistakes are fatal → there are no bad mistakes
there is no place for emotions in learning → embrace your emotions

Letting go of harmful assumptions

I needed to let go of the idea that programming was easy and that I should understand programming concepts straightaway.

Learning in general is an effortful, challenging task. If you believe programming should be easy, then every time it is not easy, you may come to the conclusion that it implies you are not capable of programming or that you are the problem. The truth is, programming is not easy and you are capable of programming, but like any kind of learning, there will be challenging days and that is to be expected.

Reframing my relationship to failure

Before babies can walk, they crawl. And part of that process includes falling down, getting hurt, and then getting back up again.

You will inevitably run into hurdles as you pursue your programming ambitions. Every time you run into a hurdle, know that you are not failing.

Any challenge is simply an opportunity to grow. So next time you make a programming "mistake", remember: there are no mistakes, just happy accidents.

Embracing my emotions

Before we are programmers, we are people with emotions.

As you embark on our journey of leveling up, you will encounter frustrating days of learning. The key is to acknowledge those feelings, whether they be feelings of frustration, overwhelm, stress, or powerlessness, before they turn into hopelessness and burnout.

In order to become the best programmer you can be, it is important to reflect on your mindset and reprogram it if you need to.

These are three points you can keep in mind:

Let go of assumptions that may harm you
Reframe your relationship to failure
Embrace your emotions

As always, please share your thoughts, I would love to hear them.

Talk Less, Listen More

Jennifer Tran — Sun, 14 Mar 2021 16:33:25 +0000

When you are in conversation with someone, are you usually eager to respond, or do you wait and listen to understand?

If you want to be a good communicator, it is important that you understand the value of active listening. Active listening allows for:

more trust
faster conflict resolution
improved productivity

The act of active listening doesn't only involve knowing what a person has said, but also observing non-verbal cues like body language and behavior.

Things to avoid

There are a few things you should avoid as an active listener: rehearsing, filtering, and problem solving.

Rehearsing

When you are focused on rehearsing, you are focused more on responding than listening. This can be counterproductive because you may not fully address what a person has said.

Filtering

When you are filtering, you are only listening for what you want to hear. This can be counterproductive because you can be limiting the potential for bonding in a conversation.

Problem Solving

When you are problem solving, you are trying to give advice or feedback. This is counterproductive because you may be emphasizing solutions over a person's feelings.

Try this in the next one on one you have and let me know what you think.

Be Openly Confused

Jennifer Tran — Sat, 13 Mar 2021 22:37:48 +0000

Fostering a culture in your software engineering team where people can share openly that they are confused is productive.

Sharing when you are confused provides an opportunity for:

team bonding
knowledge sharing
clarification of potential ambiguity
transparency

Others on your team might be confused too but may not feel confident enough to share it. Value vulnerability and truth over comfort and the guise of understanding because the team will benefit as a whole.

Three Ways to Prepare Your Pull Request for a Great Review

Jennifer Tran — Tue, 28 Apr 2020 03:20:53 +0000

Three Ways to Prepare Your Pull Request for a Great Review

Some software engineering teams use pull requests to perform code reviews. In a pull request (sometimes referred to as PR), you have the chance to get feedback or approval on your code and make any additional changes before merging your code.

The review process can be dependent on the personalities of reviewers, but I will describe the three ways I try and prepare my pull requests so that I can ensure that it is of the best quality before submitting it.

1. Review your own PR first

Try to take on the perspective of whoever might review your code. Do you have a mental checklist for what you think they might be looking for during the code review? For example, you can check for typos, formatting, or failing tests.

2. Add a description of what you prioritize in the review

When I am reviewing code, I find it helpful when the person who requested a review points out specific parts of the code they want me to look at more closely. Making note of a particular section you might want greater feedback on will help speed up the time it takes to receive a review. For example, if you are unsure of the way you mocked certain objects in your test, you can point that out!

3. Explain the changes made

Explaining why code changes were made along with what changes were made will help provide context to your reviewer. I find it better to provide some context than none at all. For example, if you are working in an open source repository and you submit a pull request, you can link the corresponding issue that was opened for the project.

You can improve your pull requests right now by:

Reviewing your own PR first
Adding a description of what you want reviewed first
Explaining why you made the changes you did

Let me know if you use any of these methods or share some other practices you follow before submitting your pull request! 🙂

Demystifying Development Environments

Jennifer Tran — Fri, 24 Apr 2020 04:32:40 +0000

To ensure that software is reliable and robust, it is important to consider using multiple environments in the process of software development. The environment setup I am most familiar with is one that has a development, staging, and production environment, sometimes referred to in their condensed form: Dev Env, Staging Env, and Prod Env.

🖌️ Dev Env

The development environment would be the first stage where a developer could deploy and test their code. It's like a sketchbook with existing sketches, where you can draw your first drafts of an illustration. This would be the first stage where potential bugs are found and fixed before moving onto the next environment: staging.

🎨 Staging Env

The staging environment is the next stage where code is deployed for additional testing. This is also the stage where Quality Assurance testing is performed. Staging is the environment where developers can test interactions between dependencies and is meant to mimic a production environment. Staging is where a variety of test cases are performed which either reveal bugs or affirm that the code is operating as intended. Once the code and all the test cases are verified, the code is deployed to the final stage: production.

🖼️ Prod Env

The production environment is the stage where code is live to users and fully functioning. Although, that doesn't mean there aren't bugs. 🐛😉

Ruby's attr_reader and attr_writer

Jennifer Tran — Tue, 21 Apr 2020 03:09:38 +0000

Imagine you are writing a program to help your local cat animal shelter, so you start by defining a Cat Class in Ruby 😺

class Cat
  def initialize(name)
    @name = name
  end

  def name
    @name
  end
end

Now you go ahead and make a call to create a new Cat with a name:

cat = Cat.new
cat.name = "Telemakhos" #=> NoMethodError

You run into NoMethodError 🙀. Well, that is expected since we haven't written a method to define a cat's name. We've just written the getter method. We also need to write a _setter_method.

What is a getter and setter method?

Getter methods are used to retrieve the value of an instance variable from an object and Setter methods are used to set the value of an instance variable. In many languages, you can read and write the value of an instance variable directly but in Ruby you have to specify a getter and setter.

Let's have a second pass at our Cat Class. Say you create a new instance of Cat attached to a variable tabby:

class Cat
  def initialize(name)
    @name = name
  end

  def name #getter method
    @name
  end

  def name=(name) #setter method
    @name = name
  end
end

tabby = Cat.new('Telemakhos')
puts tabby.name #=> "Telemakhos"

With our new getter and setter methods, we can now get and set the name of a cat 😼

Now imagine if you had more properties to a Cat than just name

class Cat
  def initialize(name, age, breed, weight)
    @name = name
    @age = age
    @breed = breed
    @weight = weight
  end
end

If you wanted to get or set any of those properties, it would require eight more getter and setter methods! 😿

There is a better alternative: attr_reader and attr_writer!

attr_reader and attr_writer are Ruby methods that can be used to replace getter and setter methods and mimic the accessing of instance variables seen in other languages such as TypeScript. Using attr_reader and attr_writer is especially useful when you want to read and manipulate the values of a Class that has many instance variables.

Here is an example of it's utility in depth:

# cat.rb
class Cat
  attr_reader :name, :age, :breed, :weight
  attr_writer :name, :age, :breed, :weight
  def initialize(name, age, breed, weight)
    @name = name
    @age = age
    @breed = breed
    @weight = weight
  end
end

cat = Cat.new("Julie", 3, "Tabby", 8)
puts cat.name # => "Julie"
puts cat.age # => 3
puts cat.breed # => "Tabby"
puts cat.weight # => 8
cat.weight = 10
puts cat.weight # => 10

In conclusion, attr_reader and attr_writer can replace a bunch of getter and setter methods in just a single line! 😻

Questions to Ask Your Engineering Team

Jennifer Tran — Fri, 10 Jan 2020 03:47:10 +0000

As I reflect on my first year as a software engineer, I realize there are many questions I wish I had asked at the start of my career. I have narrowed down this infinite list into a set of ten questions I think anyone currently on or newly joining an engineering team will find useful.

1. Who looks after applications?

In this context, I am using "application" to describe a self-contained unit of functionality. As a new engineer, my main code contributions were initially to existing codebases. It wasn't until I gained more experience and started building out whole solutions from scratch that I had realized the importance of determining who was responsible for the application. This question gets to the root of responsibility: who is responsible for monitoring applications and who is responsible for handling any incident that may occur? Who is responsible for maintaining the application? Who is responsible for responding to an alert about the system being down at 2 in the morning?

2. What is the team's deployment process like?

Knowing how to deploy your code is just as important as writing code. Deploying code is the process of moving code from one environment to another. Typically, programmers write and test code in a development environment, and the code eventually makes its way to a production environment where real users actually interact with it! Firstly, knowing how to deploy your code is important so that you can actually make changes that eventually reach real users. Secondly, asking this question is important because it will clarify the actual deployment process which could range from something like running a single command to performing a manual process that is long and arduous.

3. What does the average path to production look like for a service or application?

This question is somewhat related to the previous question in the sense that it lies in the same domain, but the main difference is that it captures the steps you may need to go through before you are able to deploy your code to the production environment. For example, is there a board of people who need to approve code changes before deploying to production? The question encourages the team to consider the steps they take when they want to deploy code to production and whether those steps are clear to someone on-boarding. As a Junior Engineer, asking this question helped me to understand if there was a standard process or if the process varied depending on the application. This question will engage the team to really define the process. This is also inherently important for any developer to get clarity on because all developers hope that their code reaches user. One day, you may be responsible for managing releases for services or applications, which is sometimes not a trivial task.

4. Does the team practice continuous integration?

Continuous Integration (CI) is a practice where developers consistently merge their code into a central repository where automated builds are created and automated tests are typically run. CI is important because it helps mitigate bugs and merge conflicts early on. The idea is, when code from a separate branch is frequently integrated into a master branch, it has fewer chances of breaking what exists in the master branch. This question can be fairly straightforward with a yes or no answer.

5. How often does the team release to production?

This is a great question you could ask prior to joining an engineering team in general! You get two major pieces of information out of this question:
When will you get to see your code in the field. One of the more fulfilling aspects of writing code is knowing that it will actually be used, and seeing it in action!
How quickly does your code need to be turned around. The more infrequent the releases, the more important each release and the more important it is that your code be working by that time.

6. How closely do engineers work with business stakeholders or customers?

This is also a great question to ask prior to joining an engineering team because it will give you perspective on how you, as an engineer, will be going about your work and provide clarity on who you may collaborate with. The more closely you work with stakeholders and customers, the stronger your interpersonal skills will become which will help you in doing your job and growing your career.

7. How does work come into the team?

The question will help clarify how tasks are assigned to engineers. Does it come in the form of tickets? If so, who assigns those tickets? Can this process be negotiated? Does it vary by quarter? The more you know how work is assigned, the better you’ll be able to manage your time and ensure that work is distributed fairly.

8. How involved are engineers with deciding what to build?

This question is great to ask in interviews or on the first day of a new engineering job so that you can have an understanding of how much say you can have on the engineering solutions you build. Some people are content to fulfill the specifications of other people. Some love to take a more involved approach. Figuring out the standards of the business will help you decide if their expectations match your preferences.

9. How do you spin up a new service?

This question will really encourage the engineering team to distill their practices into a coherent and easy-to-follow process which is good for the on-boarding engineer and the team in general!

10. How are architectural decisions made?

Is there a formal process? Is it open-ended? This will help you understand the standards and process of designing new solutions in your new team.

Summary

In summary, these are ten questions I wish I knew to ask before I started my first software engineering job. I also believe each team should be able to answer these questions definitively and could even provide them to new engineers who are on-boarding!

Who looks after applications?
What is the team's deployment process like?
What does the path to production look like for a service or application?
Does the team practice continuous integration?
How often does the team release to production?
How closely do engineers work with business stakeholders or customers?
How does work come into the team?
How involved are engineers with deciding what to build?
How do you spin up a new service?
How are architectural decisions made?

What are some other questions you would ask your team? 🙂

Forem: Jennifer Tran

Reprogram Your Mindset

Letting go of harmful assumptions

Reframing my relationship to failure

Embracing my emotions

Talk Less, Listen More

Things to avoid

Rehearsing

Filtering

Problem Solving

Be Openly Confused

Three Ways to Prepare Your Pull Request for a Great Review

Three Ways to Prepare Your Pull Request for a Great Review

1. Review your own PR first

2. Add a description of what you prioritize in the review

3. Explain the changes made

Demystifying Development Environments

🖌️ Dev Env

🎨 Staging Env

🖼️ Prod Env

Ruby's attr_reader and attr_writer

What is a getter and setter method?

There is a better alternative: attr_reader and attr_writer!

Questions to Ask Your Engineering Team

1. Who looks after applications?

2. What is the team's deployment process like?

3. What does the average path to production look like for a service or application?

4. Does the team practice continuous integration?

5. How often does the team release to production?

6. How closely do engineers work with business stakeholders or customers?

7. How does work come into the team?

8. How involved are engineers with deciding what to build?

9. How do you spin up a new service?

10. How are architectural decisions made?

Summary

Cover Image by Jennifer Tran