DEV Community: Kevin Hicks

How To Use Your Manager’s Help To Get Promoted as a Software Engineer

Kevin Hicks — Sun, 09 Oct 2022 17:36:35 +0000

Many software developers I chat with don’t take advantage of the assistance their manager can provide to help them advance in their career.

Being promoted as a software engineer can be a challenge. Even if you are the most talented developer and hardest worker on your team, there are no guarantees that you will be promoted. A big blocker to being promoted is not letting your manager know you want to be promoted and getting their advice and feedback.

Moving up the software engineer’s career ladder isn’t only about your coding abilities.

Other talents, such as mentoring, teaching, planning, and explaining technical concepts to nontechnical individuals, come into play. Or you may need to complete some projects or duties that aren’t part of your regular responsibilities. Unfortunately, reading books, asking for advice online, and other general advice might not help you get promoted where you work, as every company has different requirements.

Working closely with your manager is one of the best ways to learn what you need to do to advance to the next level.

The first step is to talk with your manager about your career goals.

Be upfront and honest about what you want and where you see yourself in the next few years. Being open with your manager will give them a better sense of where you want to go and how they can help you get there.

Your manager may be able to give you specific assignments that will help you develop the skills you still need.

For example, if a requirement for promotion to senior software engineer is you need to be able to lead teams but lack experience leading a team, your manager may assign you to lead a small project. This will allow you to prove that you have the skills to take on a leadership role.

Additionally, your manager may be able to help make sure you are aiming for the correct position for you.

I always thought I would want to be a manager, which would be the best way for me to move up. Talking with my manager about my career goals, he was able to help me realize that I may not like being a manager. He knew how much I liked to code and that I may not like the day-to-day life of a manager.

Now settled into a software architect role and seeing more of what managers do every day, I know he was 100% right. I would have regretted being a manager.

Ask for feedback and then act on it.

Feedback can be difficult to hear, but it is essential if you want to grow and develop in your career. It is not enough to ask for feedback from your manager; you also need to take that feedback and use it to improve your performance. Remember, your manager wants you to succeed and will only give constructive criticism to help you reach your potential.

If you are doing a good job, your manager may not give you anything but positive feedback if you don’t ask for more.

Many managers are always keeping team morale in mind. They don’t want to upset a good developer with constructive feedback (which is sometimes taken negatively) if the developer is doing a good enough job for their current role. The feedback they are willing to give will change if you ask for it.

I made asking for feedback a normal part of my check-ins with my manager for my entire career.

During my bi-weekly check-ins, I would ask what I could do better and what I needed to do or improve to get to the next rung of the career ladder. Over the years, my feedback changed based on my experience, skills, and the next position I was shooting for. Whether it be to do more of something I already did, to improve a skill, or start doing new tasks he always had something specific to help me go to the next level.

I don’t believe I would be where I am if I didn’t regularly ask for this feedback.

Start and share a brag sheet with your manager.

A brag sheet is simply a document that lists out all of your accomplishments. Julia Evans has an excellent article about them you should read to learn how to write one. You aren’t going to remember your accomplishments as time goes on. Even worse some of your accomplishments might go unnoticed by your manager. Your manager is also unlikely to remember your accomplishments come review time with everything else on their plate and an entire team to evaluate.

A brag sheet is a way to keep track of everything you have done, so when it comes time for performance reviews you have a reference to why you should be promoted.

The brag sheet should include both your small and big accomplishments. It can include the times you helped a peer overcome a problematic bug, the extensive rewrite you led over the finish line, or the small lunch and learn you did to teach your team a new concept. You don’t want to leave small, or team accomplishments out as those may be the crucial things for you to get promoted.

Your manager can also use brag sheets to help them push for you to be promoted.

At many companies, a manager can’t move you to a new position without approval from other managers or their manager. Committees approving promotions become more common as most developers become more senior. A brag sheet is one way your manager can make a case for you to get promoted to these committees.

It is never too late to start a brag sheet and you should maintain it throughout your entire career.

I started mine after over a decade in the field, and it was difficult to remember even the biggest accomplishments that happened just a few years ago.

It may not be easy to talk to your manager about your career goals and ask them for feedback.

Many people may feel it may come off as asking for a promotion. Your manager will appreciate the initiative. Many managers are always looking to help their employees reach their career goals and are happy to hear employees want to move up in their current company.

Taking the steps to get your manager’s help will only help you move up quicker.

4 Reasons Why You Need Code Reviews

Kevin Hicks — Fri, 24 Dec 2021 14:46:45 +0000

Our code works after a middle-of-the-night hotfix…do you still need reviews?

If you are newer to programming or work for companies that don’t do reviews, you may be wondering why code reviews are so critical.

This question is more likely if you already have automated testing or a QA (Quality Assurance) team. Code reviews are necessary as they offer multiple benefits that help improve your code and your team. These benefits include:

Helping reduce bugs and logic errors
Providing an opportunity for training
Spreading knowledge across areas and teams
Revealing new ideas and techniques

Let’s take a closer look at each of these.

Code reviews help reduce bugs and logic errors.

One of the main things a reviewer should be looking for when reviewing code is that the code does the right thing without any errors.

I can’t tell you how many times a reviewer saved me the headache of debugging an issue by pointing out bugs they found during a review. I was very thankful to them.

It may seem like it would be hard to find bugs while reading code, but as developers become more experienced reviewing code, issues will start to stand out.

Even with QA and automated testing, finding bugs during a code review is helpful.
Take a second to think about a project with automated testing but no code reviews. How do you know a test is correct if you do not review the code? It is all too easy to make the same mistakes in automated tests as actual code.

Reviews help verify the code and tests are both correct.

