In the video below, I demonstrate the step-by-step process to update an existing Angular v19 project to Angular v20 using the Angular CLI. I also show you how to create a brand-new Angular v20 app using npx, which allows you to generate the latest Angular project without updating your global Angular CLI installation.

A quick note on terminology: Many developers, especially those new to Angular, casually say "upgrade" when referring to moving between Angular versions. I used to do this as well.

However, the correct term is "update" and it corresponds to the Angular CLI command that performs this process: ng update. When you encounter someone using the term "upgrade" instead of "update," keep in mind this might indicate they haven't actually run the process before. Once you've been running it regularly - especially for an extended period like I have - the distinction becomes ingrained and you naturally use the correct terminology.

Post Update Project Cleanup

After updating your project with the Angular CLI, there are some additional changes you might want to make to fully align with Angular v20 conventions and the new style guide. I’ve created a CLI tool called angular-v20-bulk-file-refactor to help automate this cleanup.

For a step-by-step guide on this refactoring process and tool usage, check out my detailed blog post and video.

https://www.youtube.com/watch?v=jE_4us6PtuY

This process is currently tedious and error-prone when done manually, which is why I created angular-v20-bulk-file-refactor - a CLI tool that completely automates the file renaming and content refactoring process for Angular v20 projects.

The Angular v20 Challenge

Angular v20's new style guide introduced systematic changes to file naming patterns. The guide removes suffixes for components, directives, and services - so user.service.ts becomes simply user.ts, while user-profile.component.ts becomes user-profile.ts. These aren't just cosmetic changes - they reflect Angular's evolving best practices for project organization and maintainability.

The challenge isn't just renaming files. When you rename a file, you also need to update every import statement that references it throughout your entire codebase. Miss one import, and your application breaks. Do this manually across hundreds of files, and you're guaranteed to make mistakes.

What angular-v20-bulk-file-refactor Actually Does

My tool tackles both sides of this problem intelligently. It scans your Angular project and performs two critical operations:

Smart File Renaming: The tool identifies files that need renaming based on Angular v20 conventions. It understands different folder contexts - knowing that a .service file in a services folder should be handled differently than one in a shared folder.

Automatic Import Updates: More importantly, it then searches through your entire codebase and updates every import statement that references the renamed files. This ensures your application continues to work after the refactoring process.

The tool is highly configurable, allowing you to specify which directories to skip, which file segments to replace or remove, and how import statements should be updated. This flexibility means it can adapt to different project structures and naming preferences.

Why I Built This Tool

As an Angular developer who has been updating projects through multiple versions, I've seen how each major release brings its own challenges. But v20 was different - the scope of file-level changes was unprecedented. I realized this was exactly the kind of repetitive, error-prone task that should be automated.

I developed and tested this tool extensively on Windows, ensuring it handles edge cases and complex project structures reliably. Understanding that the Angular community spans multiple platforms, I've also included a Linux binary, though I haven't been able to test it thoroughly yet.

Getting Started

The tool is available on npm and can be installed globally or locally within your project. Once installed, you simply point it at your Angular project directory and let it handle the heavy lifting. The tool includes sensible defaults that work for most projects, but also provides extensive configuration options for specific needs.

You can get the tool at: https://www.npmjs.com/package/angular-v20-bulk-file-refactor

https://www.youtube.com/watch?v=CU79NTqo4Mc

The Bottom Line

Manual file refactoring for Angular v20 is time-consuming and risky. This tool eliminates both problems, handling the tedious work while ensuring accuracy. Whether you're updating a small personal project or a large enterprise application, angular-v20-file-refactor saves hours of work and prevents the frustrating bugs that come from missed import updates.

Before using the refactoring tool, make sure you've completed the basic Angular v20 update process. For guidance on that foundational step, check out my guide on updating from Angular v19 to v20.

Author: Multignite (@multignite)

A Decade of YouTube as a Creative Outlet

I’ve been making YouTube for more than 10 years, hopping between channels and topics without a strict plan. In the last 5 years, my content has centered on coding - raw, real-time programming sessions where I share my workflow as a full-stack developer. I never chased subscribers or monetization. For me, YouTube was about the joy of the process: filming, editing, and crafting visuals that pop. It was a side project, secondary to my primary career as a hands-on full-stack developer.

In recent years, YouTube also became a creative outlet to take a break from the intensive coding I often do on work projects. Even though I still record myself coding in real time, the video creation process -planning, filming, and editing - offers a refreshing change of pace from the focused, high-pressure coding I tackle professionally. But over time, I noticed something unsettling. Being a ‘YouTuber’, which I saw as a fun extension of my skills, gave some people an opening to misrepresent me.

The truth is, my YouTube presence didn’t inherently make me seem less professional - but it was used by people who wanted to paint me that way. They seized the opportunity to frame me not as a skilled developer but as an “unsuccessful YouTuber who hasn’t been able to grow their channel.” They conveniently decided that the area where I had less visible success must be my primary focus, ignoring the fact that YouTube was just a hobby.

My videos literally show me coding in real time, clear evidence of my expertise, yet some chose to twist the narrative to diminish my professional standing. This stung. I’d have people wish me “luck with my YouTube channel,” as if it were my main pursuit. It was baffling - my content was me building software, yet some acted like I was chasing YouTube stardom instead of excelling in my career. These comments, often from acquaintances or professional contacts, felt like they were rooting for a dream I didn’t have, while overlooking my actual achievements as a developer.

The Truth: My Career Speaks for Itself.

Reflecting on this, I’ve realized something crucial: I don’t need YouTube to prove my worth. My career as a full-stack developer stands on its own, with projects, collaborations, and contributions that showcase my skills. My videos were meant to share my workflow, not to build a personal brand or chase clout. But if they’re being weaponized to misrepresent me, they’re not serving the purpose I intended. I’ve also come to see that YouTube isn’t the right platform for me to “prove” anything.

For some, it’s a powerful tool to establish authority or grow a following. For me, it hasn’t been that. My channels never took off, and I’m okay with that - I wasn’t aiming for viral fame. I did it for the love of creating. But now, I’m letting go of any notion that YouTube might validate my expertise. My work as a developer does that just fine.

Will AI Voices Impact Quality or Viewership?

A natural question is whether switching to AI voices will affect the quality of my videos or reduce viewership. Honestly, I don’t think it will have a negative impact - and I’m even curious if it might boost my content. My channels have never garnered huge views, so I’m not worried about losing a massive audience. In fact, I’ve noticed that many videos using AI voices are thriving on YouTube, with polished, engaging delivery that resonates with viewers. I am inclined to think that the change might have a more positive than negative effect. I’m interested to experiment and find out.

But as someone who treats YouTube as a hobby, view count isn’t my top priority. What matters most is providing quality, accurate information in my content, especially in my coding workflows. I’m as devoted to that goal as ever and will continue to ensure my videos deliver value, regardless of the voice delivering the message.

The Voice Cloning Concern and My Big Decision

The final push for this change came from a growing worry about AI voice cloning. With AI tech advancing rapidly, anyone with enough samples of my voice could create a convincing digital replica. Having shared my voice freely on YouTube for years, I’ve essentially been handing out those samples on a silver platter. The risks are serious: a cloned voice could be used for scams, deepfakes, or other malicious acts, potentially damaging my reputation or harming others.

While I can’t erase all of my past content or fully protect myself, I can take steps to limit future risks. This wasn’t an easy call. I love making videos, and using my own voice has always felt personal and authentic. But the potential dangers of voice cloning outweigh the benefits of continuing to share my voice online. Switching to AI voices lets me keep creating while reducing the chance of my voice being misused. It’s not foolproof, but it’s a practical way to move forward with peace of mind.

What’s Next for My Content

As for my existing videos, I have set every video where I used my own voice to private. I may or may not re-edit them with new narration in the future - I’ll only do so if they remain relevant or if I find the time, but for the most part, I’ll focus on creating fresh content. After all, many may be outdated given how rapidly tech evolves and changes.

I’m not walking away from YouTube entirely. I’ll still make videos when the creative urge strikes - video creation is too much fun to abandon. I love the process of filming, editing, and designing, and I’m excited to keep exploring that. But from now on, every video will use an AI-generated voice. This change lets me protect myself while still sharing content on coding and other passions.

I’m eager to play with AI voices and see how they can enhance my videos. With so many options - from natural tones to unique styles - it’s a fresh creative challenge. I’ll keep making content without the pressure to grow a huge audience or turn my channel into a business. It’s still just a hobby, and I’m happy to keep it that way.

