Forem: Pauline

Creating high-quality pull requests: tips and tricks

Pauline — Mon, 29 Jul 2024 07:47:51 +0000

In the busy world of software development, pull requests (PRs) are a vital part of collaborative coding. They help us review each other's work, share knowledge, and keep our projects running smoothly. However, creating a great PR takes some skill and know-how.

Following simple guidelines from this post, you'll learn how to elevate your PRs and make them clearer, more concise, and more reviewer-friendly. Whether you're a seasoned developer or just starting out, getting good at pull requests can boost your workflow and improve collaboration within your team.

Let’s explore how you can optimize your pull requests to ensure faster and more thorough reviews! 👇

1. Level up your PR description

After you’ve given your PR a title that succinctly summarizes the changes, let’s focus on the PR description.

Describe the context: Explain the problem and the task you're solving. What is the motivation behind your changes? This will make the possible context switch easier for reviewers and allow them to understand your changes quickly. Accurately describe the scope of PR—what does your PR cover, and what will be done in a follow-up task? This helps set expectations and avoids confusion.
- Tip: Using bullet points can be helpful here to help the reviewer parse the information more effectively.
- Tip: If writing is not your forte, consider using tools like Grammarly to help you (not sponsored)!
Include relevant links: Add links to related resources, such as design documents, Jira tickets, feature management tools, Slack threads, etc. Painting a complete picture can help reviewers in conducting a more valuable review. It also saves your team time because they won’t have to dig up related resources; sharing them in your PR ensures that the reviewer starts on the same page as the author.
Include steps describing how to test your changes: What are the prerequisites to reproducing a flow, or how can the reviewer reproduce a bug? Outline the steps required to validate your changes. Make sure to cover edge cases, too! This ensures that reviewers can verify your work efficiently.
Add visuals: If applicable, add visuals of the before and after situation. Provide screenshots or screen recordings so reviewers can see what to look for. Visual aids can help reviewers understand the impact of your changes more clearly.
Consider future reference: A detailed PR description is invaluable if you or someone else needs to revisit the code later. It provides context for why specific changes were made, which is especially helpful when debugging or tracing code.

Implementing a PR template can help maintain a consistent standard across your team, ensuring all necessary information is included. Finding and creating the right template might require a few iterations, but can serve your team well in the long run.

Having a solid description already boosts the quality of your PR significantly, but keep reading on if you want to learn more!

2. Atomic commits and meaningful commit messages

Clarity in your PR begins even before its creation, starting with how you commit your code.

Atomic commits + meaningful commit messages: Make sure each commit is atomic, representing a single logical change. This makes your commits easier to understand and review. Pair this with meaningful commit messages that clearly describe what each commit does.
Limit the number of files changed: Try to minimize the number of files altered in a single PR. Reviewing hundreds of code changes across many files can be overwhelming and can lower the quality of the review. Smaller, focused commits make the review process less daunting and more manageable.
Review per commit: For larger PRs, consider advising your peers to review the changes commit by commit. This naturally breaks down the review process into smaller, more digestible chunks, making it easier to follow the changes and provide detailed feedback. Atomic commits and meaningful messages help reviewers understand your changes and maintain a cleaner project history.

3. Self-review and annotate your PR

Consider doing these as a final touch before sharing your PR with the wider team for a smooth handover.

Annotate your PR: You can do this by leaving PR comments on your code changes. Add comments to your code changes to explain your decisions and thought process. This provides valuable context, helping others understand your reasoning and intentions and facilitating more meaningful feedback.
Self-review: This is similar to chefs tasting their food before serving. Prior to asking others for a review, take the time to review your PR. Check for clarity and completeness. You might find unnecessary code or realize the PR is too large. Evaluate your PR as if you were the reviewer, ensuring it is well-organized and easy to understand.

Hopefully, this was helpful! What are some of your methods for making reviewing easier for your team?

3 affirmations for the next 365 days: on improving myself as a developer

Pauline — Sat, 16 Jan 2021 14:16:19 +0000

On this day exactly one year ago, I published a piece in which I talked about 6 habits that I wanted to create in order to level up as a developer (you can read it here).

I re-visited it a few days ago and found this little retrospective very valuable and enjoyable, which gives me more than enough reason to write an updated piece for the coming year. This time I am changing it up a little bit by turning it into a shorter list of ✨affirmations✨ that I hope to manifest (because truthfully, calling it "2021 goals" makes it sound like a checklist and gives me too much pressure).

I'm again sharing this publicly mostly for accountability reasons, but hopefully this will also inspire you to think about some things you want to work on during the next few months!

1. I am getting better at creative problem-solving

Whenever I build features, I have the tendency to solely focus on making things work and getting features shipped at a steady pace. While this is not necessarily a bad thing in itself, I often find myself criticising my own code for not being "elegant" or "sophisticated" enough—the implementations I come up with are oftentimes rather basic and in my opinion are nowhere as clever as some of the implementations built by my peers. Although my code also gets the job done, moving forward, I'd like to pay more attention to how others structure their logic and to the feedback I get in PRs in order to improve my problem-solving skills.

