After I graduated from my 4 month coding bootcamp, I knew the hard work was only just beginning.
As I wrote about in my previous blog post, just under two years ago I made a decision to pursue the goal of becoming a web developer. I went to coding boot camp DigitalCrafts for 16 weeks, I was overwhelmed with new information on a daily basis, but I made it to end and graduated.
Not only did I graduate, but just the day before, I earned myself a contract-to-hire position as a Junior Java Developer at The Home Depot. The initial evaluation period was about three months, and, if I did well enough, and proved myself, I might get hired as a full-time Software Engineer.
Here’s some tips for how I approached this new challenge.
1. Aim High
Just as my goal had once been making it through coding boot camp, my new goal became getting a job offer — and that’s my first piece of advice:
Keep setting new goals to help propel you forward — keep reaching higher.
This view was my new goal (Software Engineer), and after that, perhaps that mountain in the distance, representing my next goal: Senior Software Engineer.
On my first day at The Home Depot, and for many days after that, I am not ashamed to admit, I had next to no idea what was happening or what I was doing. Of course, I did my best to follow along with my developer pair of the day (The Home Depot subscribes to the pair programming model), but honestly, I don’t feel like I contributed much in my early days.
Once again, I was doing my best just to keep from drowning in all the new information being thrown at me: The Home Depot’s overall culture (welcoming and inclusive) and way of operating, my team’s way of developing software (TDD, agile and MVP-style with a focus on quality), and the tech stack my team used (which included all kinds of things I hadn’t encountered during boot camp, naturally: like Java, Jenkins and Pivotal Cloud Foundry, just to name a few).
2. Work, Work, Work, Work, Work
It was exciting and exhausting, and I was certain one day someone would catch on that I didn’t have it all figured out and I didn’t have a CS degree and they’d ask me to leave. Impostor syndrome is real, believe me — I still experience it pretty regularly.
But here’s my next piece of advice, which is a direct quote from my oldest brother, George:
“Work like hell for the first 6 months, listen carefully and learn from everyone you can — from the lowest of the low all the way up. Also, avoid the negative people, don’t engage in gossip and don’t consider any job beneath you if it takes the company forward.”
And he was right, even though I was continuously inundated with new material, new ways of doing things and learning a totally new programming language (Java), I needed to do all I could to get up to speed quickly and prove I could add value and was worthy of being hired as an associate.
I was never at the office quite this late, but there have been plenty of nights when I was one of the last people on the floor. I kind of like the peace and quiet actually - it’s easier to concentrate.
Here’s some things that helped me do that:
3. Ask Questions & Write Down the Answers
I took notes — lots and lots of notes. And I asked questions whenever I could — even if it sounded stupid in my head, I swallowed my pride and asked anyway.
This is a segue, but one of the most pleasant surprises I encountered as I joined the tech community is that, by and large, people are really willing to help.
StackOverflow should have been a good indicator of this, but if you have a question and you’re on a Slack channel or with a bunch of other developers, they are almost always willing to share a similar experience they had and help you move forward or figure it out with you.
It’s really encouraging when you're struggling to know other people are in it with you and have your back.
Anyway, back to my point, I started with a notebook and a pen, then migrated it over to a note on my MacBook. That’s all it is — just a giant list of random notes, that I quickly learned would be invaluable to me.
Most of the notes are things that are simple enough to do in practice, it’s just remembering how to do them because I don’t need to do them very frequently (since then I've also been writing blog posts like these, and I can reference them too when I forget how to do things I've done before but it's been a while 😛).
For example,
- setting up IntelliJ (my team’s IDE of choice) to run our SpringBoot Java micro services with environmental variables or Lombok annotations, or
- knowing what database tables to query when troubleshooting production issues, or
- having the commands handy for how to increase the logging levels in Pivotal Cloud Foundry applications for greater visibility into why network calls are failing.
No kidding, I (and most of my colleagues) have notebooks and digital note pads where we keep track of stuff that will come in handy in the future. Try it, you’ll be surprised how much you might reference it.
None of these things are hard to do — but I do them infrequently enough, that it’s really helpful to be able to pull up my note sheet, and just search through it to get what I (or my teammates) need quickly.
4. Use the Resources Provided
My manager was kind enough to get me access to Pluralsight, a fantastic online learning platform, and put together a library of courses covering my team’s tech stack to help me know what to focus on as I ramped up.
He also gave me a piece of advice I’m still following to this day:
"Take an hour after work every day just to improve your skills: watch some videos, work on a side project, read a book or some blog posts. The point is to take time outside of our day to day to keep improving, and after a while, that ~5 hours of extra time a week will really add up, and help differentiate you from other devs who just work the 9–5."
I’ll admit, there have been plenty of days where I’m not motivated enough to do this by the time I get home, but I try to hit that 5 hour mark each week.
Sometimes it’s sitting down for a few hours on the weekend, sometimes it’s just staying late after work an hour or two and letting the traffic die down at the same time, sometimes it’s sneaking in a little bit of reading or coding during lunch or waiting for builds to finish at work, but I can say I certainly feel like my problem solving skills and coding ability have improved from this kind of continued after-hours learning.
And as I said above, I got to pair with a different dev on my team practically everyday, all of whom are knowledgeable, talented, capable people, so from them I was able to learn a whole lot.
I was introduced to lots of new ways of doing things: new ways of approaching problems, new ways of debugging solutions, new ways of managing application architecture and feature writing and testing, so not only could I do something one way, I knew several ways to do it by getting exposure to it from my different pairs.
I wasn’t afraid to ask questions either, I wanted to understand how we were building our applications and why. Besides combing through the code myself, which was sometimes such a mess of spaghetti that I’d end up very turned around and unsure of where to go next, I could ask my pair what this was doing or that was referencing or why the file structure was set up this way and get an answer I could understand and process.
The Slack channels for the entire Home Depot IT department are active and full of helpful, smart people I could also turn to when I needed assistance.
The resources I have access to helped me put the pieces of many puzzles together.
5. Prepare to be Uncomfortable — If You’re Not Uncomfortable, You’re Not Growing
And here’s my final tip, and I think, what helped push me over the edge from "maybe we should hire her" to "let’s hire her":
Get used to being uncomfortable, get used to putting in extra time and effort, and show that you want to be there and you’re willing to persevere, even when it gets tough.
After about two months of working at The Home Depot, my manager sat me and another new developer who was hired a week before me down and gave us a personal project.
The goal of the project was to show we had learned enough about a new language (Java) to build a simple application using the same tech stacks our team used, but on our own. This meant an app with AngularJS and Node.js for the frontend, Java, JDBC, Springboot and Gradle for the backend, a MySQL database, and integration tests.
Ok, I can do this. I wasn’t sure how and I didn’t feel nearly as confident as I might sound, but I was ready to work. He gave us the specs and set us loose. Looking back, I can say without shame, it took me six weeks of after hours and weekend work, Pluralsight video tutorial references and walkthroughs, documentation references, Google and StackOverflow searches and little nudges of encouragement and question answering from my teammates to get there. When I look back at the code now, I cringe — it looks so hacky, but it worked.
Yes, sometimes I wanted to toss my laptop out the window, but I didn’t. I stuck it out.
When both of us showed our manager what we accomplished he said: "Good job, it took you both way too long to get to this point. Now rebuild the backend service using Maven, XML and JPA/Hibernate." Three weeks (and again many after work hours later), we both had our second version to show him.
And here’s the kicker — the thing that I think showed him I could go above and beyond what he’d asked and helped prove I should have a permanent spot on his team.
To give a bit of background, first: our team uses Pivotal Cloud Foundry to host our apps. It’s a cloud platform like Google Cloud Platform or AWS or Microsoft’s Azure.
I was very unfamiliar with PCF and how it worked in most every way, but I went ahead and signed up for a free personal account while working on my proejct, PCF gave me some amount of free credit ($70, maybe?), and I pushed my applications (with quite a bit of difficulty since I didn’t really understand what a Java JAR or WAR file was) up to PCF and hosted it in their cloud with a database service attached.
When I finally showed my manager I’d built the app he’d asked me to, I could proudly do so with a link to the live site, not just my localhost site on my laptop. That, in my mind, is one of the reasons I think I was made an offer to join The Home Depot as a Software Engineer, just about a month later.
That project was by no means easy, but I learned so much from it (including that I learn best by doing, not by watching somebody else do it, but by physically opening an IDE and typing in the code — and fixing it when I make a typo and the console errors out), and I stuck it out, even though there were times I banged my head against the wall and wanted to just quit. I showed my grit and my desire to be there and succeed.
In the end, about 5 months after I began as a contract-to-hire with The Home Depot, I was rewarded with a full-time offer to become a Software Engineer, and I couldn’t have been more thrilled.
This is close to the amount of joy and accomplishment I was feeling upon receiving that full-time offer.
In Conclusion, Just Keep at It
If you’re in your first developer job, or you’re still hunting for it, all I can say is: keep at it.
My advice in TL:DR form:
- Aim for jobs asking for more experience than you have,
- work your butt off — you’ll be amazed at the changes you see in yourself,
- don’t feel dumb for asking questions, but write down the answers so you won’t have to ask a second time,
- use any and all resources at your disposal (including your coworkers),
- prepare to continue being uncomfortable — it means you’re doing it right and you’re growing.
It's cliché, but... if I could go from zero coding experience to a full time job offer and a title as a Software Engineer less than a year later, there’s no reason anyone else can’t too.
You got this.
Check back in a few weeks — I’ll be writing more about JavaScript, React, IoT, or something else related to web development. If you’d like to make sure you never miss an article I write, sign up for my newsletter here: https://paigeniedringhaus.substack.com
Top comments (0)