DEV Community

Cover image for Three Arguments for Why You Should Write More
Marek Zaluski
Marek Zaluski

Posted on

Three Arguments for Why You Should Write More

Let me try to convince you to write more.

I don't mean write more code. I mean write for humans.

There's a huge benefit to getting good at writing as a developer. And all it takes it practice.

You don't have to be a good writer to write. In fact, it's the opposite: you have to write a lot first, and then with time it becomes easier and easier.

Being good at writing isn't about writing high-quality stuff at all. Quality doesn't matter. You can have a crappy blog post and that's infintely better than no blog post at all.

The goal of practicing writing is not to write high-quality material. The goal is to get efficient and fast at getting your thoughts into text. It's a skill that's for you first, and for the reader second.

The more you write, the easier it will feel to just open up a blank page and write.

You might tell me: I'm not a writer, I'm a developer. I don't have time for writing. Well, then this post is for you. Let's jump into 3 arguments for why you should do it.

An argument for the collaborators

Writing is the most powerful way to boost your value as a collaborator.

Most software teams aren't bottlenecked by how much code they're writing. They're bottlenecked by the bandwidth of the communication between team members.

Here's a good strategy for any team of developers: over-communicate. You can't go wrong with over-communication, because you will eliminate a LOT of problems due to misunderstandings or miscommunications.

Here are important things that you can do that involve writing:

  • Share progress reports with the rest of your team
  • Write tutorials and onboarding checklists to help new team members get up to speed
  • Describe obstacles that you encountered and how your team solved them
  • Make bug reports better by writing about the fixes, the trade-offs and the lessons learned

If some of your team members are remote, or if sometimes people on your team work from home, then written over-communication becomes critical.

If you're having in-person conversations at the office and things don't get written down, then the team members who are absent are going to miss out on important information.

Slack messages are OK for short-term ephemeral communication. But if you want your team to get serious about collaboration, write things down for real. I mean outside of Slack: in a knowledge base, a wiki, or a documentation repo. Somewhere where you have to lay out your thoughts in a structured way.

An argument for the competitors

Maybe collaboration doesn't get you motivated.

Maybe you're competitive and you're more focused on career advancement right now.

Getting good at writing as a developer is a remarkable way to stand out from the crowd.

Communication is a skill that's overlooked a lot by developers. From the many conversations that I've had about this, I suspect that a lot of developers get into this line of work precisely because they'd rather interact with computers than with people. If you're competitive and you want to get ahead in the career game, then writing can be a huge advantage.

Start a blog. Write about your projects. Share what you're learning with the world. These are powerful tactics for career advancement. This is how you get noticed and how you get your foot in the door at your dream company.

An argument for the introverts.

I call this argument "for the introverts" for lack of a better term, but that's not exactly what I mean.

Here's what I actually mean. If the above two arguments don't do it for you, then just write for yourself.

A large part of software development is problem solving. And problem solving starts with identifying and verbalizing what kind of problem you're looking at in the first place.

Describe the problem. Write it out. It'll force you to really think about what you already know, what you need to find out, and how to put the pieces together.

It's amazing how much simpler most problems start to look once you write them out. Sometimes you figure out a solution before you're even done writing the problem down.

It's like the concept of rubber duck debugging. It's helpful to talk through a problem with someone, because the act of talking helps your brain map out what's going on and it gets you closer to a solution.

Writing is even better than talking to a rubber duck. It gives you a record of the problem that you can return to in the future. And you can share it with others who are facing a similar problem. That's a huge win right there.

It doesn't actually matter what you write

I tried to lay out 3 perspectives on writing, to appeal to different motivations that might speak to you.

Here's something that I've learned: if you want to get good at writing, it doesn't actually matter what you write. Just write.

The practice adds up. And let me reiterate: don't worry too much about the quality of your writing. That kind of worry is what causes writer's block. I like Seth Godin's advice on this. He says: write like you talk. Nobody ever gets talker's block.

Don't know what to write about? Pick things from your own daily experience. Write about what you learned today.

Don't have anywhere to post it? Post it on dev.to.

If you do this every day or every week, I guarantee that your writing ability will improve fast. It's all about quantity and consistency.

Top comments (35)

Collapse
 
phoinixi profile image
Francesco Esposito