A code review can direct the developer to the exact area of the problem, making it easier to debug and fix.
Would you rather have to work through a vague bug report to reproduce a bug or a reviewer point you to the exact line of code that is an issue? It is harder to debug off of a bug report. When we get a bug report, a user is already affected by the problem. I don’t know any developers who like fixing urgent user bugs.

Reviews are just one more step we can use to help avoid stressful after hour bugs.

Reviews offer opportunities for training.

We all know how quickly the technology around us changes. It isn’t that much of a stretch to say that there is a new language, tool, or framework every day. We also learn new best practices, standards, and ways to do things as we gain more experience.

There is always something new to learn.

How do you keep all the developers on your team up to date with these changes?
Of course, there are courses, tutorials, blogs, your team wikis, and guides out there. Developers should continue to use these resources and learn from them. But do you have time for every developer on your team to always go through a course?

Are they going to remember everything from them?

I can honestly say the most I have ever learned about writing good code has come from code reviews.
I have taken many great courses, got a computer science degree, and stayed up to date with many blogs and resources. However, none of these resources have come close to what I learned by working with my team and having my code reviewed.

I have to credit my team’s reviews for any high-quality code I write today.

I honestly learned more in a few months from code reviews than I did through years of courses. There are a lot of fantastic resources that do a great job of teaching software development. But they have to cater to a massive audience and can’t cater their lessons to your project, code, and your skills.

Code reviews are excellent at addressing these flaws.

Code reviews will focus on your team’s code and workflows while naturally raising areas you need to improve.
You will get feedback on your code for specific things you may need to practice or research more. When I notice the same comments coming up in reviews, I’ll read more about the topic or work with one of my peers that I know are experts on that topic. Other times the comments are enough to learn what I need to without additional resources.

Learning from code reviews is a natural result of effective review comments.

In addition to learning from comments on your code, just reading another developer’s code is a great way to learn.
Reviewing another developer’s code will show you new ways of approaching problems, how different developers architect and design features, and expose you to various packages, tools, and technologies.

Seeing how other developers code is one of my favorite things about performing code reviews. I’m often inspired to go back and use things I see developers doing in reviews in my code.

Code reviews spread knowledge across areas and teams.

If you had two teams of developers who always worked together and reviewed each other’s code versus two groups of developers who never reviewed the other team’s code, who do you think will have better code in the long run?

It probably will be the teams that review each other’s code. Those two teams will be passing knowledge back and forth about their specific areas and the best way to do things. They will be learning from different experiences and projects.

It’s essential someone familiar with the project still reviews the code, but getting someone from outside the team as a reviewer only helps.

Cross-team reviews are a great way to expose all team members to these different areas and spread specific learnings across all teams.
Depending on the size of your company, you may have many different teams and applications. Or maybe you have a complex application with a team that not everyone gets a chance to work in every application area. Developers across different projects don’t always get to work together.

If someone on team A introduces a better way to do things or experiments with a different design pattern, team B usually doesn’t get this knowledge.

Even if team A announces their new way of doing things, team B may not adopt it or realize its value.

When team B can review the code, they can see exactly how it works and the value it can bring.
Or maybe they would get other ideas and be inspired to try something else or help improve team A’s design. Plus, no one from Team A has to realize this should be shared or remember to make an announcement.

Team B will naturally see it during its code review.

Code reviews are one of the only ways to share knowledge naturally across multiple teams.

Code reviews also reveal new ideas and techniques.

Reviews will teach the same team new things the same way they will teach multiple teams. But new ideas and techniques often come up in code reviews even among the same team members.

Think about most of the code you write. How often do you research different design patterns, consider different architectures or attempt multiple solutions before deploying code? If you are anything like me and many of the developers I work with, I’m guessing this isn’t that often.

We do an excellent job of going through these steps for more complex features and new projects but don’t often feel the need to do this for our standard everyday features.

At most places, we don’t have the time to pair program on everything or always meet about how to code every feature.

You can get some of these same benefits from code reviews.
The reviewer may suggest an improved design or ask a question that leads to a better plan. They make these suggestions without taking the time to pair program or schedule a meeting. Once a team implements a review process, these suggestions happen without extra steps.

Code reviews make some of the benefits of pair programming, and design meetings naturally occur for every piece of code without special steps.

Putting up small and focused PRs help get this feedback quicker.
You can ensure everyone can move quickly by getting feedback in small iterations. Small and quick reviews let the author know they are on the right path early and often. When reviews are practical and efficient, developers can often avoid massive rewrites.

Think like running your code reviews like your agile sprints.

If you care about code quality, you need code reviews.

It doesn’t matter what processes you already have in place. QA, automated testing, or acceptance testing is not a replacement for another developer reviewing your code. Code reviews are not a replacement for the other processes either.

For high-quality, bug-free code, we need all these processes.

If you liked this and would like to see other tips, advice, and articles from me, you can find me on most social media under @kevinhickssw.

Why You Need a Coding Scratch File

Kevin Hicks — Mon, 13 Dec 2021 01:16:22 +0000

Sometimes the best place to write code for your project is outside it.

This may sound like a lie. How could writing code outside of a project be the best place for the project's code? How can it even help the project at all?

Working within a project, especially a large and complex one, other code can get in the way of what you are writing.

By removing the distraction of unrelated code, you can focus on your task.

When experimenting with designs or figuring out a tricky issue, it's quicker and easier to focus on the smallest amount of code needed. You don't have to worry about passing arguments around, multiple software layers, and other complexities. You also won't need as many manual steps or automated tests to test your code.

Sometimes you will need the rest of the project code, but removing it can be a huge productivity boost when you don't.

How does a scratch file help?

A scratch file allows you to write code that can be compiled, ran and debugged without the rest of your project or setting up a new one. You can copy the code to your project and delete the file when you finish. Scratch files also help avoid accidentally committing temporary code.

It's like a sticky note for the code you throw out when done with it.

