Chronicling the things I've learned while teaching myself to do various things in life has shown me that sharing the information with others is a good way to avoid information overload and serves as a great way to order thoughts and notes on the subject matters at hand. Therefore, take a walk with me and see some of the things I encounter as I become a full-fledged software data scientist and software engineer. The first step, self-assigned given my lack of knowledge and skill in coding, is to become a software developer. Gotta walk before you can run, right?
Over the past few months, I've begun to teach myself to become a developer. Although, "re-teach" might be a more applicable term.
To give a bit of background on myself, this is something I'd once started in high school over a decade ago, however, due to certain circumstances, I ended up pursuing scientific research in college instead of continuing with the development aspects. Therefore, my formal training is as an applied mathematician, however with what I feel is an undergraduate level of mastery.
Interestingly enough, it was a combination of this same scientific research, and study of differential equations, which re-ignited my love of programming and finding software solutions to complex problems.
That being said, to make myself into an even better programmer, I've decided to chronicle the lessons I learn. More or less as I learn them. There will be drama, intrigue, soul-crushing despair, and utter euphoric bliss, as we take this journey. There is no specific instructor, no designated teacher, for this material…as much as it'd be more convenient for me if there were. There are, however, senior developers, books, friends, tutorials, guides, online classes/videos, and various projects, which teach me everything that I know. Yes, teach; either directly or indirectly on a case by case basis. To these resources, I have immense gratitude; I would only hope to be as much of a resource to those for whom I would appear as a pioneer.
While this may seem a frivolous post, it is primarily to show my gratitude to those who believe in and support me on my journey. So, if any of you happen to see this:
THANK YOU!!
Okay, so onto the more interesting materials. The first topic I'd like to discuss is clean code. This is something which will be revisited on various occasions and, as such, my view is likely to change as I develop. That is to say, by no means should you or anyone else take these words as gospel; I strongly encourage you to explore various methods and develop your code-sense as it's very clearly something I'm developing as well.
The book I'm using to develop this is Clean Code by Robert C. Martin. Although I may post excerpts, I suggest that you to read through this book on your own at your leisure. I am thus far loving this book because the first thing he does is state:
"You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer."
I would argue that you are undertaking this journey with me for the same reason.
Nevertheless, I find this part to be highly important since it's all too easy to doubt ourselves and our own capabilities. As much as I am equivalently guilty, I'd encourage you not to fall into this trap of self-doubt; it is disrespectful to those who back you as much as it is disrespectful to the hours of hard work you invest.
Now, I'm sure we've all had the fantasy of having our own edition of Jarvis; or some other such intelligent machine which understood our intents to their core and would accomplish what we wanted instead of being a veritable monkey's paw. However, we will never escape the need to be absolutely specific in our details; our requests. This is true with our interactions with other humans, and even more so does it remain true with our interactions with machines. While I'm not going to pretend to know much about humans, or their desired escape sequences, perception is not reality. Reality is reality. Since at some level there are details which cannot be ignored or abstracted, then they have to be specified. In this case, specifying those requirements in such detail that they can be executed by a machine is, in and of itself, programming.
Now, even though I say that, just like there are horrible specifications, terrible instructions, and numerous other things which may fall under that umbrella, you can always assume that there will inevitably be bad code. At some point in our lives. Most likely, if you're staring at a program you wrote and are at least as inexperienced as I am, then you are also guilty. However, you shouldn't let bad code bog you down. Don't become significantly impeded by it. That is, don't try to go fast, don't try to rush. There's a saying I once encountered regarding coding:
Code can fall into a few categories; good, fast, or cheap. Choose two.
"Programmers face a conundrum of basic values. All developers with more than a few years' experience know that previous messes slow them down...In short, they don't take the time to go fast! ...The only way to make the deadline -- the only way to go fast -- is to keep the code as clean as possible at all times."
Writing such code takes discipline. Discipline and a developed code-sense. I'm still working on my code-sense, so I have no advice to offer there. But hey, we'll learn together. That said, clean code does one thing well. That is, a one line function is better than a multi-line function.
Let's think about mathematics for a moment. Yes, we'll be using math and chemistry a lot as reference points, but don't worry, I'll keep the examples superficial. Take the slope-intercept form of a line; y = mx + b. While we all know that the slope, m, and the intercept, b, have various interpretations and methods of evaluation, imagine how messy it would be if all of them were to be included in that equation? Instead, we tend to find the "individual pieces" elsewhere and then inject them accordingly into this function to find the solution. Similarly, your code should be elegant. Each function, or method, should do one thing and do it well.
"Clean code is simple and direct."
Your code should be readable such that the original intent is never obscured. The author makes the allusion to reading a well written novel such that the words themselves seem to fall away and you are able to immerse yourself in the world the story creates; seeing images instead of walls of text. Similarly, your code should have a high level of readability and remain crisp.
Similarly, again relating to mathematics, I'm sure any viewers of the classic slope-intercept form of a line, y = mx + b, would never feel that the original author was indecisive about how that line should be fit. I would argue, in this instance, that you should not at all be afraid to delete, edit, and re-edit, your code as your write to accomplish this aspect of cleanliness.
"Clean code can be read and enhanced by a developer other than its original author."
While this seems fairly straightforward, its implications are of a very high degree. Think about it for a moment. Your code should be readily able to be edited by someone other than yourself. That is to say, well written code, clean code, is literate. To that end,
Clean code has "reduced duplication, high expressiveness, and early building of simple abstractions."
Now, something about that which is implicitly critical. Implying that clean code is also minimal. Almost as if to say that it only speaks when necessary; not verbose. One of the talks I was watching (on YouTube of course) made reference along the lines of, "a function that takes no arguments is better than a function that takes one argument". Although his language was Ruby, so take it for what it's worth. If your language doesn't allow you to do that then don't force the issue. Conversely, if you're able to pass values inside your function itself by means of a reference, a pointer, or result stored in a variable, then that may be a better option. Most of the time.
Uncle Bob (the author of Clean Code gave this self reference) goes on to state, "It's not the language that makes programs appear simple. It is the programmer that makes the language appear simple!"
Then, "...if you want your code to be easy to write, make it easy to read."
Thus far, there have been a few aspects of clean code which have been explicitly stated. Clean code is:
Now, it's important to remember that this is simply one school of thought. There are others, and mine may change as I continue to grow. "There will be lots of code. You'll see good code, you'll see bad code. You'll see bad code transformed into good code... You'll see example after example. After that, it's up to you."
There was once a concert violinist who got lost on his way to a performance. He stopped an old man on the corner and asked him how to get to Carnegie Hall. The old man looked at the violinist and the violin tucked under his arm, and said: "Practice, son. Practice!"
Top comments (0)