Thank you for sharing this! Very motivational 🙂

Don't have anywhere to post it? Post it on dev.to.

This exactly what I am doing, starting my journey in sharing my thought, writing simple posts.

My writing skills are pretty basic and my vocabulary still poor, but from somewhere we need to start, right? 🙃

Collapse
 
lechenco profile image
Gabriel Lechenco

Yeah! I'm trying to do the same. And I don't have English with my native language, so writing here it is a way that I found to push me over and improve my skills.

Collapse
 
tcelestino profile image
Tiago Celestino

It's same here.

Collapse
 
sandordargo profile image
Sandor Dargo

I agree with your article, but I'm troll enough to make a remark on this phrase: "I don't mean write more code. I mean write for humans."

According to some of the finest computer scientists, code is written primarily for humans:

“Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, "Structure and Interpretation of Computer Programs"

Are their points still valid? That might be the topic of another article.

Collapse
 
qm3ster profile image
Mihail Malo

For sure, no?
Otherwise no one would use say... TypeScript? Which contributes nothing to the runtime.
Nor would anyone ever leave comments.
One can even make the argument they would not use a high level language at all, but that's the iffy one.

Collapse
 
berkmann18 profile image
Maximilian Berkmann

They are still valid, why?
Because, unless you only do code golf and throw away all the code you write, you'll be writing something that someone (including the future you) will be reading and trying to maintain, fix and what not so it's important that the code is readable.

One might say, your code should be self-documenting so no documentation is needed, I'll argue that it would depend on several things but we're not discussing about documenting code vs not doing it.

Collapse
 
triptych profile image
Andrew Wooldridge

This is good advice. I would only add to try to write for your own domain first and cross-post to places like medium and dev.to to get maximum benefit. Also, after say 6 months of writing -- roll that up into a book and self publish!

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

As an author who founded his own publishing company (one step beyond standard 'self-publishing'), with many years exposure to the writing industry, I'd like to add a few points to the "roll that up into a book" comment: It isn't something you want to do on a whim! Successful publishing requires extensive planning and a potentially expensive initial investment.

  • Plan your content. Any effective book still has to have a cohesive structure, even those which are collections of essays (For example, The Cathedral and the Bazaar or The Size of Thoughts: Essays and Other Lumber.) Unless you're E.B. White, no one will want to read a random collection of your articles/essays if it doesn't have a cohesive theme.

  • Get it edited professionally! Too many authors skip this step, or assume that if their Aunt Ruth didn't find any missing commas or spelling errors, it's good. Real world editing goes far beyond proofreading, and is essential any book's success. Find at least one reputable professional editor. If possible, you should also get several of your industry peers to read the book as well and offer their constructive criticism.

  • In concert with the editing step, prepare to revise heavily. Even the best author has to edit, tweak, and revise their book repeatedly before it has any chance of success. It really does take a village to publish a book.

  • Get it designed properly. Unless you're like me, and have an inexplicable knack for typography and typesetting, you'll want to find a professional book designer. Some printers offer these services for a fee. "Good enough" is not good enough. (By the way, print and ebook have to be designed separately.) While you're at it, be sure to get a good cover designed!

  • Beware most self-publishing schemes. Read consumer reports from independent sources, and select your printer carefully. All legitimate, worthwhile printers and publishers will pay you pre-arranged royalties on every single sale; printer setup fees should by well under $500 (not counting ISBNs, design work, or marketing). I use IngramSpark (LightningSource), which offers the industry's best distribution. BookBaby and CreateSpace are other options, although they both have limits and drawbacks. Alternatively, consider submitting to a relevant, independent publisher like No Starch Press.

  • By the way, to sell the book, you will need one ISBN per format, e.g. one for paperback, one for ebook (any type). Bowker is the only place to buy these legitimately - ISBNs from anywhere else are either recycled (and thus worthless) or fake. Some reputable printers may offer to resell an ISBN from Bowker to you, however; just make sure they did get it from Bowker, not elsewhere! (Ingram and BookBaby both offer this.)

  • If you're doing this all yourself and getting it printed, consider registering the book with the Library of Congress (through their PCN program). By doing this, your book can be carried by libraries; otherwise, they won't touch it.

  • Be sure to consider the legal, business, and tax components here. Does your state require you to register as a business if you're collecting royalties? (Some do.) Do you need a retail license? Would an LLC be a wise investment, to keep your personal money out of any possible legal tangles? Self-publishing should not be approached on a whim; you need to understand all the implications of your publishing endeavors.