Create your first scratch file.

Scratch files can usually be created inside your IDE. The process is different between IDEs, so search for "your IDE name + scratch file" to get started. It's also helpful to read everything your IDE can do with scratch files when you look this up.

Once you create the file, start writing code.

There are also options outside of IDEs for scratch files.
You could use a fiddle site (like jsfiddle) for your language. Some languages and frameworks have tools for this, such as artisan tinker for Laravel and LinqPad for C#. A default project for your language or framework could also serve as a scratch file if you need to work across multiple layers with no other custom code.

Learn about the scratch file options for your project and use what you prefer.

While not suitable for every situation, scratch files are a fantastic tool when focusing on a small amount of stand-alone code.

When are you a developer?

Kevin Hicks — Mon, 06 Dec 2021 20:25:44 +0000

Once you write any code to solve a problem

The answer really is that simple.

It doesn't matter what programming language you used. Or if you wrote code for mobile phones, a website, or a desktop application.

Even if you wrote the tiniest amount of code, as long as you solved something with code, you are a developer. Any experienced developer knows we spend way more time thinking about how to solve problems than actually writing code.

You don't need to solve hundreds of problems to call yourself a developer either. The first time you write code, you are a developer. Sure, you are a beginner developer, but you aren't any less a developer than anyone else.

Whether you wrote code for yourself or were paid also doesn't matter.

Ignore the trolls that say you aren't a developer if you didn't use X language or work on Y platform. These people are insecure and trying to validate that their work is better than everyone else's. They forget what makes someone a developer.

If you wrote code to solve a problem, go ahead and call yourself a developer.

Should You Specialize?

Kevin Hicks — Sat, 27 Nov 2021 15:00:14 +0000

It's no secret that experts that specialize in a particular niche tend to make more money. It can be easy to think of how you pick a specialization and your career takes off.

But before you can choose a specialization, you need to decide if you should specialize or how much you should specialize.

The first step is figuring out if you want to specialize.

Will you like doing the same type of work for the same industry every day?

Specialists do not have as much variety between the types of clients or projects they take on.

With the limited variety of jobs, there won't be as many job opportunities compared to the prospects for a generalist. However, the generalist also competes against many others for the job, including specialists.

Along with fewer opportunities, sometimes specialists are brought on to solve a specific problem only, leading to shorter projects. Yes, specialists can make more money for these smaller jobs than a generalist working on a long-term project.

But they need to be an expert to demand that higher rate. Waking up one day and deciding you now specialize in X won't magically make you more money. First, you have to build your experience and reputation within the specialization.

The good news about choosing to specialize is you can also decide how niche your specialization is. The more niche your specialization, the more chances you have to make money and become a top expert for a specific area. The broader you keep your specialization, the closer you are to the benefits and drawbacks of being a generalist.

It is up to you to decide just how far you may want to specialize.

How To Find A Bug Without Pulling Your Hair Out

Kevin Hicks — Wed, 24 Nov 2021 11:07:59 +0000

Working with code you're unclear about is like wading through a swamp. You should attempt to get yourself on solid ground as quickly as possible

– Jon Skeet

One of the most frustrating things about bugs with computer software is you get a bug report, someone is breathing down your neck to get it fixed, customers are upset, and everyone thinks it should be easy to find and fix.

We're lucky if the problem is precisely where the error says or the user's bug report has enough details. Often we are stuck having to dig into the code while trying things ourselves to figure out where the problem is. It's never as easy as just jumping to a code line everything points to and changing something. We need to find the "root cause" to make sure we aren't fixing the symptoms of another bug.

root cause - A root cause is an initiating cause of a bug

Debugging is just like investigating a case. There are some initial steps you need to take. You can't investigate a crime if you don't know what it is and where it occurred. The same thing applies to fixing a bug.

Time to put on our detective hats to find the root cause.

Gather Details

Before trying anything, before changing any code, you need to gather as many details as possible. Review the bug report or error, then start asking questions to uncover missing details. If it is a bug report, you can ask the user, QA tester, or whoever submitted it. If it's an automated error report, you may need to ask yourself these questions by digging in the code, your systems, and online.

Here are some of the questions you should ask:

Is it easily reproduced?
- If so, what are the exact steps to reproduce it?
Have others run into this issue?
What is the device and system info the error occurred on?
What changed recently? Any code deployments, configuration, or hardware changes?
What should the code do when it works successfully?
- Is there any validation, error handling, etc., in place that should be running?

In addition to asking questions, you also want to make sure to research any additional information that could help you.

Check logs and error reporting software for related errors and events that happened around the same time.
Google any error messages. Google both to make sure you understand it and to see if others have solutions.
Check git logs for recent deployments, hardware, or configuration changes. Keep in mind any recent changes, even if they seem unrelated.

Reproduce The Problem

After you learn everything you can about the error, the next step is to reproduce it yourself. Ideally, you will reproduce this in the local environment you usually code in. The fewer chances you have to break other things while debugging, the better.

One of the worst things we can do when debugging is changing things or fixing a bug when we couldn't reproduce the problem ourselves. This is why if we can't reproduce it locally, we want to try to reproduce it in production safely.

We need to be careful of the potential issues and requirements we need to maintain in production, but sometimes the only choice is to debug in production. I'll write another article soon giving tips to limit needing to debug in production and how to do it successfully.

Reproducing the bug is easy if you have steps from a bug report or error reporting tool. If you don't have the steps, you will need some trial and error until you figure out the exact steps to reproduce the bug. Reproducing bugs gets easier as you learn more about a system.

Once you know the required steps to reproduce a bug, try to reduce the steps to the absolute minimum number of steps. The fewer steps needed to reproduce a bug, the quicker fixes can be tested. This is also a significant benefit for writing automated tests (if you have automated tests) to test the changes. Fewer steps mean less setup and easier to write automated tests.

