Forem: Rouan Wilsenach

Use git bisect to see when you broke the tests

Rouan Wilsenach — Mon, 06 Sep 2021 10:41:37 +0000

I wanted to push a number of commits but my tests failed. Naughty me for not running them more often. Anyway, here's how to use git bisect to tell when they started failing.

git bisect start HEAD origin/main
git bisect run npm test

You should get a result something like:

b73399a404433af29d95fb66d7b7facc1de49aa3 is the first bad commit

And then you can run:

git bisect reset

when you're done to exit bisect mode and go about fixing things.

A bit more explanation

Here are some details if you want them.

Start

git bisect start HEAD origin/main

The syntax here is git bisect start <known-bad-commit> <known-good-commit>.

In the example above I've used HEAD as a known bad commit, because it's the latest commit. My example assumes the remote is called origin and the branch is main.

You could narrow the range further, but this will work well if your tests are fast enough, and you don't have too many commits.

Run

git bisect run npm test

The syntax here is git bisect run <command>, where command will exit with 0 if all is well and a non-zero code if not. (Read the docs if this doesn't work because there are some exceptions, but should be a fine assumption in most cases.)

If you don't have an automated way of telling whether things are fine, you can also do your testing manually. Run git bisect bad or git bisect good to mark commits as good as bad. Git will walk you through it.

Sources

https://git-scm.com/docs/git-bisect#_examples

Writing inclusive job adverts

Rouan Wilsenach — Thu, 22 Jul 2021 14:09:36 +0000

I recently spent some time helping a startup set up their technical hiring process. Diversity and inclusion are important to me and I love working at inclusive companies, so I wanted to make sure the hiring process was as inclusive as possible to help us build a diverse team.

Here are the highlights of what I learned about inclusive job adverts.

Be explicit about your desire to be inclusive

Here's an easy win. Say somewhere in your job advert that you're open to applicants from different backgrounds. This template can get you started:

[Company Name] is an equal opportunity employer. We celebrate diversity and are committed to creating an inclusive environment for all employees. We welcome applications from those typically underrepresented in tech.

Don't pretend your company is more inclusive than it is. Don't make any wild claims. Just say you'd love to hear from folks who are underrepresented – it makes a big difference to whether someone reading your job ad is likely to apply.

Optimise for clarity and transparency

What does it take for someone to go from reading your job advert to clicking "Apply"? Turns out that folks from underrepresented groups are less likely to apply for a job when the job description doesn't clearly set expectations. Here are some areas where you want to make sure you provide as much clarity as possible:

The job application process. This includes what the steps are, how long they take and how long the applicant will need to wait for feedback.
What the role entails. What will the successful candidate's average day look like?
What does the company do? What is the culture like?
Benefits and compensation
Constraints or deal-breakers. For example, is the job remote-friendly? Do you need to live in a specific country?

Don't over-specify requirements

We've all seen the classic bulleted list of requirements:

Master's degree in Computer Science
Docker
React
Node
Redux
Postgres
Woodwork
Test-driven development
Jenkins
90s Sitcom Trivia
AWS InfiniDash

How is a person looking at this list supposed to make sense of it? Do they need to have done all of it in order to be considered? What if they're super-experienced with Node and React but haven't used Redux? Are they a bad hire?

The problem with exhaustive lists of requirements is that they facilitate self-selection: the process where a candidate says to themselves "I don't meet the requirements" and doesn't apply. Research shows that women are less likely to apply for job adverts where they don't match all the listed requirements. Is Redux experience really something worth losing a great candidate over?

Rather have a short list of the requirements that really matter. Karen Catlin recommends picking the five skills your candidate truly needs and including only those. She also advises that you avoid extra-curricular requirements like a well-populated GitHub profile, as these unnecessarily filter out great candidates.

Describe experience instead of prescribing it

What makes a software engineer experienced? This question is surprisingly easy to answer wrong. I've worked with self-taught engineers who can code circles around some folks that have an M.Sc. in Computer Science. Ten years of experience could be ten years of doing the same thing repeatedly and learning nothing. Someone else might have learned everything they need to know in a few short years, while working with world-class engineers.

In the job adverts I put together, I tried an experiment. Instead of prescribing professional experience, I described it. Here's what I mean:

Traditional prescription of experience:

At least a Bachelor's degree in Computer Science or related field
5 years of software development experience
At least 2 years of experience working with relational databases

My experiment: a description of experience level

This example is for what you might call a "mid-level" engineer

There is a technical stack in which you feel confident delivering features
You have a broad base of engineering skills and have started to deepen your knowledge in one or two areas
You're able to contribute to technical conversations about how to solve problems
You ask questions about whether you're building the right thing, rather than just about how you're building it
You've made some technical mistakes and learnt from them

This way, you're building a clear picture of where a person should be at in their career. You're talking about how you might judge someone's experience, rather than providing a box-ticking experience. This approach lets the candidate see what's important to you. If you've got well-articulated descriptions of your company's job grades or salary bands, you might find something there you can re-purpose. As a bonus, this may make salary negotiation fairer because the job requirements will be aligned with your internal promotion and pay processes.

It is also worth including some wording that encourages folks to apply even if they don't meet all the listed requirements.

Use some objective analysis

Turns out people have done some research into the kind of language turns people away from job adverts. For example, the words we use are subtly "gender-coded". The research shows that you'll turn women away if your job description that is full of masculine-coded words.

There's a great online tool you can use to highlight gender-coded language in your job description. If you have too much masculine language, you can spend a little time rewording things to be more inclusive.

For the startup I helped, it turned out the job adverts were "strongly masculine-coded". Some example words included: "leading", "competitors" and "decide". Remember that none of the words are inherently bad. It's just that, once you have enough of them, your description starts to put people off applying for your job. Rather drop them and appeal to a broader audience. As a plus, the research shows the number of "feminine-coded" language in a job description has no impact on the number of male applicants.

Ask for feedback

Okay, so you've spent some time improving your job advert. Now test it. Reach out to your network and find some people who match the demographic you're trying to reach. Show them your job adverts and ask them how it makes them feel. Implement their suggestions. They'll also let you know if you've said something silly.

Better job adverts lead to better candidates

Turns out the trick to attracting applicants from underrepresented backgrounds is simply to write a better job description. If you want to attract the many fantastic software engineers from underrepresented backgrounds, you need to put in a bit of work and create a better job advert. Be clear, be concise and be objective.

Resources

I'd recommend you read The “Better Allies” Approach to Hiring. It's a great resource, with practical tips (checklists, even) for making your overall hiring process more inclusive.

TIL: Add your git repo to a tarball

Rouan Wilsenach — Tue, 23 Feb 2021 20:04:41 +0000

Today I learned that you can neatly pack all of the files in your git repository into a tarball:

git archive --format=tar -o my_repo.tar -v HEAD

The best thing about this is it will automatically honour your .gitignore file, so won't include any files you don't care about.

Other formats

It also works with zip files:

git archive --format=zip -o my_repo.zip -v HEAD

Excluding files

In order to exclude files from the archive, you can specify them in a .gitattributes file. Here's an example that excludes the README.md file from the export:

README.md export-ignore

Including the git repo itself

It doesn't include the git repository itself (the .git directory). If you'd like to include it, you can run:

git archive --format=tar -o my_repo.tar -v HEAD
tar -rf my_repo.tar .git

Sources

Want to be a better developer? Work somewhere inclusive.

Rouan Wilsenach — Wed, 03 Feb 2021 11:41:02 +0000

When we fail to welcome diversity, we're missing out on being better at software engineering.

The skills you need to thrive in an inclusive workplace are the same skills that will make you an amazing software developer. So not only do we have teams where diversity is not valued – the developers in those teams are missing out on the chance to be so much better at their jobs!

The skills that make you inclusive and awesome

Let's break this down. I'm going to show you three skills you need in order to succeed in a diverse workplace – three skills that will also make you a stand-out software developer.

Communication

If the person you're talking to comes from a different background, you might have a harder time understanding them or getting your point across. When you don't share the same childhood experiences, don't watch the same TV shows or live in the same country, you have to make a special effort to understand each other.

This requires a really good communication skillset. The same skillset that is great for explaining technical topics to people without a technical background, onboarding a junior developer or finding the right way to present data to a user.

Empathy and imagination

Working effectively with someone different from yourself requires something we often call empathy – the ability to see things from their perspective.

Empathy also helps you:

Collaborate with co-workers playing different roles e.g. product management, design, legal, sales
Better understand what your users or customers need from the software you're building (spoiler: your user base is likely very diverse)
Guide someone you mentor as they try to visualise a career path or a find a resolution to a difficult situation
Review code well - this requires the ability to understand what the person was trying to achieve through the code they wrote

Here's where I think things get really interesting. At its core, empathy is an act of imagination. To truly understand someone, you need to put yourself in their shoes and see the world like they do. It's easy to leap from here to the general value of imagination in the workplace – imaginative thinkers are better problem solvers, more creative, more resourceful.

But this extends to writing code too:

Writing software is in many ways creating something out of nothing and for that you need a bit of imagination to understand what it is you're trying to create
Debugging software requires the ability to imagine what's happening in the computer's memory
Software design is often about creating useful abstractions. These act as metaphors for a system and you need to use your imagination to create them and understand them.

Self-awareness

How do you see yourself? Are you aware of your strengths and weakness? Of your prejudices and biases? Of how you come across? Being able to answer these questions is crucial to working effectively with people from different backgrounds and is also the bedrock of a good software engineering career.

Knowing yourself will allow you to better plan your career, know the skills you need to build and gather the right feedback to support your learning. It will also help you understand the adjustments you need to make to respond to different situations (e.g. a new project, a tough job interview, learning a new UI framework).

A fuller bookshelf

Not only will working in an inclusive workplace help you gain the skills above, but I've found that working with people from a variety of backgrounds gives you a much broader range of skills to draw from, to lean on and to enjoy learning from. If you imagine the skill-set of your team as a bookshelf with each book representing a skill, a diverse team means you get to work with a much fuller bookshelf.

Good engineering and diversity are on the same path. Are you?

If you're hiring software developers and you think you have to make a choice between hiring a diverse team and a good team – think again.

If you're a software developer looking for your next role (irrespective of your background) look to work in as diverse a team as possible and favour employers seeking to build an inclusive workplace.

I believe there's a strong ethical argument for us to demand inclusivity as a core practice from our employers, but even on a personal level doing so will give you the opportunity to work with people that can teach you some of the most valuable (and rarest) skills in the tech industry.

Photo by Christina @ wocintechchat.com on Unsplash