loading...

"Can't we just...?"

nimmo profile image Nimmo Updated on ・2 min read

Want to go to the moon? Just fly there.
Want to spend all of your free time doing whatever you like? Just quit your job.
Want to be in a band? Just start a band.
Want to write a blog post? Just write one.
Want to have steak for dinner? _Just do it. Two minutes' work, done.

It's easy for most people to see why you can't just fly to the moon, or just quit your job.

But you may be thinking that you can just start a band.

It's reasonable to just write a blog post.

And anyone can cook a steak, right?

People don't like having their achievements trivialised. So why are we quick to trivialise problems that we need to solve?

Perhaps it's misplaced optimism. But the word "just" is a quick way to trivialise someone else's workload, or the tasks you're asking them to complete.

It's easy to accidentally increase someone's stress levels by telling them to "just do x". Consider these two questions:

"Can you just write a blog post on service testing?"

This tells the other person that you don't appreciate what you're asking them to do.

"Can you produce a guide on service testing?"

That's more like it. You'd never have asked Einstein to just prove atomic theory.

===

Further info:

The thing that made me think more seriously about "just" and its over-representation within our language at work was Evan Czaplicki's fantastic Strangeloop talk earlier this year, about the hard parts of open-source. I highly recommend giving it a watch!

Posted on by:

nimmo profile

Nimmo

@nimmo

I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.

Discussion

markdown guide
 

I've tried to stop using the word "just". There was a post a while back talking about it as well, it really is a problem when we use "just" because it's never just that easy :P

dev.to/marcuscreo/the-4-letter-wor...

 

Thanks for sharing - I'll give that a read! :-)

 

The documentation bit is interesting because often, as with code, an improvement to documentation means making it shorter. Or spending hours understanding all the contingencies and edge cases enough to feel comfortable directing users to do a single thing.

 

Yeah, I understand where you're coming from. Our situation though is that we're a team with remote workers (one of whom is myself!), and a lot of domain-specific stuff that should have been documented just wasn't.

Something I'm pretty keen on is thinking about things from the perspective of someone on their first day, and this thought process re: "just" has really helped highlight things that could and should be documented, but weren't.