If you don't have automated tests, I highly recommend investing in the time to set up and add tests for all your code. There are plenty of resources for each platform and language to get started with automated testing. Automated testing offers many benefits, including speeding up debugging and ensuring bugs don't come back later.

Ask Someone Else

One of the first steps should always be to ask if someone else ran into this bug before. Don't be afraid to ask QA testers, other developers, and sometimes even users about the bug. Asking can be the quickest way to fix a tricky bug if someone is already familiar with it.

You never know who may have run into the problem before. There is a chance this person will know:

How to fix it.
They may have a workaround that can be used for now.
They may also know if a permanent solution is filed to fix it.
They could already have completed research to help speed up debugging.

By tackling each of these steps first, you will find fixing bugs to be less stressful. When you know the root cause and how to reproduce a bug, fixing it becomes a quick and painless process.

If you would like more tips and tricks to level up your debugging and make fixing bugs less stressful, my book Level Up Your Debugging is up for early access pre-orders on Gumroad.

When Are You Ready To Freelance?

Kevin Hicks — Tue, 23 Nov 2021 00:09:21 +0000

Many people dream of the freedom being a freelancer brings. However, it can be a difficult journey, especially if you aren't ready for it.

How do you know if you are ready?

1. Do you have the experience and can work on your own?

Clients expect freelancers to be able to hit the ground running, so make sure you know your job well enough to work on your own.

2. Do you have a portfolio?

Clients need proof you can complete the job. Having a portfolio also helps you answer #1 correctly.

3. Are you able to manage yourself?

Freelancers need excellent time and project management skills. You won't have the structure a typical job provides to help keep you accountable.

4. Are your people and communication skills strong?

You will need to market and sell yourself, solve disagreements, and handle all communications yourself.

5. Do you have a plan to get clients and get paid?

Before starting, you need to know how you are going to make money. Decide if you will use a freelance marketplace, referral, cold calls/emails, etc.

6. Are you ready to deal with the up and downs?

Freelancing can be fantastic, but it can also be stressful. Like any job, there will be bad days and good days. You may have to be ready to deal with a drop in income at times too.

The great thing about freelancing is all the skills you need; you can learn and practice until you are ready to jump into the freelancing pool.

Avoid The Pain of Repeated Database Queries With Laravel Query Scopes

Kevin Hicks — Sun, 12 Sep 2021 15:11:50 +0000

As you continue building out Laravel apps, you will notice spots that you need to perform the same queries. If your project is like most projects I've worked on, you will start with just repeating the query code in many places.

This works great until you need to change the query. Because the query is repeated throughout your code, you now need to change it everywhere. And you might forget to change it somewhere 🤦🏻. This is an enormous maintenance headache. I can't even count how many bugs I've encountered (and written myself) from forgetting to update code in multiple places.Luckily there are a few easy solutions to reduce duplicate queries.

You can move all database code to stored procedures and only interact with the database through stored procedures.
Create repository, service, builder, or other classes for your queries.
Add methods to the Eloquent model to perform the queries.

All of these solutions will work and have their pros and cons. One solution that is built into Laravel that works well for this is Eloquent Query Scopes. Query scopes provide some advantages over the other methods I mentioned. Three of the most significant benefits are:

It is a first-class citizen of Laravel and built into how Eloquent works
It can be easier to create smaller, reusable query scopes that can be combined in larger query scopes or one-off queries.
They can be automatically applied to all queries on a model

So what exactly is a query scope?

A query scope is a method that works on a model's query builder to modify the default query that would be run. What makes a query scope different from any other method you would write is that it is built into Laravel's Eloquent and meant to be a set of common constraints you would run instead of the entire query. Here is a typical method you might write to tasks that are not complete yet and assigned to a user.

public function GetActiveTasksForUser(int userId) : Collection
{  
    return Task::where('assigned_to_user_id', $userId)
        ->where('isComplete', false)
        ->get();
}

Now, if you think about the typical queries, you might need for a task. It isn't hard to imagine needing to query both for all tasks for a user and another for their tasks that aren't complete. Let's add a second method to only get the tasks assigned to a user.

public function GetAllTasksForUser(int userId) : Collection
{  
    return Task::where('assigned_to_user_id', $userId)->get();
}

Notice how the first half of this method is the same as the previous one. We are already duplicating code after just two different queries. It should be easy to see how this could get out of control pretty quickly. Let's convert the two constraints (tasks assigned to the user and incomplete tasks) to query scopes to see how that would help these methods.

// In the task model (Task.php)
public function scopeAssignedToUser(Builder $query, int $userId) : void
{
    $query->where('assignedtouser_id', $userId);
}
 
public function scopeIncomplete(Builder $query) : void
{
    $query->where('isComplete', false);
}

The two methods from before can be updated to use the new query scopes and avoid the duplicated query where clause.

public function GetActiveTasksForUser(int userId) : Collection
{  
    return Task::assignedToUser($userId)->incomplete()->get();
}

public function GetAllTasksForUser(int userId) : Collection
{  
    return Task::assignedToUser()->get();
}

The best thing about this approach is that we call simple methods whenever we need a new query that either gets tasks assigned to a specific user or incomplete.

How to create a query scope?

Creating query scopes is pretty similar to creating any method. There are just three main requirements to make the method a query scope.

Local scopes need to be on the model they apply to. Global scopes need to implement Illuminate\Database\Eloquent\Scope; We'll get into local vs. global scopes in a little bit.
Local scopes need to start with scope. For local scopes, everything after the word scope becomes the method name to call to use the scope using camelCasing. Ex: scopeAssignedToUser() is called with assignedToUser. Global scopes don't have any special naming requirements.
The first argument should be an instance of Illuminate\Database\Eloquent\Builder. For global scopes, the second argument should be an instance of Illuminate\Database\Eloquent\Model.

