My first 60 days…
If you’ve read my other posts, you’ll know that I didn’t start out as a software developer. In a previous career I was a Geologic consultant in oil and gas. As many know, O&G is an industry that more or less operates in cycles of ups and downs. The ups are great but the downs can ruin people and their careers. As someone that prefers stability in their career, this wasn’t the industry for me.
So begins my transition…
I spent months thinking about what I’d like to do when I leave oil and gas and the thing that always came to mind was tech, specifically software development. It’s an industry that is stable and has the kind of open minded culture that I couldn’t find in O&G. I also wanted to do work that was interesting to me and provided me with a creative outlet. I had a lot of learning to do though.
Upon deciding to leave my career behind I chose to enroll at Turing School of Software and Design. I had heard a lot of great things about Turing and a few not so great things but the pros outweighed the cons. This part of my career change, however, isn’t as crucial to this post as the next section is. Maybe I’ll write a post about my time at Turing (scratches chin).
On to my first job in tech!
From Code School to OJT (On the job training)
I was very fortunate coming out of code school in that I pretty much had a job lined up for the week following graduation. I won’t get in to where I got on at (you can do the research for yourself) because where isn’t as important as what, and by what I mean what I’ve learned since starting. The position I took is at a company that is a small (or large depending on who you ask) part of a much larger company. We develop applications whose purpose is to fill gaps in markets that haven’t been addressed. As a result we are building multiple applications at a time, all doing very different things and utilizing varying tech stacks. This has resulted in my learning much more at a hire rate than I did while in school. I’ve been working on full stack applications utilizing technologies that I didn’t even know existed. I have found though that there is a different type of learning going on.
When you’re in code school, you learn a lot about a few technologies, but these technologies are the latest and greatest and are generally enough to get you started in web/application development. It isn’t until you get in to the real world though that you have the time to explore other technologies. Since I’ve been working, I’ve been able to look in to new libraries and tools such as Swagger, MongoDB, and react-md. The thing about this new learning environment though, is that I’m not taking a deep dive in to anything. What I’m finding is that since leaving school, my depth of understanding of new technologies is much shallower but I’m covering a broader range of material. I don’t think this is a bad thing necessarily, but you can see how it might be possible for someone to get lost in all of the information and ONLY develop a shallow understanding of everything. Its been helpful for me to pick some technologies that I’m very interested in and take a deeper dive in to those on my own time.
All of this new leaning is great and all but if my code never sees the light of day, its all for nothing which leads me to my next point…..WORKFLOW!
Development isn’t just “writing code”
What I quickly realized once I started working was I have no real workflow around my development process. For a few weeks, I had a difficult time showing people that I knew how to code because I was spending more time just trying to figure out Pivotal Tracker, the estimation process, git flow, and design practices. When I looked back at my time at school it kind of made sense why and as I talk to developers from other programs, they all seem to have the same issue. Whether you’re in a short or long program, the main weakness is workflow. Most all bootcamp programs do a good job at creating coders but development workflow always seems to be an afterthought. Design isn’t really taken seriously, project management and story writing isn’t covered in any useful way, and most instructors have never had a “real” job in development so how could they know much about git flow? These skills can all be learned, of course, but it does place you on a significant learning curve as a new developer.
How I Learned all the Things
Pairing and Feedback
Pairing with my coworkers as well as getting feedback, whether they were more senior or at the same level as me helped me fill in many of the gaps in my skillset. There is a wide range of experience in my office and there will be in yours too. You could easily hunker down and try to teach yourself everything you need to know but it will take much longer and be far more difficult to do. For every issue I had there was at least two people around me that knew the answer. The pairing/feedback cycle has been the fastest way for me to level up my skills as a developer for so many reasons. Not only are others able to fill in the gaps on skills for you but you also see how they structure their code and their tests, what tools they use, and what they pay attention to that you don’t. In pairing with all of these experienced people, I’ve found a lot of coding styles and techniques and adopted them to use in my tool kit.
Bootcamp schools are all about teaching you how to write code, what they don’t do much of is teach you how to read it. The hardest part about stepping into a production environment from school for me was reading code that somebody else wrote in a context I wasn’t familiar with.
As before, my solution to this problem was pairing with someone and diving into some part of the library I was working in. Pick a piece of the library you are curious about and start digging into how it works. Even figuring out how a single method works can be challenging in larger libraries, I know it was for me!
I was pretty fortunate in my job hunt but others haven’t been, and this industry is getting harder and harder every day for junior developers to find a job in. My advice for junior devs and especially bootcamp grads would be to learn some of the skills discussed above and showcase them in your interviews. They’ll give you a competitive edge in this job market and will be valuable once you are on a team.