DEV Community: Ariel Caplan

Baby's First Keynote

Ariel Caplan — Mon, 06 May 2019 02:03:38 +0000

I'm on a plane, traveling back from RailsConf 2019 where I was one of the keynote speakers. My head is full of thoughts and reflections on my experiences before, during, and after the talk.

I've given a few talks before, including several at previous RailsConfs, but this time was... different, somehow.

I'd like to share my experiences with you, in the hope that you'll learn something of value along the way.

Genesis of the Talk

The process that led to my talk, The Stories We Tell Our Children, began circa 2.5 years ago, when my wife bought our first Israeli children's book, A Tale of Five Balloons by Miriam Roth. I started to read it to my daughter nearly every night, and she loved it, but I honestly was bothered by the book. It was sad through and through, and I couldn't figure out why it was clearly a popular book. It took me months to learn how it had become popular, and even then I wasn't fully comfortable with it. It took at least a year to make my peace with the book, and to start to appreciate and even love it.

Through the process, I started to see how literature and the society within which it exists are intimately connected. It made me reconsider a lot of the American early childhood literature I grew up with. And the thoughts began to percolate around whether this could be something worth exploring in the context of a conference talk.

Time went on, and I began to read further. More Israeli books came into my life, and I continued to follow the pattern and see the connections. I started to seek out Israeli children's classics actively, and try to perceive how each connected with Israeli history. I also read some literary criticism, mainly that of Dr. Shimona Fogel, which helped clarify things for me as well.

About 9 months ago, I decided I had enough material for a talk, and I had a sense of what I wanted to talk about. I submitted the topic to the RubyConf CFP, and was waitlisted, meaning I still got a free conference ticket, but would only give the talk if someone backed out at the last minute. No one did. In retrospect, this was a blessing; the talk was still somewhat raw and unrefined. I'm happy I got a few extra months to let things settle more in my head and on my slides.

Getting Accepted

Since I had been waitlisted rather than rejected, I already knew my proposal was pretty good. So I edited the proposal a bit more, and submitted it to RailsConf.

In case you're wondering, I didn't submit the talk to smaller conferences, for two reasons:

Small conferences tend to be on weekends. I don't go to conferences on Saturdays for religious reasons, and I also don't like the idea of making a long trip to a 2-day conference where one day is Saturday. Add the various Jewish holidays, and a great many conferences simply aren't relevant possibilities. RubyConf and RailsConf are wonderful exceptions to this rule, since they are specifically held midweek so as to interfere minimally with attendees' lives and to let them have full weekends before and after the conference.
Even if a relevant conference could be found, I had a sense this talk was special. It was certainly special to me. And I wanted to make sure I get to share it with as many people as possible. RubyCentral conferences would be my best shot at sharing these ideas with a large group, between the attendees and the many people who watch the Confreaks videos afterwards.

At any rate, one day I got an email from the conference organizers, stating that they'd decided my talk would make a great keynote, and they'd like me to take one of the keynote slots. Especially given that I'd been waitlisted last time, this wasn't what I had expected, so of course I was thrilled to have the opportunity!

However, I was a little bit concerned. I knew I'd be addressing some Israeli history, which can be a sensitive and emotional topic for many people, and I definitely didn't want to ruin someone's conference experience by saying something insensitive or biased. Furthermore, because it's a keynote rather than one talk of many in a multi-track slot, it wouldn't be a talk people chose to attend. Keynotes also generally don't get an abstract published in advance, and even whether to include the title in the program was a choice. (I decided yes.) So I wanted to make sure I'd have resources available for content review. Once I received confirmation from the RubyCentral team that this would be made available to me, I accepted the slot and started improving the talk.

Cranking Up the Quality

I've given several talks before, but this was a keynote. That means a bigger audience and higher expectations. So I set a higher bar for this talk and made every attempt to meet it.

I knew more or less what I wanted to say, but somehow all sorts of ancillary information always manages to creep its way into the talk. And there were some things I wanted to discuss which would have been ill-advised in consideration of the goal of not conjuring up uncomfortable feelings for people during my talk.

I expanded and pared down, again and again, until I felt pretty ready. Sadly, my talk was significantly longer than the recommended 40-50 minutes, so aside from wanting general feedback, I needed advice on what to take out.

Some folks from the US and UK were visiting the Cloudinary Israel office, and I figured it would be a good opportunity to get feedback from an audience that would be fairly representative of the people who would ultimately hear the talk. I invited the visitors, and ended up with a room of 5 participants in the audience. I got some great feedback, and ended up making many significant changes (additions and deletions) in response to their comments.