Local scopes can have no additional arguments or can have any arguments after the builder argument. Arguments in a local scope are used to change the query that runs. For example, in scopeAssignedToUser we passed in an $userId argument to change what user the query was checking tasks were assigned to.

But queries don't belong in the model.

Depending on the size and complexity of your app or your coding standards, you might think that query scopes don't belong in the model. It is true that with Eloquent, it can be very easy to make your models bloated and full of logic that doesn't belong in it. If you aren't careful, the model can become a mixture of business logic, persistence layer, and other logic.

Don't write off query scopes just yet. There is an easy way to take advantage of query scopes without bloating the model. Since query scopes are just methods that work on the model's query builder, you can extend the query builder and include your query scopes on the extended class. This puts all query scopes for each model in its own dedicated class.

// In TaskQueryBuilder.php
use Illuminate\Database\Eloquent\Builder;

class TaskQueryBuilder extends Builder
{
    public function assignedToUser(int $userId) : self
    {
        return $this->where('assigned_to_user_id', $userId);
    }
}

// In Task.php
public function newEloquentBuilder($query) : TaskQueryBuilder
{
    return new TaskQueryBuilder($query);
}

// Still can be called the same way as before
Task::assignedToUser($userId)->get();

Local Scopes vs. Global Scopes

The main difference between a local scope and global scope is local scopes have to be called and are meant for repeated database constraints you may not need all the time. Global scopes, on the other hand, will run automatically for every query on a model. They are meant for things you are almost always going to want to run and don't want to forget when querying for that model. For global scopes, think of things like not loading soft deleted records (Laravel's SoftDeletes trait uses global scopes) or checking if a record belongs to a company for multi-tenant apps (apps that serve multiple different companies each with their own dataset).

The scopes we created above were local scopes. The following examples will be global scopes that have a few differences in how they are made and used.

They need their own dedicated class and to be registered in the model's booted method.
The method names are not prefixed with scope.
They can not have arguments that easily change for each query in the same request. Any arguments for global scopes will require some type of global state.
They run without calling them explicitly. To avoid running them for a query, the withoutGlobalScope method needs to be used.

Let's create an example Global scope for checking if a record belongs to a company.

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class BelongsToCompanyScope implements Scope
{
    protected CompanyResolver $resolver;

    public function __construct(CompanyResolver $resolver)
    {
        $this->resolver = $resolver
    }

    /**
     * Apply the scope to a given Eloquent query builder.
     *
     * @param  \Illuminate\Database\Eloquent\Builder  $builder
     * @param  \Illuminate\Database\Eloquent\Model  $model
     *
     * @return void
     */
    public function apply(Builder $builder, Model $model)
    {
        $builder->where('company_id', $this->resolver->getCurrentCompanyId());
    }
}

This example shows how we can use a resolver passed into the global scope to change what company we are loading records for. The resolver could be any class that tracks the current company for the current user. Maybe it is stored in the session, cache, or querying the user's database table.

This is one of the easiest ways to get global scopes to work with arguments that could change based on the current user or session. However, it does have its downsides that we are now introducing some type of global state into the scope, and the model will also have to know about the CompanyResolver too. This can make fixing bugs and changing features in the future harder. For this reason, I'm not a big fan of doing this on larger projects or for anything that doesn't rely on a global user or session state the entire app needs to know about anyways.

To use this BelongsToCompany scope, it needs to be registered in the model class.

// In Task.php
/**
 * The "booted" method of the model.
 *
 * @return void
 */
protected static function booted()
{
    static::addGlobalScope(new BelongsToCompanyScope(new CompanyResolver));
}

Now every time we query for a task, it will automatically add where company_id = $someCompanyId to the query. However, if we don't want the global scope to run, excluding them for specific queries is also easy. For example, maybe we want to get all tasks for all companies. In this case, we need to exclude the BelongsToCompanyScope.

Task::withoutGlobalScope(BelongsToCompanyScope::class);

If we wanted to exclude multiple scopes or all scopes, we could use withoutGlobalScopes. When called with no arguments, it removes all scopes. When called with an array, it will remove all scopes in the array.

Query scopes are just one way to reduce duplicate query code

As mentioned earlier in the article, query scopes are just one way to reduce duplicate code. They might not be the best for every situation or project, but they should be another tool in your belt. It is up to you and your team to decide what patterns and practices you want to follow for your project.

Becoming A Senior Developer Is Not About Your Code

Kevin Hicks — Thu, 25 Feb 2021 13:37:01 +0000

I have talked to several great developers who write fantastic code with years of experience who were confused about why they were not a senior developer yet. Maybe you have had some of the same thoughts. Perhaps you think you are ready to be promoted, but it doesn't seem to be coming any time soon.

If you look at the requirements for most senior developer positions, it seems like all the requirements are you need 5+ years of experience with language X and technology Y. So when you see this, you start thinking I write great code. I have the experience, I should be a senior developer.

In reality, being a senior developer is more about your skills outside of coding. A senior developer is also a leader. If you pay attention, you will see most senior developers perform many tasks outside of coding. They also seem to possess some of the same skills and quantities. Senior developers often are great leaders, manage projects, the go-to person for help, and help everyone around them grow. Now don't get me wrong, some senior developers don't lead teams, or their greatest skill might be their code. However, in my experience, these senior developers take longer to get there, might be passed up for other opportunities, and aren't looked at with the same type of respect as seniors who can excel at both coding, and being a leader. It's often these other skills that lead to being promoted, not the quality of code.

How do you improve these other skills?

First, you want to focus on yourself. Become an expert at managing and leading yourself before you attempt to lead anyone else.

Know how to plan and manage your tasks and projects.

