1. Let people choose what they want to work on π
When you are working on a team, it is easy to just assign tasks to other teammates and move on. But next time, instead of assigning, just ask! At the beginning of each day my Labs team would get into a video call and talk about what goal(s) we had for ourselves, then we would put these goals on our Trello board and get to work. I love how our Project Lead asked instead of assigned, this allowed us to pick our own path and do what we felt comfortable with. Everyone has different strengths, and helping people utilize those strengths is so important!
2. How to properly create a Pull Request π»
I am still not an expert at creating Pull Requests, but I can definitely say that Labs helped me level up my PR skills. To demonstrate this, here are the before and after pictures π The first one is before Labs, where you can clearly see I have no reviewer, no description, and the title is just my name. In the second, I have lots of reviewers, a good description, and a descriptive title. I would say that I am happy with these improvements and I plan to grow and learn more about how to properly communicate with a team through Pull Requests.
3. Communication is key π
Just as I said in Step #1, everyone has their own strengths, but we also have our weaknesses. If another member on your team has conflicting ideas of how something should be implemented, it can be difficult to work through this. The best thing to do is communicate! Communicating with your team is so important, whether or not it's to discuss an issue, communication should be happening at all times. Especially when you are...
- Implementing something new
- Have a question
- Just need a second opinion
Communicating through every step of the way, will make your team stronger πͺ
4. Don't forget to leave comments in your code! π
There is a big difference between "commented out code" and "comments in your code." Leaving the correct kind of comments in your code, describing to others what you have done, can play a big part in Step #3. When a team member wants to add onto some code that you have written, you do not want them to be scratching their head and whispering to themselves, "what the heck is going on here?!" You want them to know exactly what everything is doing and why. This also lessons the amount of time a feature will take, because your teammates will not have to wait on you to explain your code before moving on. To demonstrate, here are some comments that I left in my code for my teammates (or myself in the future) π
// this adds a new goal progress
router.post('/', (req, res) => {
const gp = req.body;
GoalProgress.addGoalProgress(gp)
.then(() => {
res.status(201).json({ message: 'Goal Progress added successfully' });
})
.catch((err) => {
res
.status(500)
.json({ message: 'Sorry, could not add Goal Progress', err });
});
});
// this gets a goal progress by profile id
router.get('/profile/:profileId', (req, res) => {
const { profileId } = req.params;
GoalProgress.findGoalProgressByProfileId(profileId)
.then((goalprogress) => {
if (goalprogress.length > 0) {
res.status(200).json(goalprogress);
} else {
res
.status(404)
.json({ message: 'Sorry, could not find user with given id' });
}
})
.catch((err) => {
res.status(500).json({
error: err.message,
});
});
});
5. How to answer interview questions π€
Throughout Labs it was required that we take a small series of interviews, both behavioral and technical. We also had to answer some mock interview questions with our Project Leader every Friday. This seemed nerve wrecking at the time, but now I realize how beneficial it was. Knowing how to answer, or even how to think about your answer, can be difficult! Going into an interview can be scary, but at least now I will feel like I have done it before when I go into a real one.
Thank you for reading about 5 things that I have learned during Labs at Lambda School! Please feel free to leave a comment below about new things that you have been learning π§ I would love to hear all about them!
Top comments (0)