I rehearsed the talk once every 1-2 days for two weeks, each time tweaking a bit more. Once I felt comfortable with the newly edited version, I did a second round of testing on a group of my Israeli peers. They corrected a few things which I had confused due to being less sensitive to some finer points about Israeli culture. (I am, after all, an immigrant!) They also made a few suggestions to help me make it appeal more to the audience.

The most important bit of feedback I got in both rounds was to make sure to continuously ground the historical/cultural content in something practical. One of my reviewers put it this way: I was forcing people to maintain a long buffer, to remember a large percentage of the talk over many minutes, in order to understand the takeaways at the end. This made it harder for an audience member to maintain focus and understand what's important to hold onto over time.

I sent a video of a rehearsal to the organizers and noted the parts that likely needed content review. It tooks some back-and-forth to make the review happen, and it wasn't completed until the day prior to the talk, but thankfully it worked out. My test audiences' feedback had already put me in a place where no further changes would be necessary. This was a great relief for me as the time drew near.

In the meantime, I continued making small tweaks, even on the plane ride, or in the conference hotel, and even the morning of the talk when something clicked in my head and I wanted to include the idea.

Some people have to "seal" a talk some time before giving it, in order to rehearse a final version and feel comfortable onstage. For me, though, a talk is a living entity, not done being developed until the moment I'm onstage and it's too late to make changes. It's an outlet of my mind and my emotions, and it needs to reflect who I am and what I think and feel when I give the talk. That dynamism lets me bring my entire self to the presentation.

Giving the Talk

It was time. I headed over to the convention center, and reached the main ballroom 15 minutes early. I hooked up the microphone and laptop, and then spent a few minutes talking to some friends who had also arrived early. That helped calm my nerves a bit, but with around 5 minutes to go, I decided I needed some quiet time. I went backstage, and took a few moments just to breathe and relax. Abby, one of the organizers, got up to make the morning announcements, and then it was time!

I got up, took in the round of applause, took a deep breath, and started. The first couple of slides were completely scripted, which helped me get into the rhythm of the talk, and the rest was bullet points and notes to let me speak more naturally. I heard the crowd laughing, crying, even gasping at one point, and I fed on that energy and connection to bring even more of myself into the talk.

It's a surreal experience, being in front of a huge crowd and conveying ideas you care about deeply. At some point, at least for me, the power of the ideas themselves begins to carry you. You feel like you're floating, you forget that your body exists, you simply become a conduit for thought and emotion, via the medium of words.

My memories of the talk itself are fairly sparse. I know I covered all the slides, and I remember a few key moments in time, but most of it is a big blur. I was in another world, yet very much connected with the audience at the same time.

Recovery

In the past, I tend to take audience questions on the side after the talk, and then take a break for a while, and later in the day start going to talks again. This time, I had a couple of talks I really wanted to hear. So I went and listened. And then it was lunch break, but instead of eating I went back to my room, took a shower, put on more comfortable clothes, and went back to the conference with a clearer head. Still, it took a few hours to feel completely back to normal.

Reactions

I was overwhelmed and often surprised by people's reactions to my talk. I imagined I'd get some interesting responses, but even so, a few things caught me by surprise. Some highlights:

An attendee from Venezuela told me about how much he values hearing about other cultures, and expressed his frustration that Americans don't fully understand the situation in his country, and that's a story that needs to be told.
An attendee originally from Pakistan (now living in the US) noted that he isn't legally allowed to visit Israel. For him, this was an enlightening experience and a chance to learn more about Israeli culture, to see the humanity of Israelis.
An American Jewish attendee described to me how excited he was to see someone obviously Jewish onstage talking about Jewish history. He said it made him feel seen. He's never been actively excluded from the programming community, but it still meant a lot to him to have representation in this sort of public forum.
Two Israeli Jews in attendance (probably the only ones aside from myself) told me about their feelings of shock and wonderment in seeing the books they read to their children onscreen at the biggest conference for Rails developers in the US. They were thrilled to have the opportunity to tell their family and friends back home what had happened across the Atlantic.
A father approached me to talk about the concerns he shares with me about the books he reads to his children. Sometimes he's noticed messages that he realizes are problematic, and he appreciated me raising awareness of the issue.
A programmer who works for TED came over to compliment my presentation style, and we got into a scintillating discussion of how TED has impacted the way people give talks, for better and for worse.
Someone I'd met the previous day approached me and told me they have been dabbling in writing a children's book. They gave me a copy to look at and asked me to share my thoughts.

