Twenty years ago today, Joel Spolsky (who later co-founded Stack Overflow) published The Joel Test: 12 Steps to Better Code listing 12 metrics for rating the quality of a software development team. The premise is simple: you get 1 point for each “yes” answer, for a total score of up to 12 points.

It’s presented a bit tongue-in-cheek: he freely acknowledges it as “sloppy” and even “highly irresponsible”. But the list resonated with so many software developers that it’s still commonly in use today. Many job posts still include their “Joel Score” as a signal to developers that they care about the health and quality of their team.

Here at Tighten, we regularly discuss (and publish) our opinions about what makes a good software team, and how to maximize our own team’s health, productivity, and happiness. So we thought it would be fun to celebrate the 20 year anniversary of this iconic post with our own twist on it—heavily opinionated, based on our shared values, and sourced from our experience as web and app developers who regularly work with a variety of different software organizations.

The Tighten Test

1. Do you work 40 hours a week or less?
2. Do you set aside time at work for learning?
3. Do you have the tools you need to get the job done?
4. Do you keep an up-to-date list of prioritized tasks/tickets?
5. When new features take longer than expected, do you cut their scope and/or extend the timeline?
6. Do your codebases have up-to-date written setup and deployment instructions?
7. Do you write great commit messages and pull requests?
8. Is all incoming code automatically linted and tested?
9. Is all incoming code reviewed by someone who didn’t write it (or written while pairing)?
10. Do your local and staging environments match production as closely as possible?
11. Are you automatically notified about errors in production?
12. Do you deploy to production at least once a week?

As with the original test, 12/12 is a perfect score, 11 is tolerable, but 10 or lower and you’ll start noticing problems. Joel also noted that most software organizations are running with a score of 2 or 3.

---

1. Do you work 40 hours a week or less?

This one should be self-explanatory: the easiest way to ensure people are happy is to give them time to enjoy their life and maintain their health. There are many studies about the negative effects on health caused by overworking, and employees who are healthy tend to be happier and more productive. Some companies like Microsoft have even been experimenting with four-day workweeks in recent years—and seeing boosts in productivity.

At Tighten we don’t have a four-day workweek (yet? 😉), but we’ve been taking 20% time on Fridays since 2016: more on this in the next section. We also don’t work overtime.

2. Do you set aside time at work for learning?

It’s one thing to be a good developer, but to stay a good developer you have to constantly learn new things and also keep your existing skills sharp. While it’s impossible to learn everything, the best software development teams make some space for learning at work.

As mentioned, at Tighten we dedicate a day every week to learning and teaching: on Fridays we contribute to open source, read or watch tutorials, write blog posts, etc., instead of our usual client work. But you don’t need to set aside an entire day—there are other ways to make space for learning, like encouraging pair programming to spread knowledge around, including time for research in your tasks, and arranging internal talks within your team.

3. Do you have the tools you need to get the job done?

If someone on your team needs a license for something, can they get it? If you need specific office equipment—like an ergonomic desk or keyboard—will your company provide it for you?

Some developers manage to produce amazing work on old, slow laptops—or even a paper and pencil—but if your company’s business depends on your software, everyone on your team needs hardware that won’t slow them down, software to make them more productive, an office setup that maximizes their physical well-being, and space to take care of their mental health.

4. Do you keep an up-to-date list of prioritized tasks/tickets?

Joel’s original test included “Do you have a bug database?”, but we wanted to stress the importance of regularly prioritizing tickets at the top of your list. Working on the right thing is more important than doing good work on the wrong thing, so make sure your team is regularly re-ordering tickets so developers are always picking up the highest priority task.

5. When new features take longer than expected, do you cut their scope and/or extend the timeline?

In our experience, setting deadlines based on estimates doesn’t work, since estimates are merely a guess at what might happen in the future; not only is software complex and unpredictable, but requirements and priorities change all the time. Deadlines also tend to be the primary cause of overtime; many teams “crunch” to hit a due date, which can jeopardize team members’ physical & mental health.