On top of this, I would also like to improve the quality of the code reviews I conduct. While I tend to test and review PRs of others quite thoroughly, the feedback I give has often been limited to nitpicks. I believe that deepening the understanding of the stack I use daily will also play a valuable role in levelling up my creative problem-solving skills (which I hope to achieve by doing more of the next item on this list)!

2. I build side projects to boost my learning and development

You don't need to code 14 hours a day and have 50 side projects that are all hosted on dedicated domains to call yourself a developer. I do think, however, that working on small projects every once in a while is a great way to learn new skills. Last year, my side project completion rate was a whopping 66.7%! My secret to success, you ask? Well... (whispers) I only finished 2 out of 3 tiny projects I started. Yes, you read that right. I can count the number of projects I started on one hand. I also started 2 different courses and out of those, finished a grand total of 0.

Because of these not-so-impressive key results, I will be recycling this item from last year's list and hopefully start more projects (and finish those courses 😅) while still saving time for other hobbies, too.

3. I am an active voice of new/junior developers

Even though my employer dropped the junior term from my job title (hooray!) at the beginning of the year, I still find it extremely important that every single engineering culture is one that's comfortable for all engineers regardless of their experience level, and one in which everyone gets heard (especially in spaces where senior engineers vastly outnumber junior engineers).

This requires (but is not limited to) documenting clearly where needed, communicating with each other in an inclusive way, leading by example, and creating a psychologically safe space for everyone. Having this type of environment will not only empower junior engineers, but can also be very helpful for engineers who are new to your codebase.

This means we're going to have to fight a few misconceptions here. I want to continue spreading the message that accommodating to new developers does not mean you are going to slow down the pace at which you ship, or that you're going to lower your code quality standards. It means being empathetic, inclusive, and contributing to the growth of others (because every senior engineer was once a junior engineer, too).

If you have made it this far, thank you for reading. 💚 I'd love to hear from you: what are some affirmations you're setting for yourself?

6 new habits I’m building to level up as a junior developer

Pauline — Thu, 16 Jan 2020 18:50:51 +0000

By the end of this month, I will have exactly 1 year of professional experience as a software engineer. As my skills improve, the expectations (set by myself as well as by those around me) are increasing too. Based on this as well as continuous self-reflection and introspection, I have identified a few things I want to change about myself and my working style in order to level up as a developer.

The purpose of this article is to inspire you to think about your own room for improvement, or perhaps you can relate to several of my bad habits and have some additional ideas on how to adjust them. Oh, and I guess it’s partially to hold myself accountable as well. 😉

Let's start!

I will ask for help faster.

I'm going to kick off with one of the habits that I want to develop most: spend less time stuck on problems, no matter how big or small it is. Within the past 12 months of writing production code, there have definitely been a few days where I have honestly wasted more time than I would like to admit.

I suppose the good thing is that I can be extremely persistent whenever I am stuck on a specific problem. I know with 100% certainty that I can solve the problem at hand (eventually, ha!). The downside, however, is that it can of course come at the cost of efficiency. I will try to be more result-driven rather than repeatedly trying to prove to myself that I can handle something individually. I was once told to never spend more than 1 hour stuck on something, and sometimes the faster and more efficient way to learn something is to simply ask someone.

I will think first, build second.

Ironically enough I wrote about this in one of the articles of my junior developer survival guide series, but catch myself not doing this often enough at all. Especially as a front end developer, I love seeing my changes come to life on my screen. I love to immediately dive straight into the codebase and get my hands dirty. Unfortunately, every once in a while this happens without really thinking about what has to be done and where changes have to be made, and in which order, etc., leading me to have to undo or revise my changes again. From this point onwards, I would like to slow down where needed and view the problem at hand from a bigger perspective.

I will use code reviews and pull requests as a learning environment.

I am incredibly grateful to be surrounded by talented and skilled engineers. Engineers who sometimes work on rather advanced features, which I am then being asked to review. Yikes.

To be honest with you, I used to stay away from reviewing these PRs because I was having thoughts such as “this implementation is quite complex, I highly doubt my knowledge is sufficient to review this properly” or "someone else will leave more helpful feedback". However, from now on I will no longer let some PRs by peers intimidate me and instead I'll focus on reviewing the parts that I am comfortable with. Then, I am going to ask as many questions as I can about the parts I feel less comfortable with, and will challenge my colleagues to verbalize their thoughts and logic.

On top of that, I am going to pay more attention to the feedback I see in the PRs of my colleagues (which is left by others). It’s not uncommon for there to be a lot of knowledge sharing and if I don’t understand the comment, I will simply ask. :-)

I will not be afraid to tackle something new.

While going through the tickets in the current sprint that still have to be picked up, I noticed that I tend to gravitate towards simple or small tasks that I know I can solve quickly and without difficulty. I believe a contributing factor to this may be the fact that when I first started writing code during my internship, my tickets would often be the only ones still in progress (or waiting for acceptance) on the last day of the sprint and I would feel seriously guilty about this.

I’d love to start embracing new challenges without being afraid of the unknowns, and to pick up work that’s in my stretch zone rather than my comfort zone. The less you know, the more you can learn, right?

I will build more side projects.

