DEV Community: Gentt

✨ Junior Dev Life: 10 Things I Wish Someone Told Me

Gentt — Fri, 10 Jan 2025 17:33:58 +0000

Starting a career in tech can be both exciting and overwhelming. As a junior developer, you're not just learning to write code; you're learning how to navigate a collaborative, fast-paced environment. Here are 10 friendly reminders to help you grow and shine in your journey:

1. Balance Your Ego: Embrace the Sponge Approach
It’s easy to feel like you need to prove yourself, but remember that your coworkers are your allies, not competitors. Be a sponge—absorb their knowledge, learn from their experiences, and acknowledge that collaboration beats competition every time.

2. Respect Others’ Time
When someone takes the time to explain something to you, ask thoughtful questions, show gratitude, and aim to fully understand the concept. Avoid repeatedly bringing up the same issue—this shows you respect their time and are committed to learning.

3. Don’t Take Pull Requests Personally
Code reviews are about improving the product and your skills, not about criticism. A well-done PR review is a gift—it's a chance to level up. Leave your ego aside and embrace the feedback.

4. Try Before You Ask
It’s okay to ask for help, but make an effort to solve problems yourself first. When you consistently try, you show initiative and a willingness to learn. Avoid becoming the person who asks questions without attempting a solution—it can be frustrating for others.

5. Speak Up in Meetings
Even as a junior developer, your opinions and insights matter. Don’t hesitate to share your thoughts—you might offer a fresh perspective. Communication is a two-way street, and your input can benefit the whole team.

6. Patience with the Product and Codebase
Understanding a product or codebase doesn’t happen overnight. It’s a gradual process, and that’s perfectly okay. Rushing this understanding can lead to more problems, so allow yourself the time to learn both deeply.

7. Master Communication
The way you communicate and act around your team will shape your reputation. Clear, respectful, and proactive communication can open doors, while the opposite may close them. Take the time to build strong, positive relationships.

8. Take Notes
In the early stages, jot down key points from meetings, discussions, and plans. These notes will become a handy reference until you're fully comfortable with the product and workflows.

9. Don’t Burn Out Trying to Prove Yourself
You were hired because the company sees potential in you. There’s no need to overwork to “show yourself.” Focus on learning, growing, and contributing at a sustainable pace.

10. Bugs Are Normal
Mistakes happen, even to senior developers. If you introduce a bug, don’t let it get you down. Debugging is a critical skill, and every bug is an opportunity to learn.

Just posted on my top 5 VSCode shortcuts :)) Hoping it helps people who might just get into it :))

Gentt — Sat, 04 Jan 2025 17:44:57 +0000

Top 5 VSCode Shortcuts That Save Me Tons of Time! 🚀

Gentt ・ Jan 4

#webdev #vscode #productivity #beginners

Top 5 VSCode Shortcuts That Save Me Tons of Time! 🚀

Gentt — Sat, 04 Jan 2025 17:40:36 +0000

Hey Devs! 👋

I’ve been using VSCode for a while now, and there are a few shortcuts I just can't live without. These simple key combos have saved me hours of frustration (and kept my fingers from getting too tired 😅). Here are my top 5 favorites:

1. CTRL + Left/Right Arrow

This one is a game changer for quickly navigating through words in your code. Instead of holding down the arrow key or awkwardly using the mouse, just press CTRL + Left/Right Arrow to jump word-by-word. It’s so much faster and makes scrolling through your code feel like a breeze. 🌬️

2. ALT + Up/Down Arrow

Need to move a block of code up or down without cutting/pasting it everywhere? ALT + Up/Down Arrow lets you shift lines or entire selections of code up or down with just a press of a button. This is super helpful when you’re reordering things or organizing your code. 🔄

3. CTRL + X (Cut)

Now, this one is pretty basic, but trust me, it’s one of those shortcuts I constantly use. CTRL + X is my go-to when I need to cut a piece of code and move it around. I don’t just use it for deletions — I cut and paste code around, re-organize my functions, or even move sections of code between files. 💻✂️

4. CTRL + P

When I need to quickly search for a file, CTRL + P is my best friend. It brings up the quick file search, letting me type part of the file name and jump straight to it in seconds. If you’re working on a project with lots of files, this shortcut is a massive time-saver. 🏃‍♂️💨

5. CTRL + G