Final Thoughts

This shift to AI voices marks a new chapter for me as a creator. It’s bittersweet - letting go of my own voice feels like losing a piece of my authenticity, but it’s also empowering to take control in a world where AI is reshaping how we share ourselves online. YouTube has been a joyful outlet for over a decade, but it’s also shown me how easily a hobby can be twisted to misrepresent who I am. To anyone balancing a creative side project with a primary career, I hope my story resonates.

It’s okay to create for the love of it, without chasing what others perceive as “success.” Success isn’t measured solely by views, money, or external validation. It’s about what feels right to you, and everyone has the freedom to define what success truly means for themselves.

And it’s okay to set boundaries to protect yourself, even if it means rethinking how you share your work. For me, AI voices are a way to keep doing what I love while adapting to new realities. Thanks for reading this long post. If you’ve enjoyed my content (however small my audience may be!), I hope you’ll stick around as I navigate this change. Here’s to more videos, more creativity, and new possibilities.

'𝗩𝗶𝗯𝗲 𝗖𝗼𝗱𝗲𝗿 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿

Just yesterday, I was dealing with another company that had the role of ‘Technical Support Engineer’ - but what they were actually hiring for was - a developer who will also provide support to their customers.

This became obvious through their 1-hour paid Test Task for the Technical Support Engineer role. It started off somewhat reasonable, with written questions focused on how you’d handle customer support scenarios. But there was a second page featuring a surprise coding challenge!

All of the sudden, they were asking the applicant to create a full-stack application using one of their starter kits - which, of course, required creating an account and using their product. It didn’t stop there; they specifically requested building a backend for the app! So, apparently, the "customer support questions" on the first page were just there to ease you in before blindsiding you with developer-level tasks. Were they hoping no one would notice what was happening?

The attempt to push titles like “Prompt Engineer” not long ago highlights the same desperation to repackage roles in a misleading way. The term was hyped as if it represented a groundbreaking new profession, but it quickly became evident that the title was simply being used to disguise a developer’s workload.

Companies slapped “Prompt Engineer” on job postings to make it sound like the work required less expertise, while still demanding high proficiency in programming, scripting, and integrating AI tools.

The result? The role never really solidified because the strategy was transparent - it was obvious the role wasn’t unique or simpler but just another way to undervalue developers by pretending their contributions weren’t as demanding as they actually are. Ultimately, the hype around “Prompt Engineer” faded, as the gimmick failed to stick.

And now, we have today’s Vibe Coder Frontend Developer role, which manages to make things worse. Not only is the title absurd, but the featured image had to include a girl on it! Additionally, the company (or AI) wrote this in the job description:

"We’re on the hunt for a Vibe Coder – a developer who doesn’t just write code but orchestrates it through the power of AI."

I'm not sure whether I should laugh or cry after reading this 🤣

So, in one sentence, they’re trying to redefine both what a developer means and what vibe coding is.

Here’s the thing: I don’t care how you choose to 'word' things - a Vibe Coder is not an upgrade over a Developer!

You’re either a Vibe Coder or a Developer. The two are fundamentally different.

• Developers are experienced professionals, proficient in one or more technologies, depending on their chosen stack.

• A “Vibe Coder,” on the other hand, is not a developer. The closest approximation of a vibe coder is... a prompt engineer.

But since the term Prompt Engineer didn’t catch on too well, it seems someone thought “Vibe Coder” would sound more appealing - or easier to trick people with.

At its core, the concept of “vibe coding” is letting AI do all the work. No developer experience or technical background is required for that because the “vibe coder” is just ensuring the program runs and the AI-generated responses are produced.

You can try working like this if you want - I sincerely wish you the best of luck - but the truth is, AI is nowhere near the level where it can handle everything on its own. It’s not even competent enough for non-developers to run projects relying solely on automation - and we all know it!

Just as we all know, a developer can easily take on the responsibilities of a vibe coder, but a vibe coder cannot take on all the tasks of a Developer. It’s obvious to everyone that when you hire someone with developer experience and say, “I’ll pay you just to do the bare minimum of that experience,” you’re still getting the whole package.

A typical developer spends months, even years, mastering their craft - learning new technologies, honing their problem-solving abilities, and developing a unique mindset capable of handling complex, elaborate troubleshooting. This mindset isn’t something that can just be switched on and off at will, nor is there any logical reason why it should be.

It’s a way of thinking - an instinctive approach to breaking down problems, optimizing processes, and building robust, scalable solutions. Asking a developer to ignore this hard-earned expertise in favor of minimal tasks is like hiring a Michelin-star chef to flip burgers at a fast-food joint.

No matter how simplified the task may seem, the chef’s years of training, precision, and high-level expertise will still influence and enhance everything they do, whether you acknowledge it or not.

And the ones doing the hiring are benefiting from the person’s full skill set while only paying for the basics and pretending that’s all the person brings to the table. This is an obvious misuse of the employee’s potential and a devaluation of their skills and worth.

Reading through the actual job description, it becomes even more obvious they’re looking for developer experience.

For example, it includes statements such as:

"A pro at 'vibe coding' – you’ve got a knack for guiding AI to crank out high-quality code while adding your personal touch."

None of this is vibe coding! What’s being described here is a combination of Prompt Engineering and Software Development. Unless, of course, you’re hiring a Reiki practitioner to “add personal touch” through vibes - resulting in something completely unrelated to development.

Later in the job description, the Preferred Qualifications section includes:

• Experience with Python scripting and automation

• Knowledge of UI/UX principles and responsive design techniques

• Expert working knowledge of CSS frameworks (Tailwind)

• Understanding of cross-browser compatibility issues and solutions

• Experience with testing frameworks and CI/CD pipelines

Again - none of these are requirements for a “Vibe Coder.”

But guess what? They’re all requirements for a

DEVELOPER

What’s happening here is companies are hiring developers under the guise of “less demanding” roles because they’re unwilling to pay for the full value of developer expertise, even though that’s exactly what they’re getting. It's just an attempt to devalue the profession and pay less - it is a win win for them, but not for us!

For me as a developer, there’s an extra hidden downside. If I accept a contract like this on a freelancing platform, in between all my full-stack work, all of the sudden a “Tech Support” or something similar shows up. Even if it’s just one instance among many contracts I’ve completed, it could still be enough for someone to misuse it - to try and label me as suitable for lower-level or unrelated work. This one misstep could pull my career off track, and part of me wonders if companies like the one I mentioned might do this intentionally for that reason.

They’ll probably argue it’s just semantics, so simply ask if the salary is the same - that will tell you everything you need to know. Of course, salary won’t be discussed until it’s convenient for them.

It’s not just one or two companies either. Sadly, more and more companies are doing this, rebranding roles with every new trend or buzzword.

If only they put the same effort into understanding the difference between Java and JavaScript 🤭

What Are LLM Chatbots?

LLM chatbots are conversational AI systems powered by large language models (LLMs), such asOpenAI's ChatGPT, Google’s Gemini, Claude AI and more. They are designed to process and generate natural language, enabling them to engage in human-like conversations, answer questions, and provide insights based on their training data.

Examples of LLM Chatbots:

• ChatGPT

• Google Gemini

• Claude AI

• Perplexity AI

• Microsoft Copilot

• Meta's LLaMA-powered Bots

• YouChat

Key Features of LLM Chatbots:

1. Conversational Specialists: Designed primarily for dialogue-based interactions.

2. Reactive Behavior: Respond to user prompts but lack autonomy or independent decision-making.

3. Text-Centric Functionality: Limited to tasks involving understanding or generating text.

Use Case Examples:

• Customer support bots that help users troubleshoot common issues.

• Tools for drafting emails, articles, or creative content.

• Educational companions for learning new topics interactively.

What Are AI Agents?

AI agents are systems designed to perform tasks autonomously. They combine various AI capabilities, including LLMs, to not only understand inputs but also make decisions and take actions based on specific goals or objectives. Unlike chatbots, they are proactive and task-oriented.

Examples of AI Agents:

• AutoGPT

• AgentGPT

• LangChain Agents

• Zapier AI Agents

• GitHub Copilot for Pull Requests

• AWS DevOps Guru

• Datadog AI

• Kustomer IQ

• Drift Conversational Sales AI

• Cleo AI

Key Features of AI Agents:

1. Autonomy: Operate independently, making decisions without constant user input.

2. Goal-Oriented: Focused on completing specific tasks or solving problems.