These steps are all applicable, even if you "just want to publish an ebook on Amazon". Otherwise, your work is fated to be nothing more than an occasionally shared free download, and a tremendous waste of your time and money.

Collapse
 
marek profile image
Marek Zaluski

Great to have your input on the book publishing world, that's really useful to know.

Collapse
 
rmhogervorst profile image
Roel Hogervorst

If you want to write better, I highly recommend writing without bullshit by Josh Bernoff. It's extremely readable, and it gives great pointers that I never got anywhere else.

Collapse
 
kristiyanpeshtenski profile image
Kristiyan Peshtenski

Thanks man!
Really nice article.
Writing well is an extremely useful skill, witch unfortunately I do not have yet.
I read many similar posts, and every time It motivates me to start, but never DO anything.
This time will be different.
I will start with small steps. First one is to write that comment.
Hope that will be the beginning.

Collapse
 
egimba profile image
Eric Gitonga

I had just started out the initial words of a post when I came here to check on something, and this is the first post I came across. The universe telling me something? Anyway, I have decided that I shall get my writing chops on by documenting my journey to learning R. More as notes to self. Thanks for this pep talk!

Collapse
 
shaikhul profile image
Shaikhul Islam

Communication is a skill that's overlooked a lot by developers

true story.

Thanks for sharing!

Collapse
 
kicksent profile image
Nick Trierweiler

You have a typo in your post: "all it takes it practice" should be "all it takes is practice".

Very nice post. I will certainly be using this to document my work for my team mates to use. I liked the section about over-communication. Over communication saves time in the long run and only takes an extra few seconds which can add up quickly. For a bonus, you should plan how to explain what to communicate briefly and then communicate it as thoroughly as you can.

Collapse
 
ant profile image
Ant

this article really encourages me,I can't agree more

Collapse
 
teleyinex profile image
Daniel Lombraña González

Good article. Actually, as a bonus, if you don't mind, write in paper with a ballpen. Why? There's some literature that says that writing with a pen will get your memory better. Thus, write it and if you can with a ballpen (I've just started to do some #bujo, hopefully to improve on this as well).

Collapse
 
craigbutcher profile image
Craig Butcher • Edited

Your post nailed it on the head!

I have been persuaded by a few people when am I going start writing blog posts again. I have been out of the loop for a few years and found a sense of imposter syndrome to anxiety who is going to be reading my 'crap'.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

Awesome article actually for me, writing has always been a pain in the butt for me since my command of English is awful since I was young.

But what I do desire is the process of creating ripple effects to a bunch of people through my writing.

Besides that, it serves as a place for me to reinforce my understanding of technology.

A side benefit is that it serves to document my process as I grow as a developer in my chosen niche and specialisation.

Collapse
 
lepinekong profile image
lepinekong • Edited

Fully agree, virtue comes with habits. Nevertheless I have asked developers in my team to do so, they're very reluctant, and I understand why: it's very time consuming, that's why I'm working on a system to lower the effort with readable.red it's not finished and documented yet, just a preview as I'm experimenting with it myself first see example redlang.red/collect :) I'll also use it to write tutorials for dev.to in the future (see past ones dev.to/lepinekong/red-for-hopeless...).

Collapse
 
phantas0s profile image
Matthieu Cneude • Edited

Thanks for this blog post! I love writing myself, I can only agree with most of this article.

Here's a good strategy for any team of developers: over-communicate.

Over communication is not necessary good either to me: miscommunication and confusion can come because you explained too much. Whatever the amount of communication, it's more important to be precise and clear.

If you over communicate and contradict yourself at the same time or provide clear and then confused explanation, expect some wrong results.

Communication is a skill that's overlooked a lot by developers.

This is really true. I think communication is utterly important for developers.

Collapse
 
rachelsoderberg profile image
Rachel Soderberg

I started doing a weekly blog-ish post writing about something I learned in the week related to software or tech at the beginning of the year... but I fell off and missed a couple of weeks. Thanks for the kick in the rear to get back on that. :)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.