This post is more about after working at a developer job than the process of getting one, but I hope it’s still relevant enough to be of use. These are just a couple of thoughts I’ve had since I got hired at my first programming job about four months ago now, in terms of how working compares to doing it as a hobbyist or student. This is not intended to be advice, but rather things that I’ve noticed - don’t try to over-generalize anything you read here, as I wouldn’t want anyone thinking that my experiences are universal.
1. Working with someone else’s code (the development end)
FreeCodeCamp, like many (most?) other programming courses, emphasizes the aspect of programming that involves building projects from scratch. This is a good and important part of the learning process, but most courses that I have come across don’t have a way of preparing you for the prospect of working with existing code.
A couple of times early on, I’ve been tasked with doing something at work, and started working on a solution with the mindset of building something from the ground-up, only to realize that something had already been written to handle what I was doing.
Likewise, working with an existing code base, I often came across function calls and had no idea what they did. I learned very quickly that my salvation was going to be being able to dig through the code and documentation and grasp what it was that the code was doing. Not as hard when it’s all your code, but a necessary skill when you start working as part of a team.
2. Working with someone else’s code (the business end)
I work for a small company. Any of the code I write, or that anyone else writes, doesn’t belong to us. It belongs to my boss. The project we’re working on isn’t mine; it belongs to our client, and we’re simply writing it for them. If they want something changed and I don’t think it should be changed, it changes. If I think something should be changed and they don’t want it, it doesn’t change. Of course, everyone is open to suggestions, but at the end of the day, I don’t own this application, they do.
None of this is a negative. It’s just a reality of working for someone else and for me, it’s been one of the adjustments to coding in the real world – with freeCodeCamp’s assignments and my personal projects, I’m the ruler of the universe, but at work, I’m the ruler of the universe’s front-end developer.
NOTE(EDIT): I will admit to having forgotten that FCC does in fact give you the chance to work on projects with nonprofit organizations later in the course, and I apologize for that oversight. My comments do still highlight a big difference between many coding courses and working in the real world.
3. Dealing with vagueness (or, Putting That Guy There On The Other Thing)
FCC’s user stories make it pretty clear what you need to do to finish your assignment. Working with clients on a real-world project can be a little hairier than that, not to mention bridging communication gaps with coworkers.
I’m guilty of it myself. You know exactly what you’re talking about, but the person you’re talking to isn’t living in your head and may not get it as quickly as you do. That works the other way around, as well. One of the challenges for me here, and I imagine this happens anywhere to a certain extent, is sussing out what needs to be done from imperfect communication.
I may add some more thoughts to this later on down the track, but those are the three that have popped out to me since I began my new career. My job really is awesome; when I look at where I was a year or two ago compared to where I am now, it’s thrilling, and it’s due in such a large part to FCC and the portfolio I’ve begun to develop as a result of my work here. It’s not wall-to-wall excitement every single day, but overall it’s so fulfilling to be doing what I have wanted to do for so long.