3. Integration Capabilities: Often work with external tools, APIs, or environments to achieve objectives.

4. Adaptive Learning: Some agents improve their performance through reinforcement learning or continuous updates.

Use Case Examples:

• Personal assistants that manage calendars, book appointments, and send reminders.

• DevOps tools that monitor system performance and automatically resolve issues.

• Research agents that gather data, analyze it, and deliver actionable insights.

Comparing LLM Chatbots and AI Agents

Why the Confusion?

The confusion arises because AI agents often incorporate LLMs as a component of their systems. For instance, an AI agent might use an LLM to interpret user intent ("Book me a flight to Paris") while relying on APIs to search for tickets and make the reservation autonomously.

In contrast, an LLM chatbot like ChatGPT is primarily a conversational interface. It can assist with information or ideas but won’t independently perform actions unless explicitly programmed to do so.

When to Use What?

Choose LLM Chatbots If:

• You need conversational AI for answering questions or generating text.

• Your focus is on interaction, not task execution.

Choose AI Agents If:

• You require autonomous systems to complete tasks or automate workflows.

• You need AI that integrates with tools or APIs to perform complex actions.

Understanding the Difference

While AI agents and LLM chatbots may seem similar at first glance, they serve distinct purposes. Chatbots excel at natural language interactions, while AI agents are built for autonomy and task execution. Knowing the difference empowers you to make informed decisions and leverage these technologies effectively.

What’s your experience with AI agents or LLM chatbots? Let’s discuss in the comments below!

What is Coder's Block?

"Coder's block" is a term that refers to a mental block or creative slowdown that hinders a programmer's ability to write code effectively, similar to how "writer's block" affects writers. One of the most striking similarities between coder's block and writer's block is the experience of staring at a blank page - or in the case of coding, a blank code editor - especially during a highly stressful situation like a technical interview.

Coder's block can feel like a fear of heights. You might freeze up, unable to move forward no matter how hard you try. It’s not about lacking knowledge; it's a mental paralysis that prevents you from accessing what you already know. Similar to climbing a ladder and reaching a point where you can’t take another step. Coder’s block traps you in that moment of inaction, preventing progress even though you know where you need to go.

At times, coder’s block may also feel like staring at a jumble of characters that suddenly seem foreign. It's as if you’re seeing the code for the first time, and it holds no meaning, leaving you completely disoriented and unable to make sense of it.

Coder's Block During Tech Interviews

During interviews, candidates are often given a blank code editor and asked to write code from scratch under strict constraints. This situation can be particularly stressful because it involves working with vague problem descriptions, abstracted helper functions with unknown implementations, and rules that are rigidly enforced. The challenge is further compounded by the lack of context, which can make it feel nearly impossible to build on the given information effectively. This high-pressure environment can exacerbate coder's block, making it difficult to access the knowledge you already possess and leading to a sense of paralysis.

Coder's Block vs. Lacking Knowledge

How can you tell if you're experiencing coder's block rather than simply lacking the necessary *fundamental knowledge? The answer lies in what happens after the stressful situation has passed.

1. Coder's Block: If, after a period of stress, you find that solutions or large parts of them come to you quickly and seemingly effortlessly, it often indicates that the knowledge required was already there. The challenge was not a lack of understanding but a temporary mental block that impeded your ability to access the information. Once you’ve relaxed and your mind is clearer, the solution becomes apparent, suggesting that your problem was more about overcoming psychological barriers rather than acquiring new knowledge.

2. Lacking Knowledge: Conversely, if you remain puzzled by the problem even after some time has passed, like a day or two, and you continue to struggle with finding a solution or grasping what was required, it’s likely that you are missing some important concepts. This persistent confusion indicates that you need to acquire or deepen your understanding of certain concepts before you can effectively tackle the problem.

Unfortunately, many interviewers don't recognize this distinction, and even fewer know how to help candidates overcome such blocks during the interview itself.

What about Syntax?

Knowing the syntax of a single language doesn’t necessarily reflect a developer's level of experience or mastery. While being familiar with syntax is useful, it doesn’t equate to deep understanding or proficiency in a language.

Those who excel at syntax may be specializing in one language or memorizing syntax specifically for interviews. However, seasoned developers who work with multiple languages often have a deeper grasp of underlying principles rather than just syntax, which can be harder to recall under pressure or during coder's block.

If a tech interview focuses excessively on syntax without allowing the use of pseudocode, it may indicate that the interview values memorization over genuine developer skills.

Why LeetCode Doesn't Help

LeetCode and similar platforms are often touted as essential tools for preparing for coding interviews. In theory, practicing on these platforms should help by building muscle memory.

But let's think about it - if the problem isn’t that you lack knowledge, but rather that your entire repository of knowledge becomes temporarily inaccessible due to stress, then adding more knowledge to that load won’t solve the problem.

It doesn’t matter how much knowledge you have if the problem is that you can’t access it. Therefore, the solution lies elsewhere.

What Could Help Dealing With Coder's Block

Don’t fall into the trap of thinking that you can overcome coder’s block by repeatedly going into interviews, believing that practice alone will make you better at it. I’ve tried this approach, and it doesn’t work.

Instead, you need to first acknowledge that coder’s block is an issue for you, and then take proactive, small steps to deal with it. Jumping blindly into one interview after another can quickly become overwhelming. Understand that dealing with coder’s block is a process, but if you want to improve and manage it effectively, there are proactive steps you can take:

Avoid Tech Interviews That Test Only Memorization Skills:

One of the best ways to deal with coder's block is to avoid technical interviews that focus solely on memorization. These types of interviews often induce coder's block by creating high-pressure situations where the emphasis is on recalling specific syntax or algorithms, rather than demonstrating real problem-solving skills. If you want to dive deeper into why these interviews are problematic and how to steer clear of them, check out my blog post here.

Seek Supportive Interviewers:

Look for interviewers who are supportive and understand the nature of coder’s block. The right interviewer can help you overcome the block by calming you down and working with you through the problem, rather than just watching you struggle. These are the kind of people you want to work with because they foster a collaborative environment. You may start with mock interviews where the interviewer is someone you know and trust, or you can book a mentorship session with me - aimed at helping you overcome coder's block by doing a mock interview in a safe environment.

Recognize When to Step Back:

When you feel coder's block setting in, sometimes the best strategy is to acknowledge it and step back. If possible, ask for a moment to collect your thoughts or suggest tackling another part of the problem. This can help break the cycle of stress and give you a chance to regain control. In real-life coding, you often have the ability to take a break and revisit a problem, so it’s reasonable to seek out interview settings that allow for this flexibility as well.

Dealing with coder’s block requires a thoughtful approach rather than just relentless practice. By avoiding interviews that emphasize memorization, recognizing when you need to step back, and seeking out supportive interviewers, you can create a more manageable and less stressful interview experience.

Remember, it’s not about brute-forcing your way through challenges, but about understanding and addressing the mental barriers that prevent you from showcasing your true abilities. Embrace these proactive steps, and you'll find yourself better equipped to handle coder's block and succeed in your interviews with greater confidence and composure.

*be cautious if interviewers use the term 'fundamental' frequently during the interview. Pay close attention to how they use it, as it can sometimes be employed in a condescending manner to make them seem more knowledgeable or authoritative than they might actually be.

If you’re going to determine my skill level as a developer by merely testing whether I can do something that an AI tool can do, go ahead.

But I’d rather look for opportunities that go beyond that.

Tech job interviews are meant to assess a candidate's suitability for a role, but some outdated practices do little more than create unnecessary stress and anxiety. One of the most glaring examples of this is the interview format where you're handed a blank code editor and expected to solve a problem using an abstracted, unseen function. These types of interviews often test nothing more than your memorization skills - an approach that is not only outdated but also counterproductive.

The Problem with Memorization-Based Interviews

These types of interviews amplify a phenomenon known as "coder's block." This is a situation where, despite your deep understanding and experience with a programming language, you freeze when expected to produce code in a high-pressure environment. The stress of having to recall syntax and solve problems from scratch, combined with the expectation to use a vague, abstracted function, can severely inhibit your ability to think clearly and logically. Instead of assessing your problem-solving abilities, these interviews often become an unfair test of your ability to recall syntax under duress.

The Abstracted Function

A common issue with this interview style is the use of abstracted functions. Interviewers often present these functions as "helper functions," but how much of a help are they really? You're expected to imagine how this function is written without any useful context. This is problematic because, in reality, the function could be implemented in numerous ways, and your interpretation might not match what the interviewer envisioned.

