DEV Community: Ibrahima D.

How to use two instances of Claude Code

Ibrahima D. — Tue, 19 Aug 2025 15:24:44 +0000

You have reached the limit for Claude Code

It's quite frustrating, especially since it often happens when our treatment isn't finished.
It's not ideal to have two instances of Claude, because it means paying for Claude Pro twice, but it's cheaper than having Claude Max, which costs over €100.

First, at the root of your account, create a new folder that will hold your Claude configurations, credentials, etc.

If you have specific configurations such as commands, don't forget to copy them. That's what I do when I activate another instance of Claude.

cp -R .claude .claude-2

in zshrc $HOME/.zshrc|.bashrc

cc() {
 claude
}

ccp() {

CLAUDE_CONFIG_DIR=~/.claude-2 claude

}

Now you just need to launch cc for claude or ccp for claude-2.

Note: cc and ccp are arbitrary you can call them whatever you want.

Enjoy

Essential Code Review Terms Every Developer Should Know

Ibrahima D. — Mon, 07 Jul 2025 09:12:09 +0000

When I first started out in this profession, I would often come across certain terms and acronyms in code reviews and team discussions, and I always wondered what they meant. If you’re new to software development or just want a refresher, here’s a handy list that might help you navigate those conversations more confidently.

Common Terms and Acronyms
WIP (Work In Progress): Indicates that the work or pull request is not finished yet and is not ready for a full review.

LGTM (Looks Good To Me): The proposed code looks correct and can be merged.

NIT (Nitpick): A minor suggestion or remark, often about style or readability, with no functional impact.

ACK (Acknowledge): Confirms that a comment has been read and considered.

PTAL (Please Take A Look): A request to review or re-review the code.

RFC (Request For Comments): An invitation for feedback or opinions on a proposal or change.

IMO/IMHO (In My [Humble] Opinion): Indicates that what follows is a personal opinion.

Blocking: A comment or issue that must be addressed before the code can be merged.

Non-blocking: A suggestion or remark that does not prevent the code from being merged.

Ship It: Informal way of saying the code is ready to be delivered or merged.

Stale: A review or pull request that hasn’t seen activity in a long time.

Self-review: Reviewing your own code before submitting it to others.

Refactor: Rewriting code to improve its structure or readability without changing its functionality.

Patch: A software fix or update.

Hotfix: A quick fix for a critical bug, usually deployed urgently.

DRY (Don’t Repeat Yourself): Principle to avoid code duplication.

Bump: To increase or update a version number, or to make a small improvement or fix.

Chore: A technical or maintenance task that doesn’t add a new user-facing feature, but is necessary for the health of the project (e.g., code cleanup, updating dependencies, configuring tools).

FYI (For Your Information): Sharing information without expecting an immediate response or action.

TBR (To Be Reviewed): Indicates that a piece of code or change is waiting for review.

Dead code: Unused or obsolete code that should be removed.

Needs Rebase: The branch needs to be updated to resolve conflicts or incorporate the latest changes from the main branch.

Outdated: A comment made on an older version of the code, often after a rebase or new commit.

TBD (To Be Determined/Defined): Something that still needs to be specified or decided.

If you know more terms or acronyms that are commonly used in code reviews, feel free to share them in the comments! This list is not exhaustive, and your input can help others in the community.

Enhancing Testability with Dynamic Data-testid Attributes

Ibrahima D. — Thu, 28 Mar 2024 14:21:39 +0000

We've all been faced with the challenge of choosing a better test ID for our component at some point. Why not leverage the logic we already use for CSS, like BEM (Block Element Modifier)? What is the best solution for achieving consistent and logical IDs across the board? What are the existing best practices?

✅ The Solution:
The best solution I've found with React is to create a custom hook that generates an ID, making it easier to locate them in our tests.

📚 Code Examples:

Create a custom hook useTestIdGenerator.ts:

Use the custom hook in your grid component:

Now, each element in your grid has unique "data-testid" attributes!

