There’s lots of talk about developers needing to learn communication skills. Programmers have to learn to communicate for all aspects of their career – to collaborate with coworkers, to pass on their knowledge, to improve the perception of developers, and on and on. “Communication skills” has too many meanings to be meaningful.

There is also a lot of discussion in the public and academic realms about how to classify programming – is it a langauge, is it maths, or something new? Once again, this is too large of a topic to begin making sense of.

These two ideas may be impractically broad, but are still fascinating to think about. I was interested in programming from this philosophic perspective before I ever learned to code. That interest is why I started to code in the first place!

In all the hub-bub, there is one idea that a beginner or intermediate developer can use to imediately increase the quality of their code by over 10000%. And it doesn’t even involve learning more code! I’d like to lay out a way to think about your source code that will make the world a better place.

1. STATIC COMMUNICATION: When the author is not present to interact with the audience. These are situations like this blog post where I do my best to clearly explain myself in writing, but you’re ultimately reading it without me over your shoulder to answer your questions or explain why I wrote what I wrote.  Your understanding of my post comes from your independent experience of the words I published.
2. ON-GOING COMMUNICATION: When the author is present to interact with the audience.  The comments section at the bottom of this post is an example on-going communication. You get the chance to deal with me personally to clarify any confusing points in the blog post, creating a space where our understandings of this blog post can grow and evolve together.  You’ll get the benefit of having your questions answered, but I’ll also benefit by being told about mistakes I made or by being shown new ways to think about what I’ve written.

On-going communication is crucial for a developer. It’s what will allow you to work successfully with your fellow developers, to deal with customer and management, and to pass on your programming knowledge to new programmers. But the rest of this article will focus on the role of static communication in your career as a developer. Specifically on how to think of your finished source code as a tool to communicate with the rest of the world.

When you’re learning code it’s very natural to be worried about whether your code will run, and if it will do what you want it to do. This phase doen’st last too long, very soon you’ll have less and less trouble building code that works. This is when it’s time to take your coding skills to the next level. The next level isn’t using REACT instead of jQuery or AWS instead of Heroku. It’s thinking about what your code will say to the world after you’ve published it.

Source code is very interesting when you start to think about it as a form of communication. When I write a blog post I only have to worry about whether or not you’ll understand me. I can focus my writing to a single (relatively) simple audience: people who are learning to program, curious about what programming is, or experienced developers who like these philosophical questions. Writing source code is far more complicated than that. When you publish your source, every single line of code needs to make sense to THREE very different audiences – at the same time:

FIRST, and maybe most importantly, your code needs to make sense to end users. After your code has been compiled and executed the resulting application must be intuitive, focused, and meaningful to the end user. This can be achieved with design thinking and a little empathy for the user. SECOND, your code needs to be clearly understandable to other developers. Whether they’re fixing your bugs, contributing to your project, or integrating your code into their own projects, other developers will need to read and understand your code base. You need to have other developers in mind every step of the way. From the lines of code themselves, through the directory structure, dev environment, and all the way up to  documentation and the repository that hosts your code. I like to think of this as “source code UX”. THIRD, your code needs to fit it’s ultimate deployment environment. One trait of a great developer is an intimate knowledge of their tech stack and deployment environment. Details like which pre-compilers to use, what data model is best suited to your deployment, and how to write applications that scale with traffic are all key to successful launches.

When you are programming you have to be aware of more than getting your code to work. You need to always be thinking about how three very different audiences will experience your code: the User, the Developer, the Computer. Your ultimate job as a developer is to make decisions that strike a balance between all of their best interests. Sure your code might run faster in browsers if you rebuild your UI in REACT, but then no one else on your team will have the experience to maintain the app anymore. Or maybe the customer wants certain data-filtering features so badly that’s it’s worth the lag in performance. Every design choice you make in your software will have trade-offs.

Source code is your final product. After hours of planning, emailing, testing, coding, and getting stuck on bugs, all that’s left is your source code. And you probably won’t be around to explain yourself, your only option is Static Communication. This means it’s crucial for you to embed everything you know about your project directly into the  source code as variable names, as directory sturcutre, as documentation … there are as many ways of doing this as there are developers! Completed source code is the primary tool you have for  communicating your intentions, use it well.

So there you are, one more thing to think about as you stare blankly at your editor wondering if your code is good enough to push.

 

I Hope this helps!

 

(Check out our open curriculum to learn more.)