Instead of estimating and pretending to know the future, we just do our best work every day and keep in close communication with our clients so everyone always knows the status of the project. If a client has a target to hit, we work with them to cut the scope of the requested feature—fans of agile practices will be familiar with this tactic—to ensure a usable, simpler version of what they need will be done with time to spare. If there’s time left later, you can always go back and add more to a feature.

Cutting scope allows us ship to production early and often, get feedback on features from real users faster, and save a lot of time by not developing and maintaining complex additions when users end up needing something different than expected.

6. Do your codebases have up-to-date written setup and deployment instructions?

How long does it take a new developer to get set up with your codebase? Without written instructions, it might take anywhere from a few days to a few weeks.

Since we work with a variety of clients, we’re constantly the new developers on a project—and while not having written instructions doesn’t necessarily mean your code is bad, we find that well-documented codebases are a good indication of regular maintenance and care for the project. Written instructions also help your team internally: for example, they can make a huge difference if the only person who knows how to deploy leaves the company.

7. Do you write great commit messages and pull requests?

While Git history might not be as important on solo projects, it matters a lot on a team. As frequent newcomers to a project, commit messages are invaluable in helping us understand why changes were made and how they relate to each other, without needing years of context or domain knowledge.

Understanding existing code is often the most time-consuming part of a development task. Once someone on a team wraps their brain around a programming challenge, it would be silly to have other developers spend that time again when they review or change the same code—but that’s exactly what happens when you leave commit messages and PR descriptions blank. The moment you submit a PR, you have more context about the task you’re working on than anyone else, so write it down while you remember! This will save time for everyone else: people who review your PR, new developers in the future who dig through Git history, and even future you when you can’t remember the details.

Great pull requests should also be digestible: ideally containing visual demonstrations, and small enough to be reviewable in 30 minutes or less. Since PR reviewers don’t have as much context as the developer who worked on a task, reviewing a huge PR can be disproportionately time-consuming.

8. Is all incoming code automatically linted and tested?

Disagreements about code style happen on every development team, but that’s no reason to let them get in the way of getting work done. Pick a style (preferably the standard in whatever language you’re using) and use linter and/or fixer tools to enforce it automatically, and never waste time arguing about code style again. You can fix your entire codebase in one go and ignore the commit in Git blame to maintain a useful history. As an added benefit, all future code changes will be easier to review since your diffs won’t be cluttered with meaningless changes to code style.

Running automated tests against all new code is also essential. Existing tests make sure new code hasn’t broken anything, and new tests protect new code from breaking in the future. The amount of code covered by tests matters too: most of it should be covered (though 100% coverage is often more trouble than it’s worth). Running an automated test suite with one test is better than nothing, but ultimately not enough to give you confidence that your app still works.

9. Is all incoming code reviewed by someone who didn’t write it (or written while pairing)?

One way we ensure that our code is of the highest quality possible is by always having a fresh set of eyes look it over before we consider it “done”.

Whenever possible we work in two-person teams, with each developer reviewing the other’s PRs on GitHub before they’re merged. We also have a strong pair programming culture here, where two developers will work together on the same code simultaneously while sharing screens over Zoom or some other tool.

Particularly when building large or complex features, pair programming often results in superior code compared to code that was written solo—not only because it helps weed out errors before they make it into a commit, but also because pairing allows the developers to reason through design decisions together in real-time, in a deeper and more meaningful way than is possible during a conventional code review. Plus, pairing can be a ton of fun, and is a great way to learn from one another!

Either way, whether through pairing or a GitHub-based code review of a PR—when it comes to code quality, four eyes are always better than two.

10. Do your local and staging environments match production as closely as possible?

