DEV Community: Tammy Alemu

Do You Control Copilot, or Does Copilot Control You? (A VS Code Fix)

Tammy Alemu — Sat, 27 Sep 2025 15:53:42 +0000

Finding Focus in the Age of AI Coding

AI-assisted coding has quickly become the norm. Tools like GitHub Copilot are changing how developers write code, helping us move faster, automate repetitive tasks, and even debug tricky logic. For many, it feels like magic. You type a few keystrokes and Copilot offers up whole functions, tests, or even scaffolding for your project.
But as powerful as it is, Copilot has its downsides—especially when it comes to how we think about coding.

The Benefits of Copilot

Let’s start with the good stuff. Copilot can:

Save you time writing boilerplate code.
Generate quick snippets you’d otherwise Google for.
Help you explore unfamiliar languages or frameworks.
Speed up debugging and testing.

For experienced developers, this means more time spent on solving problems rather than re-typing the same syntax over and over again.

The Hidden Downsides

The challenge is that Copilot doesn’t just speed up code writing, it can also hijack the process of coding itself.
For learners, this can be especially harmful. Instead of figuring out what to build and why, you end up blindly accepting suggestions. The syntax may look right, but the thinking behind it, the real skill of development gets skipped.

Here’s the truth:

Writing code is necessary, but understanding systems, problem-solving, and logic design are the real craft.
If you can’t code well without AI, you’ll struggle to build scalable, maintainable projects with AI.
Copilot sometimes bloats solutions or suggests suboptimal patterns, which can create more debugging work.

In other words, if you don’t know how to code, Copilot won’t save you. It’ll just speed you along into bad habits.

Thinking vs. Typing

Software development has never been about who types the fastest. Syntax is the easy part. The hard part is thinking clearly about systems, designing, architecting, and understanding how pieces fit together.
That’s why many “vibe coding” projects those where developers let AI lead the way often end in abandoned repos. Without strong fundamentals, AI just amplifies confusion.
Still, I don’t think AI should be ignored. Used correctly, it’s a powerful assistant. It can debug with you, take care of the repetitive stuff, and free you up for higher-level thinking. The key is balance.

Where Copilot Gets in the Way

For me, the biggest problem was inline autocompletions.
These suggestions pop up constantly while you’re typing, filling the editor with half-finished logic or entire chunks of code you didn’t ask for. Instead of helping, they often interrupt the flow of thought pushing me toward solutions I might not actually want.
I realized that while Copilot is great for certain tasks, I needed a way to choose when to use it.

Building My Own Fix: Copilot Toggle

So, I built a small extension for Visual Studio Code: Copilot Toggle.

It adds a simple toggle button to the status bar that lets you turn Copilot’s inline autocompletions on or off instantly.

Need focus to solve a problem on your own? Switch it off.
Want quick help with syntax or scaffolding? Switch it back on.

It’s a lightweight tool, but for me, it makes all the difference. Instead of Copilot controlling my coding experience, I control Copilot.

Final Thoughts

AI coding tools are here to stay—and they’re incredibly useful when used intentionally. But the real skill of a developer has never been typing syntax; it’s in thinking clearly, solving problems, and building systems.
By toggling Copilot on and off when I need it, I’ve found the right balance between human creativity and AI assistance. And that’s what keeps me growing as a developer.
You can try the Copilot Toggle extension yourself on the Visual Studio Marketplace

My Journey as a Laravel Intern

Tammy Alemu — Tue, 06 Aug 2024 05:55:26 +0000

By Tammy Alemu

Hi, I’m Tammy Alemu. Let me take you through my exciting journey as a Laravel intern. I aimed to gain industry experience, write readable code, and understand the framework deeply. Here’s how it all went down, with the challenges I faced and the solutions I found along the way.

During my internship, I had three primary goals:

Industry Experience: Gain practical experience in a professional environment.

Readable Code: Write clean, maintainable, and readable code.

Framework Understanding: Develop a deep understanding of the Laravel framework.

Development Environment

My journey began with setting up the development environment. Before this internship, I interacted with the backend using a frontend architecture, either through Blade views or JavaScript bundled with Vite. So, I didn’t really see the necessity to set up CORS and all that. Then, I got introduced to Postman — wow, what a game-changer!

Postman

Postman helped me set and edit HTTP requests, pass parameters and values, and manage authentication and bearer tokens. This broadened my understanding of the backend’s structure and how it works. Seeing data in its raw form and manipulating it directly was eye-opening. I realized that the seemingly complex backend operations were more straightforward than I initially thought.

Composer