Jumping to a specific line number is so simple with CTRL + G. Just hit it, type the line number, and boom — you’re right there. It’s perfect for debugging or when you’re trying to quickly navigate between lines of code you need to reference. 🔍

Honorable Mentions ✨

CTRL + SHIFT + F (Search in Files)

This one is a lifesaver when you need to search for something in your entire project. Whether it’s a function, variable, or even a specific word, CTRL + SHIFT + F will search across all your files. It’s like having Google search inside your codebase. 🧑‍💻🔍

CTRL + ` (Toggle Terminal)

If you're like me and constantly switching between code and terminal commands, CTRL + ` (the backtick key) will open and close the terminal without breaking your flow. Super useful when you're running scripts, testing stuff, or just need to see the output without losing focus. 🎮🖥️

If you’re not using these shortcuts already, give them a try — they’ll seriously save you so much time! ⏳

What shortcuts do you swear by in VSCode? Let me know in the comments!👇

Happy coding! 🎉

From Chaos to Clarity: My Developer Workflow to Stay Organized and Focused On Tasks 🎯🧠

Gentt — Thu, 02 Jan 2025 17:09:34 +0000

Understand the existing flow (if its existing).. This is a crucial part as this will technically be the glue between your mental map and existing structure that you have, well in all honestly, might be a glue but it might be an "eraser", as on some cases it will cause you to identify some things that you might need to change, remove, or add even.

Creating a mental map of what needs to be done and how everything might be connected. This allows me to have a better understanding of what really needs to be done, and at the end even understanding the flow much better, which leads me to asking the right things, or catching potential issues.

Asking questions that you have while processing the "mental map", this includes potential issues that you think might cause you trouble or need to be fixed, then keeping track of these.

If it is a hard flow, I'd use something like excalidraw.io in which I can convert that mental map to a visual one, creating it with but not over complicating the visuals. I'd then have the questions/issues I've identified side by side as points, probably ranking them as well in some way, and colorizing the ones that are done/not done as well.

Taking some time to re-evaluate once more if you could potentially go another (smarter) way about it. I've heard somewhere of the 5 minutes rule, its something along the lines of giving something 5 mins to first settle in, and not just jumping right at it.

Not over optimizing them from the start, as I yet do not know what might arise and what might not really remain at the end, this doesnt mean that I should write shitty code. This has saved me a lot of time, but equally cost me time as well haha.

Trying to see what is already there, what I mean by this is, I've seen myself and other devs re-inventing a "custom wheel" a lot of times, but in this case, we had 3-4 instances of the same custom wheel around our codebase, now keeping this in mind, finding out that you might not need to do it from scratch does save some time.

Keeping myself honest, now this one is interesting, sometimes we tend to get "biased" when it comes to our own reasoning (shocker, right ?)... So every now and then, I do a reality check-ish with myself in terms of, "well, does this really make sense?", this tends to keep me grounded and has helped me to sometimes find out that there's really a better way of doing something.

💻🔍 React: Things You Might Want to Know

Gentt — Wed, 01 Jan 2025 18:54:56 +0000

Heyyy everyone!

Wishing you all a Happy New Year! May it bring out the best in all of us!

With this post, I want to showcase some tips and tricks that you might not know—little things that can simplify your code and make it cleaner. So, let’s get down to business!

1. Simple useEffects Usages Can Be Super Simplified

We've all seen something like this:

import React, { useState, useEffect } from "react";

const MyComponent = ({ propValue }) => {
  const [internalValue, setInternalValue] = useState("");

  useEffect(() => {
    setInternalValue(...); // Some extra logic modifying the propValue

  }, [propValue]);

  return <div>{internalValue}</div>;
};

But all of this could be simplified by deriving the value directly from the prop. React’s props and re-rendering mechanism can handle this seamlessly, giving you much simpler and cleaner code.

Simplified Version:

import React from "react";

const MyComponent = ({ propValue }) => {
  const internalValue = // Some extra logic modifying the propValue

  return <div>{internalValue}</div>;
};

Why It's Better:

Less Boilerplate: No need for useState or useEffect.
Immediate Updates: The value updates automatically when the prop changes.
Cleaner Code: Easier to read and maintain.

2. State Might Not Need to Live in the Parent Component

A common sort of defaut ish pattern I've seen is allocating state to a parent component without a valid reason. If the state is only used in one child component, it’s better to move it there. This keeps the parent cleaner and improves reusability of the child component.

