Every senior, experienced developer once started their career as a junior developer with basic coding skills and foundational knowledge of computer science. Junior developers gradually learn real-world design patterns, architectural decisions, advanced programming concepts, and domain knowledge to transition into senior developers—those who understand the big picture of the software products they develop.

Being a senior developer is not a permanent badge based on your past experience—your “seniority” depends on how you work and the decisions you make to ensure the success of a software project. A poor decision or a deliberate wrong action can damage your reputation, so senior developers must always be mindful of their coding activities and their consequences.

In this article, we will explore things that senior developers never do to maintain their reputation within a software development team. Avoid these habits and actions to become a skilled senior developer and advance your career!

Overcomplicating Project Architecture

An artist showcases their skill and experience through paintings. Similarly, a project’s source code becomes the playground for developers to demonstrate their expertise. Using an optimized infrastructure and dependencies focused on architectural simplicity is a great way to prove your experience.

However, adding advanced architectural components beyond what a project actually needs—just to show off expertise or make the project look “high-end”—results in overengineering. An overengineered project introduces unnecessary complexity to the entire team, even when the project itself only requires a simple solution.

A common example is startups implementing hundreds of microservices when a simple monolithic REST API would suffice.

A great case study is Stack Overflow, which serves millions of developers without needing hundreds of microservices.

Senior developers never overcomplicate project architecture to showcase their skills or make a project appear sophisticated—they focus on simplifying the architecture to use resources efficiently and impress through minimalism.

Writing Overly Complex Code & Chasing “Perfect” Code

Using appropriate design patterns in source code enhances maintainability. Additionally, experienced developers leverage language features, design patterns, and efficient data structures to improve software performance and maintainability.

However, perfect code does not exist—developers can always refine their code using design patterns and language features, believing they are achieving perfection. But what happens when a developer over-improves their code beyond the “good enough” threshold?

Striving for perfection often leads to overengineering the code.

For example, imagine implementing a Fahrenheit-to-Celsius converter in Python as part of a simple weather app. A senior developer anticipates future maintenance needs but never adds unnecessary complexity in pursuit of “perfect” code—they write simple, sufficient, and maintainable code.

They improve code only when necessary for maintainability but never write unnecessarily complex code based on speculative future requirements.

Ignoring Increasing Technical Debt

Technical debt arises when developers choose short-term, easy solutions without considering long-term consequences, especially regarding maintainability. While technical debt is unavoidable in the competitive software industry with tight budgets, it can be managed through continuous code improvements and well-organized code review sessions. Technical debt can also accumulate in project architecture components.

Here are common situations that lead to technical debt:

• Writing code solely to ship features and fix bugs without prioritizing maintainability.
• Extending features on a weak code foundation by adding duplicate code and quick fixes—for example, working on a plugin without stabilizing the core plugin runtime APIs.
• Choosing infrastructure and runtime services that are difficult to scale for a high-user product.
• Ignoring outdated, unsupported, or deprecated code and libraries.
• Integrating incompatible libraries or sticking with suboptimal architectural decisions.

Technical debt may seem harmless at first, but if it accumulates too much, it can shorten the lifespan of your product.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Are you one of those people who occasionally find using GitHub a bit of a headache?

I get it. At first glance, GitHub can seem intimidating—so many branches, pull requests, merges, conflicts… it’s easy to feel lost.

I’ve been there too. I often wondered whether I was following best practices or just making things messier for the team with every commit I pushed.

The good news is, it doesn’t have to be that way. With the right approach and a few key tips, GitHub can seamlessly integrate into your development workflow.

Whether you’re a complete beginner or someone overwhelmed by its countless features, GitHub is here for you.

WHY SHOULD YOU CARE ABOUT GITHUB?

GitHub is more than just a fancy cloud storage for code—it’s where the magic of collaboration happens.

It allows you to implement version control in the most efficient way possible, something every developer needs when working with a team to avoid stepping on each other’s toes. Mastering GitHub will make your life easier, whether you work solo or in a group.

BASIC WORKFLOW

Let’s go through a simple GitHub workflow. This assumes you have a basic understanding of Git, so we’ll focus on GitHub as a collaboration hub.

CREATING A NEW REPOSITORY

Go to your GitHub dashboard and click the “New Repository” button. Give it a cool name—maybe “super-cool-project” or something more professional if you’re working in a team.

CLONING TO YOUR LOCAL MACHINE

Now, clone this new repository to your local computer.

(Illustration: “GitHub Repo Clone”)

BRANCHING OUT

This is where many beginners struggle: branching. If you’re developing a new feature, always create a new branch from main (or master, depending on your default setup).

(Illustration: “Branching Out”)

MAKING CHANGES

Go ahead and do what you need—write great code, add some files, maybe fix a few bugs along the way.

COMMITTING AND PUSHING

Once you’re happy with the changes, stage them and commit. Remember the golden rule: write meaningful commit messages. Avoid vague messages like “fix stuff” or “final version control.”

(Illustration: “Commit and Push”)

CREATING A PULL REQUEST (PR)

After pushing your branch, it’s time to create a pull request on GitHub. This is a crucial step. PRs allow others to review your code, provide feedback, and discuss potential changes.

Go to your repository on GitHub, and you’ll see a big button that says something like “Compare & Pull Request.”

Click it, add a meaningful title, and write a clear description. Be specific—let your teammates know what you changed and why.

MERGING THE PULL REQUEST

Once your team has reviewed your code and you’ve addressed their feedback, merge the PR into the main branch. Voilà!

You’ve just successfully collaborated like a pro.

HANDLING MERGE CONFLICTS LIKE A “BOSS”

Merge conflicts are inevitable, but don’t let them stress you out. If two people edit the same part of a file, Git won’t know which version to keep. That’s where you come in.

When Git notifies you of a conflict, it will mark the conflicting parts in the file. You’ll see something like this:

(Illustration: “Handling Merge Conflicts”)

Simply decide which code to keep, or merge both in a logical way, save the file, and commit again. That’s it!

GITHUB ACTIONS: AUTOMATE YOUR WORKFLOW

Another game-changing feature on GitHub is GitHub Actions. Why waste time manually running tests, building code, or deploying updates when GitHub can do it for you?

Actions allow you to automate almost anything in your workflow.

For example, you can set up GitHub Actions to automatically run tests every time a pull request is created, ensuring no buggy code gets merged. You can even set up continuous deployment to push changes to production once they pass all tests.

Here’s a basic setup for an action that runs tests on your code:

(Illustration: “GitHub Actions”)

This means that every time you push to main, GitHub will run tests for you—like a little assistant reminding you, “Hey, let me check if everything’s still good to go.”

FINAL THOUGHTS

GitHub is your best friend in the world of version control and collaboration. With features like branching, pull requests, and GitHub Actions, it provides everything you need to work effectively with others—or even just by yourself.

It’s not as scary as it seems. Stick to good practices, keep things organized, and soon, you’ll be committing, merging, and collaborating like a seasoned developer.

Key takeaways:

Use meaningful branch names and commit messages.
Don’t fear pull requests—they’re your safety net.
Handle merge conflicts with confidence, not panic.
Automate testing with GitHub Actions to save time.

And remember: no matter how great GitHub is, it’s the people using it that create the real magic.

Have a good day!

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.