This approach greatly facilitates testing of dynamic components while maintaining the cleanliness and maintainability of your code. 🔥

An example test using this unique attribute:

Don't hesitate If you have another even better solution, to suggest it in the comments.

The boy scout rule : Small Steps, Big Impact

Ibrahima D. — Mon, 04 Sep 2023 10:01:31 +0000

In his book 'Clean Code,' Robert C. Martin introduces us to an essential principle for writing beautiful code, the famous Boy Scout Rule, which can be summed up in one sentence: 'Always leave a place in a better state than you found it.'

As developers, we are constantly faced with challenges to produce clean, readable, and maintainable code. One of the simplest yet most powerful methods to achieve this goal is the Boy Scout Rule. Inspired by the idea of leaving the environment in a better state than we found it, this rule can have a significant impact on the quality of our code. In this article, we will explore this concept and discover how it can enhance our development process

The Boy Scout Rule, popularized by software engineering veteran Robert C. Martin, encourages us to improve the code with every change we make, even if that change is not directly related to our current task. This can include minor adjustments such as renaming variables for clarity, adding comments to explain complex parts of the code, or reorganizing sections for better readability.

The Benefits of Following the Rule

Cleaner Code: By adopting this rule, we ensure that our code remains consistently clean and organized. The cumulative effect of small improvements over time contributes to overall quality maintenance.

Ease of Maintenance: Well-maintained code is easier to understand and modify. Future development teams will appreciate code that reads like a well-written book.

Reducing Technical Debt: By preventing the accumulation of poor code, we avoid technical debt, allowing development to proceed smoothly without being hindered by quality issues.

How to Apply the Boy Scout Rule

Be Conscious: Every time you modify a part of the code, be mindful of opportunities for improvement. Ask yourself, "How can I leave this part of the code in a better state?"

Prioritize: Not all improvements are equal. Focus on changes that will have the most impact on code readability, maintainability, and clarity.

Communicate: Share the Boy Scout Rule with your colleagues. Encourage a development culture where a commitment to quality is valued.

The Boy Scout Rule is a simple yet effective approach to ensuring the ongoing quality of our code. By incorporating this philosophy into our development process, we contribute to an environment where code respect and a continuous improvement mindset are at the core of our work. So, the next time you make a change, ask yourself,

'Am I leaving the code in a better state than I found it?'

Your code, your colleagues, and your future self will thank you.

11 Pieces of Advice I Wish I Had Known as a Junior Developer

Ibrahima D. — Wed, 16 Aug 2023 10:41:40 +0000

Being a junior developer is an exciting stage, but it's often filled with challenges and learning experiences. Looking back, many developers realize that there were several things they would have liked to know at the beginning of their careers. This article delves into the valuable lessons and advice that I would have wished to receive when starting out in the field.

1. Don't Neglect the Basics !!!

One of the most common mistakes made by junior developers is to focus solely on memorizing syntax and using ready-made solutions. In reality, understanding the fundamental concepts of programming and specific languages is essential. This enables more effective problem-solving, adaptation of solutions to needs, and building a solid foundation for further development.

2. Read the Documentation

Reading, re-reading, and reading documentation again is often underestimated, but it can make all the difference in the development process. Junior developers should learn to read and create accurate documentation from the start. This facilitates collaboration with other team members, understanding libraries and frameworks, and contributes to quick problem resolution.

3. Learn How to Learn

The development industry evolves rapidly with new technologies and emerging best practices constantly. Developers should become familiar with the idea that learning never stops. Participating in online courses, following relevant blogs, and working on personal projects are all ways to stay updated and continue evolving.

4. Code Simply, Then Format the Code

It's easy to fall into the trap of wanting to write perfect code from the start. However, it's more important to focus on efficient problem-solving. Developers should learn to iterate, test their ideas quickly, and improve gradually. Perfection comes with experience.

5. Don't Hesitate to Ask Questions and Seek Help

Development isn't limited to just programming. Communication with team members, clients, and stakeholders is crucial for understanding needs, sharing ideas, and solving problems. Developers should cultivate their communication skills to become valuable team members.

