I was asked: Does anyone out there have any good advice for code academy grads?
Here’s some general advice for 1) those who are new to programming 2) those who want to cater for them –
I graduated from Makers 3 years ago. I just so happened to chat to a few friends from my class about their advice to current students, a few days ago 
My answer will naturally be much more from the perspective of a noobie, although I’ve helped many noobies too.
I think the question breaks down into a number of themes:
- General vibe: Confusion / Learning / Headaches / Helplessness. How to deal with emotional side of knowing relatively little?
- Learning: how best to learn?
- Support: who can you surround yourself with to help you?
- Advantages of being a noob: how to harness the noobiness from both ends
- Which job to choose?
- Drawing general conclusions: why this advice isn’t just for noobies.
1) General vibe: Confusion / Learning / Headaches / Helplessness. How to deal with emotional side of knowing relatively little?
The first 6-12 months will be very difficult. I had headaches regularly. Everyone is speaking Martian . You have no idea who is saying useful things and who is saying useless things or even what’s supposed to be funny (do people still make jokes about the Scala compiler?)
Compared to a CS grad , not least the vocab but the general concepts were alien to me, very basic terms like “server” were nebulous and vague and made discussions into a very tiring rearrangement of my ideas, in addition to an attempt to have a conversation.
You also lack self-worth because you feel like a drain on others and you probably won’t deliver much useful for a while.
For me, the best way of dealing with the emotional side was speaking to others in a similar boat. It’s also handy to speak to people slightly ahead of you and really far ahead of you, but they can already start speaking Martian so this can backfire 😉
Take breaks: in the day, a long lunch, holiday. Learning seems like a string of random “eureka moments” and it’s tempting to think that more time at the computer screen equals more learning but when you’re overwhelmed by new ideas, you do need to simply rest, reset, and come back at it all from a different angle. This also gives you a chance to ease headaches and back pain and forget your frustrations!
This leads nicely onto 2.
2) Learning: how best to learn?
As a nooblet, freedom is useful. There are two main reasons why I think this.
- noobs are highly unlikely to challenge the way things are done (e.g. the standard routine of the working day) because when you don’t understand why things are done the way they seem to be done, it’s hard to say what it is you would change about it. From this vantage point (or lack thereof) it’s hard to make freedom for yourself, you can hardly formulate the questions you should be asking, because questions seems to be currently formed in the language of Martian. Therefore freedom is useful because it affords you some space to think outside the normal routine, a routine where I personally had a fairly constant stress of thinking about doing what I thought others are expecting me to do.
- freedom affords you space to make your mistakes and learn directly, and without others telling you why they think X is the way to solve Y, you can go through the steps of seeing for yourself why A, B and C are really not the way to solve Y and hooray, achievement unlocked. You feel like you’re getting somewhere.
In my short time in the industry (and on Planet Earth), when I look back to when I learnt a lot, it’s when I was responsible for something and I was out of my comfort zone. This encourages you to learn a lot, learn by doing and challenge and cement ideas, and try new things. Scary though this is.
Concretely, when three new grads joined my last job, we came up with a plan that incorporated some freedom for them. We made every Thursday and Friday their project days. We thought of a project that wasn’t too challenging yet delivered something valuable. They had internal customers and got advice and consulting from others on their work but were largely left to build by themselves.
This approach had several advantages:
- less burden for those that would otherwise be pairing with or teaching them,
- more mistakes for grads – they could put to work what they had learnt in principle while pairing (realistically mostly watching others),
- responsibility gives the work meaning and the grads drive and
- self worth of delivering something useful, which they did!
The last learning point is that Grads are a long term, selfless investment. It’s difficult to quantify value exactly, but I think that Grads aren’t about an immediate return on investment (this is almost so self evident as to be funny to even make the point), but then they should be treated that way.
Yes they should go to conferences, see different parts of the business, gain a broad understanding of different systems instead of becoming proficient on one, and generally speaking, depart from the day-to-day that most others have. They shouldn’t be expected to be great deliverers of value on a complex system.
Imagine your 16 year old cousin wants to be a software engineer, would you show them a problem to do with upgrading an old DB driver in a legacy system that spits out obtuse errors in a horrible font on a screen that hurts your eyes, or do you walk them around the floor showing them the various team dashboards and then spend the afternoon working on a new customer-facing front end that they get to help design? This extreme example doesn’t necessarily translate to designing life for a Grad but I am trying to make the point that they should have a different experience to your mid-level and senior-level engineers.
Learning as a Grad, I found a broad knowledge has served me well. I wouldn’t recommend changing too many variables at once e.g. don’t learn Vim and a new language at the same time, but I am glad that I got a more surface understanding of more things e.g. strong vs weak, static vs dynamic, approaches to testing, monoliths vs microservices, types of DB etc etc by moving teams fairly frequently, and then moved to Ops to learn about DNS, TCP, virtualisation, containers, PaaS etc etc because now I am in a good shape to learn a lot about what I think I know I find interesting and where it fits into the bigger picture, instead of becoming particularly adept at say, Ruby, and knowing little about say other languages or deployment or how the Internet works.
3) Support: who can you surround yourself with to help you?
Having a mentor is and has been really important to me. Personally, if I can’t see someone that I want to be like down the line then what I’m doing now feels a bit disconcerting. Friends that are in a similar boat cannot provide an idea of what you will be like if you stick to your craft for a decade (or three :p )
It is really useful to write down and/or collect articles that capture your passion about programming and learning or whatever it is that drove you to go to a code academy. Eg I read this from time to time, and similar things I can’t recall right now lol.
4) Advantages of being a noob: how to harness the noobiness from both ends
There’s a real temptation to seem like you know what you’re talking about. As time goes by, this gets stronger (“by now I should know how CSS works!” you tell yourself). Instead I try to think the following:
- anyone else in my position would know a similar amount
- knowledge might not even be important to finding a good outcome to what i’m currently facing
- generally it’s far better to admit what you’re ignorant of and solve it than to pretend it’s not a problem and plough on.
- let’s all have an inquisitive mindset and try to find a nice solution by playing nicely with each other, even if it is the fifty-seventh API we’re building this year, this might be the best one yet!
Being the noob about town means it’s even easier for you to question the authority behind the various assumptions we all make on a daily basis. Try and harness this power for good!
Furthering this power for selfish ends, I would ask “What’s it like to be a (insert job role)?” and try and gain experience of life from others’ point of view, especially in areas you think are interesting to you, but also those you don’t, perhaps especially those you don’t, as Mr West said Everything I’m not made me everything I am 😉
From the employers standpoint, any new pair of eyes is useful to draw out the “normalisation of deviance”[def]. I’m talking about how we get used to the way things are done. Nooblets are particularly good at questioning things you wouldn’t even think to question. “Why is caching done at this layer?” “err, dunno, it just is”, “what layers are in between?”, ”err, there’s a firewall somewhere, I think?“, “why don’t we eat at our keyboards?” “because then the keys get sticky.” “oh that makes sense”. Try and harness the power of the noob! One way is to sit down once a week and ask how their week’s been. This will most likely lead to “X did this crazy thing that I still don’t get” which usually elicits “Oh that’s this paradigm we’ve all accepted” or “wtf is that! that is crazy”.
5) Which job to choose?
Three main points I can think of:
- pick an area / product that interests you
- pick a company that has thought about Grads if you like structure, or nevermind if you think you have the initiative to make it up and ask for what you want as you go along (probably a bit of a rogue piece of advice but there we go, some of us are quite rogue)
- pick a place where you know there’s someone that can look out for you
Then if you’re really suffering, move on after 6 months. If you’re suffering but it’s not fatal, plug away because the helplessness does fade after 12-24 months 😀
It is hard to maintain your initial passion after 6 months in a job that didn’t work out well for you. OTOH, there seems to be a rush at the start to become an expert, which I don’t quite see squaring with the other qualities of being an expert- like patience and dedication.
If you were guaranteed to be an expert in 15-20 years, so long as you held onto your initial motivations, would you be hugely concerned about the next 1-2 years? Of course, but you don’t need to stress to death about it. I think involvement in the community (meetups, conferences, hackathons or whatnot) tempers your initial (un)luckiness in job choice more than enough.
6) Drawing general conclusions: why this advice isn’t just for noobies.
I guess the obvious point to make now is, what’s so special about noobies that this advice doesn’t apply to all of us? I guess there isn’t a single topic where there’s not someone who knows more or at least a different subset of things to you, so yeah.
OTOH it doesn’t all apply. Thankfully there are people who categorically know 10x more than me and are experts on certain things for when I have no idea what’s going on, or I just brought down a whole host of services by making an irule change whoops 😀
Steve: i was speaking to X and X wants us to come back to one of the graduations as a cohort and talk about what we are doing now
Jerry: Junior devs take quite a fair amount of resource and you can’t employ 20-30 a year without some leaving/getting lost/not feeling supported etc
Steve: yea true… you need the right infrastructure and processes
Jerry: Can’t help but think it’s better going to a company with fewer grads than more imho
Maggy: yeh I think we need to communicate that it’s ok feeling like you are falling behind etc and you feel a bit lost
Maggy: and suggest strategies to cope
Maggy: like petting animals
Jerry: And when your ‘senior’ dev is a grad a year ahead of you 😕
Steve: i think you’re right Jerry. having a mentor who may only work with 1/2 juniors allows you to have that support
Maggy: that’s the dream, never going to happen in reality I’m araid
Maggy: people have stuff to deliver, etc.
Steve: thats what i had
Maggy: that’s too bad
Maggy: wow that’s lucky Steve
Steve: its not about walking through everything with you
Steve: more about PR review and discussion
Maggy: well now that I think about it, I did have a mentor too, the work assigned wasn’t that exciting though
Steve: let them work but be there to answer questions and chat about other ways of doing things
Maggy: true, but they also have to be willing to ask loads of questions, which is an attitude i don’t see
Maggy: we have an intern and she’s really shy, won’t ask much beyond her day to day work
Steve: hmmmm maybe but if you PR review something in massive detail you force them to ask questions
Maggy: and she’s a bootcamper like us, that’s why I think it’s a tad weird
Jerry: One thing I drilled in to my students was to constantly ask questions about EVERYTHING.
Maggy: yeh we are trying, she is getting better
Steve: my mentor used to write maybe 20 comments on a PR. they were not bugs but him asking questions about why i did it this way. Just forcing me to think about why even if it was the right way of doing things.
Maggy: I also have shitloads to learn though, so I don’t have much time for that 😅
Maggy: I think that’s great, don’t lose that mentality
Steve: PR review doesnt take long
Maggy: many mid level to seniors think that’s “nitpicking”
Jerry: Steve, that’s another can of worms. Code review etiquette. I’ve been trying to get that through to my team. Especially as we’re all remote
Steve: yea i used to want to punch my mentor in the face because of his comments but you need to think about it as debate and not confrontation.. It’s made me significantly better
Jerry: I just ignore everyone’s comments and merge anyway
 I didn’t mean to use this term so much but as I wrote this it seemed apt. By Martian I mean a language you don’t understand (yet).
 this is more a hunch based on CS grads I’m friends with, more than worked with.