Developing on different framework, language, database, or operating system versions will almost certainly cause unnecessary friction (“It works on my machine!”). Limiting the differences between environments also limits time wasted on errors caused by mismatched software versions. If you use build scripts and dependency managers (like Composer), you can update dependencies automatically in all environments, and take advantage of new language or software features everywhere.

Using tools like Docker, you can go even further and have your environments match exactly. If your local, staging, and production environments are identical, developers can prepare the application for the exact environment in which it will run. And with continuous integration and deployment (CI/CD), updates to the project and environment can be built, tested, and shipped the same way.

11. Are you automatically notified about errors in production?

Nobody writes bug-free code, and you can’t fix errors you don’t know about. Make sure any errors that occur in production are reported somewhere the whole team can see. Many legacy PHP apps silence errors altogether, which is even worse—silencing an error doesn’t make it go away! There are plenty of bug reporting services like Bugsnag and Sentry that give you a full stack trace, request & session data, and all the context you’ll need to fix most errors, as well as configurable notification channels like Slack.

12. Do you deploy to production at least once a week?

The timeframe is arbitrary; the important thing here is that you’re deploying to production frequently. Deploying shouldn’t be a big, scary event: if you do it often enough, if your deployments happen automatically after tests pass, and if you report errors in production there’s really not much to worry about. Modern continuous integration (CI) pipelines make it easier than ever to deploy automatically. We use tools like GitHub Actions and Laravel Envoyer to deploy to production every time we push code and our tests pass.

---

If you don’t meet all of these guidelines today, don’t worry! They simply serve as a set of goals our team has agreed to work toward, because they make us happier and more productive developers. We hope they’ll do the same for you.

Thanks to @dhicking for the original half-baked idea behind this post, and @jakebathman, @keithdamiani, and @marcusamoore for contributing content & reviewing.

We LOVE Costco! We love the product selections, we love the prices, we love the food court, we love the fuel discounts, we love car rental prices, and more. If you’ve don’t have a Costco Membership, this is the deal you’ve been waiting for.

Groupon is offering a Costco Membership Deal that you don’t want to miss!

For a limited time, you can purchase a One-Year Costco Gold Star Membership Package which includes a $40 Costco Shop Card and $40 Off Online Order for just $60! 

This offer is valid for NEW members, or for prior members whose memberships expired prior to April 1, 2020. This deal is not valid for membership renewals

Costco Membership Deal details

The deal includes a one-year Costco Gold Star membership for $60 (regular price), but includes a cash card and coupons that make it worth trying out the membership. Even if you only shop in-person at Costco and use the $40 gift card, you’ll only pay $20 for the membership.

• A One-Year Costco Gold Star Membership with auto-renewal of the Costco membership using a Visa® credit or debit card. It’s easy to cancel your Costco membership before or right after the renewal – they will prorate your refund at any time during your regularly priced membership.
• A membership card for the Primary Cardholder and one additional Household Card for anyone living at the same address, over the age of 18
• A $40 Costco shop card (gift card is valid towards any purchase, including gas). This is an amazing offer! 
• $40 off any order of $250+ on Costco.com

Why I love Costco

We have had a Costco membership for over 10 years – even when we were just a 2-person family. Now that we have 2 children, the amount of money we’ve saved on groceries, household goods, clothing, diapers, beverages, vacation car rentals, insurance, new tires, and more is WAY more than we’ve paid for our membership. 

Did I mention the clothing? I should be embarrassed by how much clothing I’ve purchased from Costco, but I’m not. The clothing rotates regularly, and they offer clothing and shoe brands such as Adidas, PUMA, Free People, Champion, Columbia, Eddie Bauer, Hunter (including Boots at times!), Tom’s, Buffalo, Lucky Brand, Nautica, and more. They also carry fine jewelry, designer bags, and more. I love that you can order the clothing online with free shipping, and return to the store if I don’t like it. 

Costco’s return policy is one of the best in the biz. They offer no-questions-asked returns for most items that they sell at any time (select electronics excluded).

Once you purchase the deal, you’ll have to go online to activate (it’s super easy).

