The next few months bring with them the completion of my first employed year as a programmer. I wanted to write an article documenting some of the things that became apparent to me as an entry level professional developer. I sort of dislike using the term “professional,” as I find it a little strong. I need to contrast the difference, however, between what I was doing before this year and what I have been doing over the last few years. When I label myself “professional programmer,” I’m not implying that I am a senior developer of any sort. Moreover, I wish to express that “professional” to me refers to, quite simply, my profession: a developer in a corporate environment and as part of a team. Prior to my entry into the corporate development world, I worked on many side projects in all areas of development. Most of these side projects were a mix of freelance work and personal project work. My goal in writing this article is to go over some of the key points of interest for any future developers following the path from student or freelancer to corporate level programmer. I strongly welcome any feedback from those like myself or those well experienced and long term veterans. Hope you enjoy.
#1: You need a great mentor.
One of the most valuable things that could come to you when you start out is either a single mentor, possibly a boss or else multiple great mentors. Be it a friend of a friend who was worked in the industry, a computer science teacher you may have had or your first actual boss. These people are going to be very important to your success. Listen to what they have to say and take their advice. I was extremely fortunate to have all three of these types of people.
#2: Choose and research which technologies you want to work with before you accept just “any” job.
You are going to be eager to start, maybe even financially under pressure but rest assured it will happen so make it happen right. The thought of flooding job sites with your resume may seem like a great way to cover all possible openings, but it is not. Take your time, invest your time wisely, really know what you want and find it. The software industry is a huge one and full of possibilities. Be sure the jobs you are applying for are really what interests you and are covering the vast areas of technology with which you want to work in. Certainly take into consideration all the regular job requirements but at the same time take into consideration what it is you will actually be doing in front of that computer screen. For newcomers like myself you may be actually unsure of which language you want to work with, which technologies you want to use and which aspect of development you want to strive in. In this situation you may need to look for a company that can give you that glimpse into everything. For instance if you hate database work, yet are happy shifting between front and back-end development, find a role that will provide you with experience in both. You will really ksnow that you have hit the career goldmine when you find a company that will not only let you steer down the path you want but guide you at the same time.
#3: A language is a logical language.
You will find countless blog posts, articles, videos and even teachers explaining why such and such a language is better than another language. Or what certain development environments provide in relation to one another. You should for sure research into these yourself. Document everything and fully compare and contrast the most popular, or need I say the most employable. While the language itself may be the important factor, you need to remember that with regards to whatever environment it is you are working with the logic of any language is the same. Once you master the logical aspect of any code you can simply shift that approach on to your next language, which is simply speaking just different syntax. In theory when beginning programming I would highly advise to pick a popular languages to start working with. The internet and your local library can be your best friends and with popular languages come an array of books, online resources and support.
#4: You are not an advanced programmer yet.
#5: Back up everything.
As you work through a problem or build a project, be sure to have a foolproof way of backing everything up. There is little worse as a programmer than wiring many lines of code only to have it all overwritten or deleted. It’s a painful experience and can happen at the worst times however, it if occurs, take it with a “pinch of salt” and pick up from where you left off. Versioning or “Sub versioning” is usually a way that multiple developers working on the same project can collaborate together. Most companies usually employ some sort of versioning control. This may be your best friend in containing back-ups of everything as you progress. Regardless of whether or not you are working on a project within a team or on your own, I highly advise considering versioning as a method of all your progress.
#6: Slow down.
There is a tendency at the beginning to fly through code when the project you’re working on is piecing together seamlessly. Although things may be going extremely well for you, my advice is to slow down anyway. Try to work at a moderate pace and not get ahead of yourself. Busting out code can lead to overconfidence, and then to errors. On the other hand, there will also be moments when things are not going well for you, no matter what you try. Things may be breaking, may be extremely complex, or you might just hate the current aspect of what you’re doing. All these frustrating factors happen to us all at one point in time. Don’t sweat it, and just take a deep breath.
#7: Document your progress.
Different developers have many different ways of doing things. Some like keeping timesheets, some like using actual time documenting programs, and others like a simple notepad and a pen. I am a notepad and pen sort of developer. Regardless of the method you choose, make sure to write down a summary of every task you do as you work through the day. There are many benefits of doing this. Namely, you have a reference of your work should anyone ask you what you did. You have a reference for yourself if you need to look back at notes on a prior task. You also have a mapping of everything you do, creating a great way of logging your work for yourself.
#8: Keep things simple.
Think: simple yet original. Clear and concise code always wins. There is sometimes a tendency to over-engineer things, but that only leads to murkiness.
#9: Set out a time plan for all tasks.
Your time is extremely valuable. You may find yourself in a situation where you are either working on something new or bug fixing something old. If there are certain selective issues that come to you and that you need to fix, make sure you allow a generous timeframe in which to complete them. You don’t want to start working on a bug fix that you assumed would take an hour, only to find yourself still attempting a fix after half a day’s work. Overestimating or underestimating time happens a lot. Stick to the time you allotted yourself to complete something. Then move onto something else, refresh your thought process and set yourself another allocated time slot in which to fix that bug.
#10: Celebrate breakthroughs.
There are going to be the tough times. Many of them. So, when you work through a tough problem and eventually find a solution, celebrate it! Even if your breakthrough may go unnoticed, don’t let that phase you. If you want, stand outside for a few moments and fist pump the air. That beer on a Friday evening will taste so much sweeter.
#11: Support your peers.
The people you work with are going to be an extremely valuable asset to you. Interact with those around you on a personal, not coding level. At the same time, involve yourself in coding discussions with them. Give them some professional compliments if you feel the space is right. If asked to help or for an opinion, give your peers your full attention. They will notice this. Teamwork is one of the most important things I’ve found that drives a development group.
#12: Don’t reminisce code failures.
Failure can get you down. Failure is a common occurrence in development. Remember that your job is not a procedural job. As a developer, you are constantly creating and coming up with new ideas and outlets to solve issues. Things that are new and are created from scratch will have their problems. No developer is completely foolproof. The signs of a strong developer are those who can see a problem, sit back, and reflect on it first. Don’t get discouraged if you mess up or come to a dead end. This struggle is all part of the learning process. When this happens, revert back to number 11. A team works together in a non-judgemental way.
#13: Try to learn something new daily.
I always like to have a pocket reference programming book nearby or a selection of apps, or blogs on my phone with something new that I can look at. No matter what it is you are currently working on pick up a small intro guide to another language at a bookstore and read a bit into it every day. I always find that jotting down little notes on some topic/code snippet I may have stumbled across is hugely beneficial. I like to then take one of these topics/code snippets and advance on it. If you do take some time to advance on it you will find that later that same topic/code snippet may come around again and this time you can handle it with ease.
#14: Projects are usually harder than you may first anticipate.
It may not always be the case but you need to be aware that a lot of the time an up and coming project that may be discussed over a coffee with the idea of being put into development, is going to be harder than you think. When words are spoken and an idea is sprung developers tend to start applying logical processes straight away. Everything looks so well laid out and meticulously planned on paper but when you put this into practise you need to prepare yourself for the many hiccups along the way. Before you delve straight into something make sure you set aside time to really think about your strategy and research the technologies you are going to use. I have my own faults in this! Namely, going down the route of using this great new technology which makes everything look and function amazing but then only to find the whole thing has to be scraped two weeks later thanks to an undetermined factor, Internet Explorer. It just happens. Make sure you pace yourself and plan everything out before you commit yourself to a workflow.
#15: Projects are never “finished”.
Regardless of what you may might think, projects are never finished. There will always be something new that you could be doing to enhance your project, be it visual, related to performance or some sort of update. If you find yourself enhancing your program it’s considered a very good thing. It means your project is working and it is being used.
#16: Google is your best friend.
You are not by any means expected to sit down and write line after line of code until you compile and then something happens. There are an endless communities of developers out there, sharing and collaborating with one another. Take to the forums, networks and communities to assist you in your learning path. Some of the best ways to learn are from others. If there is an issue you are having or something you are stuck on take to a search engine or stackoverflow to investigate into the issue. Ideally what you want to find are a series are different methods into what you are trying to achieve. The real investigative part of you should be able to take snippets from these resources and implement them into what you are working on. Regardless of what some people may tell you this is not plagiarism, this is learning. Yes, sometimes it is text on a screen that you may be replicating, but in essence it is similar to somebody telling you that you are plagiarising by using a wrench to undo a bolt. Keep an open-source mind on things, we are all learning together.
#17: Embrace your frustration.
Things are not always going to go your way the first time around. Sometimes even second time, or third time. That’s just the way it is. You are no different than what any other programmer or what they have experience before. The real skill is to be able to step away from the keyboard for a few moments, walk around the block, grab a coffee and try to relax your mind before you come back to the issue. You would be surprised at how effective this tactic can be. I have witnessed many times developers that can’t manage themselves. They huff and puff, and even sometimes throw things around if things don’t go their way. I have never ever seen one of these types of people end their day with success after they get like this.
#18: Zone out.
Different developers find different ways to “zone out” from the world around them, or in contrast “plug in” to their work. I personally love putting on headphones and finding a cool hour long playlist of music online to help me along while I work. Try the Tron legacy soundtrack J. This is a tough pointer to apply as everyone has their own way of being focused and productive. I guess what I mean to say here is that you need to find your best way to be focused and productive and without question utilize it to the best of your ability.
#19: Code review.
You must always adhere to code reviews either by yourself or by those above you. Always keep the question lingering in your mind after you do something “How well did I write that?” or “Is there any way I could have done that better?” Sometimes asking yourself the second question can actually lead to some interesting finds and in turn heavily increase your skill set. Take any remarks good or bad mentioned about your code as constructive criticism. We are all learning. Regardless of what many think we are still always learning.
#20: Ask questions.
The best thing you can do is ask questions. Think of it in a certain way. No matter what company or group you find yourself working with there are always certain aspects specific to that company/group that you will need to adhere to. Let’s face it you could be working for a company like Amazon related to books or a kindle, iTunes which are all music based, Boeing which are completely air-transportation related, EA games which are all computer games related or else the start-up companies that simply need a website and a few accounting applications. In any situation you will be the new developer to their community and you may find yourself embarrassed to ask questions that you think “should” be simple, or you may think others will judge you for asking. As I have mentioned before, what may be considered “simple” to one developer may be a complete head melt to another developer.
#21: An extra tip! Avoid Anti-Patterns.
I am not sure if this is technically classified as an anti-pattern, but for the sake of this article I will reference that term. Try at all possible to leave your browser to debugging only. J Most will laugh when I say this, and certainly for good reason. One of the most distracting things you could have are social interventions of any sort. In Number 18 I wrote about zoning out. These days it is extremely hard to just turn your smart phone off or else close those tabs that contain those continuous notifications of social something or other. It’s going to be hard, but just do it. I promise you one thing. Avoiding constantly checking your social status, or updating your feeds as your day goes by will dramatically increase your productivity. Even consider closing regular email notifications from interrupting you. As I mentioned music can be great for zoning out. If you have YouTube/sound cloud/Spotify music playlist’s as I do you could easily be triggered into the same scenario as I do. Stick to the music and avoid the distractions. Try to set up playlists so that you are not constantly switching tabs to change tracks or artists. Music can be highly productive while one is coding only once it is applied correctly.