PERSPECTIVE

Coding is not about Code:

Carving Your Thoughts in Code

Evan Cole, Director of Elewa Academy
25 January, 2018
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.
“To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others.” – Tony Robbins
Let’s begin this discussion by defining two broad types of communication you will have to deal with as a professional developer:
  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.
( PSST. I’ve made up the terms On-Going and Static Communication.  If these ideas interest you, you should read more about rhetoric.  It’s an old idea with interesting implications for modern technology. )
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.
“Truth can only be found in one place: the code.” – Uncle Bob Martin
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.

“Working code does not a finished project make!” – William Shakespear, CTO
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.)

Share your thoughts
Become part of our open community, and get coding!
Related Articles

Solution Design

The most important skill of a true developer has nothing to do with writing code. Then what truly differentiates an excellent developer? Read how weeks of work could have been avoided by thorough analysis, spiced with a bit of laziness.

Start Learning

Start Learning

Get free access to our open and available curiculum. Be ahead of the future and start learning now!

Thank you! We will send you the curriculum soon!

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list and receive cool updates about our curriculum, approaches to 21st century learning, coding, market orientation, etc. 

You have succesfully described. Prepare to receive the news as it comes in!

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

Pin It on Pinterest

Share This