Ask Me Anything!

I’ve been developer for nearly 4 months now, and it baffles me how hard it is to digest anything I’ve done into something I feel is post-worthy. It’s the same situation with presentations for Boulder Ruby Meetup, I just don’t know what to talk about. Don’t get me wrong, I have leveled up more in the last three months than I could have even dreamed of, but I’m just not sure how to filter that into something to talk about. I’m thinking I might do a ‘brain dump’ post, where I literally just list off all the things I can think of that I’ve come across, or gotten help with since I started, but I’m still working on that list.

One thing I have been doing in the past few months is giving advice. I’ve had people get in touch with me about various things, but mostly asking specific questions about my path from non-dev to student to paid dev. I got to where I am because I asked a ton of questions to just about anyone I could get in touch with, so I am always more than happy to do the same to anyone who contacts me. With that said, I want to be more proactive about helping others and put it out into the whole of the interwebs that I’m open to any questions from anyone about my experience up to this point. Im not claiming to be any kind of expert, but ask away and I’ll do my best to respond with helpful input.

Yes, I’m serious. To be honest, just about everyone I’ve ever encountered in this field would probably do the same, but few advertise it. And I know for a fact that a lot of people wouldn’t think to ‘cold-call’ someone they didn’t know with questions, so I’m opening the door. As a student I followed up on a strangers’ Twitter post where he offered a half hour of his time to anyone, and it helped steer me in a better direction when I was getting a bit off course with school.

This isn’t a one-way street, the interactions will help me determine what the community as a whole would like to hear more about, which will help guide me as to where I should focus future posts and presentations. And the flipside is, if I get questions I don’t have immediate answers to, that will force me to dig around and find those answers, helping with the ‘you don’t know what you don’t know’ scenario.

For the time being, let’s start off with emails. Ill try to get back to them within a few days, but who knows what might happen, so I’ll say with certainty within a week. For the sake of my spam box I’m not going to link my email, but a message sent to noelworden(@)gmail will get to me.

This is an experiment, lets see how it goes!

My First 8 Weeks as a Junior Engineer

Well, the highly anticipated My First Weeks as a Developer post is about a month overdue. This is the second time I’ve blocked out a chunk of time to write this post and I still don’t really know what I’m writing about. I’ve definitely had plenty of ‘ah ha’ moments in the last 8 weeks, and most of them a candidate for their own blog post. I feel a need to have life-changing advice or words of wisdom as a recent graduate of bootcamp who successfully found a pretty great job. The trouble for me is that my situation is just that, mine. During school I took some extracurricular actions that I thought would help me in the future, and most of them were well worth the effort, but those same actions may not work for someone else. Ive definitely used this caveat before, and I’m not entirely sure why I always feel the need to preface advice with it. But, with all that said, there are some nuggets of advice from the first eight weeks of me being a Jr Full Stack Engineer that I’d like to share.

First and foremost, it gets easier. This is definitely something that may not be the case for everyone, but for me it’s true. Just this week I’ve tackled two different challenges that I’ve been dreading since I first saw their respective tickets almost a month ago. You’d be surprised how much you know, event if you’re not that confident about it. For instance, the first dreaded challenge of the week dealt with polymorphic associations. I was dreading this ticket because I had only dealt with polymorphisms in one other instance, and it did not go very well. But that was school, and learning in school is so much different than learning on the job.

The first step I took was to look through our existing repos to find another project that used polymorphisms. I’m in a fortunate position where I work in a consultancy, so we have an extensive and diverse git repo that I can utilize. I have also honed my search skills within a repo, something that my internship helped a lot with (more on that later). So, I found a few repos using polymorphic associations and was able to see how the tables were set up, how other models were being associated, and how to produce the results in views. With this in my back pocket I turned to my mentor/team lead/boss (we are a small team) and together we drew everything out on the whiteboard.

After that was wrapped up I started building. I took the rest of the day and built out the table, associations, and the logic to produce the data in the views. The logic was a bit clunky, and I knew it would need to be refactored. But instead of asking how it should be done, I decided to keep pushing on and get it reviewed afterwards. I feel like this shows initiative. Its pretty easy to just ask questions and get the right answers. But chipping away until you have even the crustiest of solutions, then asking for reviews better shows your strengths and weaknesses and that you are accepting of critique. This will make will help you level up faster.

Before the end of the day I got a review of the logic code I had written, and in less than 20 minutes we refactored it down from 9 lines to 3 and with about 20 percent of the original database hits. And that was it, I had tackled polymorphic associations in one day, with almost no banging-head-into-keyboard moments. I solved the problem at hand, and when it comes up again I have working code, written by me, to use as a guide. My original experience with polymorphisms in school kicked my ass for 3-4 days and ultimately my mentor ended up walking me through the process.

That work day was one that I tallied into the win column, and I have already lost count of how many days like that I’ve already had with this job. There are a lot of events that set me on the path to have successful days like that, both in school and out. I think that the internship that I worked while going to school has payed off exponentially. I picked up so many real world developer skills there that school just didn’t have the time to even touch upon. I don’t have any major issues with my school, but at the end of the day it’s a bootcamp, and the point of almost every bootcamp is to give you just enough skills to get your foot in the door as a Junior Developer. The internship helped me refine my git skills, gain more experience working in a collaborative environment, and work with existing, dated, codebases. I can’t recommend an internship highly enough. Even if you feel you’re already maxed out, carve out a chunk of time and get some coding experience outside of your current school or bootcamp, it will pay off.

The type of work environment you end up in is also a huge factor in being a successful Junior. One of the first questions I asked when interviewing was if they had hired a bootcamp graduate before. In my case they had, three, in fact. So my followup question was what kind of mentorship program they had in place. They didn’t have a set mentorship system, but were adamant about their ‘ask anyone anything’ policy, which seemed pretty good to me. This may seem like a given with all companies, but I’m here to tell you that it’s not. There are plenty of companies that hire Juniors because they can get them cheap, then throw them in the deep end with no mentorship and expect them to perform. Some people fresh out of school can rise to the challenge, some can’t. I didn’t want to be in that kind of working environment, so I made sure to ask.

The first few weeks as a Junior were a bit nerve wracking, but positive nonetheless. Once I found my rhythm I started noticeably leveling up, little by little every week. Four weeks in I was made part of a new team, given a fresh domain, and tasked to build out the entire database and a bit of the front-end. Initially I was super nervous that my superiors thought I was a better developer than I actually was. But four weeks in, with three weeks left in the project, I’m knocking out tickets like its cool and feeling confident about being able to make the deadline.

The bottom line, at least as I see it a few months out, is that if you set yourself up right, code school is probably as consistently intense/chaotic/emotionally draining as it’s going to get.