Costco often has GREAT deals on holiday gifts for all ages, so now is the perfect time to join!

Other articles of interest

Laravel has a new Broadcaster: Larasocket. Today, we are going to see how we can use Larasocket with Tailwind, Alpine, and Livewire to build a beautiful, and lightweight real-time chat room. You can view the complete tutorial here.

What is the TALL stack?

Tailwind: Made by Adam Wathan. A powerful, lightweight, CSS library made up of utility classes. Utility classes offer all the power of normal CSS in a class-based interface for developers. Need to add margin-right? Just add the class mr-{amount}

Alpine: Made by Caleb Porzio. A lightweight javascript library for simple client-side logic without needing the bulky Vue or React frameworks.

Livewire: Made by Caleb Porzio. A powerful library to help the abstract client to server communication. Need to make an AJAX request to submit a form? Not anymore. Livewire offers an easy way to call PHP code, right from the clients, as well as re-render to UI based on backend changes.

Laravel: From laravel.com: “Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.”

Getting Started

We can quickly get started using a few helpful commands on the CLI:

laravel new larasocket-tall-demo
cd larasocket-tall-demo
composer require livewire/livewire laravel-frontend-presets/tall
php artisan ui tall --auth

For any Laravel application that uses Broadcasting, we need to uncomment this line in config/app.php :

// App\Providers\BroadcastServiceProvider::class,

Broadcasting with Larasocket

Now that our Laravel application is off the ground, let’s bring in Larasocket to use as our broadcaster. It’s free to get started 💪

composer require larasocket/larasocket-driver
npm i laravel-echo larasocket-js

Over in config/broadcasting.php we need to add the Larasocket driver as an option:

'larasocket' => [
    'driver' => 'larasocket',
    'token' => env('LARASOCKET_TOKEN'),
],

And let’s update bootstrap.js to use Larasocket instead of the default Pusher:

import Echo from 'laravel-echo';
import Larasocket from 'larasocket-js';

window.Echo = new Echo({
    broadcaster: Larasocket,
    token: process.env.MIX_LARASOCKET_TOKEN,
});

The last thing we need to do for Larasocket is to update our .env file:

BROADCAST_DRIVER=larasocket
LARASOCKET_TOKEN=<token>
MIX_LARASOCKET_TOKEN="${LARASOCKET_TOKEN}"

Just remember to replace <token> with your token from Larasocket. They are free!

Chat

Time for the fun part, building our chat room.

php artisan make:model Message -m
php artisan make:event MessageSentEvent
php artisan make:livewire ChatRoom

We can now update the newly createdcreate_messages_table migration with:

Schema::create('messages', function (Blueprint $table) {
    $table->id();
    $table->text('body');
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->timestamps();
});

We are all done making database changes so let’s persist these:

php artisan migrate

Let’s add our column and relationship to Message.php:

class Message extends Model
{
    protected $fillable = [
        'body'
    ];

    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

Over in User.php we can add the messages relationship:

public function messages()
{
    return $this->hasMany(Message::class);
}

Laravel Events provide a great interface to send data in the socket messages. Let’s update our newly created MessageSentEvent to pass along the needed data:

class MessageSentEvent implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;
/**
     * @var Message
     */
private $message;

/**
     * Create a new event instance.
     *
     * @return void
     */
public function __construct(Message $message)
    {
        $this->message = $message;
    }

/**
     * Get the channels the event should broadcast on.
     *
     * @return \Illuminate\Broadcasting\Channel|array
     */
public function broadcastOn()
    {
        return new PresenceChannel('demo');
    }

/**
     * JSON data to broadcast with this message
     */
public function broadcastWith()
    {
        return $this->message->toArray();
    }
}

Later on, we will dispatch this event when the user submits their message.

Important: don’t forget the implements ShouldBroadcast! This interface tells Laravel to use the Broadcaster to send out socket messages using whichever driver you have configured.