Confession time! Unlike many other engineers, I hardly have a side project graveyard (spoiler: it's not because I finish 99% of my projects). I always had the urge, this inner requirement, to build side projects that are useful, beautifully designed, and could add value to my life. I was severely criticizing every single project idea I came up with, and guess what? Most of the time I ended up building nothing at all.

In the coming months, I am going to simply build projects solely for my own eyes to see and to place focus on my own learning and development rather than trying to put the next big thing out into the world.

I will no longer copy and paste mindlessly.

Copying and pasting is something that greatly simplifies our lives as engineers and it's probably also our most used keyboard shortcut. Truth be told, I may or may not use this handy-dandy shortcut more than I should. Being extremely focused on the implementation of a ticket (once again, gotta move that ticket from the ‘to do’ to the ‘done’ column), I used to often copy and paste code without truly understanding what was going on. Even though my feature would work perfectly fine, I never really knew exactly why (yikes, way to feed my own imposter syndrome 😅).

Moving forward, I will take my sweet time to be more cautious of what and why I am re-using certain pieces of code.

That's all for today! If you’ve made it this far, thank you so much for reading! 🙌🏻 Now I'm curious to hear from you — what is a new (developer) habit you would like to create?

🌙 Navigating the codebase | The ultimate junior web developer survival guide

Pauline — Fri, 15 Nov 2019 18:21:28 +0000

The junior developer survival guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

This guide will touch upon topics that they don’t teach you in tutorials; I will be talking about non-technical matters that you learn on the job. The articles will be relatively short and concise so you spend less time reading and more time executing. 🙌🏻

Whew, you’ve successfully made it to part 5 of this series! Today I’ll be shedding light on some things that I truly wanted (or needed) to hear when I first started writing code professionally, and it’s something that I was worried about the most as a newbie: navigating a company’s existing codebase. It can take a while before you familiarise yourself with a codebase and I’ll be sharing some tips below on how to feel more comfortable going about it as a junior dev. 👇🏻

1. Practice reading code

When you’re learning how to code and following some tutorials here and there, the focus is often placed on writing code. What I personally didn’t realise at that time is that in reality, you will be spending far more time reading code than actually writing it.

Once you are given access to a codebase and start working on tasks, take some time every once in a while to step back and not think about writing code. Now I’m not saying that you should spend hours simply sitting and reading hundreds of lines of code in an attempt to understand it. Instead, whenever you will be touching certain parts of the codebase, don’t be afraid to look into the code that (in)directly surrounds the feature you’re trying to build. If something doesn’t make sense after a glance or two and a developer has not left any helpful comments, feel free to poke a colleague and ask them about the purpose of the code. Although this may not directly contribute to the feature you’re trying to build, it can be helpful to identify and understand similar code patterns next time you take a digital stroll around the codebase.

2. Don’t be afraid to modify existing code

To be honest with you, I used to feel very reluctant about making a lot of changes to the codebase. I felt like everything was already there for a reason, it was working properly on production, and I tried to change as little as possible whenever I was busy building new features. I always tried to add as few lines of code as possible. After almost a year of working with my company’s codebase, I sort of got the hang of both deleting code, refactoring code and also adding a lot of code.

The approach I like to take is to focus on getting your code to work first and to not worry about how much you may be polluting the codebase or how messy your implementation is. Some developers may disagree with this approach, but I found that it works for me to first aim to get the functionality down and then take some time later to finetune and tidy up the code.

3. Use code reviews as your learning playground

This is my favorite tip of the week. Pull requests and code reviews are the ultimate place to learn, to expand your knowledge, and to have fruitful discussions about code. When used properly, there can be far more to it than simply sharing your code changes and hoping that your colleagues and peers will approve your pull request.

For starters, try to review your own pull requests. Recap the flow and the changes you made, and ask yourself if all of this makes sense. Can you justify your changes, or explain why you made certain decisions? Are there more suitable approaches you can take to build a feature or fix a bug? Are there other ways to refactor code that will make it more maintainable in the long run?

Bear in mind the playground is not confined to just the pull requests that you yourself create. There is just as much to learn in the pull requests that are being created by your colleagues. Challenge them, ask questions. If you’re reading their code changes and you’re not entirely sure what’s happening, this may be a sign that perhaps the logic is not as clean and structured as it could be. Just because you’re a junior developer, does not mean that you can’t have any valuable input on changes made by senior developers! Be bold and seek explanations. Observe the different ways of problem solving and learn from them.

Another great way to learn from the pull requests of others is by first asking yourself how you would solve the task at hand prior to reviewing your colleague’s PR. There’s no need to think of all the exact details here, but try to grasp the bigger picture. Ask yourself what changes are necessary—you can jot them down or form some clear ideas in your mind. Then, start reviewing the pull request and check what things you missed or which alternative problem-solving methods there are. It may sound like a tedious process but you can definitely learn a lot while you’re at it!

✨ Support systems | The ultimate junior web developer survival guide

Pauline — Fri, 08 Nov 2019 09:29:25 +0000

The junior developer survival guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

This guide will touch upon topics that they don’t teach you in tutorials; I will be talking about non-technical matters that you learn on the job. The articles will be relatively short and concise so you spend less time reading and more time executing. 🙌🏻

Welcome to the ultimate junior web developer survival guide, we’ve made it to part 4! The theme of this week is working relationships and support systems. Because even if you complete all tutorials on the web at beginner, intermediate and advanced levels with the most incredible discipline, motivation, and ambition, becoming a skilled developer ultimately also involves the people around us who bring out the best in us all.

1. Never skip a 1 on 1 meeting with your manager

Prior to starting my very first software engineering internship, I reached out to the community and asked for advice. I received helpful replies that included asking a lot of questions and getting to know the people, to be visible, and so on. It was a single piece of advice given to me by a friend who already had a few internships under his belt that stood out the most because I had never heard it before: “never skip a 1 on 1 meeting with your manager”.

At the time, I wasn’t sure why this would be someone's key piece of advice. Or why I had to do it, why was it so incredibly important? But I decided not to question it any further and just followed up with it. Oftentimes when I checked my calendar and saw that I had a 1 on 1 meeting coming up with my manager, I used to think “Oh, but everything is going perfectly fine on my end. I don’t have anything to say, so there might not be a need to have this meeting”. However, by never skipping a meeting, I’ve learned that there is always something to talk about. It never hurts to double check whether your sense of accomplishment is shared with your manager or not. And just because you feel like everything is going well, it doesn’t mean that you can’t improve even more. This brings me to my next point..

2. Continuously ask for feedback and constructive criticism

Acknowledge that there is always room to grow and improve yourself. Feedback opportunities do not present themselves all that often and if they do, they are likely to be in very formal settings. Don’t wait for other people to give you feedback, and instead proactively seek it. Approach colleagues that you work with a lot, but also those that you do not share many interactions with.

Make sure you’re ready for honesty. Remember that you’re seeking feedback and constructive criticism, not praise. Some questions you could ask others as guidelines are:

What is something you really appreciate about me? (continue doing)
What would you encourage me to do differently? (stop doing)
What would you love to see me do more of (and why)?
What is something I could develop to add more value to the company or team?

3. Find your allies and build a support system

In this post about advice for developers in the early stage of their careers, Molly Struve shares: “Having a good mentor and a solid support system is going to set you up for career success.”, and I couldn’t agree more. I have found it to be very helpful and valuable to talk to as many developers as you can and start building connections with them, even if you do not work together. Show interest in what they're working on and ask questions, even if it's completely out of your skillset or job description. Be open and honest with your manager or team lead, and share your milestones but also your struggles. Keep in mind that your support system does not have to consist of developers only. Support can come in many ways — ranging from help with problem-solving or a listening ear when you’re going through a bit of a rough time — and it’s wonderful to have people by your side through both good times and bad times.

Thanks for reading! What are some of your approaches to surrounding yourself with the right people?

Do developers have higher job satisfaction than non-developers?

Pauline — Fri, 01 Nov 2019 12:10:04 +0000

I can say with full honesty that I never dread going to the office because I absolutely love what I do and I'm surrounded by amazing, kind and talented engineers. The majority of my friends and acquaintances, however, are not in tech/engineering roles and I often hear them complain about how boring their 9 to 5 jobs are. One of them even said: "But everybody hates their job, don't they?". At some point I even started wondering whether I should feel guilty for genuinely loving my job, while everybody else seems to be miserable at the office.

Is this something you recognise within your social circles? As a developer, do you get the impression that your job satisfaction is higher than that of your non-developer friends? What do you think?

I find this tweet by Kitze to be spot on and couldn't have said it any better:
// Detect dark theme var iframe = document.getElementById('tweet-1189951090629976065-429'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1189951090629976065&theme=dark" }

Disclaimer: I'm not trying to say our jobs are better than non-developer roles. I suppose the only thing this watercooler discussion can really measure is whether my friends are more pessimistic than yours. 😅

🌟 Personal growth and learning | The ultimate junior developer survival guide

Pauline — Fri, 25 Oct 2019 12:46:43 +0000

This is part 3 of the ultimate junior web developer survival guide, a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

This guide will touch upon topics that they don’t teach you in tutorials; I will be talking about non-technical matters that you learn on the job. The articles will be relatively short and concise so you spend less time reading and more time executing. 🙌🏻

1. Make a lot of mistakes

As junior developers, the pressure (either from ourselves or from others) to perform a task well can be quite high. However, keep in mind you don’t always need to aim for perfection. Perfection can be time-consuming. In order to truly learn the craft, you are going to have to make a lot of mistakes. And the faster you make them, the better. At times it means asking for help sooner than you’d like. At times it’s better to make the code work first, and to not think about it being all clean and perfect yet.

Making mistakes is something that all developers at all levels do -- even the most experienced developers and engineers. While I know the imposter syndrome can really kick in here, don’t worry about judgement from your colleagues and don’t view mistakes as failures. It’s a beautiful mix of trial and error and it’s by far the fastest way to learn!

2. Recap everything you learn in your own words

Everytime you learn something new or pick up a new concept, summarize your learnings in your own words. Similarly, if you receive help on a tricky problem from a colleague, recap why your code was initially not working and repeat the solution to your colleague to confirm your understanding. Grasping new knowledge in your own words will also help you retain it better!

One example of how I like to apply this is when a team member creates a PR and I don’t really know what’s going on, I ask them to pair review it together and to get an explanation of what changes we’re making. Throughout the explanation or at the end, I then summarize and recap what I was told to really make sure I understand things correctly. There is no need to always break down every single implementation detail; sometimes it's helpful to simply be able to see the bigger picture.

3. Attend local meetups (and conferences)

Surrounding yourself with like-minded individuals and meeting fellow developers is a great energizer (especially if not many of your friends and acquaintances are developers!). It’s a wonderful opportunity to meet people with all kinds of experience levels, fellow junior developers and senior developers who can help you out alike (or who could receive help from you!). Even if the meetup themes or topics do not match your skill set, show up anyway because these new topics can still turn out to be very interesting (and may even lead to some new side projects).

Not every city has an abundance of meetups, so take advantage of it if your city offers this luxury. Nervous to go or are you an introvert? Missing a +1? Don’t worry, as there are tons of people attending these events solo without knowing anyone else. In fact, I realised that I end up meeting the most people when I go alone instead of with a friend or colleague!

As for conferences, keep in mind that tickets can be rather expensive, so I recommend checking with your employer if there is perhaps any conference budget available for you to use so you can expand your knowledge!

Thanks for reading and make sure to also check out the other parts if you haven't done so already. 😉 Happy coding!

💫 Writing code | The ultimate junior developer survival guide

Pauline — Fri, 18 Oct 2019 11:18:52 +0000

Welcome to the ultimate junior web developer survival guide, part 2! 🎉

If you're new here: this guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

1. Think first, build second

This is something I still struggle with a lot. Being a front end engineer, whenever I pick up a new ticket, I have the tendency to start writing code as soon as possible. I want to see changes on the screen as fast as I can. ‍
More often than not, this completely unnecessary rush leads me to get stuck easily and also having to rewrite a lot of my code. By not thinking about the desired solution first, I don’t have a full and clear overview of the existing code that is going to get affected by my changes. I’m not aware of which pieces of code I can reuse, or how to split up tasks into different, smaller chunks.

Instead of taking the above approach, go through the steps that you have to take in order to build your new feature (similar to writing pseudocode prior to solving an algorithm). Digging through the codebase and found the files that you will most likely be making changes to? Leave a comment for yourself outlining what needs to be done and in which order, and don’t write any code yet until you actually have a clear idea of the exact steps you need to take.

It very much pays off to first evaluate what has to be done first. In which order should you approach this problem? Do you have all the knowledge required in order to solve the problem at hand? Can this task or feature be split up into multiple different PRs? Having a plan then also makes it easier to discuss your approach with a colleague, and they might be able to share some helpful pointers to improve your plan. Refraining from immediately jumping onto your keyboard will save yourself a lot of time fixing the code that you wrote when you didn’t have all the necessary information.

2. “Kill your babies”

I once attended a masterclass where an industry expert shared his advice on becoming a better developer. One of his lessons was to “kill your babies”. Uhm, excuse me, what?! He then proceeded to explain that as a developer, you will often be deleting or rewriting the code you wrote (and are likely extremely proud of) and that you therefore shouldn’t get too attached to it.

This tweet by Kyle describes it beautifully:
// Detect dark theme var iframe = document.getElementById('tweet-1179501014849703936-153'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1179501014849703936&theme=dark" }

There may be situations where you are able to hold on to your code by only slightly modifying it, but there will also be tons of cases where you are simply going to have to let go of it. No matter how much time you previously spent on it or how proud you are of it. Some code isn’t meant to stick around and that’s okay (and even though the label to this piece of advice may be a little provocative 👶🏻, it’s certainly powerful enough to make sure you never forget it).

3. Learn to step away from the problem

In those moments when you get stuck on a given problem, force yourself to step away from your computer for a brief moment. You may tell yourself something like “but I am this close to finding a solution, I am almost there! I can feel it, if I step away from it now then I will lose my train of thought and it will take some time before I can get back into my flow again.”

These are actually all the things I used to tell myself whenever I was dealing with a tough problem. The thing is that taking a break and revisiting your code with a clear mind and perspective is far more beneficial than staying in a rut. We cannot force our brains to work harder or to dig deeper. Sometimes it helps to start over again and to reevaluate what you already know and what you’re missing. Oftentimes the solution comes to you when you least expect it, along with an “I can’t believe it took me this long to arrive at this solution”-moment!

As always thanks for reading and happy coding!

If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it! 🙏

⭐️ The basics | The ultimate junior developer survival guide

Pauline — Fri, 11 Oct 2019 10:53:50 +0000

Welcome to the ultimate junior web developer survival guide! This guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnings, lessons, answers to questions my past self had, mistakes I made (so that you don’t have to make them), and much more in an attempt to simplify and improve your life as a junior developer as much as I can.

This guide will touch upon topics that they don’t teach you in tutorials; I will be talking about non-technical matters that you learn on the job. The articles will be relatively short and concise so you spend less time reading and more time executing. 🙌🏻

Ready? Let's go!

1. Learn how to ask questions

Asking for help can be hard. And once you succeed reaching out, asking the right questions is even harder. It’s key to prepare your questions and sketch the situation as clearly as possible to outsiders.

For example: What is the context you’re working from? What are you trying to achieve? What solutions did you try and what was the outcome of it? On top of that, be specific with your questions. Rather than bluntly asking your colleague or peer “Why does this code not work?”, try something like “I’m trying to render the data from my API call here and have tried out solutions X and Y. I suspect the problem lies in this part of the code, could you explain why this approach does not solve problem Z here?”.

Gordon Zhu has written an excellent piece on asking great questions in which he shares a thorough outline of steps to take to get better at requesting and receiving help. I found this article very helpful and I encourage you to check it out too.

2. Take notes

As developers, we are learning new things every single day. With so much new information non-stop coming our way, we shouldn’t always be relying on our memory to retain all of it. Do your future self a huge favor and take notes (even if no one else around you is doing it)!

If you work through a bug or problem where you got stuck or faced some difficulty, recap and document the solution. Our brains are solving so many problems on a daily basis and we very easily forget certain solutions, even if they made sense the first time we encountered them (I know I’m not the only one). Had to Google or StackOverflow something and feel like it may come in handy again later? Jot it down. This doesn’t have to be some official or formal documentation for others to read. It doesn’t matter if you take notes digitally or with paper and pen.

Documenting your solutions and learnings does not only serve as a future reference guide, but it’s also a great way to keep a log of things you learned along the way (and therefore indirectly tracking your progress so you can see how far you've come!). You will thank yourself later. 🎉

3. Set up knowledge-sharing sessions with more experienced developers

When I started my first internship/developer job, I found it very helpful to block time to discuss certain engineering topics and concepts with a more experienced colleague. This can be just 30-60 minutes where you sit down together to improve your own understanding of something.

You might be thinking now: “Shouldn’t I educate myself and study the topic on my own first, rather than asking my colleagues to be my tutor?”. Bear in mind that this is not a lecture where you just sit back and absorb theory. You are creating an opportunity to improve your knowledge and understanding (and let’s face it, thereby also increasing your value to the company). This then also allows you to see how certain theoretical concepts are applied in practice in the company’s codebase. On top of that, don’t forget that you’re also testing your colleague’s understanding of certain topics and helping them improve their communication skills. 😉

Select some topics you might struggle with (some topics I for example asked for help with were Git and JavaScript/React testing), dive into the topic and prepare a few questions. Which parts are unclear to you? Invite other junior colleagues if you feel like it can be helpful for them too.

This is it for part 1, stay tuned for part 2! If there are any topics you are curious to read or learn more about, leave a comment or send me a message and I will try my best to cover it!

If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it. 🙏

20 VS Code shortcuts to speed up your flow ⚡️

Pauline — Fri, 04 Oct 2019 11:54:19 +0000

In this article I want to share some of my favorite and most used VS Code shortcuts that help me save time, make my life a little easier and, as a heavy keyboard user, also allow me to stay in my developer flow.

You may be familiar with some of them already but hopefully you will discover a new shortcut that you can introduce into your workflow starting right now. 🤞🏻

I jotted down the key combinations for Mac users. If you’re a Windows or Linux user, you can find the key bindings for your OS here.

Alright then, so without needing to select the entire line first...

⌘X - cut a line
⌘C- copy a line
⇧⌘K - delete a line
⌘L - select the line

And while your cursor is on a specific line..

⌘Enter - insert a new line below it
⇧⌘Enter - insert a new line above it
⌥↑ and ⌥↓ - move the line up/down
⇧⌥↑ and ⇧⌥↓ - duplicate line on the line above/below it
⌘] and ⌘[ - indent and outdent the line
⌘/ - (un)comment out the line

Or within a specific file..

⌘D - find other instances of selected code
⌥Z - toggle word wrap

Lastly, for some editor/window management..

⌘P - find and go to file (quick open)
⌘N - new editor
⌘W - close editor
⌘B - toggle visibility of the side panel
⌃` - toggle visibility of the integrated terminal
⌘2 - split screen into two editor groups
⇧⌘T - reopen recently closed editor
⌥⌘← and ⌥⌘→ - view editor tab on the left/right

Happy coding!

If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it! 🙏

5 things to know before you start learning how to code 👨🏼‍🏫👩‍🏫

Pauline — Fri, 27 Sep 2019 18:39:38 +0000

I originally posted this article on Medium in December 2018 and thought it would be nice to share it here too. Hope you enjoy this read!

Given that you decided to read this article, I assume that you have recently made the decision (or are in the process of deciding) to expand your current skill set and learn how to code. Perhaps you’re here to find some structure or to see recommended approaches others have taken. That’s exactly what I did when I first started to learn how to code: I tried to find the most efficient way and would only try out the most popular resources in order to optimize my learning journey.

Two years down the road, I have learned a whole bunch of things that I would like to share with those who are at the beginning of their coding journey now. Things that I wish I had known before I started learning.

Now, I am not planning on telling you which websites, books and tutorials to use or which languages and frameworks to pick up first. Instead, I aim to put you in the starting block equipped with the right mindset and knowledge to make these decisions on your own and to eventually help you reach your most ambitious developer goals.

Let’s do this.

1. Find a teaching style that works for you

This is the first and most valuable tip I can share with those who decide to learn how to code on their own. It’s something that took me quite a while to realize.

If you are new to the world of code, it is tempting to follow the opinion of the masses. A quick “learning how to code” Google search brings up more than 2.5 billion results! It is safe to say that coding is gaining popularity and there are tons of platforms and resources, but also millions of opinions on how to start learning. Before you commit to a certain platform that you select based on popularity, first ask yourself the following question: What is the most effective way for me to learn new concepts?

Are you someone who likes to dive into the theory first before getting your hands dirty and therefore might enjoy books as a learning medium? Or do you prefer video tutorials where someone shows you how something is done while talking you through it? Perhaps you are someone who likes to learn by doing: familiarize yourself with a topic by reading just a couple of sentences of theory, studying an example, and then immediately applying your brand new knowledge to an exercise.

If you’re not sure about your preferences, feel free to experiment with this and try out different kinds of styles. Are you not enjoying or learning anything from a course that seems to be loved by everyone else? Don’t criticize or doubt your competence, or get stuck on a resource that you dislike. Don’t stick with it too long just because others praise this specific resource or platform. Learning a new topic on your own offers you the luxury that you can fully personalize and customize your journey — use this to your advantage and find something that works for you!

2. Don’t be afraid to drop (popular) resources

If you’re like me and don’t like to leave things unfinished, this can be a hard thing to do. I lost count of how many resources I tried just because they were heavily recommended. As a result, I ended up wasting a lot of time listening to poor explanations and skimming tutorials far above my skill level. Not to mention that some tutorials or instructors, in my opinion, were downright boring.

To share some examples with you, I have attempted to read the heavily-recommended ‘Eloquent JavaScript’ book at least 5 times. When you’re reading this, I have successfully finished the book (assigned reading by my bootcamp) but still fail to see why it’s so hyped. When I first started learning how to code, I also avoided Codecademy because I felt like it was taking me by the hand too much and just telling me what code to write. It wasn’t teaching me how to solve the problems on my own. That being said, these two examples are still loved by a lot of people and might work perfectly fine for you.

Don’t make the same mistake I did. Drop a resource (or save it for later) if you feel it’s just introducing more questions rather than answering them. Don’t get caught up thinking “maybe it will get better towards the end”, thereby prolonging your suffering. There are always plenty of alternatives!

3. You don’t need that fancy set-up

This is one you may have heard many times before, but it’s worth mentioning again. If you have a laptop, a working internet connection, and an editor, then you’re good to go.

If you’re at the beginning of your coding journey, there is no need to invest in the latest, newest, most powerful tools as these will not make you grasp concepts any faster. I often get asked whether people should get a Macbook or a Windows laptop to learn how to code. My answer is: it doesn’t matter. Use what you have and what you prefer. An expensive camera will not necessarily help an amateur photographer take better pictures. Similarly, a programmer’s knowledge and skill is far more important than the laptop or computer he or she is using. See if coding is really for you and focus on expanding your knowledge first — the rest will come in due time.

4. Apply your growth mindset and know your motivation

Programming is not always easy. Apply a growth mindset (“I can’t do this” vs. “I can’t do this yet”) and find the real reason(s) you want to learn how to code. What is it that you enjoy about it the most? What would you like to use your new skills for? Having your motivation clear will not only make learning more fun, but it will also make you more resilient in times when you’re frustrated because your code is not working the way you want it to.

I have studied alongside people who only choose web development because there is high demand for it in the labor market. Similarly, I know people who are in it just for the money as such jobs pay well in their country. It’s fine if these things drive you — but from my experience, these specific people aren’t as driven as those who pursue web development with passion and a purpose. They won’t feel the extra motivation to really understand a concept 100% or to figure out why something isn’t working.

Learn to persist through hard times. Know when to take a break, and when to push yourself just a little further. Don’t be afraid to reach out for help, but don’t forget to try things on your own first.

5. Give yourself some credit

Never compare yourself to other learners as everyone has their own timeline and techniques when it comes to learning how to code. Keep looking forward focused on your goals, but don’t forget to stand still sometimes and see how far you have already come. This may sound straightforward and obvious, but your progress may not be immediately visible as learning how to code by yourself can take quite some time. Don’t be too harsh on yourself and enjoy the ride!

If you’re a self-taught developer, what are some things you wish you knew before you started? What are some of the greatest lessons you learned?

5 ways to create a junior developer-friendly culture 🚀

Pauline — Fri, 20 Sep 2019 20:00:01 +0000

Let’s face it - being a junior developer is anything but easy. Imposter syndrome kicks in multiple times a day, asking questions can be absolutely terrifying, and the more you learn, the more you realize how little you actually know. As junior developers, we are often extremely hard on ourselves. We often question our own capabilities, force ourselves to come up with the solution to a problem on our own, and continuously feel the need to prove ourselves.

One of the ways we can make it a little easier, though, is to place ourselves in the right environment and to surround ourselves with the right people. Below, I have compiled 5 things to look for if you are aiming to join a supportive engineering culture that will contribute to your learning and growth.

These 5 pointers are not only relevant for junior developers who are perhaps looking for their first (or next) employer, but also, for example, for senior developers who get the opportunity to work with junior developers or for tech leads trying to make improvements to their engineering culture.

Without further ado, let’s jump right in.

1. Empathy and respect

Empathy is an incredibly helpful factors in ensuring that junior developers are given the space to grow.

It is something that can be observed and expressed in multiple different ways. Some simple examples are:

Avoid derogatory speech.
Don't assume that the person you're talking to has the exact same knowledge as you. Don't assume they know absolutely nothing, either.
Take your time to answer questions without any shortcuts.
Make eyecontact. I lost count of the amount of times colleagues only look at other senior developers when talking, as if I wasn't even in the room.

And honestly, if you really do have 30 years of experience writing code and you don’t feel like dealing with junior developers, then respectfully stay in your own lane and don’t get in their way. Don’t go around trying to complicate other people’s lives, or even worse, start bullying them. That, too, is a way of showing respect and allowing others to grow.

It’s very easy to forget that everyone started off as a junior once.

2. Use “we” instead of “you”

This point more or less builds on the previous points. Being part of a team that takes full responsibility and ownership of what they work on is incredible to see. This means all working towards the same goal and trying to keep a clean codebase, rather than criticizing each other’s work.

This point can be observed very easily in code reviews. When you see room for improvement, rather than commenting “why did you write it like this?”, an alternative approach is asking “maybe we can try a different approach in this case because it would be better for this or that reason”.

To illustrate this mentality of "we" instead of "you", I'll share a short story about a situation I found myself in at work. I once shipped code that consisted of a lot of small changes in many places throughout the codebase. A couple of days after that, one of the developers realised that something was broken on production. I quickly apologized for breaking features on production. Then, another colleague turned to me and calmly said: “No, you didn’t break it. We all broke it”. In fact, no one managed to spot the mistake before we shipped the changes. While making the actual mistake itself was rather unpleasant, it's comforting knowing that your colleagues are never waiting for the moment they can blame you for something.

Try to to join and build a culture of breaking and building together and to not engage in any finger-pointing at other developers. Knowing that your colleagues won’t judge you for making mistakes creates psychological safety and is a huge growth accelerator.

3. Pair programming and debugging

For junior developers, pair programming with multiple different developers is highly valuable to improve your communication skills and to get exposure to various ways of working and problem-solving approaches. In turn, it may also help develop your own preferences and “style” of writing code, rather than copying a single person’s way of working and opinions.

Admittedly, pair programming is something that takes a lot of time and patience. It’s very easy to say “it will get done faster if I just work on this feature by myself”. The same can be said when reaching out for help with debugging: it’s much faster to just hand your colleague the solution, rather than walking through what’s happening step by step. Nonetheless, it’s far more valuable to teach someone certain ways of thinking.

4. Find your stretch zone

Tara Ojo has done a wonderful talk on working from your stretch zone. She explains how every developer has three zones they can find themselves in:

Firstly, there is the comfort zone. As the name suggests, work that falls within your comfort zone is not challenging. It’s too easy and as a developer, regardless of your experience level, you don’t learn anything new by staying in your comfort zone.
Secondly, there is the panic zone. This is the extreme opposite of the comfort zone, where the task at hand is far too difficult, leaving the developer responsible for it feeling extremely frustrated, possibly intimidated, and essentially just extremely lost and not knowing where to even begin. In this zone, too, the developer ends up getting overwhelmed and therefore also does not learn anything.
Thirdly and lastly, right in between the comfort zone and panic zone, there is the stretch zone. This is the perfect sweet spot where the developer is sufficiently challenged, has the right knowledge to get started, and is capable of learning new things with just a bit of guidance from peers and colleagues.

Finding one’s stretch zone requires some experimentation, especially when working with junior developers. One way to discover what’s right for the junior developer is to start with tasks such as small bugs or technical debt, allowing the junior developer to work in limited parts of the codebase (so they don’t get overwhelmed). If these kind of tasks seem to be going well, feel free to go ahead and continue with building small features. Identify the knowledge gaps and slowly increase the size of the tasks to help the junior developer deal with challenges without feeling awfully uncomfortable.

5. Say “I don’t know”

This may sound silly to some people, but in my opinion this point carries just as much importance as the previous ones. Hearing other developers say “I don’t know” is absolute music to my ears. As a junior developer, hearing others say “I don’t know” is extremely reassuring and erases the common misconception that experience developers know the answer to every question, and have a solution in the back of their mind for every type of problem. Admitting you don’t know something is nothing to be embarrassed of -- instead, it’s a new learning opportunity for everyone involved! It may even lead to another occasion to pair programming or debug a problem together (see point #3 😉).

Similarly, if you're a junior developer, don't be afraid to admit not being familiar with something. You're a junior, you're allowed to ask questions, and this also gives others the chance to test their own understanding by explaining something to you!

I hope this was helpful! I'd love to hear from you next: what are some things you value as a junior developer? And if you're a senior, what are some examples of how you work with junior developers and contributing to their growth and development?

If you enjoyed reading this post or if it was helpful to you, you can support me by buying me a coffee — I'd really appreciate it! 🙏