This mismatch creates unnecessary confusion and frustration. Instead of focusing on solving the problem, you're left guessing how the abstracted function behaves. How often, in a real-world job setting, do you have to code in such an isolated, context-less manner? The answer is almost never. In your day-to-day work, you have the context, documentation, and the ability to explore and understand the functions you're working with. This makes the entire exercise of guessing how an unseen function works during an interview both unrealistic and unproductive.

Memorization vs. Real Skills

At the heart of this interview style is the assumption that being able to write the correct syntax from memory equates to a strong command of a programming language. This is a flawed assumption. The ability to memorize syntax does not reflect how frequently you've used it or how well you understand the underlying logic. You might have written a for loop a thousand times, but in the stressful environment of an interview, coder's block might prevent you from writing even the simplest code.

Everyone familiar with programming knows about coder's block. It's a common occurrence during interviews, yet it's often dismissed as a sign that the candidate lacks fundamental knowledge. This is far from the truth. What these interviews are really testing is not your coding ability, but your memorization skills - something that is not, and should not be, a core skill for a developer in an age where tools and resources are readily available to assist with syntax.

And then there are the types of interviewers who will go so far as to claim that if you don’t know basic syntax by heart, you couldn’t possibly understand programming logic, so there’s no point in giving you more complex tasks.

Stay away from those as well, because this is a complete fallacy.

Understanding programming logic and solving complex problems require deep analytical thinking and a strong grasp of concepts - not rote memorization. Logic is about how you approach a problem, break it down, and think through solutions, not about whether you can instantly recall a piece of syntax. Memorizing syntax is just a small, mechanical part of coding, something that can easily be supported by tools or references. Not remembering syntax has no bearing on your ability to handle more advanced concepts; it’s just a weak excuse to prevent further evaluation.

This is what I call 'screening out,' not 'screening in'.

Dealing With Unproductive Interview Practices

If you find yourself in an interview that tests your ability to recall syntax rather than your problem-solving skills, take note of how the interviewers react. There are generally two scenarios:

1. Negative: They might criticize you for lacking 'fundamental' knowledge of the language, completely overlooking the possibility that you’re experiencing coder's block. Instead of adapting the challenge or trying a different form of evaluation, they rigidly stick to the original test, missing the opportunity to fairly assess your true skills. This often stems from the interviewer's own inability to create a new challenge on the spot or their reliance on pre-prepared answers, which limits their capacity to evaluate creative or unconventional problem-solving approaches.

2. Positive: They recognize that you’re experiencing coder's block and offer assistance to help you break through it. They may encourage you to write pseudocode, explore different concepts, or approach the problem from a new angle, which reflects a more understanding and supportive work culture. This response typically comes from a more experienced developer who can adjust and create a new challenge on the fly, demonstrating flexibility and a genuine interest in assessing your problem-solving abilities rather than just your memorization skills.

However, my advice is to stay away from such interviews altogether. They deliberately put you in a disadvantageous position, and there's little to no benefit in putting yourself through that. Instead, seek out interviews that test your ability to work with a codebase, understand logic, and apply your knowledge in practical ways.

Rather than memorizing syntax, focus on developing your problem-solving skills and your ability to understand and work with different approaches to a problem.

If avoiding these types of interviews isn't an option due to financial or other constraints, I also offer supportive free of charge mentorship sessions, and premium mock interview sessions, to help you prepare and adapt while ensuring you're practicing in a safe and constructive environment.

More Effective Option

A far more effective interview format would involve giving the candidate two sets of code - two different implementations - and asking them to choose which approach they would take and why. This method is superior for several reasons.

First, it shifts the focus from rote memorization to critical thinking and problem-solving, which are the true indicators of a developer's skill. By comparing two implementations, the candidate is encouraged to engage with the code at a deeper level, analyzing its logic, efficiency, and appropriateness for the given context. This approach also helps prevent coder's block by providing a concrete starting point, rather than a blank screen that can trigger anxiety and mental blocks.

Moreover, this method tests a candidate’s ability to work with the language in a meaningful way, rather than just their ability to recall and write syntax out of context. It reflects real-world scenarios, where developers often need to evaluate existing code, understand its nuances, and decide how to improve or extend it. In doing so, the interviewee demonstrates not just their familiarity with the syntax, but also their understanding of best practices, design patterns, and the trade-offs involved in different coding approaches. This is a far more accurate measure of a developer's ability to contribute effectively to a team and solve real-world problems.

I strongly believe that memorization is not a skill that developers should be expected to excel at, especially in a world where we have so many tools available to assist with syntax.

If I find myself in an interview that emphasizes memorization in any form, and the interviewer quickly jumps to conclusions without considering potential underlying reasons, I immediately reconsider whether that job is the right fit for me.

If there’s already an AI that can handle the job of recalling syntax and basic functions, why is the company testing whether I can do the same thing?

At this point in time, shouldn’t the value and expectation come from what I can do that the AI can’t ???

Things like creative problem-solving, critical thinking, and working effectively within a real-world context?

We all know that AI, at this point, struggles with understanding and applying context. So why should there be so much overlap in our roles? If we're both expected to do the same basic tasks, it’s no wonder people worry about AI replacing developers.

Instead, why not divide the tasks more sensibly? Let the AI handle the routine, context-free tasks, while we, as developers, focus on what AI struggles with -navigating complex, nuanced problems that require a deep understanding of context and a creative approach.

I prefer to seek out opportunities where my true skills are valued and tested in a realistic and supportive environment, and I encourage others to do the same.

It’s time to rethink how we assess developer talent - let’s focus on what really matters.

In addition, I will offer suggestions for more effective methods of evaluating developers' skill levels, provide guidance to developers on accurately assessing their own skill levels, and explore the potential impact of AI chatbots on the measurement of skill levels.

Main Skill Level Categories

Currently, in the tech industry, developers' skill levels are often categorized based on years of experience, such as:

Junior Developer

• typically has 1 - 2 years of experience

After gaining some experience, entry-level developers typically move up to become junior developers. Junior developers have one or a couple of years of experience and are capable of working on moderately complex projects under supervision. They have a good understanding of programming concepts and may be familiar with more than one programming language.

Mid-level developer

• typically has 2 - 5 years of experience

Mid-level developers typically have a few years of experience and possess a strong grasp of programming concepts. They are capable of working independently on moderately complex projects and require minimal supervision. While proficiency in multiple programming languages is not a requirement, mid-level developers should be proficient in at least one language. Additionally, they may have the ability to mentor junior developers, although this is not a prerequisite for their role.

Unfortunately, some companies do not recognize the mid-level category, and they often label their mid-level developers as juniors, depriving them of the recognition they deserve. Such companies may exploit the developers by paying them less than what they should receive.

Senior Developer

• typically has 5 - 8 years of experience

After several years of experience, a developer can become a senior developer. They can handle complex projects with minimal supervision and have a deep understanding of multiple technologies. They may also have a leadership role within their team and be responsible for mentoring and managing junior developers.

You may be a senior developer but good luck in proving that. Despite your extensive experience and seniority in the field of development, it can be a challenging task to convince companies and colleagues of your true level of expertise. Unfortunately, both employers and coworkers may attempt to keep you at a lower level to pay you less or to feel superior to you.

Staff Developer

• typically over 8 years of experience

Staff developers are senior developers who have additional responsibilities such as managing a team or leading projects. They have a high level of expertise in multiple programming languages and are capable of providing guidance and mentoring to other developers.

Principal Developer

• typically over 15 years of experience

Principal developers are the most experienced and knowledgeable developers in a company. They have a deep understanding of multiple technologies and are responsible for designing and overseeing the development of large-scale software systems. They also serve as technical leaders and mentors to other developers.

Architect/Lead Developer

• typically over 15 years of experience

Architect/Lead developers are responsible for the overall technical design and direction of a software project. They have a deep understanding of multiple technologies and programming languages and have extensive experience in software development. They often lead teams of developers and work closely with stakeholders to ensure the project meets business objectives.

Categories that Should not Exist

Entry-level Developer

• typically has less than 1 year of experience

Associate Developer

• typically has less than 1 year of experience

While some may argue that the label "Junior" is intended to provide developers with guidance and support in the workplace, the truth is that categories such as Entry-level, Associate, and Junior are not truly beneficial to developers.