There is just one last task before our backend is ready. We need to secure the demo channel using routes/channels.php:

Broadcast::channel('demo', function ($user) {
    return [
        'id' => $user->id,
        'name' => $user->name,
    ];
});

Front-End

Remember that ChatRoom Livewire component we made earlier? It is now time to put it to work. The first thing we need to do is create a new route in our routes/web.php file:

Route::livewire('chat', 'chat-room')->middleware('auth')->layout('layouts.auth');

When you have a simple route and don’t need a method in a controller to return your view, you can use Route:view('path', 'myview') as a route.

Laravel Livewire comes with a nifty helper that is very similar: Route::livewire('path','mylivewireviewcomponent'). This is what we are using above.

Next, let’s build out the functionality:

class ChatRoom extends Component
{
    public $messages = [];
    public $here = [];

    protected $listeners = [
        'echo-presence:demo,here' => 'here',
        'echo-presence:demo,joining' => 'joining',
        'echo-presence:demo,leaving' => 'leaving',
    ];

    public function render()
    {
        return view('livewire.chat-room');
    }

    public function mount()
    {
        $this->messages = Message::
with('user')
            ->latest()
            ->limit(30)
            ->get()
            ->reverse()
            ->values()
            ->toArray();
    }

    public function sendMessage($body)
    {
        if (! $body) {
            $this->addError('messageBody', 'Message body is required.');
            return;
        }

        $message = Auth::user()->messages()->create([
            'body' => $body,
        ]);

        $message->load('user');

        broadcast(new MessageSentEvent($message))->toOthers();

array_push($this->messages, $message);
    }

/**
     * @param $message
     */
public function incomingMessage($message)
    {
// get the hydrated model from incoming json/array.
$message = Message::with('user')->find($message['id']);

array_push($this->messages, $message);
    }

/**
     * @param $data
     */
public function here($data)
    {
        $this->here = $data;
    }

/**
     * @param $data
     */
public function leaving($data)
    {
        $here = collect($this->here);

        $firstIndex = $here->search(function ($authData) use ($data) {
            return $authData['id'] == $data['id'];
        });

        $here->splice($firstIndex, 1);

        $this->here = $here->toArray();
    }

/**
     * @param $data
     */
public function joining($data)
    {
        $this->here[] = $data;
    }
}

Laravel Livewire is doing a lot behind the scenes for us.

First, note the protected $listeners array. Livewire uses this array to automatically subscribe to channels (uses Echo, in Javascript) for us. You can read more about that here. We will use the standard here, join, leaving presence channel events to keep track of who is in the chat room.

Currently, there is a Livewire bug that limits the presence channels we can subscribe to. It only allows those 3. Not a problem, we will leverage Alpine to easily subscribe to more channels in the Javascript. Let’s create the UI to go with our ChatRoom. In chat-room.blade.php let’s update it with:

@section('title', 'Larasocket Demo')

<div
    class="mt-4 bg-white rounded-lg shadow-md p-6"
    x-data=""
    x-init="
            Echo.join('demo')
                .listen('MessageSentEvent', (e) => {
                    @this.call('incomingMessage', e)
                })
            ">

    <div class="flex flex-row flex-wrap border-b">
        <div class="text-gray-600 w-full mb-4">Members:</div>

        @forelse($here as $authData)
            <div class="px-2 py-1 text-white bg-blue-700 rounded mr-4 mb-4">
                
            </div>
        @empty
            <div class="py-4 text-gray-600">
                It's quiet in here...
            </div>
        @endforelse
    </div>

    <template x-if="messages.length > 0">
        <template
            x-for="message in messages"
            :key="message.id"
        >
            <div class="my-8">
                <div class="flex flex-row justify-between border-b border-gray-200">
                    <span class="text-gray-600" x-text="message.user.name"></span>
                    <span class="text-gray-500 text-xs" x-text="message.created_at"></span>
                </div>
                <div class="my-4 text-gray-800" x-text="message.body"></div>
            </div>
        </template>
    </template>

    <template x-if="messages.length == 0">
        <div class="py-4 text-gray-600">
            It's quiet in here...
        </div>
    </template>

    <div
        class="flex flex-row justify-between"
    >
        <input
            @keydown.enter="
                @this.call('sendMessage', messageBody)
                messageBody = ''
            "
            x-model="messageBody"
            class="mr-4 shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            type="text"
            placeholder="Hello World!">

        <button
            @click="
                @this.call('sendMessage', messageBody)
                messageBody = ''
            "
            class="btn btn-primary self-stretch"
        >
            Send
        </button>
    </div>
    @error('messageBody') <div class="error mt-2"></div> @enderror
