On the Job - Early Days
You got hired! … Now what? It’s funny how breaking into a new career can continually have these moments of celebration and achievement followed by the realization that it’s all just the beginning.
Impostor Syndrome: “Don’t tell them you’re new.”
Code Fellows talks a lot about impostor syndrome in their kick-offs. For those who don’t know, impostor syndrome, in our context, is that feeling that you’re not a real dev. You don’t know enough and you never will; the only reason you made it to where you are is because you’re good at lying. You got lucky, but you didn’t earn it. You’re just faking it and at some point, someone’s going to look at your code, gasp, point a finger, and say, “YOU’RE A PHONY!”
However, as much as I felt pretty comfortable in classes and projects, I got impostor syndrome piled on after I’d actually started my first job. At one point with one of the early clients I was assigned to, my manager remarked offhandedly, “Don’t tell them you’re new.”
An innocuous enough statement, it nonetheless gnawed at me a bit. “How can I not tell them I’m new? I mean… What if they ask me something that should be simple and I don’t know the answer? How do I explain that without saying I’m new? What if they find out? Oh, man, I’m going to be harboring this secret that I don’t know what I’m doing and they’re going to find out!”
It caused me to be extremely nervous about any mention of being onsite or speaking with anyone at the client company for any reason, because every interaction meant a possibility of being exposed as someone who didn’t know what they were doing.
Now, what my manager meant was, “Don’t volunteer that you are new and try to find a more tactful way of saying, ‘I don’t know’.” The reality is, we are a consultancy and we’re supposed to be the experts. It looks bad if we’re giving advice on what they should be doing if it appears that we don’t know, either. Instead of, “I don’t know,” I should be responding with, “Let me talk to the team and I’ll get back to you.” You can give a reassuring answer without being bluntly honest.
As a quick side note, the advice really came to light when, on a call with another client, I heard a junior business analyst remark, “Hi guys, I’m so-and-so, I’m kind of new, but I’m really excited to work with you.” I cringed a little bit and thought, “OK, I see what my manager was getting at now.”
What should I be learning and how should I be learning it?
If you’re lucky, you will be hired at a company that has a well-fleshed-out onboarding process, a mentor resource available to help you understand how to integrate with the team and improve your code, and plenty of time to become adjusted and comfortable in your new role.
However, I’ve yet to talk to anyone for whom that was the case, so instead, you’re going to need to figure out the most important things to learn. Should you be focusing on learning some language’s framework? Do you need to really hone your front-end dev skills? Do you need to sharpen your security knowledge for dealing with credit cards?
The best way to figure these things out is to get as much pair programming time as possible with the long-time or senior devs. Figure out what they’re doing and look for anything they do frequently. If they don’t have time to pair program, ask to just shadow them and watch over their shoulder.
Get comfortable asking questions. If you see something you don’t understand, don’t keep quiet because you’re worried about being exposed as a hack (there’s that impostor syndrome again!). It’s always better to be honest about not knowing something and ask for help than it is to not know something and quietly cause problems that have to be fixed later.
On the Job - Settling In
You’re starting to get a sense of what you should be learning, you’ve memorized the names of everyone in the office, you went out for drinks with a few coworkers to celebrate becoming part of the team. You’ve figured out how to seem competent without having all the answers. Now what?
Hours estimates and scopes
Did any of your instructors ever tell you that you should start keeping track of how long any given task takes you and trying to estimate the next one? You probably thought you didn’t have time for that, right? You have stuff due right meow, nobody’s got time to figure out time!
You should. You’re going to be given a lot of projects where someone says, “I need you to build some email templates for us to send out, that look exactly like this mockup, and are configurable in this exact way. How long will that take?”
Often, people who are not developers are going to come up with an application request or a feature enhancement. They are going to be told that they should do it, but only if they can do it within budget. They have no idea how long it’s going to take or what the budget will look like, so they’re just going to ask you. Whatever answer you give them, they’re going to take that back to their boss, calculate the hours you told them by the hourly rate the devs are working at, and decide if they want to go ahead or not.
If you say, “I don’t know,” that won’t go over very well. If you don’t give yourself enough time, they’re going to come back to you impatiently when you said it would be done and say, “Why isn’t this done? You said it would be, we spent money on the assumption that it would be.” If you give yourself too much time, they’re going to come back and say, “How could it possibly take that long? There’s no way you need that much money. We think you’re charging us too much.”
The reality is, you’ll never know down to the exact hour how long it will take, but the more accurate you are, the better your relationship with your managers and your clients will be. It will also vastly improve your work life, since it will directly affect the amount of work you are given. Too much work and you’ll stress out working overtime, too little and you might not be seen as contributing enough value back to the company.
Code review
If you’re on a good team, your code will be reviewed. It will probably be mercilessly reviewed. You will probably feel like you’re a terrible programmer because of how many things need to be fixed. However, your code will vastly improve as a result.
You’re pretty much never writing code just for yourself on the job. Everything you write is going to be worked on by someone else at some time. Code review is that moment where, before what you do sets in place, the team gets a chance to say, “Would I want to work with this later?” When you’re new, expect that the answer is going to be, “Not without significant cleanup and refactor.”
It can also be a chance to make sure you’re not doing something expensive you hadn’t thought of. Did you remember to put all the necessary attributes in your HTML markup to make your page compliant for screen readers? Did you remember to properly hide secure information instead of accidentally exposing something you shouldn’t in a call to an API? Did you ensure your solution will have code that executes in acceptable time instead of slowly loading on the page for several seconds?
Code review can sometimes be treated as a necessary chore that nobody wants to do. It may feel nitpicky, pedantic, or pointless, but it should ideally be treated in such a way that your code will continuously improve to the point that anyone could easily pick it up, make modifications or improvements, then put it back in the same clean, easily understandable way they found it.
In short: get used to being told you need to fix things. A lot.
Managing Workflow
Did you follow best practices in your pairing assignments? Did you have meaningful commit messages that explain exactly what you did with each change? Did you write code that makes it obvious what it’s doing, with comments and documentation to explain the pieces that aren’t readily understandable? Did you do everything in your power to make it so the next person working behind you or with you doesn’t have to put their head in their hands, sigh, and go, “What were they thinking?!”
These are all important parts of working on a team. If you created a useful component for your project that I realize would be the perfect solution to an issue in mine, but all your commit messages are, “Fixed a thing,” “Fixed twice,” “New feature,” “Added a function,” and I have to open up every single one of your commits to hunt for it, I’m going to be very frustrated. It’s even worse if there’s a bug and I need to see what the code looked like when it still worked.
This is also something that’s good for yourself. Setting up a good workflow increases your efficiency and gives you a level of predictability that can improve your time estimation (remember how important that was?) and ability to work without constantly stopping and scratching your head.
On the Job - Clients
Depending on the sort of role you enter into, you may be giving presentations or having meetings with clients. Even if you don’t, you might be doing the same for managers or other internal teams. Most of the time, these people will not be developers. A big part of the job is going to be figuring out how to explain your job to someone else.
You’re a web designer now
Hopefully you know the difference between a web developer and a web designer. You do? Great! Clients probably don’t.
You are probably going to have the following conversation a number of times:
“I want you to make me a website. It needs to do the following things.”
“OK, great, I can do that. How do you want it to look?”
“Simple and professional.”
“… Yyyyyes, I figured that would be the case, but what do you want the layout to be? What colors would you like to use? How would you like the user to actually interact with all this functionality you’re requesting?”
“Uhhhh… You know, just use your best judgement.”
A lot of companies won’t have artists, graphic designers, UI/UX experts, or, in short, a web designer on their staff. However, they’ll figure you’ve built enough things for other clients that you have some thoughts on what looks good and what doesn’t, regardless of whether or not you do. Truly, you may know more than they do.
As such, you should expect that people will rely on your expertise in areas that you don’t have any in.
Translating “dev-speak”
There’s a reason they’re called programming languages. You now speak, for all intents and purposes, a foreign language. This language is spoken by computers, who have their own social norms and customs. Their culture is very strict about following these norms and they don’t respond well to people who don’t follow their laws.
You’ll need to be able to explain these laws, customs, and cultural differences to other people in the same way that an interpreter or guide would. When a client says, “It’s broken,” you need to figure out how to interpret that into your language of choice. “I’m getting this weird error” is a phrase you will hear frequently, typically related to something like, “x is undefined,” “null pointer exception,” or something else that’s more immediately obvious to you, but might as well say, “Banana banana banana” to them.
Practice explaining what you’ve been doing at Code Fellows to someone who’s willing to listen, but do it in a way that they can follow along. Explain the bugs you’ve been fixing, the hurdles you’ve been overcoming, or why a “simple feature” is such an exciting success. Finally got your Bus Mall charts to display with Chart.js? Explain to a non-dev why that’s so awesome, using “layman’s terms.” It will be a valuable tool to have in your kit.
It’s all about communication
As long as you’re open and honest with people about whether or not something is simple, how long something will take, why you’re ahead of or behind schedule, or the reality of what they’re requesting, they’re generally pretty willing to work with you. You’ll probably have regular calls or updates you’ll need to inform somebody of, whether a client or your manager, and as long as clear progress is being shown, or you can communicate effectively why there isn’t, you’ll be in a good position.
If you have good communication skills, it will go significantly further towards pleasing your clients and having positive work relationships than good coding skills will. Passable coding skills can often be made up for by excellent communication talents. “Rock star coders” who are failing in their ability to communicate, however, most likely don’t have a smooth career ahead of them.
Setting Expectations
As a final note, learn to set your own expectations. We all got into tech for one reason or another, but a common theme across many Code Fellows students was wanting a better life in some way. Part of that will require setting your own expectations for the job. What is a good work/life balance? How much can be asked of you? Where do you see yourself in five years (trite, but you should think on the answer for it)?
If a client wants you to be available on weekends as an on-call resource, how do you want to respond to that? If an employer expects you to travel a lot, is that something you want? Stand up for your own wants and needs and be clear about them from the beginning.
Then, after you’ve blazed your personal trail, be open to turning around and offering your experiences and advice to the next group behind you.
If you’re interested in becoming a software developer like Steven and starting on a path to a new career, see what you’ll learn in Code 401: Advanced Software Development in Full-Stack JavaScript »