6. Don't Fear Failure

Making mistakes is part of learning, so don't be afraid of making them. Even great software developers have been fired, made mistakes, and felt down, but what makes them great is that they rise and learn from their mistakes. Don't be discouraged by errors or bugs; use them as learning and growth opportunities.

7. Contribute to Open Source Software

You'll learn a lot by contributing to an open-source project, so by helping the community, you're helping yourself, and maintainers are happy. Start small and learn about the project; begin with a framework/tool you use. There are many ways to contribute to open-source projects, such as reporting a bug, reproducing the bug, and writing code to fix a bug or implement a new feature.

8. Be Open to Feedback and Criticism

Receiving constructive feedback on your code is a chance to learn and improve. Be open to critiques and consider them as opportunities for growth. Practicing egoless programming can be beneficial.

9. Manage Your Time

Development can be time-intensive. Learn to manage your time by planning, setting priorities, and avoiding getting overwhelmed by secondary tasks. The day you're satisfied with your development is the day you'll no longer grow.

10. Version Your Code (GitHub, GitLab, Bitbucket ...)

Use a version control system like Git from the start. This allows you to track the evolution of your code, collaborate more effectively with other developers, and revert changes if necessary.

11. Enjoy the Journey

Taking breaks and vacations is essential to maintain a healthy balance between work and personal life. Schedule short, regular breaks throughout the day to rest your mind. Techniques like the Pomodoro technique recommend working for about 25 minutes and then taking a 5-minute break. Use this time to stand up, stretch, take deep breaths, or simply step away from your screen.

Don't underestimate the importance of vacations. Plan your time off in advance and make sure to adhere to it. When you go on vacation, truly disconnect from work. Avoid checking your work emails or thinking about ongoing projects. Allow yourself the necessary time to rest, relax, and recharge.

Regardless of the experience gained over the years, being junior or senior isn't determined by time alone, but by the level of professionalism one achieves. Each day is an opportunity to continue learning, growing, and refining one's skills. This mindset enables me not only to embrace new technologies and tackle challenges but also to stay connected to the very essence of programming – a constant quest for improvement and understanding. Recognizing that development is a perpetually evolving field, I remain linked to its ever-changing dynamics.

Egoless Programming

Ibrahima D. — Thu, 10 Aug 2023 12:21:55 +0000

In the dynamic landscape of software development, a transformative concept is gaining prominence: "Egoless Programming." Rooted in collaboration and humility, this approach transcends individual ego to prioritize collective success. This article delves into the tenets of egoless programming, its impact on project quality, and its role in cultivating a harmonious development environment. A fresh perspective that could steer developers toward more efficient and fulfilling horizons.

Egoless programming," also known as "programming without ego" in French, is a concept in the field of computer programming that encourages developers to embrace a humble and collaborative approach when creating software. The fundamental idea behind egoless programming is for developers to set aside their ego, biases, and personal desires in order to work together constructively and produce high-quality code.

The key principles of egoless programming include:

Focus on Results, Not Individuals: Emphasis is placed on achieving project objectives rather than seeking personal credit or recognition. Programmers prioritize what's best for the software and its users, rather than their own glory.

Embrace Constructive Criticism: Programmers should be open to feedback and suggestions from peers. They should be willing to challenge their own code and make improvements based on received feedback.

Team Collaboration: Egoless programming promotes effective collaboration and communication among team members. Programmers should be ready to share knowledge and learn from others, rather than monopolizing expertise.

Continuous Learning: Programmers acknowledge that there's always something new to learn and discover. They should be open to continuous learning and skill improvement.

Minimize Code Ownership: Instead of clinging to specific code as if it were their exclusive creation, programmers should encourage code sharing and collective improvement.

Egoless programming can contribute to code quality enhancement, reduce conflicts within the development team, and foster a more positive and collaborative work environment. Ultimately, the focus is on creating high-quality software rather than individual programmer ego.