In fact, companies often use these labels as a means of underpaying their employees. Moreover, the industry's tendency to create increasingly disparaging labels beyond "Junior" only serves to further undermine the contributions and value of developers. Ultimately, these labels only perpetuate a culture of undervaluing and exploiting skilled professionals.

Current Ways of Measuring Skill Levels

Years of Experience

While years of experience can certainly be an important factor in assessing a developer's skills, it is not a foolproof method. It's crucial to recognize that everyone learns and advances at their own pace. Therefore, relying solely on the number of years someone has been working in the field can be misleading. Instead, it's important to consider a developer's actual abilities and accomplishments as a more reliable measure of their skill level. Ultimately, years of experience can provide helpful guidance, but it should not be the only factor considered when evaluating a developer's proficiency.

Credentials

When evaluating a developer's credentials, it's important to keep in mind that degrees, bootcamps, and certificates are just one piece of the puzzle. While these educational achievements can certainly be valuable and demonstrate a certain level of knowledge, they do not necessarily guarantee real-life experience or practical skills. It's entirely possible that a developer who has completed a degree program may not be able to perform as well as a junior developer who has gained hands-on experience through internships or other practical training. Therefore, while credentials can be a useful starting point in assessing a developer's qualifications, it's important to consider a wide range of factors when evaluating their actual abilities and potential for success.

During Interview

The most common ways of measuring developers' skill levels during an interview are:

Theory Conversations

Theoretical conversations can be highly misleading, particularly when the interviewer is not familiar with the work of the developer. Without context or practical application, the ability to memorize and theorize about concepts becomes the focus of the conversation, rather than actual skills and experience.

Furthermore, this approach can be easy to set up, and can potentially embarrass the developer if they are unable to perform as well as expected in a theoretical conversation. It's important to keep in mind that being able to code or program something doesn't necessarily mean that a developer can verbalize and explain it to others.

Coding Challenges

Coding challenges can be problematic as well, especially when there is a time limit. Developers may feel pressurized to perform, and the platform they use may not support all the features needed to implement best practices, limiting their ability to showcase their full potential.

This is particularly true if the platform is outdated or not commonly used in the industry. In such cases, developers may have hands-on experience with more advanced tools and technologies than what the platform allows them to demonstrate, which can be frustrating. (True story)

Moreover, coding challenges are often irrelevant to the actual work that the developer would be doing if hired, leading to a mismatch between the candidate's demonstrated abilities and the actual requirements of the job.

Pair Programming

Pair programming is another approach that some companies use to evaluate developer skills. This involves pairing a candidate with an experienced developer to work on a coding problem together. While peer programming can be semi-effective, as it provides a glimpse into the candidate's problem-solving abilities and collaborative skills, it is still an interview setting that can be stressful for the candidate.

Additionally, the candidate may not be used to the tools or technologies used by the company, which can impact their performance. Moreover, the pair programming approach may not reflect the actual work that the candidate would be doing if hired, and it may not be feasible to use for all candidates due to time and resource constraints. While peer programming is a step in the right direction toward more comprehensive evaluation methods, it should not be relied upon as the sole evaluation method.

A Better Approach

Traditional methods of evaluating developer skill level, such as theoretical conversations or coding challenges, are not always effective. A more comprehensive approach, like letting developers complete actual work-related tasks and evaluating their performance, can provide a more accurate and fair evaluation of a candidate's skills and abilities.

The Hands-On Approach

This approach has several benefits. First, it allows companies to evaluate developers based on their actual performance and abilities, giving them a better understanding of their skill level. Second, it allows developers to demonstrate their skills and abilities without the pressure of theoretical conversations or the risk of being misjudged based on credentials or experience alone. Third, it lets the developer, the company, and the co-workers evaluate if the candidate is a good cultural fit for the team. Fourth, it empowers the developer to determine if the company's work style and values align with their own, and if the team dynamics are conducive to their working style. Fifth, it offers transparency, which can help mitigate the risk of the company misrepresenting the job requirements, work culture, or team dynamics during the interview process.

To implement this approach, companies should give developers a couple of weeks to a month to complete actual work-related tasks. The developer should be paid during this period, and the actual long-term contract can be signed after the evaluation is complete.

This approach is not only beneficial to the company, but it is also fair for the developer. During the evaluation period, the developer can see firsthand the real work and technologies used, which can help them make an informed decision about whether they would like to continue working with the company.

In addition to the benefits outlined above, it's worth considering the time and effort that can be saved by using a hands-on approach to hiring developers. Traditional approaches often involve multiple rounds of interviews, with a great deal of pressure to prove oneself. This can be a time-consuming process, taking several months in some cases. On the other hand, implementing a hands-on approach can be completed in as little as one month. By streamlining the hiring process and focusing on practical skills, companies can save valuable time and resources while identifying top talent more efficiently.

While traditional interview methods such as theoretical conversations or coding challenges can be useful to some extent, they are not always the most effective way to evaluate a developer's abilities, skills, and cultural fit. A more comprehensive approach, like letting developers complete actual work-related tasks and evaluating their performance, can provide a more accurate and fair evaluation of a candidate's skills and abilities. This approach benefits both the company and the developer by ensuring a good cultural fit and a successful long-term hire, and by providing transparency and empowering the developer to make an informed decision about their future with the company.

How Can Developers Accurately Measure Their Own Skill Level

This guide is meant to help developers have a better and more realistic understanding of their own skills.

It's important to note that developers may encounter individuals who try to undermine their skills and value, whether it's colleagues, managers, or potential employers. In these situations, developers need to stand their ground and fight for their rights. Some signs that someone may be undervaluing your skills include:

• constant criticism

• a lack of recognition or opportunities for growth

• being offered lower pay or job titles than what you deserve.

If you suspect that someone is undervaluing your skills, there are a few steps you can take to prove it:

1. Conduct a self-assessment: Conduct a self-assessment of your skills. Be honest with yourself about your strengths and weaknesses and consider seeking feedback from peers or mentors. This can help you identify areas where you need to improve and give you a better understanding of your own skill level.

2. Research industry standards: Research industry standards for different skill levels and job titles. This can give you a better understanding of the skills and experience that are typically expected for different roles. You can use this information to benchmark your own skills and ensure that you're being valued appropriately by potential employers.

3. Ask for specific feedback: When receiving feedback from employers or colleagues, ask for specific examples and details about where you need to improve. This can help you determine whether the feedback is legitimate or whether it's an attempt to undermine your confidence or value.

4. Seek out third-party assessments: Consider seeking out third-party assessments of your skills, such as certifications or independent evaluations. These can provide objective measures of your skills and give you a better understanding of where you stand regarding industry standards.

5. Network and stay informed: Network with other developers and stay informed about industry trends and best practices. This can help you stay up-to-date on the skills and experience that are in demand and give you a better understanding of how your skills compare to others in the industry.

Ultimately, developers need to have a realistic understanding of their own skills and value and to be willing to advocate for themselves when necessary. By taking proactive steps to assess their skills, research industry standards, and seek out opportunities for growth and improvement, developers can position themselves for success in the industry and avoid being undervalued or misled.

Potential Impact of AI Chatbots on Skill Levels

I like to think that there is a possibility that the categories of skill levels for software developers may slowly become less distinct and merge into one category of "skilled developer." It is already difficult to accurately measure skill level, and with more developers using AI chatbots as part of their workflow, this could become even more challenging.

As AI chatbot technology advances, it presents an opportunity for junior developers to accelerate their learning process and receive guidance from an AI chatbot. This could reduce the burden on mid-level developers who previously had to mentor them and enable juniors to advance quickly into mid-level developers.

In turn, mid-level developers may also benefit from chatbots as they can leverage the AI chatbot's support to advance more efficiently toward seniority. With AI chatbots in place, senior developers may not need to closely supervise and guide junior and mid-level developers as they have in the past. This could free up senior developers' time to focus on higher-level tasks, such as strategizing and innovating.

Overall, the use of AI chatbots could blur the lines between different developer roles and enable a more flexible and efficient workflow within development teams.

We should be aware that some companies may take advantage of this blurred line by assigning mid-level developers to junior roles or demoting senior developers to mid-level roles, to save costs on hiring more senior developers.

Some companies may make the false claim that AI chatbots can handle most of the workload, with developers simply supervising them.

I believe that this is a severely misguided assumption that fails to recognize the indispensable role that skilled developers play in designing, developing, and maintaining complex software systems. Such an attitude is not only erroneous but also dangerous because it overlooks the critical human skills and expertise that developers bring to the table.