Estimates for software projects are rarely correct. It's tough to account for all the unknowns and get it right. We still need to try to do our best at estimating, though, so other features, teams, and marketing efforts can be planned around our features. When you first start out trying to manage your projects, first learn how long it takes you to do specific tasks. Once you have a good baseline for how longs things take you, you can start using that to estimate similar features. You should double any estimate you come up with to play it safe.

Once you are comfortable estimating your tasks, start learning how long your teammates take for their tasks. You should get comfortable being able to estimate for your team and judge how long a developer of specific skill levels may take. One important thing to remember for this is developers should never be solely assessed on their speed. Everyone will work at different paces, even at the same skill level. Two of the best developers I ever worked with were on complete opposite ends of the speed scale. Speed is not a comprehensive measurement of a developer's skill.

Learn the best ways to get unstuck and help yourself.

To be clear, I don't mean to spend hours stuck on a problem without asking for help. If you are stuck on something for longer than 15 - 30 minutes and have the resources to ask for help, you should. I can't tell you how many times I spent hours trying to figure out an issue for someone else to tell me how to fix it in 5 minutes. However, it would help if you started learning the best ways to debug problems, look up information, and troubleshooting in general. This is important as senior developers have to figure out challenging issues no one else may have the answer to and guide others on fixing their bugs.

Identify weaknesses.

A large part of being a leader is being able to admit what you aren't good at. You can't be the best at everything. You also can't complete everything yourself. Senior developers recognize this and learn when it's best to ask for help and rely on their team. It is about maximizing the team's potential and leading them to success, not your success.

Practice empathy.

Think back to some of your favorite bosses or teachers. One of the reasons you liked them likely was you felt like you could relate to them and be comfortable around them. We feel this way around people that practice empathy. They can put themselves in other people's shoes to see what they are going through and understand their viewpoint. Doing this can help people relax, help connect to them, and guide them on the correct path.

Even before being a senior developer, you can start to practice this. Learn to recognize when a team member may be having an off day, struggling with an issue. Don't jump to judge them if they have been seeming slow or running into problems. They may be going through something you don't know about or frustrated from being stuck. Again think back to some of your previous favorite bosses. When you had a rough time, they probably weren't rough on you. They probably cut you some slack. Maybe they let you work on something that they knew you would enjoy, offered to talk, or just took a step back. Being able to step into someone's shoes to understand them and then react accordingly may be one of the most critical skills a leader needs. It's hard to be a leader people want to work with, but great leaders are people others want to follow.

It will take time.

It is easy to be so excited about moving up that you forget that it will take time. There is a reason all those job requirements list years of experience for senior developers. Becoming a great developer takes a long time. Improving all the skills outside of coding takes years of practice. Even after you are a great developer and have nailed down all the other skills, it can still take even more years to be promoted. First, there has to be an opening for a senior-level position to fill. If a job is open, your manager and team also need to see a proven track record of you using the required skills. They need to see you in situations where you can prove that you have what it takes to be a senior developer.

Don't give up. Don't lose excitement over moving up. Just keep practicing and improving your skills, and eventually, you will be a senior developer.

Did you break your code today?

Kevin Hicks — Wed, 17 Feb 2021 17:07:21 +0000

I broke my code today. And I'm glad I did.

You might be wondering why I would be glad I broke my code? Wouldn't I want it to work? Am I crazy?

I'm happy that I broke my code before anyone else broke it. I found the issue before it caused problems for users and before I spent QA's (quality assurance) and a peer reviewer's time. We should all be aiming to do this. It's easy to get code that works 90% of the time. But that other 10% of the time, all those annoying edge cases can be hard to even think of, let alone make sure your code handles them correctly. So how do you think of these edge cases we need to handle?

Think about your code like QA

Now I don't mean you need to do everything QA does or replace your QA person. You don't even need to write the test cases and test plans if QA normally handles that, but you need to think about breaking your code the same way they think about it.

So how does QA think about breaking your code?

Understand what your code should do

The first thing you can do to make sure your code works correctly is to understand what it should do. This might seem like common sense, but it is common for bugs to be caused by misunderstandings between project managers, stakeholders, and developers.

If you have any doubts, questions, or concerns, they need to be discussed before the code goes live. Don't worry about this coming off as pushing back or asking dumb questions. If something isn't clear to you, it probably isn't clear to someone else. I've even seen stakeholders realize they don't understand their own requirements when I asked for clarification. Think you have a better idea, bring it up. Your stakeholders and users will thank you if it improves things. If it doesn't improve things, they will still appreciate you trying to improve the product.

Test for the success cases

Now that you know what the code should do, you should test that it actually does what it should. At this time, give the program the exact input it expects and don't do anything that may risk breaking it. We will get into trying to break it later. For now, we want to make sure we have a good starting point to test for failures and edge cases.

If your project has automated tests, this would be the time to write the automated tests for all the success cases. Automated tests will allow us to ensure the success path still works without manual testing as we address failures and edge cases. I highly recommend writing automated tests. Yes, automated testing can be a pain to learn and get right, but it will save you in the future. I can't count how many times I broke code with changes that shouldn't have affected anything because of not having tests. If you aren't ready to learn automated testing or can't add it to your project, no big deal, but you will need to revisit this step later to test it again manually.

Test for known failures

You know what the code should do. You know the code does it successfully. Now it's time to test for failures you know are going to happen. Maybe these failures are spelled out in the requirements. For example, it might say, "When clicking on a link, it goes to the product page. If the product is not found, redirect to a product listing page." This is easy to test for as your stakeholders tell you what to do when it fails.

Other known failures would include things you realize may happen while working on the success case. Going back to the product page example, if the stakeholders didn't mention how to handle a not found product, you might think about this issue yourself. You may decide it should return a 404 error or redirect to a product listing on your own. Better yet, ask the stakeholders which one it should do. Or you may be working on a search and realize you need to throw a validation error if no search term is provided.