Non-Optimal Example: State in the Parent Component

Here, the parent holds state (name and age) that is only relevant to one child:

import React, { useState } from "react";

const Parent = () => {
  const [name, setName] = useState("");
  const [age, setAge] = useState("");

  return (
    <div>
      <h1>Parent Component</h1>
      <Child name={name} setName={setName} age={age} setAge={setAge} />
      <Sibling />
      <AnotherSibling />
    </div>
  );
};

Good Example: State in the Child Component

Here, the state is encapsulated within the Child component, ensuring only it re-renders when needed:

import React, { useState } from "react";

const Parent = () => {
  return (
    <div>
      <h1>Parent Component</h1>
      <Child />
      <Sibling />
      <AnotherSibling />
    </div>
  );
};

const Child = () => {
  const [name, setName] = useState("");
  const [age, setAge] = useState("");

  return (
    <div>
      <h2>Child Component</h2>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Enter name"
      />
      <input
        type="number"
        value={age}
        onChange={(e) => setAge(e.target.value)}
        placeholder="Enter age"
      />
    </div>
  );
};

Why It's Better:

Encapsulation: State belongs to the component that uses it.
Improved Performance: Other siblings don’t re-render unnecessarily.
Cleaner Parent Component: The parent focuses only on orchestrating its children.

3. On most cases, React's optimization methods might not be needed

Now this is a harsh one to touch on, but lets just say React is really really good at handling re-renders and the situations where you really need optimization mechanisms are very rare.

This isnt to say they are useless, its just that you need to keep in mind that premature optimization is a thing.. I dont really support the "if its not completely broken dont fix it" but lets just say, you need to give it a proper check before you go to those mechanism and not just go to them straight away.

Even though, realistically there are some really good articles that I believe show us that there isnt as much drawback from using them a lot (i guess except bugs they might cause due to lack of people's understanding of how they might work). But my point is, you might not need to go through them at all, and well .. save you some time too

4. You don't have to "hookify" everything ...

Hooks are cool, right? They give us the ability to manage state, side effects, and more in a functional way. But just because hooks are available doesn't mean you need to create one for everything. I've seen a lot of developers fall into the trap of turning simple logic into custom hooks just for the sake of it. Instead you should be thinking in the direction of what problem will it help you? will you be reusing it? will it abstract some logic away for you? And so on...

I think I'll end it here, I really hope this helps and that we can all learn something new :))) Please feel free to reply with any possible scenario I might have missed with these, or improvements. I'd love to hear them and learn as well.

Testing out Safari on Windows (older versions too)

Gentt — Fri, 06 Dec 2024 21:33:27 +0000

Testing Safari on Windows (Without Losing Your Mind)

Hey everyone! It’s been a while... 😊 I recently ran into a tricky situation where I had to debug an issue happening specifically on Safari while working on a Windows machine. Let’s just say—it was a challenge. 😅

Thankfully, I stumbled upon an awesome article:

👉 Test Your Site in Every Browser

This article introduced me to a handy trick using Playwright. With a simple command, you can open a browser that uses the WebKit engine (the same engine Safari is built on) and pause it, giving you full control to:

Visit pages
Click around
Watch videos
And more!

The Specific Safari Version Problem

While this approach was a game-changer, it wasn’t a complete solution for my case. I needed to debug a specific major version of Safari, and WebKit alone didn’t quite cut it.

Here’s where it got interesting:

I dove into the Playwright changelog, where I discovered that it maps Playwright versions to specific WebKit versions. Using this information, I was able to emulate the Safari version I needed, by installing that version instead! 🎉

Debugging with DevTools

What’s even better? The emulated browser allows you to open DevTools, making it easier to inspect and debug issues. This saved me tons of time and effort—without needing access to a physical macOS device.

Limitations

Of course, there might be some limitations I haven’t encountered yet, like file uploads or other advanced functionality. But for my use case, this was an effective and FREE solution that worked perfectly.

Got Suggestions?

If you have any other suggestions for testing Safari on non-Mac devices, I’d love to hear them! From what I’ve seen, most services offering Safari emulation are either trials or require a paid subscription, so finding a free alternative like this was a gem. 💎

Happy coding! 🚀

Essential Tips for Junior Developers, Steering Clear of Common Pitfalls 💡

Gentt — Sat, 08 Jun 2024 10:14:49 +0000

Hey everyone! I'd like to showcase some of the things that have helped me with my learning process as a junior developer & to showcase what traits caused the biggest issues. This is to be taken lightly as even if you've done one of these, it's totally normal and should not be considered a "crime". We're humans at the end of the day :))