As AI chatbots continue to evolve, they have the potential to impact how we measure the skill levels of developers and the tasks they are responsible for. With chatbots able to assist and guide developers at different levels, I hope that the distinctions between junior, mid-level, and senior roles become less rigid.

This could lead to a shift towards a more flexible and dynamic model of development, where developers are valued for their overall skill set and ability to adapt and learn new technologies quickly. In such a scenario, the traditional categories of skill levels may gradually merge into one larger category of a "skilled developer."

However, it is important to note that skilled developers are still going to be in demand and having a broad range of skills and knowledge will continue to be essential for success in the industry. While AI chatbots may change the way we think about developer roles and skill levels, they are unlikely to replace the need for skilled developers altogether.

My Conclusion

I think that all of these categories and divisions are a bunch of unnecessary BS.

I divide developers into two simple categories:

• those who enjoy programming and are loyal and devoted hard workers.

• and those who are in it for bragging rights and spend more time gossiping and procrastinating than coding.

I believe that AI chatbots could slowly wean out the latter group and leave behind the truly dedicated and skilled developers who will excel and progress faster.

However, the pseudo-developers will surely put up a good fight and make it harder for the devoted ones, as they have been doing in the past.

Nevertheless, I encourage devoted developers to stay focused, keep up their hard work, and not be discouraged by the challenges that lie ahead. With their commitment and passion for programming, they will undoubtedly stand out and thrive in the industry, while the others will eventually fall behind.

%chatgpt

In this blog post, I'll explore a common cause of this issue and provide a straightforward solution to get your SCSS bracket colorization back on track.

The Problem

You've been diligently working on your SCSS code, but suddenly, you notice something's off – all your brackets are appearing in plain white, without any colorization as expected. This unexpected change can be frustrating, particularly when you heavily rely on visual cues to swiftly identify code blocks and structure within your SCSS files.

The Cause

The root of this issue often stems from conflicts or errors within your settings.json file in Visual Studio Code. This file serves as a central configuration hub for your editor, housing various settings and preferences that dictate its behavior.

The complexity of this problem arises from the dynamic nature of the settings.json file. As you work with Visual Studio Code, extensions you install can add their own rules or configurations to this file. Additionally, any manual changes you make to the editor settings can also result in lines being added or modified within settings.json.

This accumulation of rules and settings, while individually benign, can lead to conflicts or unexpected behavior when they clash with one another. An innocuous extra comma, an unused rule, or an empty section can trigger a cascade of unintended consequences, such as the loss of bracket colorization in SCSS files.

The Solution

To fix the SCSS bracket colorization issue, follow these steps:

1. Open Visual Studio Code

2. In the menu bar, go to File > Preferences > Settings (or press Ctrl + , on Windows/Linux or Cmd + , on macOS).

3. This opens the settings interface. In the search bar type settings

4. Then click on Edit in settings.json

5. Identify and and fix the errors

Using an AI Tool

If you're unsure about potential errors in your settings.json file, you can try using an AI-based tool to detect them. Keep in mind that this process may require a couple of attempts, as it can be tricky to identify subtle errors.

In my case, the problem was with these lines:

"editor.codeActionsOnSave": {},
"editor.language.brackets": [],

These sections are empty and don't specify any configurations. This could lead to unexpected behavior or conflicts with other extensions. You should either remove such empty sections or provide relevant configurations within them.

In essence, the settings.json file acts as a delicate ecosystem where each line contributes to the overall behavior of Visual Studio Code. When this ecosystem is disrupted by conflicting rules or errors, it can manifest in visible issues like the loss of bracket colorization. Understanding and managing the intricacies of this file is crucial for maintaining a smooth and efficient coding experience in Visual Studio Code.

Don't let SCSS bracket colorization issues slow you down. With the right configuration tweaks, you can enjoy smooth and efficient coding sessions in Visual Studio Code.

Happy coding!

However, what transpired next left me contemplating the dynamics of conversations about personal achievements. Without acknowledging my recent accomplishment, another lady at the table, situated right next to my mom's ex co-worker, posed a question that caught me off guard: "And what did you study before?"

The immediate shift in focus from my latest achievement to a past endeavor raised an important point. It struck me how some conversations tend to dwell on the past rather than celebrating the present and future. This individual's inquiry seemed to imply that what I had done before held more significance, despite the fact that we naturally progress, move forward, and achieve greater milestones over time.

The dialogue continued along similar lines when I shared my five-year tenure as a software developer. Once again, the same lady interjected with, "Oh, and what was your job before?" It was at this moment that I felt a surge of frustration, almost reaching the point of wanting to react impulsively.

Nevertheless, I opted for the path of politeness and provided a detailed response. Reflecting on this experience, I now realize the importance of not letting such questions dictate the narrative of our accomplishments. There is a lesson to be learned about disengaging gracefully, redirecting the conversation to the present and future rather than delving into lengthy explanations about the past.

In situations like these, a dismissive response could be a powerful tool to steer the conversation away from the past. Simply stating, "What it was, it was, and it will never be," or emphasizing, "I have not done anything illegal," can effectively shut down inquiries about the past. This strategy not only preserves the focus on current achievements but also communicates a strong message about the irrelevance of revisiting past endeavors.

Furthermore, the power of words extends beyond the immediate conversation. Expressing oneself about the past, especially in response to unnecessary inquiries, can inadvertently pull attention away from the present. The words we use shape our reality, and by avoiding the verbalization of past experiences that hold no relevance, we can maintain a narrative that aligns with our current accomplishments and future aspirations. Choosing words wisely is a means of asserting control over our narrative, allowing us to project confidence and focus on the remarkable milestones we continue to achieve in the present moment.

In essence, there is a valuable lesson here: we should not allow ourselves to be pulled back into a stage where we were less accomplished. Questions about past endeavors, especially when they hold no relevance to the present, deserve responses that redirect focus to the here and now. By adopting a strategy of deflection and emphasizing personal growth, we can encourage others to appreciate and celebrate our current achievements rather than dwelling on the past. After all, we are shaped by our journey, but the emphasis should always be on the remarkable milestones we continue to achieve - not on one or a few things we did once that are out of context or hold minor significance.

Explore with me as I break down the process
into the following steps:

📂 Choosing a git repo and opening it locally
🛠️ Creating a netlify.toml file
📦 Adding the build to prod command to package.json
🚫 Removing the /dist folder from .gitignore
🚫 Removing the subdirectory after the dist/ in angular.json
🔄 Adjustments if working with Angular v16 or prior
🔄 Adjustments if working with Angular v17 or higher
🏗️ Building the app for production
📤 Pushing the changed files and the dist folder to Git
🌐 Adding a new site on Netlify - import from GitHub
🚀 Deploying

https://youtu.be/nADnC-esRjc

Ready to streamline your deployment process? Let's make deploying Angular Frontend a breeze!

In this video, I'm thrilled to share my typical Full Stack Development workflow, showcasing the creation of a frontend using Angular v17 for the 'Users' endpoint in a REST API I previously developed with Node.js and Express.

The purpose of my REST API is to serve dummy data, which can be visualized in many ways, making it ideal for testing, prototyping, and exploring creative possibilities.

Video key topics:

💻 FRONTEND:
🅰️ Creating an Angular app
🎨 Adding Angular Material UI
➕ Adding the HttpClient
📚 Defining a service & interface
👥 Fetching & Displaying users

🧱 BACKEND:
🌐 Endpoint Customization
🔄 Adding an 'Active' Property for Users
🖼️ Adding Image Source for Users

https://youtu.be/p6rstIwX17M

Users Website Live Site

my REST API Live Site

Beyond the mere speed of thought, multilingualism amplifies the richness of personal expression. Each language becomes a palette, allowing individuals to paint their thoughts with a spectrum of shades. Certain emotions and concepts find more precise and nuanced expression in one language over another, offering a profound depth to the multilingual experience.

Multilingualism and Programming

The cognitive benefits of multilingualism extend seamlessly into the world of programming, providing a unique set of skills and perspectives.

1. Problem-solving Agility: Multilingual individuals develop cognitive flexibility that translates into problem-solving prowess in programming. They approach coding challenges with diverse perspectives, drawing on a repertoire of problem-solving techniques ingrained in each language.

2. Efficient Code-switching: Just as they seamlessly shift between languages in conversation, multilingual programmers excel at code-switching between different programming languages. This adaptability allows them to choose the most suitable language for a specific task, optimizing efficiency and readability in their code.