Many other people approached me in the days following my talk. Some wanted to connect on a more practical level; I was invited to be a guest on two podcasts, which should be a fascinating experience. Mainly, though, people wanted to share all kinds of reflections, mostly centered around being more aware of the messages in children's books and in the stories we tell.

My Takeaways

I'm still unpacking the experience, but I've drawn a few lessons from my little adventure.

First is the power of vulnerability. This talk put me in a potentially very vulnerable place. It involved many of my own feelings, both about literature and about the society in which my wife and I have chosen to live and raise our children. But I found that people were very receptive to my honesty and openness about myself. There are certainly limits, and I needed to take great care to ensure I wouldn't trod on someone else's feelings. But I was amazed at how positively people reacted to the talk and the content.

Next is the value of letting ideas simmer. This talk came to be over a period of years, as the result of a personal journey. Even once I put together the initial abstract, nearly a year passed before I gave the talk onstage. The passage of time allowed me to clarify my goals in the talk and what exactly I wanted to convey in the time allotted.

Third is the value of testing. I thought I had a pretty good talk, but I found out I was too close to the material. Hearing the reactions of a test audience helped me to notice the ways in which my talk could be improved and made more valuable for them. Because this isn't about me getting to spew at people. It's about what they carry with them when they exit the room.

Fourth, I was prompted a few times to make the talk feel more relevant. It's easy for a speaker to forget that you need to have a strong and clear answer to the question, "Why should I care about any of this?" And it needs to be stated early and often. I think my talk was much better received because I chose to scatter some of the takeaways and lessons throughout, rather than concentrating everything at the end of the talk.

Finally, I was intrigued to see how different people took different things away from the talk. Some focused more on issues of literal children's literature, while others wanted to talk about messaging in media and in programmer culture. Everyone listened to the same talk, but heard something a bit different. This reminded me that as a speaker, you can't control what your audience will hear, but that's OK. Maybe everyone hears what they need to hear at that time. It's a gift to them; they choose what to do with it. And my job as speaker is to give up the illusion of control and allow each attendee to interpret in their own way.

Thank you, dear reader, for listening. I hope it was worth the time and energy you've invested, and you're a bit wiser now than you were before reading. I'd love to hear what you learned from my experiences in the comments.

Speeding up a Simple Static Site (With Help from Cloudinary!)

Ariel Caplan — Thu, 24 Jan 2019 19:06:43 +0000

Diagnosing The Patient

For the last 2 years, I've run Dev Empathy Book Club, and the site hasn't changed much. I've tried to keep it low-effort so I can focus on the community and the content we're producing. One casualty of this was that the site, while simple, wasn't very performant. (Google's
PageSpeed Insights gave it a very low score of 30/100 on mobile.)

I recently began working at Cloudinary, and I realized it's pretty embarrassing that, as an employee of a company whose product is all about optimizing media on the web, I have a personal site that does a terrible job of it.

The final bit of encouragement came from fellow Cloudinarian Eric Portis, who published an article about Website Speed Test, a free tool from Cloudinary to grade image performance on your site. When I ran it against the Dev Empathy Book Club site, I saw that users had to download 1.5MB, which could be optimized down to 370kB, i.e. about 1/4 of their weight. I also knew these images were being served directly from GitHub Pages, without any CDN, so on mobile devices the page load was pretty slow.

On top of all this, there was a good amount of render-blocking JS and CSS being downloaded without a CDN.

All this meant slower load times, and lower scores in search results. There was no good reason for it, except that I didn't have the know-how to improve things, or the time to learn how to do it.

Enter Cloudinary

Cloudinary is a robust but easy-to-use service to upload, transform, and serve images and videos. The free tier contains way more than you'll ever need for a simple static site, so it's a great choice for e.g. personal sites with a few images you'd like to serve efficiently.

One awesome feature of Cloudinary which made this incredibly simple is the ability to auto-fetch images.

For example, consider this URL:

https://res.cloudinary.com/caplan/image/fetch/https://amcaplan.ninja/images/ninja-cropped.png

The URL consists of

https://res.cloudinary.com/caplan/image/fetch/

which tells Cloudinary you want to fetch an image for the caplan cloud (you create a cloud with a unique identifier when you sign up for Cloudinary), and the rest is the URL where the image can be found:

https://amcaplan.ninja/images/ninja-cropped.png

When you hit this URL, Cloudinary will fetch the image in the background, and begin serving via CDN.

Theoretically we could take all the images on the site and preface with the fetch incantation, but there's a better way. Cloudinary has another feature called Auto Upload, which lets you create folders which are proxies for web locations. So if we create a ninja_images directory mapped to https://amcaplan.ninja/images/, the URL looks like this:

https://res.cloudinary.com/caplan/image/upload/ninja-images/ninja-cropped.png

Much better! Here's the result:

Now comes the fun part.

Cloudinary lets you edit images by adding transformations right into the URL. For example, by adding /w_100 before the image location, we creates a 100-pixel-wide version of the same image:

https://res.cloudinary.com/caplan/image/upload/w_100/ninja-images/ninja-cropped.png

You can crop, set gravity (focusing on a region of the image or on human faces), scale, add text layers or image overlays, and do a whole bunch more awesome stuff, just by adding to the URL.

This opens up the opportunity to create multiple versions for various breakpoints, driven via CSS. So if you take a large version as the original, you can tell Cloudinary to crop/scale the image as you see fit, no Photoshop skills required!

As one concrete example, here's a large image for wide screens:

https://res.cloudinary.com/dev-empathy-book-club/image/upload/f_auto,q_auto/site/slider-bg.jpg

You'll notice a couple transformations here: f_auto, which chooses the most bandwidth-optimized image format for the user's browser, and q_auto, which reduces image size by degrading image quality without being noticeable to the human eye. Those 2 transformations already reduce the image size from 874kB to 385kB, without any noticeable difference to the user!

But we can do better on mobile, where this many pixels still aren't helping anyone. Here's a scaled-down version for mobile:

https://res.cloudinary.com/dev-empathy-book-club/image/upload/f_auto,q_auto,w_480,h_800,c_lfill,g_auto/site/slider-bg.jpg

In this case, we're creating a tall image bounded at 480px width, centered on what Cloudinary determines to be the most interesting part of the image, and using a fill approach to the crop (expressed as c_lfill) to ensure we cover the entire requested dimensions of 480x800.

There are many parameters and even more options for those parameters, but the documentation is quite thorough and the system is really powerful.

To see a real-life example for what this might look like, check out the CSS for Dev Empathy Book Club's site on GitHub.

The Gravatar Challenge

At first I assumed that Gravatars (we display a few) on the site would work the same way, but I soon realized there is a big problem with Gravatar. The URL for an image looks something like this:

http://secure.gravatar.com/avatar/7b5a451ee25044b9c869e3e98b79425d.jpg?s=200

with this result:

If I want a larger version, I just change the s query param. So for a 400px
square, I'd use this URL:

http://secure.gravatar.com/avatar/7b5a451ee25044b9c869e3e98b79425d.jpg?s=400

Lacking the s parameter, Gravatar defaults to an 80px square:

http://secure.gravatar.com/avatar/7b5a451ee25044b9c869e3e98b79425d.jpg

If you try to fetch a large Gravatar avatar with Cloudinary, here's the result:

https://res.cloudinary.com/caplan/image/fetch/https://secure.gravatar.com/avatar/7b5a451ee25044b9c869e3e98b79425d.jpg?s=400

What happened? Cloudinary treats ?s=400 as a meaningless parameter passed to Cloudinary, and doesn't forward it to Gravatar.

This can be fixed, though, by URL-encoding the ? character as %3F, like so:

https://res.cloudinary.com/caplan/image/fetch/https://secure.gravatar.com/avatar/7b5a451ee25044b9c869e3e98b79425d.jpg%3Fs=400

This technique should work for any characters you might need to include in the fetch URL.

However, that's not the end of the story. What happens when someone updates their Gravatar image? Ideally, it would get updated on our site, too. But on the free plan, fetched images never change. (They can be configured to be updated on paid plans.)

It turns out that someone at Cloudinary thought of this, and therefore built Gravatar support directly into the platform. Unlike the fetch and upload image types we've seen so far, there's also a gravatar image type which knows how to source a high-quality image from Gravatar, and update it automatically, with a small delay, when someone changes their avatar! (There are similar systems for other social networks, including Facebook, Google+, Instagram, and Twitter.)

If you fetch images via Gravatar in this way, you can easily scale up or down using the normal h_ and w_ parameters. So here's that same 400px image of yours truly, fetched via Cloudinary:

https://res.cloudinary.com/caplan/image/gravatar/w_400/7b5a451ee25044b9c869e3e98b79425d.jpg

Of course, once you've done this, you can use f_auto and q_auto to optimize images further and reduce bandwidth use. Neat!

Not Just for Images!

One little-known fact about Cloudinary: They can serve anything via CDN, not just images and video! So if you have JS or CSS files, you can serve them through Cloudinary's CDN in the same fashion as mentioned above for images: Set up an Auto Upload folder and reference those URLs instead of the place where they're hosted on your site. So for example, instead of:

https://devempathybook.club/css/bootstrap.min.css

we reference:

https://res.cloudinary.com/dev-empathy-book-club/raw/upload/css/bootstrap.min.css

(where css/ is a folder mapped to https://devempathybook.club/css/). Note that instead of image as before, we write raw to indicate that this should be considered an unknown file type and Cloudinary shouldn't try to do any image processing with it.

Usually you'll want to use a versioning strategy for your JS and CSS assets if you use a CDN, but the goal here was to be lazy on a static Jekyll site. Since there wasn't much custom CSS and JS, I simply left a few files that are loaded directly from GitHub Pages, but things that won't change frequently (or ever) are served via Cloudinary's CDN. You can see the code here.

Cut Waste

You might notice, if you looked at the code from the last section, that a number of lines were commented out. It turns out that the Jekyll template I used bundled with it a number of JS/CSS frameworks and plugins I didn't actually use. Removing them reduced the total page load size, and makes the page run faster, since there's less for the CPU to worry about. As they say, no code is faster than no code!

The Outcome

I wouldn't call the site blazing-fast now, but its PageSpeed mobile score went up from 30 to 50 in a few simple steps taking a couple hours total. There are more things to optimize, but these quick tricks helped bring down page load time a lot already. Importantly, time to first paint on mobile was cut by about 50%. That's a much better experience for mobile users.

So go out, try these tips, and let me know in the comments how you did!

As a reminder, I work at Cloudinary, so if you do find anything here difficult to implement, I can pass along your concerns to the right people... 😉

P.S. If you use Jekyll or some other blogging framework, and you have many images on your site, it may be worth going further with automation using a plugin. For example, jekyll-cloudinary lets you define transition presets, and does all the work to generate URLs for images at various screen sizes. It's pretty magical. Of course, if it's a dynamic site, Cloudinary has a host of SDKs which can do everything discussed here, and much more!

NOTE: Cloudinary did not ask me to write this. Nothing in this post should be taken as representing anyone other than myself.

UPDATED 2019-01-29: Added option to include URL-encoded characters in a fetch URL.

Why I Created Dev Empathy Book Club

Ariel Caplan — Thu, 14 Sep 2017 22:54:50 +0000

I was just a few months out of the Flatiron School, had gotten my bearings in
the codebase at my first job, and was starting to take on more responsibility. I was sitting with a product manager—let's call her Sierra—trying to explain the technical impact of a product idea she had proposed. And I was frustrated.

No matter which way I explained it, she just kept getting confused. Why couldn't she understand that making these changes would drastically increase response time on a critical endpoint? It was a simple workflow involving 2 microservices and a NoSQL database, and she didn't even have to understand the details, just how they were connected together on a high level.

At some point, I realized: No one had ever given Sierra any level of technical explanation of the system whose development she was supposed to guide every day. Instead of going further with the conversation, I asked, "Why don't we set up a meeting just to describe the basic outline of the system? Nothing overly detailed, just enough to allow us to have a conversation about how product concepts will impact the real-life product when they're translated into code."

To my surprise, she agreed. To my further astonishment, I actually enjoyed the meeting more than any other I'd had since beginning my software development career. We slowly built up a diagram of the parts of the system relevant to her job, clarified confusing points, and made sure every bit of explanation was clear to her.

At the end of the meeting, Sierra thanked me and said, "You know, no one's ever done this for me. This is going to significantly improve my ability to come up with ideas and communicate with developers. I'd really like to understand more about the technical elements of the project, but there never seem to be opportunities for me to learn."

At that moment, I realized something that has become a theme in my career: The most significant impact you can make on a product isn't through design, code, marketing, sales, or customer support. It's building bridges, enabling people of varied backgrounds and skills, each with their own perspectives and spheres of understanding, to work together through effective communication.

A Series of Fortunate Events

As I continued to mature and advance in my career, I ended up taking on the role of a more senior developer and mentor, as well as having more say in the work I was doing. Although I saw myself taking on more responsibility, there was no event that sparked a big change, until...

In late 2016, I attended RubyConf in Cincinnatti, where I heard Paulette Luftig's talk, "Finding Your Edge Through a Culture of Feedback". She ended with a few recommendations for books to read, and I decided that this should be the next step for me. There are many fantastic texts about developing skills in communication, team-building, empathy, and other soft skills; I'd be cheating myself of personal and professional growth if I didn't take advantage!

A few days after the conference, I bought a number of books recommended in that talk, plus a few I'd seen suggested around the internet. And so the fun began...

Ariel Caplan

@amcaplan

Anyone wanna #BookClub on some of these?

Nonviolent Communication
Difficult Conversations
Emotional Intelligence
& 2 Dale Carnegie classics

22:44 PM - 15 Nov 2016

11

I wanted more, so I ordered books online. Like a good programmer, I was approaching stack overflow...

Ariel Caplan

@amcaplan

As a reminder, if you want to join me in journeying through these empathy- (& sometimes dev- too!) related books, ping me, let's #BookClub!

20:50 PM - 29 Nov 2016

511

It was difficult to stay motivated and keep reading, so I knew I had to actually get serious about making this thing happen. Also, I would get a lot more out of it if I could discuss my thoughts with others. So I decided that RailsConf 2017 would be the Big Bang for Dev Empathy Book Club. I designed a site, set up a book club on Goodreads, and walked into the conference ready to recruit.

Justin Herrick gave a workshop about team-building and communication, so he seemed like a good person to try; he was! Amy Unger approached me in response to a tweet and asked to join as well; I was certainly delighted to have another thoughtful voice actually approach me about the club! So we had a panel.

I also gave a lightning talk (which I'm far too proud of) about a silly little hack, and used the opportunity to plug the project. So we got a bit of free marketing.

Then everyone went home, and the real work began.

Down to Reality

Reading a dense book and actually trying to incorporate some ideas into your life every 2 months is a reasonable but still significant commitment. Even more difficult is coordinating with other people to make time for a panel discussion, keeping online materials up to date, and generally promoting the project. Dev Empathy Book Club is important to me because I think it adds a much-needed voice of compassion and humanity to the commotion in our industry. But it takes a lot of time and effort.

We also needed to evolve. Goodreads has a very unfriendly system for managing a club, and the forums weren't easy to use. So we moved to an open Slack channel. Then, we wanted to make it more interactive, less a pure announcements conduit, so we started a monthly open discussion in Slack.

We also needed to be flexible. With a small number of panelists (though we're looking to grow!), sticking to a schedule has been a real challenge, resulting in 5 instead of 6 books covered over the last year. We're hoping to do better this year, to provide a more consistent experience for participants in the club.

This Just Got Real

While being part of Dev Empathy Book Club, I took on an informal team lead role within my working group. Since we went through a few management-related books at the same time (The Mythical Man-Month, Radical Candor, Peopleware), I had the opportunity to think about the ideas conveyed and experiment in a real-life work environment. I saw that people respected me because I invested a lot of thought into how teams work in general, and how to make my specific team more effective and simultaneously much happier.

Then, a month ago, I was informed that I would have an opportunity to move into a management role at my company.

A year ago, I would have been terrified, if the opportunity had even been presented, which of course it wouldn't have. I wasn't ready. Now, while I didn't walk into the role as an expert (it takes a lot of experience to get there!), I could consider myself educated enough to know how to learn the rest. A year of investment truly paid off.

What Are You Waiting For?

Even if management will never be your thing, soft skills are the big differentiator between people who write code and people who solve real-world problems using code. They might save you wasted years of effort by solving the people problems that would otherwise have mandated countless lines of code. And they will definitely make you happier in your job. You have to deal with other people all the time; may as well learn to enjoy it and make the most of it!

Becoming a more empathetic, compassionate, kind person with better communication skills will probably be the most valuable investment in your career (and possible your life in general).

Is Dev Empathy Book Club right for you? If you're looking for something concrete and consistent to add to your routine to develop personally and professionally, check it out!

If this isn't the right time for you to join, that's fine too. I'd love if you would share this post, and the club, with friends, or tweet about it with the hashtag #DevEmpathy. (Or just mention our Twitter account, @DevEmpathy!)

You can find out more information on our site, devempathybook.club.

This article was originally published on my blog.