Composer was another essential tool. I used it to install packages and adhered strictly to PHP PSR-4 formatting standards. When I say strictly, I mean it! Haha. I ran into errors when I didn’t follow the standards, like generating documentation and realizing I had errors in namespaces due to extra spaces or incorrect naming conventions for models and tables.

Project Setup

Setting up the project involved several key steps:

Repository Management

Cloning repositories and setting up my environment was quite overwhelming at first — haha, what a ride! I was introduced to scribe:generate, a package that generates documentation. Initially, I was like, “What?!” Running specific class seeders was another challenge. I didn’t understand their purpose compared to normal seeders until I realized php artisan db:seed --class=...Seeder runs a specific seeder class directly, useful for seeding specific tables or data sets individually.

Model and Data Handling

I highlighted the parameters needed when adding new attributes to models and specified data types. Familiarizing myself with data serialization and transformation to format responses was crucial. I also learned to use includes and default includes for formatting specific data and parsed includes to add data to responses.

Eager Loading

Eager loading was one of the beautiful things I learned. Instead of lazy loading, where a new SQL query executes within a loop, eager loading performs a single query to load all necessary data. The with helper became vital for efficient database querying, this made me look into beautiful helpers available in Laravel, what a difference it made!

Query Scopes and Builders

I used query scopes available to the controller to fetch data before transforming them. Query builders also became my go-to for streamlined data retrieval.

Controllers

Controllers handle basic logic for various request types (GET, POST, UPDATE). I learned to write endpoints and clearly comment for Scribe documentation. Using actions to extract reusable code into different controllers ensured a clean code structure. Implementing try-catch methods when working with the database was another valuable lesson.

Views

Although not used extensively, views were mainly used to format mail responses.

API Development

I learned to design and implement APIs following RESTful principles and tested them using Laravel’s built-in logging tools and Postman.

This knowledge further spawns me to building and working with Laravel socialite, integrating google auth for sign in and the use of Laravel sanctum, live on my GitHub profile.

Challenges and Solutions

Challenges

Understanding the codebase was initially tough, especially since there were no collection routes available in Postman. I had to build them and understand the structure, which sometimes required extra parameters and slowed my development process.

My shallow fundamental knowledge of PHP also affected my progress, leading to extra time spent on tasks.

Solutions

To overcome these challenges, I focused on learning the fundamentals and practiced by working on a separate branch aside from my assigned tasks. I took a deep dive into understanding PHP, sourcing resources like “Programming with GIO,” “PHP the Right Way,” and Laracasts — highly recommend them!

It’s okay not to have the syntax memorized. Haha, for cases like this, I always referred to documentation. Reading docs broadens your understanding of a particular topic.

Overall, my experience working with the team has been superb. Besides being a paid position, they offered help with understanding and building apps. The team I work with explains the tasks intended to achieve and gives swift responses when attending to challenges I face.

What do Hiring Managers have to say?

Tammy Alemu — Fri, 15 Sep 2023 00:47:38 +0000

Introduction:

Getting hired can be a challenging process, for every open role there are a quite number of applicants and a streamlined process is in place, how do you stand out? Hiring a prospective candidate is easy but getting that candidate sometimes could be hectic for Hiring managers and often these issues are on the candidates' end. Have you ever wondered what HR managers are looking for?

Importance of Hiring Managers:

Hiring managers play a crucial role in organizations. They define job roles, strategize recruitment, assess candidates, consider cultural fit, negotiate offers, and oversee onboarding, ensuring the right talent is onboarded for company success.

Problems in the Hiring Process:

The hiring process involves an initial filter to remove irrelevant applications, identifying the best profiles, assessing cultural fit, technical interviews, and final offer evaluation. In any open role on the internet comes over 100 applicants, the sad part is that most CVs are not read or didn't pass the ATS bots. (An ATS bot, or Applicant Tracking System bot, is a type of software application used by employers and recruiters to streamline and automate various aspects of the hiring process.)

Your application goes through 5 stages

recruitment filter 1. Getting rid of obvious nonsense.
Developer filter 1. Finding the best profiles.
Recruiter filter 2. Cultural fit(non-technical interview)
Developer filter 2. Interview (technical).
Offer filter.

What do hiring Managers have to Say and why aren't you hired is a question every applicant would want to ask.

I asked a few hiring managers and here's what they have to say and issues regarding candidates in an open role, and their common flaws include:

