The rules for coding are more often guidelines or stylistic suggestions, not hard-and-fast rules that must be obeyed or code death will follow (except the occasional, yet dreaded 500 error). Regardless, there are some important practices that you should consider, at every point in your coding career.
The intention of the list below is to leave you empowered and for us all to be better developers and human beings in general. As always, feedback is welcome.
Think before you code.
Keep your code gluten-free: not bloated and no spaghetti code! You should have the solution figured out in your mind before you even begin typing it out.
When you are first starting out, you will mess up often and you will under-estimate the amount of work that goes into what you are trying to build. That’s okay; if you aren’t messing things up, you probably aren’t trying hard enough.
However, if you take the time to think through the structure of what you are building and create a mental blue print, you will save yourself a lot of hassle. This doesn’t have to be fancy, the point is to grasp a holistic view of what you are building and consider all of the working parts needed for it to come together. Personally, I love using my notepad or window markers at this stage.
If you’re a fan of corny analogies, like myself, let’s think about an artificial Christmas Tree (if you’ve never head one of these before, you should be grateful). December 1st roles around and you muster the strength to drag the colossal, 8-foot box of tree pieces and accompanying ornaments out of your basement. You take out the contents and sprawl the “body parts” onto your living room floor. Now, what do you do first? No, you can’t start putting the pretty tinsel and delicate, ornaments that are probably older than you are, onto the branches yet. Then you would have to try to assemble the tree without shattering your grandmother’s favorite star. You need to piece the tree together starting at the base, then branches, stand the structure upright, splay out the little, poky leaves, wrap on some lights, and THEN you can start to adorn it with pretty things.
Building software is similar. I love a sexy User Experience as much as any techie, but the CSS doesn’t matter if the integrity of my product’s infrastructure is not there. Adding blingy buttons to an app that doesn’t work will never render any result.
Prototype.
Its called an MVP (minimal, viable product) for a reason. Where I work, it’s a standard practice to build a little, test, then build some more.
If you write small bits of code, set up tests for it, debug it, and iterate often, you start to develop at shocking speeds. This methodology seems redundant at first, but it’s a lot less of a headache than getting carried away writing 1,000 lines of code and then try to figure out where that 1 missing coma is…etc.
Also, if you haven’t realized it yet, in-browser debuggers suck. Use testing tools instead of a debugger, and create everything as a small test case. This is becoming recognized as “Test-Driven Development.”
When you get adept at TDD, you will be able re-use your code more often, thus saving yourself time and a few migraines trying to remember how you built that one thing, 6 months ago. If you love your future-self, keep a library or record of smaller snippets of code, especially ones you use often. This will help you be able to easily reference, grab something and tweak it, instead of having to re-write it over again.
Frequency.
If you aren’t working on something every day, you’re going to forget what or how you did it, a lot faster than you think. I’ll build something, not touch it for a week, then trying to do it again, and crickets… It’s amazing how quickly something can escape you, especially when you are first starting out.
Repetition and working on a certain skill every day, your neurons will reform and become habits, making lots of development second nature. Until then young Padawan, do yourself a solid and work on something, however small, for a minimum of 30 minutes, every day.
You are not a robot.
While it may not be intuitive, coding is not a mechanical job, it can’t be forced. Coding is however, a creative experience and you need to be prepared for and know how to deal with “writers block”. Inspiration seems to have a mind of its own, some days you may look up and realize you’ve been plowing through work for 10 hours straight and even forgot to eat. Other days, a glass of cold water to the face won’t get you out of bed.
Start looking for your triggers. What will throw you off kilter? I leave my cellphone on “Do Not Disturb” most of the time, because text messages will easily throw me out of flow.
Is there anything that helps you find focus? Perhaps light a candle or make an espresso to sip. If you find yourself staring at the screen, reading the same line for what seems like an eternity, looking for a syntax error, step away for a few minutes. If you look at something long enough, your brain will see what it wants to and catching little bugs can become more difficult. Taking a ten minute break or a short walk can help you reset and be able to come back with new eyes.
For something more serious, like an architectural problem, take half the day off, doing something away from screens, and let the solution brew in the back of your mind. Obviously, this more difficult to pull off when you are in an office environment, but if you have the luxury of working remote, I find myself to be a lot more effective if I can drop it for a while and let my subconscious do the work.
Rituals.
This is more of a subjective experience, but still worth mentioning. Do some self-exploration and create “standards” for yourself, as a developer, and stick to it. For example, define a specific structure in which you write name variables and write your Javascript functions..etc.
If you’re new to coding, this can be learned from looking at other’s code bases, but please, do yourself a solid and vet their quality of work. How are they formatting something? Is it consistent across the board, regardless of the number of contributors?
Your future self will love you for this. You will be able to quickly search for and find where past projects and useful code snippets are stored and increase the readability of your code in general. Consistency is key.
Comment your code.
Please, do yourself a solid and keep it structured. When you are on a team this is crucial. If you aren’t on a team now, you will inevitably be on one, so start practicing this now. You will thank yourself when you don’t look at something for a week, month, year even and can easily figure out what certain function was for.
If you are on the market for a job, being able to show potential employers your code and how beautiful and commented it is, will really help you stand out in a stack of resumes and portfolios. I wouldn’t hire someone that I didn’t think would be a good fit for the team or is able to code well with others.
At the same time, don’t become a novelist and comment every line. Comments are a great resource to explain method to your madness, i.e. why you broke a rule on purpose, the general purpose of a snippet, or a reminder to change something later. If you are still learning, its fine to break something down and comment line by line as a practice to ensure you understand every step. However, once you have it working, go back, refactor, clean it up, and recap with a simple comment.
Documentation.
While we are on the topic of being a good human, start documenting your projects. I know, its a pain in the ass and takes time away from you actually building the thing, but, if you ever want another human to look at your Github repo, a ReadMe is advised. It doesn’t have to be a novel, but explain what you are working on and any step by step instructions that may be required. What does it do? What is the over goal or problem you’re solving? Why did you code it that certain way?
Not only will you will learn a lot from this practice and better understand your own style of development, but it will make working with others a lot easier and they will appreciate you for it. (Notice a theme here?)
KISS
Perhaps you had a snarky, grade-school teacher like myself and have the acronym Keep It Simple Stupid, burned into your mind. While this isn’t sage advice for aspiring rock gods, it is for programmers.
I feel this is worthy of an Albert Einstein quote: “If you can’t explain it simply, you don’t understand it well enough.
If you can’t explain it in a few sentences its already too complicated.
Hopefully this is getting drilled into your brain by now, keep things simple for yourself and anyone that will interact with your code. I love the movement for minimalism in our homes right now, its elegant, and I think the same is needed for coding standards.
Its up to you to make your code base either a pleasure or displeasure to work with. Don’t try to show off by writing obfuscated code that only you can understand. This doesn’t make you look smart; your colleagues or clients will only resent you for this.
Fork it baby
So this all sounds fine and dandy, but now what? If you haven’t already, go fork and tear up a code base. My favorite way to learn is by finding a cool project and seeing how it was built. How did they comment it? What’s in their documentation? What’s their coding style?
Maybe there’s an open source project you’re into, go contact the creator and see where you can contribute. I think Open Source is awesome, but sometimes it can be a bit disorganized. Use that to your advantage to learn how to edit and maintain another’s code base.
You can pick up a lot from observing others, but true learning will happen when you try it out yourself, and break a lot.
Give credit where it’s due.
Don’t steal and say its yours, whether you believe in karma or not, its probably best practice to be a decent human being.
You can learn a lot from others, but in pretending you built something you didn’t, you are only hurting yourself. Besides, a true understanding of a subject can only be achieved when you are willing to dive in and do the work required.
Writing this article was a collaborative effort. I picked the brains of several, highly-intelligent people when writing this. I was genuinely curious what their advice to aspiring developers is and together we were able to come to a common consensus on the content of this post.
I won’t claim to know all of the answers, and I’m happy knowing I never will. We are all familiar with the adage:
“If you’re the smartest person in the room, you’re in the wrong room.”
One of the most rewarding opportunities available to us (in tech or any field) is the chance to collaborate, mentor, and learn from each other.
The web development landscape is ever-evolving, there’s always a new tool, framework, and methodology to play with and possibility adopt. Learn for the sake of enriching yourself and the pixels contribute to the web.
Keep calm and code on.
—
This post is a compilation of advice from our team members, namely Jeff.
