It's the last issue of 2022, and it's been quite a ride. But rather than do the usual "look back at the year," I'm bringing you three fresh articles in this last issue, and I hope they're helpful. First, you'll look at some tactics to help find work in a slow job market, and then you'll explore two command-line programs that can help you free up disk space. And finally, I'll try to convince you to rethink using "we" in your technical tutorials.

Also, you'll notice this newsletter looks a little different. I've moved to Buttondown, and I'll be making some changes to where messages come from and where the archives are stored. Please bear with me as things roll out between now and the next issue.

Let's go!

Finding Work in a Down Market

It's rough out there for a lot of people right now. The site layoffs.fyi has been tracking layoffs since the beginning of the COVID-19 pandemic, but if your LinkedIn feed looks anything like mine, you'd think that layoffs are happening everywhere. Fortunately, many companies are still hiring, but with this many people looking for jobs, any job seeker will face stiff competition.

As my friend recently pointed out, many people under 30 have yet to experience an economic downturn as an employee. For the last ten years or so, times have been good. A year ago, we were all talking about the "great resignation" and how it was an employee's market. But not anymore.

Some of us have been through the ups and downs a few times. Here are some tips to help you stand out and increase your chances of landing a tech job when the competition is tough. These apply whether you're just starting out or have many years of experience.

Network and connect with industry professionals

Building a solid network can help you learn about potential job openings and get your foot in the door.

Attend industry events and conferences, join online groups and forums, and reach out to professionals in your field for advice and guidance.

But you have to do more than join and consume. You need to be an active participant in the community. Answer questions you can answer. Participate in discussions by adding your thoughts or follow-up questions. And most of all, continue doing these activities once you land a job. A solid network needs cultivation and care. You can't use people to get a job, disappear once you've got one, and then show up again when times are hard again. As you grow in your career, you'll rely on your network to find new opportunities, especially roles higher up in organizations. Build a good network and a solid reputation within that network.

Keep your skills up to date

Companies will be more selective about the candidates they hire in a down market. They have smaller budgets and fewer open positions, so each hire they make has to be impactful. By staying up to date on the latest technologies and trends in your field, you can make yourself a more attractive candidate to potential employers. A job market downturn is often when people flock back to education. Consider taking online courses or getting some new certifications while looking for work. That can help, but not as much as being able to show you can do the job. Taking a course on a programing language isn't as impactful as producing something valuable. Remember that learning happens through practice, feedback, and performance. And that brings me to the next tactic you can use...

Freelance

Use your network to find freelance work, such as subcontracting or contract work. You'd be surprised how many software consulting agencies need a few extra hands. This is a way to make more connections, put your existing experience to work, and continue sharpening those skills. It's also a place for you to get some exposure to work that lets you use some of the new skills you've picked up recently.

If your network isn't as strong, you can use sites like Upwork and Contra to create profiles and get started. You can also volunteer or make meaningful pull requests to open-source projects. Small documentation patches are helpful, but if you're looking for an engineering role, more complex contributions will let you demonstrate your skills.

Tailor your résumé to the job you are applying for

When applying for a tech job, highlight your relevant skills and experience. This means you'll need to customize your resume and cover letter to the job you are applying for. Emphasize your technical skills and show achievements directly related to the role.

One of the biggest mistakes I see when reviewing applications is that there's no alignment between the role and the résumé. If the job asks for experience with JavaScript and you only have Python on your résumé, they will move on to the next candidate quickly.

Most importantly, don't give up. Finding a job in any market can be challenging, and a down market can make it even more difficult. Be persistent, and remember that it may take time to find the right job. Keep applying and networking; eventually, you will find the right opportunity.

And reach out if I can help! I'm always happy to make introductions if it makes sense.

Year-end Disk Decluttering with du and find

I take a couple of weeks off at the end of each year to pay down some personal technical debt. I look through projects and files I worked on this year and archive them, do any tweaks or upgrades to websites I manage, and see if I can declutter the hard drive.

I use two commands to do this: the du command and the find command.

du stands for "disk usage," and it allows you to see how much space a directory and its contents are using on your disk. The find command can find files based on file names or access times.

Here's how to use both commands to identify things to clean up.

First, use the ducommand to figure out where your space is going. For example, to check the space usage of the ~/Documents documents directory, run the following command:

du -sh ~/Documents