</div>

Note that we are using Tailwind to help construct a pleasant UI, easily. Tailwind provides a nice library of CSS classes to easily update margin, padding, borders, display, colors, everything, and anything. Styling our elements in using Tailwind has a few key advantages:

1. Lightweight
2. Readable class names
3. Standardizes styling across organizations
4. Customizable
5. More

We are now ready to give our application using the Tailwind, AlpineJS, Livewire, and Laravel stack a go.

Let’s compile our front-end assets:

npm install
npm run dev

… and run our server:

php artisan serve

You can navigate to http://127.0.0.1:8000/chat and start playing with Larasocket and your chat room.

Related:

1. Building a real-time chat application with Laravel and Larasocket
2. Laravel Broadcasting in 2020
3. Larasocket: Laravel’s Newest Websocket Broadcasting Solution

All throughout the nation, people are calling for the destruction of anything and everything they can see that might even be minutely related to slavery and racism that permeates so much of American history.

While this racism is typically overstated to some degree, any honest look at our nation’s history has to acknowledge that racism has been a part of that history. It’s been there for far too much of our country’s time on this planet.

These days, the destruction of statues has been the predominant way of pushing back against that history, yet there’s another racist legacy that still exists in this country.

The funny thing is, the people ripping down the statues? They tend to support that legacy.

In particular, gun control. Check out this video from The Daily Caller.

None of this was new to me. I’ve seen it all before and it’s correct. Gun control rose out of a desire to see black men and women be unable to fight back against the racism that surrounded them.

Here in Georgia, up until 2010, it was illegal to carry a firearm at a “public gathering.”

The history of that law stems from an incident during Reconstruction. A number of black legislators had been removed from their offices illegally. In Camilla, Georgia–not too far from my own home, actually–a group of African-American men and women decided to march to a Republican rally as part of a protest.

In the woods along the march route, white men with guns opened fire, killing about a dozen people and injuring as many as 30 others. In response, many of the marchers got guns of their own.

The incident was known as the Camilla Massacre and, in response, lawmakers made it illegal to bring guns to any public gathering.

You see, gun control was passed in this era with a nod and a wink. It was understood that no white sheriff or prosecutor would go after a white man carrying a gun illegally, only the blacks. It was a decision meant to unevenly apply laws so they only hurt one portion of the population.

Even today, such laws still have a similar effect.

While police routinely apply the laws against anyone who breaks them–at least in theory–these laws have a disproportionate impact on African American men and women. They’re the ones who are typically hamstrung in their attempts to lawfully purchase firearms. They’re the ones killed because they couldn’t buy a gun to protect themselves and their families. And yeah, they’re the ones prosecuted for violating gun control laws when they step outside the system.

If these protestors are serious about destroying all of America’s racist legacy, then why don’t they join us in standing against this particular racist legacy? Some of us–the very people they typically call racist bigots, I should add–have been opposing this particular legacy for years now. We’d love to welcome them to the fold so we can eradicate this particular blight from our nation.

Somehow, though, I suspect none of them are interested. What a shame.

By Robert B. Young, MD

