January 19, 2016
From nczonline.net, with love.

Subscribe now

Communication Skills

Hi everyone,

I've frequently told people that I don't consider myself a great software engineer. I think that I'm a good software engineer, but nowhere near the level of the best in the business. The reason I've been able to succeed is not that I'm the best coder, or understand algorithms the best, or generally anything to do with my technical skills. No, the reason I've achieved what I have is because I'm a really good communicator.

Communication is another one of those soft skills that no one tells you is important for an engineer, yet most software engineers will find themselves held back at some point due to  communication issues (myself included). As one of my mentors once told me, "at a certain point, you stop being judged on your technical skills and you start being judged based on how you work with people." Communication, naturally, is at the heart of working with people.

When someone asks you to work on your communication, what does that mean? It typically breaks down to two things: communicating intent and communicating results. Communicating intent means you tell people what you're going to do before you do it (for example, I'm going to switch our tests from QUnit to Mocha). The purpose of communicating intent is typically to gather feedback and ensure the right number of people are working on the right things (including
eliminating duplicate efforts and prioritizing among the team).


Communicating results means you tell people what you just did and why it matters (for example, now that's we're on Mocha, it's easier to write tests the same way for the browser and Node.js). The purpose of communicating results is to signify that you have completed task and validate why the task was done. As another mentor once told me, "if you do great work and no one knows about it, then you'll never get the credit you deserve." Your work doesn't actually speak for itself, you need to speak for it.

To put it more simply, communication means telling people what you're going to do, doing it, and then telling people what you just did. Following this pattern makes managers and colleagues happy because they don't have to guess what you're doing or where you're spending your time. If you take some time this year to practice better communication, you may end up with a new job title next year.

Be well.

-N

P.S. A few people have asked how they can support my work. You can pick up one of my books or consider becoming a patron. Either way, I hope you continue to enjoy my work.
JavaScript WeeklySponsor: TrackJS
Fix Your JavaScript with Error Monitoring from TrackJS.

Recommended Links

Web App attacks, PoS intrusions, cyberespionage leading causes of data breaches (article)
We hear more about data massive data breaches these days, and it's important to understand that web applications represent one of the largest avenues for such breaches. This is a stark reminder that what we do, as web application engineers, matters a lot to more than just us. Cutting corners on web application security can be disastrous, and we have the power to protect a large number of people with our work.

babel-service (project)
I've mentioned before how I think service workers are the next game-changing web technology, and this project seems to back up my position. This service worker script includes Babel.js to automatically transpile files in the browser based on the browser's capabilities. So instead of transpiling your files ahead of time, you ship them as-is and allow a service worker to determine when they need to be transpiled to ES5. 

The problem with progressive enhancement (article)
While the title of this article indicates a criticism of progressive enhancement, it's actually more a criticism of how we talk about progressive enhancement. Representing progressive enhancement as a sort of theoretical ideal or mark of craftsmanship isn't very compelling when you're trying to run a business. However, there are business advantages to progressive enhancement, and that's what we should be talking about more often.

Recommended Book

The Design of Everyday Things was originally published in 1988 but remains as useful and insightful as ever. While not strictly about software, it is written by a computer scientist and explores how products we use every day were built. The same processes used to design toasters and door handles can easily apply to software, too. This is a book I find myself referring back to time-to-time, especially as it relates to error handling in products, for which Norman has some profound advice. Especially interesting is a section in which he talks about the emerging technology "hypertext" and how he's not sure how it will work but that it presents a huge opportunity to connect information together (remember, HTML was released in 1993). Overall, reading this book will make you a better software engineer by getting you to think more about product design.

Recently on NCZOnline

Why I'm not using your open source project
When you think of open source software, you might think of a few specific projects depending on your area of interest. If you work on web applications, the term "open source" might conjure up visions of Apache or Node.js; if you're into big data, then perhaps Hadoop comes to mind; if you care a lot...

Hidden performance implications of Object.defineProperty()
I've recently been working on a project to port Espree[1], the parser that powers ESLint[2], to use Acorn[3]. In so doing, I ran into an interesting performance problem related Object.defineProperty(). It seems that any call to Object.defineProperty() has a nontrivial negative affect on performance in V8 (both Node.js and Chrome). An investigation led to some...

ECMAScript 6 destructuring gotcha
With all of the new syntax in ECMAScript 6, you're bound to periodically find something that is confusing (likely as you're hunting down an error). Recently, I've seen an uptick in the reporting of a specific type of error as it relates to destructuring assignment[1] using object patterns. Destructuring basics Before you can understand the...

Feedback

Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.


unsubscribe from this list    update subscription preferences