3 rules for novice programmers
The last few years have definitely been a steep learning curve for me. Three different companies, each with very different outlooks on development, productivity and improvement. The field of development often seems like a blank canvas. You doodle around for a bit. Soon your attention holds long enough for your doodle to graduate to a drawing. The drawing’s complexities evolve with you. Shading, colours and all other intricacies start to form. But here’s the problem: whatever masterpiece you may believe to be creating still gets its foundations from the doodle you found yourself sketching at the start.
But are those foundations strong enough to reinforce industry leading knowledge? If not, then perhaps it’s time you started drawing another doodle. This is essentially what it comes down to. There are number of times that I have had to unlearn and relearn aspects of development. With that in mind, I think it may be useful for me to share what could have reduced that number.
I would not consider myself senior just yet, but I have learnt a thing or two. I hope that perhaps someone whose just starting their journey into the world of software development can get an edge on some of the common pitfalls of this industry.
1) You are not competing with your colleagues — use that to your advantage
When I began my first development position it was like having my floats, crutches and stabilisers all swept away from me in an instant. I had gone from Udemy tutorials in the comfort of my living room to the merciless hustle of a digital consultancy. There is such a torrent of information thrown at you that I found myself becoming slightly defensive. You may begin to judge yourself against your colleagues. Anyone who read my first article knows that I only see trouble in losing focus on your own path through placing it on others. The expectations curdle into preoccupations and there is the potential for you to become a pariah of paranoia. DO NOT let this happen. It will only work against you.
The issue here is not being paranoid that others know more than you. That will almost certainly be the case. The issue is with the framing. The insecurity that comes with a novice level of knowledge can lead you to not want to open it up to your colleagues. This in turn can drive a wall between you and them. The longer this stays the case, the more intense an “us and them” mentality will become. Instead, embrace your ineptitude and others will gladly come to aid you. Your colleagues are not mind readers and may not always assist you if you pretend that everything is ok. See yourself as part of the team and you will be a hundred times better off than had you taken the “high road” alone.
“There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.”
― Carl Sagan
Ask questions. The greatest mistake I made was not asking enough when I started out in fear of others knowing how much of a novice I was. The reality was, obviously, that I was hired as a novice so this was no secret. By asking nothing you are only telling the world you would rather be ignorant than embarrassed.
2) Be flexible
“Those who cannot change their minds cannot change anything.”
― George Bernard Shaw
One of the most common phenomena I’ve both experienced and witnessed in development is the unspoken notion of “the right way”. To flog my doodle example once more, someone beginning their sketch can often apply a sense of absolutism to it. You should be malleable with your method upon starting. It is a certainty that it will be far from perfect. When you begin development the expectations are low enough that you have the incredibly rare chance to experiment in a professional environment. DO NOT take this for granted, you will not get it again. If you see someone else doing something, try it out. If you read about something new, don’t hesitate — just try it. The shortcomings of starting over will be unrecognisable in the shadows of finding your footing.
This isn’t just applicable with method but also with work. My first job was quite straightforward in terms of the work flows. I would get given a design and I’d build it. There was very little cross over into other flows. This created the bad habit of feeling chained to whatever piece of work I was currently on. In todays “agile” (I hate this word) world you cannot have this mindset. My work today can often involve me working on 2 or 3 branches concurrently. When you work with others you will sometimes have to wait for them to finish work in order to continue. Do not let this hinder your momentum. Be ready to pick whatever else up that you need to in order to keep your mind active. By doing this, you will get the most out of your work.
3) Set personal targets now
It is very easy to confine your development life cycle to the count of a clock. Measuring yourself by how your company does will only box you in. You are the master of how you want to develop (see what I did there) and you should therefore be keeping tabs on progress. What your targets are initially doesn’t really matter. What matters is having them. Perhaps it can be something as simple as “I will read three articles a day” or “I will right at least 200 lines of personal code a day”. There’s no real science behind these targets but by doing them each day you will instil a sense of personal duty to yourself. In the book “Make Your Bed: Little Things That Can Change Your Life…And Maybe the World” William H McRaven sums up the psychology behind this perfectly:
“Making my bed correctly was not going to be an opportunity for praise. It was expected of me. It was my first task of the day, and doing it right was important. It demonstrated my discipline. It showed my attention to detail, and at the end of the day it would be a reminder that I had done something well, something to be proud of, no matter how small the task.”
By committing to something daily you are committing to an improvement of your standards. Pick anything, it really doesn’t matter all that much at the start. But, make sure you do it everyday. If you stop doing it once then you’ll have given yourself an excuse to drop it any other day.
To anyone that read my article on Sisyphus and standards, you should know that this is only the beginning. Getting into a routine is important but make sure to keep it dynamic. Measure yourself, if you can get three articles done in 20 mins then make it five. If reading articles isn’t sticking, start taking notes and set targets around that instead. You need to figure out what works best for you and then capitalise on it. Never be satisfied with it to the point of stagnation, but do take enjoyment from it. I find that the better that I measure my progress, the easier it is for me to take enjoyment from placing effort into personal improvement.
Do you have any rules for beginning programmers? I’d love to hear them.