At this stage, think of anything you can that may go wrong and test your code to see what happens in those situations.

Make foolish mistakes; do the wrong thing on purpose

The amazing thing about users is they will always do what you don't expect. They will break things in a way you can't think of. They will also make things work in unexpected ways and cause outcomes you didn't believe were possible. This is the part I find fun about testing code. It's an excuse to go crazy and make dumb mistakes on purpose to see how your code reacts. This is precisely how a great QA person will test your code.

Even if we are going crazy with making mistakes, we still need to follow a process. If you just test for random things and don't pay attention to what you are doing, you won't know how to recreate the issue to test your fix. Instead, you want to make sure you are paying attention to exactly what you click on, what you type in, and what happens as a result. You also want to make sure that you remember what you have tested and haven't tested even though your testing may be random. Make a list of the tests you have run and put a mark next to those that require a fix.

So what are some good foolish mistakes to make?

Push validation to the limit

What happens if you don't include inputs? What happens if you use an excessively long string or a large number? What about a negative number or passing a string for a number?

To test validation, you want to do everything wrong with all of your inputs you can think of. You know what each input should do; now do the opposite and other silly things to see if your code can handle it.

Do the opposite of what you expect users to do

Literally do the opposite of what you expect users to do.

Do things out of order.
Click out of pages in the middle of a process.
Hit the cancel button in a modal, reopen the modal and try to submit again.
Anything else you can think of that doesn't make sense for the feature.

This type of testing could be anything and will vary depending on what feature you are working on. The point is to make sure you aren't doing what you tested for during the success cases. A great way to do this may be to act like you don't know how to use a computer or website.

Hack your code

It is your turn to be the hacker. Can you find any security issues in your code? Have you tried a SQL injection, XSS (Cross-Site Scripting), CSRF (Cross-Site Forgery Request) attack, etc.?

Security is a big topic that has its own articles, books, and courses. It's also going to vary based on platform, language, devices, etc., so I won't go into details on specific security threats. Make sure you become familiar with common threats for what you are working on so you can test for them.

Make it so slow you get bored

You don't want to make your code inefficient on purpose, but you should test features with a ton of data. Have the option to change the number of records on a page? What happens if you make that number 10,000? Is it still fast? Can you upload a file with 10,000+ records without getting bored waiting for it to complete?

It's easy to fill in 5 dummy records and start testing a feature. We often forget that real users may try to work with enormous amounts of data at once. It's usually after our first power user hits 10,000+ records, and we have an urgent bug fix because the page won't load; we realize performance is a problem. Find the limit of how much data your code can handle, then try to optimize it. Once you can't optimize it anymore, make sure your users can't go past that limit or provide a way to offload the process to a background job so the user can be alerted when it's done instead of making them wait.

You broke your code; now its time to fix it

Each of the issues you find is probably going to require different fixes. You might need to add validation checks and messages, add additional alerts for the user, prevent actions from happening, or optimize queries. The important thing is to refer back to the steps you took and what went wrong when performing them. Ideally, you would write automated tests for each issue you fixed, so you can be sure it won't happen again. If you don't have automated tests, then it just means you have more manual testing to do for all these issues every time you touch this code.

As a final note, it is essential to realize you won't find every issue every time. There is a reason QA is a vast profession and necessary in our industry. A developer doing this type of testing aims to eliminate back and forth between developers and QA and save time, not find and fix all issues.

Have any other tips or suggestions on how to test your code for edge cases? Please share in the comments or on Twitter.

Now have fun and break your code, so no one else has to know it was broken.

How do you deploy your database changes?

Kevin Hicks — Tue, 16 Feb 2021 15:17:05 +0000

When working with websites that are likely to have active users at any time and you can't have downtime, deploying database changes with your code changes can be an issue. You need to either deploy changes in a way that they can go out at different times without causing issues or deploy database changes that take effect at the same time as the code changes.

Concerns during database deploys

No downtime
Possible bugs
Rolling back code
Data changes
Possible long-running tasks (import data, big data updates, etc.)

Possible deployment solutions

Deploy with the code as part of the code CI (Continous Integration process) using something like migrations or deploy scripts
Deploy database changes ahead of time in a way that won't break existing code.
Deploy database changes with their own CI
Manually deploy database changes

How do you handle your database deployments? Do you use one of the above solutions or something else?

Do you have any tips or tricks for database deployment or handling issues that may arise?

Even Senior Developers Have Imposter Syndrome

Kevin Hicks — Sat, 13 Feb 2021 14:05:08 +0000

If I told you I spent all day trying to figure out how to design the solution to a problem in a language I worked in every day and made absolutely no progress, would you think I was a new or junior developer? What if I also told you that nothing I tried worked at all and that I felt like I was "faking" being a developer? Many of you may think I'm a relatively new developer with only maybe a year or two of experience if this was the only thing you knew about me. The truth is I am an experienced developer with several accomplishments, including:

Over ten years of professional experience
I've been programming since childhood
Spoken at a conference and meetups
Became a Senior Software Engineer at a company with a large and very talented developer group
Run a successful digital agency doing both consulting and development for startups and enterprises.

Even with these accomplishments and knowing that I am some developers' mentor (some of them paying for the coaching), I still felt like I wasn't a real developer today. I felt as if I wasn't good enough or smart enough to be a good developer. This feeling of faking it or better known as imposter syndrome that I want to focus on.

What is imposter syndrome?

A psychological condition that is characterized by persistent doubt concerning one's abilities or accomplishments accompanied by the fear of being exposed as a fraud despite evidence of one's ongoing success. - Merriam Webster