The lack of relevant experience:
Most prospective candidates lack relevant experience as stipulated in their resume but couldn't answer basic programming questions. companies are looking to hire people or engineers that solve real problems, anyone can make a simple box card component or to-do list, and there are tons of libraries that a developer could easily pick from for these, but they don't show you solving real problems, they just show you can follow a tutorial, they want to see you solve the problem, how you approached them and how you made the decisions to resolve it. Irrespective of the tools, can you solve an issue or do you know how to use the tools.
Having a bulky resume:
Candidates having a bulky resumé have less chance of being regarded recruiters skimp through your resumé /CV for relevant experience.
cloned portfolios, and a focus on generic projects rather than unique ones.
Cloned portfolios, with so many W3Cc validated errors, no basic understanding o fundamentals.
Your projects can be completely fake, but they are subject of conversation during interviews and most times candidates couldn't answer the basic questions about coding fundamentals. A lot of people build out projects that are generic and basic, like a to-do app, sure technically there's nothing wrong with that, but the truth is you're going to have other resumes with similar projects. It's just boring and doesn't make you stand out.
Instead, focus on unique projects that are interesting to you. Interviewers care a little about your projects, but if you do have one, questions would arise from it. It gives you a better edge if the project is interesting to you. They look at you and how interested you are in the field.
You can also build a to-do app and make it interesting to ignite the curiosity of the user.
Soft skills: communication, ability to learn, interest. Tech skills can be taught,"a monkey can be trained to code" , they're mostly looking at your soft skills, it takes one person to ruin a team, regardless of what they know and what they can do, skills can be developed and cultivated but who a person is, is what these companies are investing in, Talking on a point of contact, can learn, how you communicate with your recruiters is important.
Problem-solving approach: problem-solving approaches are highly valued, even more than knowing every syntax. Problems can be solved in several ways, but knowing how to approach and solve things is what gets you noticed. In development an important factor is the details, the differentiator isn't in the problem set, but the execution because in engineering a lot of innovation is actually within the execution. They show your thought process.
Your thought process of achieving a task and not being mundane is of topmost importance, they don't expect you to know every syntax, because they are not hiring encyclopedias.

Recommendations and Advice:
A portfolio is of little concern to Hiring managers, It's best you Build a clean and fundamental portfolio, as it's important to get the basics right. Don't bother with a portfolio, or else you can make it perfect, because in learning anything new, it's important to get the fundamentals right.
A computer science degree is not mandatory to excel in coding; don't fear interviews, and admit when you don't know something.
Developing a strong personality and interpersonal skills can boost your hiring prospects.
If you don't get hired, consider creating your job by showcasing your programming skills, This is software development. Once you have the basics down, you can create anything.

-Your self-doubt is perceived by only you, you have skills and those skills are valuable when used.

GitHub for babies

Tammy Alemu — Tue, 18 Jul 2023 02:10:00 +0000

A Walk Around GitHub

What is GitHub?

GitHub is a web platform where people can store and share their computer code. It's like a big online library where programmers can upload their code and collaborate with others. It provides a place for developers to work together on projects, make changes to code, and keep track of those changes. GitHub makes it easier for people to work on code together, even if they are in different parts of the world.
Take, for instance, you and your friend had a startup, but you both need jobs for funding, so you were actively applying. Finally, that email came, and you got the job. It's remote. You celebrated with your friend and encouraged him to apply more. Down the line, he got one. Great news, but it's onsite, which means your friend has to relocate. It's great, right? You don't want to jeopardize his chances, but what happens to your startup?
Okay, cool. We can share codes on WhatsApp... WhatsApp? Not reliable. It's different time zones. How do you merge conflicts? (I'd explain that). How do you test? Definitely, it's going to impact user input.
That's where GitHub comes in. Not only can you edit codes, but it also keeps track of changes. Isn't that super cool? 😎

Why GitHub?

If you're a music lover, I can tell you have your playlist personally curated based on your preferences and taste. You can't wait to share that feeling with your buddy, so you share your editable playlist. But how do you refrain your friend from inputting abstract songs into the playlist? However, he knows your taste in music, but sometimes he can miss the mark, right? You don't want jazz on a blues playlist (I love jazz music, haha). How do you refrain from that? Hmmm.

That's a conflict right there, but you still want to share your playlist with your buddy, right?

Take GitHub as a playlist filled with lines of your code. You create the playlist, and he makes a copy of it to add more interesting blues. All you have to do is verify if they suit your taste. So, Git typically merges both playlists, and voila, you've got a better playlist.

In instances of conflict, what's the best way to resolve them?

All you have to do is create your own branch and roll your updates... But wait what is a branch? We don't have an HQ yet, its just a startup. Hahaha, in GitHub practices, the main branch is the original project, but you need a repository (repo for short) to do that. Now lets understand what's a repo is.

Understanding GitHub