3. Cultural Sensitivity in Coding: Multilingualism fosters cultural sensitivity, a valuable trait in a globalized tech landscape. Understanding the cultural nuances embedded in programming languages facilitates effective communication and collaboration, creating a more inclusive and productive development environment.

Challenges and Benefits

However, the multilingual journey is not without its challenges, notably in the realms of spelling, grammar, and response dynamics.

1. Linguistic balancing act: the more languages one is fluent in, the greater the probability of encountering spelling and grammar challenges. This arises from the intricate web of linguistic structures, syntax, and grammatical rules that differ across each language. Essentially, the cognitive load of managing varied linguistic nuances increases with each language added to one’s repertoire. As a consequence, multilingual individuals may find themselves treading carefully to maintain accuracy and precision in spelling and grammar across these diverse linguistic landscapes.

2. Typing: For multilingual individuals the typing process is influenced by the inherent speed of their thought processes. As they swiftly move between languages, the heightened typing speed can lead to occasional occurrences where letters are typed slightly out of order, despite the intended word retaining the same letters. This intersection of linguistic versatility and rapid typing dynamics adds a layer of complexity to the multilingual experience, highlighting the delicate balance required when expressing thoughts across different linguistic frameworks.

3. Delayed responses: Multilingual individuals often experience delayed responses, not due to a lack of mental activity, but precisely because of the abundance of optional responses they consider. This surplus of linguistic possibilities, particularly evident when showcasing programming abilities, can make the assessment process more challenging. In environments that prioritize swift responses, the nuanced decision-making involved in navigating various programming languages might be misunderstood. People’s initial assumption, when faced with a delayed response, might be that the individual lacks options or is not familiar with the topic all together. However, in reality, the multilingual candidate is engaged in a rapid-fire mental process of evaluating and dismissing multiple coding solutions, a testament to their agile and diverse thought processes. Recognizing this dynamic is crucial for a fair evaluation of a multilingual programmer’s abilities.

Communication and Learning Dynamics

In the realm of communication, multilingual individuals exhibit a preference for interacting with others who share a similar, slightly faster pace of speech. This synchronicity not only enhances mutual understanding but also fosters a sense of linguistic kinship. Likewise, when it comes to learning and absorbing information, multilingual individuals often gravitate towards content delivered at a pace that mirrors their own. Verbal information imparted at a pace aligned with their thought speed tends to resonate more effectively, facilitating a smoother absorption of knowledge. This nuanced preference underscores the interconnected nature of thought, speech, and the receptivity to information for those fluent in multiple languages.

The intricate interplay of language, thought, and expression underscores the diversity of the human mind. The multilingual experience, with its variations in thought speed, nuanced expression, and even occasional linguistic challenges, serves as a compelling reminder of the unique cognitive landscape each individual possesses. It is paramount to recognize that there is no one-size-fits-all approach to evaluating someone’s knowledge or capabilities. Our diverse thought processes, shaped by factors like language proficiency, defy simplistic assessments. As we embrace the rich tapestry of linguistic and cognitive diversity, let us refrain from making assumptions about others based on superficial measures. In understanding and respecting these differences, we foster an environment that appreciates the unique strengths and perspectives each individual brings to the table.

In this video, I explore:

🔃 Angular v16 app & Angular v17 app side by side
📂 File Structure
🧩 Components
🛣️ Routing
🌐 HTTP Client
💉 Injecting Services
🎨 Angular Material UI
🔃 The New Control Flow
🔃 @for in Parent to Child component template example
⏰ Deferrable Views
🔃 Updating to Angular v17
🛠️ Build, Rendering & Deployment

https://www.youtube.com/watch?v=HSkP1bD96n0

Join me as I share the challenges and triumphs of breaking through limitations. Subscribe for insights into balancing work, battling imposter syndrome, and the value of formal education in the tech world. 🎓💻

Video

https://youtu.be/aktM3dvpKiU

Topics that I learned in more depth:

• Full Stack Development

• Abstract Data Types (ADT)

• Data Structures & Algorithms (DSA)

• Python

• Signed and Unsigned Integers

• Network

• Website Security

  List of all the 36 courses

https://www.youtube.com/watch?v=fWDjzuecmDg

Building with the "--standalone" Flag

Creating a module-less application in Angular v16 is achieved through the use of the --standalone flag. This flag is applied during the initial building process of the application using the command "ng new app-name --standalone". This directive allows the creation of an application where components stand on their own, without any associated modules. This leads to a leaner codebase by eliminating the additional complexity that comes with managing multiple modules.

Working with Standalone Components

Standalone components are independent units, each encapsulating its own logic, template, and styles. There is no need for a NgModule to define their dependencies or declarations. This kind of architecture deviates from the traditional module structure, promoting a more flexible, maintainable approach. Standalone components enhance code reusability and isolation, fostering a more robust application structure.

Simplified Lazy Loading and Routing

Standalone applications streamline lazy loading and routing. The absence of a module simplifies routing configurations, making them more direct. Lazy loading also becomes more efficient, as each standalone component can be loaded individually when needed. This improves application performance and quickens load times, thereby improving user experience.

Routing: StackBlitz vs Desktop IDE

During the development of the standalone application on StackBlitz, an extra file, app.routes.ts, was automatically generated. However, despite this addition, the routing functionality did not operate as expected within this environment. To troubleshoot, I replicated both approaches - with and without the app.routes.ts file - on my desktop IDE. Contrary to the experience on StackBlitz, the routing worked flawlessly on the desktop IDE, regardless of the presence of app.routes.ts. The reason for this discrepancy on StackBlitz remains unclear, highlighting that the choice of development environment can sometimes have unexpected implications when working with standalone applications in Angular v16.

The Benefits of Standalone Application Structure

As a developer who has been immersed in the structured world of Angular modules, the shift to a standalone, module-less architecture was a change of pace. However, after experiencing it firsthand, I can confidently say that the benefits are substantial. The standalone application structure provides flexibility, simplicity, and maintainability. It reduces overhead, simplifies component management, and ultimately leads to cleaner, more efficient code. For Angular developers looking to optimize their coding practices, this new perspective on Angular application structure is worth trying.

Git global setup -

git config --global user.name "Multignite"
git config --global user.email "<youremail>"

*please replace "Multignite" with your name.

Quick setup — if you’ve done this kind of thing before

…or create a new repository on the command line

echo "# <project-name>" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/<username>/<repo>
git push -u origin main

…or push an existing repository from the command line

git remote add origin https://github.com/<username>/<repo>
git branch -M main
git push -u origin main

…or import code from another repository

Setting up a GitLab Repo

Command line instructions

You can also upload existing files from your computer using the instructions below.

Git local setup -

if you already have GitHub set as global, omit the --global tag when adding GitLab and vice versa.

git config user.name "Multignite"
git config user.email "<youremail>"

*please replace "Multignite" with your name.

Create a new repository

git clone https://gitlab.com/<username>/<repo>
cd appointmentscheduler-c969
git switch --create main
touch README.md
git add README.md
git commit -m "add README"
git push --set-upstream origin main

Push an existing folder

cd existing_folder
git init --initial-branch=main
git remote add origin https://gitlab.com/<username>/<repo>
git add .
git commit -m "Initial commit"
git push --set-upstream origin main

Push an existing Git repository

cd existing_repo
git remote rename origin old-origin
git remote add origin https://gitlab.com/<username>/<repo>
git push --set-upstream origin --all
git push --set-upstream origin --tags

Renaming origin to gitlab for clarification

For the script to work there has to be some difference between the two origin repos that you are pushing changes to. In my case, since GitLab was added after GitHub which is my primary version control, I did the following:

git remote rename origin gitlab

see more below.

Creating a Script to add ., commit and push to both repos

In the root directory of your project, create a file named something like

git-push-all.sh

The contents of the file should be something like this:

#!/bin/bash

# Add all changes
git add .

# Commit changes
git commit -m "Update: $(date)"

# Push to GitHub
git push origin main

# Push to GitLab
git push gitlab main

This is the simpler version of the script, assuming that you want to link the same directory with two repos - one on GitHub and one on GitLab.

However, there are different cases - in my case, I had a main directory with many projects which was already connected to a repo on GitHub and what I wanted to do was to connect only one of the sub-directories - only a specific project, to a GitLab repo.

So in a case like this the git-push-all.sh can be modified like this:

#!/bin/bash

# Add all changes
git add .

# Prompt for a commit message
read -p "Enter a commit message: " COMMIT_MESSAGE

