A little over a month ago, I started my first developer job. It hasn’t been exactly what I was expecting. For the first few weeks, I blamed the job. How could they not have a desk with a monitor set up for me? How could I not be assigned a project on as soon as I got there? Why didn’t they get my background check results from the consulting company I work for and issue me an ID on the first day?
After a while, I realized that blaming the company was not realistic. Yes, I think there are things that could have been done better in my first few days. But most of the problems I had came from walking in with unrealistic expectations.
If I could go back in time and talk to myself before I started this job, here are some pearls of wisdom I would share with myself:
- Just because they need you, doesn’t mean they’re ready for you. Most companies need more developers. They have too much work to be done and not enough people to do it. So they hire more people. The problem is … they may be too busy trying to get the work done to have time to get things ready for the new people. You may not have a desk right away. They may take some time to assign you to a project. Take the time to get to know the people around you, learn the codebase (see below), and volunteer to help when you think you might be needed.
- Expect to have to learn the codebase yourself. I don’t know what the standard procedure is for introducing new hires to the codebase. But for me … there really wasn’t much. I was given access to instructions for downloading and running parts of the codebase … and that didn’t even fully work. I later learned that we’re moving away from the existing codebase and working on something new. I still don’t know what most of the code does. Anything I learned was something I taught myself. Going in, I thought someone would at least tell me what codebase and files I would need to work on … apparently not. I honestly don’t know if this was me expecting too much or a problem with the onboarding process at my company, but … I wish I had known going in that I would need to learn the codebase myself.
- The tools they use may not be the best for the job. Every company has tools they like to use. That may be a framework, an agile tool, a testing tool, or really anything else. Sometimes those tools are what’s best for the job. Sometimes they cause more trouble than they’re worth. As a developer, you need to decide if you want to work with the sub-par tool or if you want to try to convince your company to switch to better tools.
- It’s okay to ask questions. The first few days, I really had no idea what was going on. I’m still not always 100% sure. I’m someone who is not always comfortable asking questions (it’s something I’m always trying to work on), but I find that when I do, my co-workers are happy to help me out (time permitting) and explain things to me.
- The interview might not reflect every part of the job. If it’s a good interview and a very well-defined job, then the interview will probably very closely reflect the job. But if the job is something that’s not 100% clearly defined, or something new that the company is doing (which is the case with my job), then the interview may be more geared towards general dev questions than the specific job. My interview was very heavily javascript-based, and my job is more focused on testing. I knew coming in that the bulk of my job would be testing, but I think the interview made me feel like I’d be working on the code too, and I’m really not. That was definitely something that surprised me (but maybe it shouldn’t have).
Every job starts off differently, and mine did not start anywhere near my expectations. I like to take every experience as an opportunity to learn, and I know that this is no exception. Next time I start a new job, I will make sure to go in with more realistic expectations and know that while things may not be perfect at first, they will get better.