Repository: Imagine a repository as a big box or folder where you keep all the important stuff for a project. It's like a central storage space where you can store and organize everything related to your project, such as documents, files, and even different versions of your work. It helps you keep things organized and accessible in one place. Just like you might have a folder on your computer for all your photos or documents, a repository serves as a dedicated place for your project's files.
Branch: Now, think of a branch as a different path or direction that you can take within that big box or folder. It's like having a separate area where you can work on specific changes or ideas without affecting the main project. Just like you can take a detour while traveling, a branch allows you to explore different ideas or make changes to your project without messing up the original version.

In simpler terms, a repository is like a big box where you keep everything for your project, and a branch is like a separate path or area within that box where you can work on different changes or ideas without affecting the main project, and there's so much fun things you could do with a repository, like cloning and initializing.

Cloning existing repositories refers to making a copy of an already existing Git repository. This allows you to have a local copy of the repository on your own computer, so you can access the files and make changes without affecting the original repository.
Initializing a repository within a project directory means starting a new Git repository within a specific folder that contains your project's files. By doing this, you tell Git to start tracking changes to those files and enable version control for your project.

In these examples, setting up a new Git repository is like creating a dedicated space for your project or hobby. Cloning existing repositories is like making a copy of someone else's work for your own use.
Initializing a repository within a project directory is like setting up a shared space where multiple people can work on different parts of a project and later bring everything together.

Working with GitHub

So back to our playlist we shared with your bud, how do we achieve this?

Here's how it works:

Start with the main branch: The main branch is like the original project. It contains the initial files and serves as the foundation for everyone's work (The main playlist).
Create your own branch: Before making any changes, you create your own branch. It's like having your personal copy of the playlist to work on. This way, you won't affect the main branch or your friends' work.
Make your changes: You start working on your branch, making edits, adding new features, or fixing issues. You can do whatever you want without interfering with others.(Basically adding or removing tracks).
Commit your changes: Once you're done with your changes, you commit them. Think of it as saving your progress. Git records the changes you made, like a snapshot of the project at that moment.
Share your branch: After committing, you push your branch to GitHub. It's like uploading your changes to a shared space where your friends can see them.
Repeat the process: The cycle continues as others create their branches, make changes, and collaborate. Git keeps track of all the changes, making it easy to see who did what and when.

By following this workflow, Git and GitHub enable smooth collaboration on projects. They allow multiple people to work on the same project simultaneously, track changes, provide feedback, and merge everyone's work into a unified whole. It's like teamwork with an efficient system to manage and integrate everyone's contributions.

what if conflicts arise while updating the playlist? He took out your favourite track or added an odd one?? Oh dang this doesn't sound good right?

Now you

Resolve conflict. In git Sometimes, two people may make conflicting changes to the same file(playlist). Git helps you identify these conflicts and resolve them. It ensures that everyone's work fits together smoothly. After identifying the conflicts and been satisfied with the resolutions(tracks on the playlist) you merge.
Review and merge: Now your friends can see your changes and provide feedback. They might suggest improvements or ask for modifications. Once everything looks good, your branch can be merged into the main branch, combining your changes with everyone else's work.

Sometimes the merge conflicts arises, don't worry let's figure it out.

Merge Conflicts:

Merge conflicts occur when Git cannot automatically merge the changes because they affect the same lines or sections of a file.
Git marks the conflicting parts in the file and notifies you about the conflict.
Conflict markers (like "<<<<<<<", "=======", and ">>>>>>>") are inserted to highlight the conflicting sections.

Best Practices for Resolving Conflicts:

Communicate: Coordinate with your teammates to understand their changes and ensure everyone is aware of potential conflicts.
Update frequently: Regularly pull the latest changes from the shared repository to reduce the chances of conflicts.
Review changes: Before merging branches, review your teammate's changes to catch any potential conflicts early.
Resolve conflicts locally: Whenever possible, resolve conflicts on your local machine before pushing the changes to the shared repository.
Use tools: Utilize Git's built-in tools or graphical interfaces that assist in visualizing and resolving conflicts.
Test after resolving: After resolving conflicts, test the merged code to ensure it functions correctly and as intended.

So does that mean my bud can merge playlist without me reviewing?

No he needs to ask you first..... In etiquette it's called polite request, in Git we call it the Pull request.

A Pull request is like raising your hand and asking someone to review your work before it becomes part of a bigger project.

When you finish your part, you want others to review it before it gets added to the final project. So, you create a pull request. It's like raising your hand and saying, "Hey, can someone take a look at what I've done? I think it's ready to be added to our project."

To create a pull request, you upload your branch with the changes to a shared platform like GitHub.
Your teammates are then notified about the pull request and can review your code, offer suggestions, ask questions, or request modifications.

Finally we have an updated playlist. Viola.