Immediately after graduating from Flatiron school, I felt somewhat confident. I had gained some skills, and the software development picture had come together in my mind. I applied for jobs, and talked to some interested parties, but a few weeks in I was still without a job. I started to feel my skills slipping. I had purchased some good books and had worked my way through parts of them, but I didn’t feel like I was learning or solidifying my skills with the speed I was during the Flatiron program. I began to feel dejected, uninspired, and pessimistic. What began as an exciting start to a potentially fruitful career, started to feel dark and hopeless. I was lost and I didn’t know what to do next.
I spoke with an old coworker of mine, an engineering manager, and I got some of the most helpful advice I’ve ever been given. Replicate the job. Decide on what you want to add or create and make Github issues for yourself within those repositories. I was previously a project manager, so I had experience writing user stories. I thought about my most recent project. What did I want to add to it or change about it? I wrote my issues out and decided on a plan of action and got to work.
Through the next few weeks I realized how great of an idea this was. I knew I would be asked to actually build things at my job as an engineer. I just need to be my own boss for a while and give myself the tasks to implement. Go through the problem solving process. I needed to actively learn instead of passively reading books. I needed to be hit with a problem that I needed to solve by using documentation. This is a better process for at least three reasons.
- A chance to practice using documentation and other resources like stack overflow.
In a real job, they don’t have time for you to sit down and read a whole book. You need to figure out the answer fast, so you need to go get the exact information you need. You’ll also become more familiar with the docs and know where things are so you can get to them faster next time.
2. More focused mentorship.
I’m lucky enough to know some very talented developers who genuinely want to teach, and help me succeed. When I hit a really hard problem or issue, I can have a targeted discussion with them. Before doing that, I try to understand what’s happening and what my question is as deeply as possible. That way I can be considerate of their time, and through doing that I always end up understanding the problem better. I’ve gotten ready to talk with my friend about a problem and figured it out just by trying to work out how I’m going to explain it. It’s a great tool. The other thing that’s been helpful is understanding that there’s more than one way to do something. I’ll go to my engineer friend and asking which one they would do and why. Just because you can do something doesn’t mean you’re doing it the best way. Use your engineer friends as resources!
3. Memorization and muscle memory
I learned the hard way that you don’t want to use the autocomplete features of VS code all the time. Get used to writing parts of code from memory. Keep writing out the whole component in React, for example. I had a coding interview where I wasn’t able to use any autocomplete. I had to rely totally on my memory and I immediately got terrified. If I would have written it from memory each time I’d have written it hundreds of times and it would have been so deeply engrained in my memory that it would have been a confidence booster. I made what should have been a huge positive into a negative by being lazy.
This may end up being a series, because I’m still learning and still looking for my first software engineering job. I’m excited to continue to share what and how I’m learning as I continue my journey.