The -s' option tellsdu` to show the total space used rather than a breakdown of the space that each individual file and subdirectory takes up.

The -h flag tells du to display the space usage in "human-readable" format, with units like "KB," "MB," or "GB" rather than in bytes.

To see the breakdown of files and subdirectories, omit the `-s' flag:

du -sh ~/Documents

On macOS, you can use the -d' flag to specify how deepdushould go when it scans. For example, to see how much space the top-level files and directories within~/Documents`, you can run the following command:

du -h -d 1  ~/Documents

You can't use the -s' flag with this option though. And if you're using the GNU version ofdu, you'll use the--max-depth=1` flag instead.

Once you've identified the directories with the most files, you'll want to start clearing them out. You can start by looking for files you haven't changed or accessed in a while.

You can use the find command to look for files in the ~/Documents directory you haven't accessed in the last six months with the following command:

find ~/Documents -atime +180 -mtime +180

The -atime flag lets you see files you haven't accessed in a while, and -mtime lets you see those files that haven't changed. The +180 options are the number of days.

This shows you the files, but you can see the sizes of the files by using the -exec option and the ls command:

find ~/Documents -atime +365 -mtime +365 -exec ls -lhS {} +

The -exec option runs the specified command on the files the find command returns. The + option at the end says to send all the files to the exec command together instead of running the command once per file.

The ls command in this example uses the -l flag to show a long listing, the -h flag to show the size in the same "human-readable" format that du shows, and the -S flag sorts the results from largest file to smallest.

I've been using these tools to identify where my disk space has gone, and this method is much faster than using some of the graphical disk analysis tools out there. Hopefully you can put these tools to work for you.

We Need to Talk About the First-person Plural in your Technical Tutorials

It's common to see content creators use the first-person plural in tutorials to create a feeling of closeness or unity with the learner. "Next, we open the file and add the following lines to our program." But over the years as a writer, teacher, and editor, I've learned that there are some issues with this approach, and I no longer use it in my books and tutorials.

The main reason I hear authors pushing for "we" is that the author feels it creates an environment where the author and reader are partners, learning together. While this may work in a workshop or live session, when you're writing something, you must remember that the learner will follow it later, so you're not with them. Using "we" tries to force a connection that might not be there

In technical writing, many style guides recommend using "you" instead of "we" to address the reader because it can make the content more personal and engaging. You can see the relevant sections in the following guides:

• Google Developer Documentation Style Guide
• Microsoft Style Guide
• OpenStack's Writing Guidelines
• DigitalOcean's Style Guide (which I helped write)

Using "you" helps create a sense of direct communication with the reader, which can make the content feel more relevant and applicable. It can also make the content more actionable and clear.

On the other hand, "we" can create a sense of distance or separation between you and the learner. It can also make the writing seem less objective and more biased, as it implies that the writer is part of the group or process.

This is the most important part: You, the author, are not the one learning, so saying, "In this tutorial, we will learn how to..." is awkward when you consider that fact.

One core tenet of teaching adult learners is to keep the focus on the learner. As the writer, it's your job to guide the learner. You're the facilitator, and part of being a facilitator is taking yourself out of the process and keeping the focus on them. Using first-person pronouns in writing can make the content more about you than about them. Keep your work "learner-focused" rather than "instructor-focused" when working with adult learners.

If you're still on the fence or in violent disagreement, I urge you to try this approach anyway. The next time you write a tutorial, see how you can use "you" instead of "we" to keep that focus on the learner. You might be surprised at the clarity and impact of the results.

Parting Thoughts

This wraps up one full year of this newsletter. I have a bunch of ideas lined up for 2023, and I'm glad you're along for the ride.

See you in 2023. But until then, consider these questions:

1. If you currently have a job, what can you do to help those right now who are struggling to find work? Are there introductions you can make? Opportunities you know of that haven't been posted yet? See if you can use your connections to help someone in need.

2. If you're looking for work and you're not having much luck, what's one thing in this newsletter that you can start doing right now that you're not?

3. How would you rewrite the following sentences?

   1. "In this tutorial, we'll explore how the find command works in Linux."
   2. "Next, we'll run the following command to run our script:"
   3. "In this article, we learned how to find the processes using the most CPU."
   4. "Let's look at how our function works. First, we take in two arguments. Then we add them together. Then we return our result back to the main program."

As always, thanks for reading. And please share this newsletter with your friends.

I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.