We may not like to admit it, but most developers will go through imposter syndrome at some point in their career. It can be hard to recognize and deal with when it happens, as you may genuinely think you are a failure and do not belong when going through it. Not enough developers are willing to talk about their experience with it, or many will laugh off their feelings about it. Imposter syndrome can be scary and hold you back. It wouldn't be surprising if it has driven people away from the industry who would have been great developers. It is essential to recognize not only when you are going through it but also that everyone else has or will go through it.

A senior developer with imposter syndrome

I personally still struggle with imposter syndrome. It is weird to admit this with my experience and accomplishments. Yet, there are days that I feel like I don't have a clue what I am doing or that I am the worst developer in the world compared to someone else. I have a long list of setbacks that my imposter syndrome has directly caused.

Unfinished side projects - I have a long list of unfinished side projects. These are a mixture of personal projects and products I wanted to launch for my agency. Every time I get close to releasing something, I start feeling ashamed of the project. I compare it to competitors or just other things I see other developers put out there and start to feel embarrassed of what I worked on and like it won't go anywhere. I have now restarted my passion side project three times after it was almost done due to imposter syndrome.
Deleted and restarted my blog - I used to have a blog going where I would write off and on. I never really wrote anything in-depth and even stayed away from some technical topics to avoid sounding like I didn't know what I was talking about. Eventually, I just deleted it and now I have to start from scratch again.
Avoiding goals - I have some goals that I have had for many years. These are goals that are part of my dream of where I want to be as a developer and where I want my agency to go. I have always wanted to write books and courses. I love teaching and helping other developers grow but am often held back by feeling like I don't know enough to be the right person to help.

In addition to these more significant setbacks, imposter syndrome has affected my productivity, made me anxious when submitting work for review, and made me upset and feeling down on a day to day basis almost any time I struggled with coding. If you have been writing code long enough, you realize it doesn't take many days to end up on a day you are struggling with a problem.

How to handle imposter syndrome?

Handling imposter syndrome is probably a little different for everyone. Everyone will have different things that will help them calm down, recognize the truth, and help build their confidence. There are a few tips that may work for you and that I have found to help with my imposter syndrome personally.

Talk to someone

Find someone who you trust and is supportive to talk through your feelings. This could be anyone that can help you see your accomplishments, what you have learned and what you know. However, it can be a bonus if this could be another developer who may entirely understand what you are going through and can speak directly to your programming accomplishments.

Make a list of your accomplishments

Make a list of any programming accomplishments you have up to this point. When you start feeling imposter syndrome come on, go back and review this list. This list should remind you of what you have learned and the problems you already overcame. If you learned a language, you are a developer. If you solved a complex coding problem, you are a developer. If you completed a project, you are a developer. This list should contain many of these things that will remind you that you can do this and are not faking it. Even if you are struggling with a problem and feel lost, this list is a powerful reminder of everything you grappled with before and learned how to overcome.

Stop comparing yourself to others

One of the worse things you can do when dealing with imposter syndrome is to compare yourself to others. Everyone is unique and each person is going to be better at something than someone else. Even the best C# developer could feel like the worse developer if they compared themselves to the best JavaScript developer thinking they should be just as good (feel free to replace these examples with any technologies or languages). Many times I hear developers I am working with comparing themselves to other developers or me. They are always wishing they knew as much, wrote code as fast, and had as good of designs. In these situations, the developers hoping they were like the other developers had also taught the other developers or myself many things without even realizing it.

Don't worry about what you don't know

As a developer, you are never going to know everything. There truly is a new language, framework, best practice, etc. every day. We need to acknowledge there isn't enough time to learn everything. Instead of worrying about what you don't know, pick things you want to learn about or improve to focus on those. Let these things be a way to grow your list of accomplishments, enhance your skills and expand your knowledge. Keep in mind you won't know everything while remembering you can learn anything you need or want to the same way you have before.

No matter your language, you are a real developer

Unfortunately, there is some toxicity in our industry. You probably have seen all the arguments about language X, framework Y, or technology Z is the best, and the rest suck. Or that if you work with language X, you aren't a real developer. This is just toxic behavior, and there isn't any truth to these statements. Every language, framework, and technology have their pros and cons. I defended web programming in my quora answer by pointing out how all the reasons to list why web programming was "looked down on" could be applied to other types of development. If you approach these arguments with this analysis, it's easy to see how no language, framework, or technology is better than another in all cases. If you work with any of them, congratulations, you are a real developer.

Get a coach (or a therapist)

There is nothing wrong with getting professional help like a coach or therapist to help with imposter syndrome. There can still be a bit of a negative response to working with a therapist, but it honestly can be the best thing for both your professional and personal life. There are also starting to be blurred lines between coaches and therapists, with some people able to feel both roles. This blending does make it harder to find someone who is appropriately qualified and can provide the help you need, but it also removes some of the negative reactions since having a coach may be seen as a positive or smart move. Honestly, working with a therapist should be viewed the same way as working with a coach. Nothing has to be wrong with someone to see a therapist. Many therapists work with people to help them improve and be the best version of themselves. This last tip may not be necessary, or it may be the one that finally enables you to overcome your imposter syndrome completely.

Personally, taking the step of working with a professional is what allowed me to start getting over my imposter syndrome. I have heard of and tried the other tips but found myself still struggling with it. I kept finding my emotions overpowering the logical sense of the above tips. Working with someone helped me figure out why I thought that way and how to take steps to improve my confidence to reduce the imposter syndrome. Since working with them, I have made progress on my side projects, releasing bits to the public, started writing a book on code reviews, and finally started my blog again.

You are not an imposter

Just remember, once you have written your first piece of code, you are a developer. Whether you feel it now or go through imposter syndrome in the future, remember you are a developer. You are not alone when you feel like you are faking it, and even us senior developers go through it too. Hopefully, this provided you with some new tips to help overcome it, or just knowing everyone else goes through it will give some comfort.