Language: exclusion and inclusion

I wanted to title this “Jargon: how not to be a douche”, but I am too mature for that. Not much, as I then made a point to start off the post with it. I have my limits. You have yours.

As I read The Art of Readable Code (ARC), I constantly find connections to other parts of my life: my university life as a German major, my previous career as a teacher, and tweets from friends afar. This one particular tweet really resonated with me:

I read that tweet shortly after this passage from ARC: “… project-specific abbreviations are usually a bad idea. They appear cryptic and intimidating to those new to the project.” I am also on a slack channel where those with jobs like to post about all of the “ugly code” they see at work, which often gives those of us still looking for a job the feeling of being left out. “Oh, look at this. Bah ha ha …” without discussing what makes it ugly. For those of us still looking for our first job as jr devs, this smacks of “We are in the know. You are not.” I’m also severely tested as one who majored in language and edited, to not correct their ugly sentences. Must. Not. Take. Bait!

But wouldn’t I be doing the same thing? Ha ha ha, I can use a semi-colon outside of coding correctly. Aren’t I superior? I would be the douche. I’m ok with feeling that way. We can’t control that or change ourselves immediately, but I believe we should own up. It is also a natural reaction to competition. One wants to jab back.

I’m not on a dev team. I’m not employed; however, as I learn to code, I create apps and snippets for myself. While the practice is good for keeping up the skills, it’s not so good for variable names. I am writing for myself. I need to start writing for others, even if I am not. I am developing habits. I chew with my mouth closed when I am alone, so I am not worried about doing it when I am not.

If I hope to be one who collaborates and not competes with coworkers, then I need to practice avoiding exclusionary tactics. Cryptic naming is like jargon; it creates an us-vs-them feel. So. Here I go. Better naming conventions. Check! On it like mouse on enter.

3 thoughts on “Language: exclusion and inclusion

  1. ive been discouraged and encouraged by coding communities as long as ive dealt with them. its understandable that they want you to “prove yourself” as much as it is they they want to help and teach, but sometimes that demand for proof never goes away.

    imo there should be the following stages in community: help, proof, acceptance/collaboration. thats it. once youre part of it, youre part of it. but there should be clear ways to get there. doing this deliberately or in a prescriptive way probably wont work (unless its a certificate program) but it might make up for communities that become all about self-aggradization and climbing up over each other– which really gets old when the thing that brought you there isnt the love of being the best-of-the-best, but the love of coding and learning and besting your own best.

    1. I love this:

      Which really gets old when the thing brought you there isnt the love of being the best-of-the-best, but the love of coding and learning and besting your own best

      Thoughtful and spot on.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s