# Commit changes
git commit -m "$COMMIT_MESSAGE"

# Push to GitHub
git push origin main

# Navigate to GitLab subdirectory
cd "path/to/gitlab/subdirectory"

# Add changes in GitLab subdirectory
git add .

# Commit changes in GitLab subdirectory
git commit -m "$COMMIT_MESSAGE"

# Push to GitLab
git push gitlab main

This way one script can handle both repos from the same place - the root directory. This version also allows adding a custom message that will be applied to both commits, and you type it without the quotes :)

Making the script executable

The final step is to make the script executable, so in a bash terminal run the following line of code:

chmod +x ./git-push-all.sh

Now you should be able to run ./git-push-all.sh in your terminal, in Visual Studio Code for example, you will get to type your message and you will have the new commits showing in both of your repos.

Happy Coding :)

In this blog post, I'll explore the differences between these concepts and how they can be applied in software development. By the end of this post, you'll have a clearer understanding of how design principles, design patterns, and app architecture work together to create software that meets the needs of users and developers alike.

What are Design Patterns?

Design patterns are specific solutions to common problems that software developers face when designing and building software applications. They are typically applied at the object-oriented programming level and provide a common language and structure for solving recurring design problems.

Examples of design patterns include the Singleton pattern, the Factory pattern, the Observer pattern, and the Strategy pattern. Each of these patterns provides a solution to a specific problem that developers commonly encounter when building software.

• The Singleton pattern provides a solution for ensuring that there is only one instance of a particular class and that it can be easily accessed throughout an application.

• The Factory pattern, for example, provides a way to create objects without exposing the creation logic to the client

• The Observer pattern allows objects to be notified of changes in other objects without being tightly coupled to them.

• The Strategy pattern provides a solution for implementing different algorithms or behaviors within an object while keeping them interchangeable at runtime.

Design patterns are useful because they provide a way to standardize solutions to common problems, making it easier for developers to communicate and collaborate on software projects. They also make it easier to maintain and extend software applications over time, because the solutions they provide are proven to work in a wide range of scenarios.

What are Design Principles?

Design principles are general guidelines or best practices that help developers create code that is maintainable, extensible, and scalable. They are focused on the code-level design decisions that developers make when writing individual functions, classes, and modules.

Examples of design principles include the Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP). Each of these principles provides guidance on how to design code that is easier to understand, modify, and extend.

• Single Responsibility Principle (SRP): Ensures that a class has only one reason to change, which makes it easier to understand, modify, and test.

• Open-Closed Principle (OCP): Encourages developers to design code that is open for extension but closed for modification, which makes it easier to add new functionality without breaking existing code.

• Liskov Substitution Principle (LSP): Ensures that objects of a superclass can be replaced with objects of a subclass without affecting the correctness of the program, which makes it easier to maintain and extend.

• Interface Segregation Principle (ISP): Encourages developers to create small, focused interfaces that are specific to the needs of clients, which makes it easier to understand and use interfaces.

• Dependency Inversion Principle (DIP): Encourages developers to depend on abstractions rather than concrete implementations, which makes it easier to change implementations without affecting the rest of the code.

By following design principles, developers can ensure that their code is more maintainable, meaning it is easier to update and fix bugs over time. They can also ensure that their code is more extensible, meaning it can be easily adapted to new requirements without requiring major changes. Design principles are essential for building software that is efficient, scalable, and maintainable.

App Architecture

App architecture (application architecture) refers to the overall structure and organization of a software application. It includes decisions about the components of the application, how they interact with each other, and how they are deployed. App architecture typically involves a high-level view of the system and focuses on issues such as scalability, performance, and maintainability.

Examples of app architecture patterns include the Model-View-Controller (MVC) pattern, the Microservices architecture, and the Event-Driven architecture. Each of these patterns provides guidance on how to structure an application in a way that is efficient, scalable, and maintainable.

• Model-View-Controller (MVC) pattern: Separates an application into three interconnected components - model, view, and controller - which makes it easier to manage complexity, modify and extend the application.

• Microservices architecture: Splits an application into a set of independent, smaller services that can be developed, deployed, and scaled independently, which makes it easier to build and maintain large, complex applications.

• Event-Driven architecture: Uses a system of loosely coupled components that communicate with each other through events, which makes it easier to build scalable, reactive applications that can respond to changing conditions in real-time.

App architecture is important because it provides a framework for organizing and managing complex software applications. By following app architecture patterns, developers can ensure that their software is easier to understand, modify, and extend. They can also ensure that their software is more scalable, meaning it can handle larger workloads without sacrificing performance.

Conclusion

Design principles, design patterns, and application architecture are three essential concepts that every developer should have a solid understanding of in order to create high-quality software applications.

• Design principles provide a set of guidelines for creating software that is easy to understand, modify, and extend.

• Design patterns provide a reusable solution to common software problems, enabling developers to write code that is more efficient and maintainable.

• App architecture provides a high-level view of how different components of an application work together to achieve a common goal.

When combined, these three concepts help developers create software that is not only functional and efficient but also easy to maintain and scale over time. By incorporating design principles, design patterns, and app architecture into their development process, developers can build software that meets the needs of both users and developers, resulting in a more satisfying and successful software application.

After completing the challenge, I had a video conversation with Juan. During our conversation, I showed him what I did to complete the coding challenge. We discussed some of the differences between vanilla JavaScript and Angular.

Our conversation was not just about the coding challenge, but also about the broader differences between vanilla JavaScript and Angular. We discussed the approaches to data handling and DOM manipulation in both technologies, and how Angular provides a more efficient way of developing web applications.

It was interesting to see how our backgrounds in development allowed us to share knowledge and learn from each other.

Toward the end of our conversation, we explored ChatGPT in the field of web development. We tested the accuracy of the answers provided by ChatGPT for questions related to web development and programming.

https://www.youtube.com/watch?v=3oAgpqxXHKI

REPO

Did I get a job offer from that company?

Despite fulfilling every requirement of the coding challenge, and going above and beyond by meticulously matching the colors of the provided image using Photoshop's eyedropper tool, I was not offered the job.

The lack of transparency and constructive feedback during the process was frustrating. It was only after I specifically asked that I was informed of the reasons for not being selected:

• the number of my commits (they insisted that it could have been done with fewer commits - no shit, yeah it could be done with one commit really, everything could be done with one commit)

• the language of my commits (it wasn't official enough for them apparently, but they are not even paying me for that work)

• a section of my code that was copied for me to see. (yeah as if I do not know what my code looks like)

No constructive feedback was provided to help me improve for future opportunities. I believe that if someone makes a point, they should be able to support it with examples and offer suggestions for improvement. Without constructive criticism, feedback can be hollow and not beneficial.

Nevertheless, I am grateful for the experience, and it has taught me to be mindful of companies that do not value transparency and constructive feedback.

Leaving all the corporate bullshit aside - my conversation with Juan was a valuable learning experience that allowed me to share knowledge of vanilla JavaScript and capture insights from our experience in Angular development. Our discussion on the differences between the two technologies, as well as the exploration of ChatGPT, provided us with a deeper understanding of the potential of these technologies in the field of web development.

By adding an emoji to your first name, you're essentially creating a quick and easy filter for your inbox. If a recruiter messages you with the emoji in your name, such as "Hi 🖥️ Multignite" you'll know right away that it's probably not a genuine outreach. It might seem like a small detail, but it can save you time and energy by helping you prioritize which messages to respond to.

This tip is especially useful for tech professionals, who are in high demand and may receive a lot of unsolicited messages from recruiters. By using an emoji in your name, you can easily identify which messages are worth your attention and which ones can be ignored or deleted.

'Add an emoji to your first name. When a recruiter messages you with the emoji in your name, "Hi 🖥️ Katy, " you know it's not a genuine outreach. lol'

Matthew Palmer, a Full Stack software developer, came up with the clever advice to add an emoji to your first name. His insight into the hiring process and how to filter out unwanted job offers or recruitment messages have been shared on LinkedIn, offering valuable advice to tech professionals. His innovative thinking and practical solutions showcase his valuable contributions to the tech industry.

More about Matthew :

• LinkedIn

• GitHub

Adding an emoji to your first name is a clever and practical way to filter out unwanted job offers or recruitment messages. It's a small detail that can make a big difference in managing your inbox and prioritizing your time. So if you're a tech professional looking to streamline your job search process, give this tip a try and see how it works for you!

%chatgpt