I routinely castigate lousy research by prejudiced academics who make their careers publishing poorly designed, illogically interpreted studies claiming that guns are bad and that widely restricting their ownership will solve society’s problems. I get tired of it, like anyone would covering the same fake news over and over. So it is really refreshing to review the rare study that gets it right from start to finish.

“Effect of firearms legislation on suicide and homicide in Canada from 1981 to 2016”  was published June 18 in PLOS One by DRGO member Cailinn Langmann, MD. PLOS One is an open access, but peer reviewed online journal. Dr. Langmann has reviewed a number of others’ work for DRGO, correcting their misattribution and bringing light to the world. Here, he takes them on with his own work.

I encourage you to go to the article itself, but here’s the summary. Canada has “progressively” taken the lead over the U.S. in piling up increasing restrictions on gun ownership, notably in federal laws from 1991, 1994 and 2001. Dr. Langmann looked at homicide and suicide rates from 1981 through 2016, which gave unequivocal before, during and after comparisons.

The results: “No associated benefit from firearms legislation on aggregate rates of . . . suicide” was found for either males or females, though there were increases in rates of hanging suicide and poisoning. “No beneficial association was found between legislation and female or male homicide rates.” On the other hand, “an increased association with suicide rates was found with rates of low income, increased unemployment, and the percentage of aboriginals.”

All his data is public and readily available online, unlike the common problem with other researchers generating data but unwilling to share it in order for others to confirm its validity and appropriateness. There is no researcher-defined case control nonsense here—Langmann analyzes his data as a whole, over time (including sub-sections defined by the three points of new laws), and by age groups and sex. He chooses his topics for regression analysis well, uncovering significant associations with unemployment, poverty, pre-existing high suicide rates, and prevalence of Native Canadians.

The approach is important, too, because its validity underlies the results’ validity. Biased researchers focus only on the rate of use of firearms in suicide and homicide. And (surprise!) “gun deahts” decline with less availability of guns. But they pay no attention to the only changes that matter, overall suicide and homicide rates because of all the ways people can choose to end their lives or others’.

A valuable side-result of work that does, like Langmann’s, is to substantiate the societal reality of means substitution. Yes, the degree of lethality of methods matters a great deal at the decisive moment—it is important to find just ways to separate suicidal individuals from guns (and high places, etc.) when there is an acute risk.

Each life counts, and saving one is a great thing. But on a population basis, there is no difference with or without firearms over time. Rational thinkers know this anyway, because there are other countries with little civilian gun access in which suicide rates dwarf ours.

Add to this finding the fact that violent crime does generally rise in the absence of firearms owned by civilians and their consequent inability to defend themselves.  Just look at the United Kingdom, or any of a number of long-time Democrat-controlled American cities where gun control has resulted in too many (criminal) guns on the street versus none in victims’ hands. Guns owned responsibly are not a cause of suicide, homicide or other violent crime.

Let’s wrap up with Langmann’s own conclusions:

• It’s true “gun control methods to reduce suicide by firearms may have benefits”—but only in reducing suicide by firearms, not overall.
• “No associated reductions in homicide with increasing firearms regulations suggests alternative approaches are necessary to reduce homicide by firearm.” These would include:
• “Steps to reduce youth gang membership and violence through diversion and educational programs”;
• “[C]ommunity based suicide prevention programs such as training of family physicians in the detection and treatment of depression and [non-judgmental] discussions about firearms, campaigns aimed at increasing awareness about depression, and follow-up of individuals who attempted suicide”; and,
• “Outreach to groups for which access to care may be a particular issue, such as Aboriginals”.

The truth is out there, for those who have eyes to see it. Just follow the science—the good science, like this.

 

DRGO Editor Robert B. Young, MD is a psychiatrist practicing in Pittsford, NY, an associate clinical professor at the University of Rochester School of Medicine, and a Distinguished Life Fellow of the American Psychiatric Association.

This article was originally published at drgo.us and is reprinted here with permission.