1. Not Developing a Sincere Connection with Your Colleagues

For me, one of the key points that will get you to enjoy your day-to-day work is having a great connection with your colleagues. Having that connection serves as a reminder that although we're in a work environment, that shouldn't stop us from having open and sincere connections. We don't have to limit ourselves to being the guy who just stares at the screen all day long (although that's a personal choice).

Don't be afraid to engage and say hello, be curious about them, and have honest conversations. Not everything should be connected to work all the time. Being the "new" guy doesn't make you "less". Be yourself, and express yourself in an honest & positive manner with your colleagues so that you can reap the benefits.

Having a sincere and great connection with your colleagues will give you the opportunity to learn from them too. It will open a door for them to give you sincere advice on yourself that you might have missed. You could even learn from one another and most importantly, count on each other too.

2. Avoiding Hard Tasks on Purpose

Honestly, this one isn't just for junior devs, but let's keep it that way for now. Look, we've all been beginners and we've gone through this process of thought: logically, you'd be thinking "I don't want to screw this up for myself at the very start and God forbid I look 'dumb' and not finish this task." Let me just say, that thought is understandable, but it doesn't make it true and let me show you why.

First of all, when you're hired as a junior, you're not fully hired for your level of knowledge when compared to your potential. So, that means the company that hired you is aware of your current knowledge and is totally fine with it. They hired you so that you could learn more and they know you have a lot of potential.

So, by avoiding those hard tasks, you're not only missing out on your learning curve, but even on the timing. Because no matter how long you avoid them, there'll always be one that you will have to do and believe me, it's best to choose to learn them properly at your beginnings than to not know them with lots of experience.

Again, I'm not saying to go full crazy mode on the hard tasks. Pick the hard ones incrementally too, you'll learn that way. Do not think of it as a way that you could endanger your job, but rather think of it as an opportunity to learn more and grow. Your company is aware of your current level and they value your potential and you should capitalize on that.

3. Not Asking Questions

It's understandable, and you probably are thinking that you'll be annoying to your colleagues/seniors and that you're bothering them. But let me just say that whichever senior is bothered and doesn't want to help isn't really a senior. You should not be afraid to learn alongside your colleagues and ask them questions, whether that is for the project you're working on, or for code-related things.

Of course, this doesn't mean to "bombard" them with tons of questions and for every problem you have, but when you feel you're better off with a question and that you can't really grasp the problem or the solution, it is totally normal to ask for help and guidance.

4. Taking PR Reviews Personally

Behind a great dev or even a junior one, there's a personality and a certain amount of ego, that's... understandable. But, realistically - the PR review process is one of the best ways for you to grow and learn from your colleagues.

You need to take into consideration that they're commenting on your code and how it can be done better, in a way for you to grow and not in a way to make you feel bad. Although we're humans and perspective on something can shape our emotions, your view on them should be that they'll help you grow and learn much more than taking them personally and not even taking them into consideration.

All I can say for this is, don't be chained by your own ego, and open yourself to being wrong (which we all are) and you'll see yourself grow exponentially more.

5. Copy Pasting Code You Don't Understand

We've all been there at some point, where if we're in "trouble" and find some working code (possibly from StackOverflow/ChatGPT) we just get that bad boy into our code repo. While it seems to do the trick, let me just say that it is a temporary solution that is not only blocking your learning process but it might even introduce new bugs to your application due to the lack of understanding.

What you should do instead is, try to understand code first and then apply it. Not only will that help you grow more, but it will also help you identify possible issues with it going forward.

You'll need to accept and embrace that part of the junior process is that you'll need to get uncomfortable more. The more you get into a "hard" spot and possibly make mistakes, the more you learn. Don't let that temporary happiness of blindly pasted code fool you and rob you of your learning process.

🌟 Discover 5 Must-Have VSCode Extensions You Haven't Tried Yet

Gentt — Sat, 01 Jun 2024 17:38:28 +0000

Hey there! Yes.. this is one of those posts, but.. I promise you're not going to find the generic stuff like "Prettier" here, don't get me wrong, while its essential, we kinda all know & have it. The purpose of this post is to try and find those hidden gems. I hope this helps :))

