Search CompSci.ca
Subscribe
Career
Junior programmer: earning respect
Clinton Forbes rants about junior programmers, straight out of University, looking for some respect from well established developers at, presumably, their first paid programming position. Having gone through being a graduate developer himself, and later looking down at the same as a senior and lead developer, I suppose that gives Clinton a fair insight.
If you are a programmer who has just joined the workforce, you may find that your excellent university grades aren’t enough to earn the respect of your peers.
The 5 step guide is essential to students on co-op jobs, useful to new graduates seeking development work, and remains applicable to any new team member. In a checklist type of summary:
- If you make a mistake, admit it
- Don’t pretend to have knowledge that you don’t possess
- Don’t expect your curriculum vitae to give you instant respect
- Don’t try to improve things straight away
- Show enthusiasm
Some analysis:
Obviously admit your mistakes. Bugs happen in code. Bugs always happen. A bug is not a feature, and claiming otherwise could quickly diminish the level of trust in your responsibility. Junior tasks are not vital, no one will get killed over a relatively minor mistake. Though denying and shifting the blame over a broken webpage layout will just about guarantee the murder of any chance to touch the code of the actual application under the said layout. Be honest.
Don’t pretend to have knowledge that you don’t possess. Especially in an interview. A practical test will quickly weed out those who memorized acronyms and buzzwords from programmers who actually wrote some code before. It’s fine to show that you are interested and are willing to learn, but resorting to lies and exaggerations in order to get assigned a task that you simply cannot do… that is just a lot of trouble. Clinton cites an interesting case from his personal experience:
Last year I interviewed about 10 developers for a senior position. I asked each of them if they were familiar with SQL Server and if they could write stored-procedures. Everyone said “Yes”. I then gave them a practical test and allowed them each as much time as they required to create a very basic stored-procedure and an associated simple application. Nearly everyone failed miserably. The shame on the faces of these people was excruciating, particularly one guy who sat for 3 1/2 hours without writing a single line of code.
Don’t expect your school report to earn your instant respect. Computer Science degrees are largely theoretical. You’ve done a lot of Math. You’ve done a lot of theory. You can draw pretty graphs on paper. Great! Now, welcome to the real world. It would take time to assess your learning potential, and to translate academic studies into practical application. First projects will consist of basic tasks, but use such easier assignments to familiarize yourself with the new team, and demonstrate yourself and your potential. Complaining will not get you far.
Don’t try to improve things straight away. I know, eager students full of ideas about cutting edge technologies jumping at every piece of the system they have heard about.
- “Lets change every application to Open Source”.
- “Lets change every application to a proprietary one taught at my school”.
- “Your PHP interpreter is not the latest release version!”
There is most likely a good reason behind the use of PHP4 instead of PHP5, so hold on to all your suggestions until you are familiar with the current system, choices and reasons. Simply enumerating a list of latest software releases is not very useful, and there are web based trackers that do the same anyways.
Lastly, show some enthusiasm about your work. Seriously, moaning about entry level work is counterproductive to getting any better work. Show some enthusiasm. Show some initiative. Then when you have completed your assigned task, and have begun to establish yourself in the new team – ask for a more challenging piece.
My personal addition would be 6. Ask for work. Sometimes there will be situations (and as a student I’ve seen those a lot) when you have nothing to do. Such is surprisingly common for junior programmers who have recently joined the team, and are not yet assigned to a project. Take this opportunity to volunteer help with some minor tasks of a larger project – it will keep you from being bored, shows initiative, enthusiasm, and earns recognition from senior developers. The difficult part of software development is communication, and this interaction with other developers on the team is your jump-start.
Lastly, keep in mind what you will learn, it will come to you easier.
Read more
Discussion
Post a comment
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
“Don’t try to improve things” — Such good advice. Write your ideas down somewhere because there is a perspective from being an outsider that you’ll lose after a while — but don’t walk into every weekly status meeting complaining about something new (aka what I do)
“Ask for work” — again, so true. You might find working on your blog and checking slashdot/digg very interesting, but that won’t help you get more respect.
Reply to comment
Nice post Tony, it really catches the do’s and don’ts. As a junior web developer myself I’ve been to many of the stated situations.
“Don’t expect your school report to earn your instant respect.” This is true, but when I got hired, I got hired with the qualifications obtained through self learning on the side of my original studies. I don’t even have my bachelor degree in IT yet, and they were still so impressed of me that I could choose between jobs. To sum it up, it is what you do that gives you respect, not what a school report says.
“Don’t try to improve things straight away” This statement should almost apply to every new junior programmer, but only if the situation of the company let you. One of my practical tasks given to me for the second round of the interviews was to be a stone cold critic of some of the sites they had. I was ruthless and suggested new standards, channel choices . That fresh and outsider perspective, engtech mentions this aswell, was the key that they liked about me. Short: be modest, but when you have the go, go for it.
One other key thing that you don’t mention in particular is that many publishing sites (ezines and such) still don’t have a clue on how things work on the web (when the junior programming job is web relative). They may want fancy gadgets and ad-o-rama on every page fubaring the site, some good stuff, some very bad stuff , it is our job, as a junior programmer, to be open to ideas, but also be professional enough to turn down stupid ideas.
Anyway, this was my two cents..
Reply to comment
@engtech, Alexander – thank you for your input.
The point about improving things obviously has two sides to it – without research and backup, early “improvement” could make one look foolish. On the other hand given a proper opportunity and supporting arguments, the same would show one as insightful and valuable.
One such personal story involved me suggesting a switch in favour of the Firefox browser. The suggested improvement (I was talking security) was brushed off and I was told to wait until the next major release (ether 1.0 or 1.5). That actually happened to come soon after, and I have excitedly send out a group email, alerting of the “improvement”.
Now even though the email clearly originated from my name, and was signed as “student” – it was written well enough to have some people confuse it for something of much more authority. I did not completely take the existing office culture into the account, and ended up causing a small scale commotion. That was one of my “junior programmer” mistakes.
Reply to comment