1. Error Lens

Think of this extension like your "Problems" tab within the VSCode terminal but on.. steroids, its basically going to show and highlight any issues in your code/syntax right at the specific line on the editor.

2. Console Ninja

We've all been sick and tired of going back and forth between tabs to only read the logs (console logs).. So the Console Ninja team said enough's enough and decided to instead showcase us the console log outputs and runtime errors directly in our editor.

3. Pretty TypeScript Errors

Look, as much as we love TS (not really?) we can surely admit seeing those long errors where one of the 43 nested types doesnt match isnt as optimal as we'd like, not to mention those error messages that can only be deciphered from Harvard PhD professors (and Matt Pocock). Luckily for us this extension saves the day by simplifying everything for us and making life easier.

4. Hungry Delete

Remember selecting all that empty space and then having to delete it, or even worse having to press backspace 10-15 times to do that? Well, this extension makes sure that you dont have to go trough that again, but instead take care of that emptyspace or tab by simply pressing CTRL+BACKSPACE

5. Add gitignore

At some point, we'll all have to create a .gitignore file and thats a fact, so, why not speed up the process and have a extension specifically built to help you create it faster with variety of templates to choose from?

What not to do when learning React as a beginner?

Gentt — Sun, 12 May 2024 21:51:09 +0000

Please take everything as a friendly advice and as a personal opinion. Most of the things said below could probably be applied for many other things not only React.

Jumping on it right away without the basics

You can surely start on it without a good foundation, but the learning curve will be much much harder as you'll have to switch on/off between React & things like JS, HTML figuring out how they work instead of spending your time purely on React mechanisms and having to practice & learn them.

While it is tempting, seeing how much people love it and not to even mention just how much tech influencers try to convince you with "Learning React within a week" (unrealistic content), its important to keep in mind that the realistic way to effectively learn React is to get the basics down first.

What does that mean? Learning things like HTML, CSS, JavaScript. Making sure you know how things work there first, think of React a "utilizer" of them but in its own way.

Blindly following courses and writing code you know works

There's nothing wrong with writing code that works & following courses.. However in order to get to the next step, what'll be more effective is to try to implement things in your own way, switching things up & experimenting with them. In order to learn more you have to start failing more, so that you can figure things out on your own way and get to that next level.

"I am always ready to learn although I do not always like being taught." - Winston Churchill

I specifically picked this quote from Winston Churchill as it points out to the reality of learning things, which is that in the beginning it will be harsh, having to dig in and find out how and why things work the way they do and having to overcome obstacles one after the other. Its frustrating, but good things come after endurance and patience, it also gives you the opportunity to develop discipline, which is doing and sticking to things you might not enjoy over and over again.

Learning without a plan

Look, while we all know that most of our plans don't always work out, it doesn't really justify lacking one. While it might not work out the way you thought, it will give you structure for what you expect from yourself, what you potentially need to go through & what level you might be at a given time.

You'll need to have a realistic incremental plan, and that goes hand in hand with having a feel on what level of knowledge you think you have. With that in mind, the best approach is to keep track of your progress, current level and then to combine it with your desired plan, at least this way you have a proper path you can follow.

I get it, at the start you dont really know whats what and having thoughts as "is this really the right way?". For that dilemma, I'd recommend taking a look at paths at https://roadmap.sh/ where you have a proper plan for a variety of paths you might want to follow, you can also try seeing how others started it, what I would do is I'd search up for Youtubers showcasing how they started & believe me you'll also be inspired from it too as a bonus!

Mastering advanced techniques out of order

Seeing those cool advanced techniques sure does give you a high spike on that desire to learn and look cool in front of your React buddies, but I'd recommend to first analyze yourself whether you're ready to go there yet. What I mean by this is that those techniques like Memo, useCallback and others are hard for a reason, you first need to have a clear picture of how React works things out behind the scenes in order to go out to its harder methods.

As a solution to this you need to use the upper point of having a plan and keeping track on yourself so you can better identify what you need to learn next, this way you'll have a better transition from one thing to the other and things would make more sense.

~THE END
Hope you enjoyed this post and found it helpful :)) There are many other things out there but I wanted to showcase the things I consider to be at the top of the list from my personal experience. I cannot wait to see many other opinions and what other people found helpful in their journey.