There are lessons you learn in developing that are outside code.
Sure, without this project, I would be a far inferior developer than I am now (and I do consider myself one, at this point). My technical skills in digesting programmatic needs and turning them consistently into solutions without resorting to how-to guides or API documentation has undoubtedly improved. But I learned far more about how to approach a problem from this project than I did about my ability to remember the React lifecycle or state management.
1.) If there are instructions, read them before you start doing anything.
I’ll try not to make this a boring listical, but I’m likely not telling you anything you haven’t heard before today.
My friend is a senior-level engineer. He doesn’t do front-end work, but understands it. He and I chat often, and I like to bounce questions off of him, mostly to Rubber Duck myself to someone that understands the concepts.
Whenever I asked about how to do something, his usual first response was a link. Not to a Stack Overflow article or a YouTube video, but usually to Mozilla or Ruby. It’s a not-so-subtle way of saying: “I don’t know, but here’s where I’m going to check, so you might as well figure it out for yourself.”
At first, I didn’t necessarily appreciate the response. It sounded a bit like when someone asks you a question, and you say “I don’t know, Google it.” But he could have said that. He didn’t. He knew it was more important for me to be looking for information in the right place. So, eventually I learned to ask him questions about what I encountered in the docs, proving I had already taken the first step.
API docs can be some of the most dry reading possible. I’m thankful for all of them, but I wanted to take this time to thank React and Redux for two of the better documentation experiences out there. The tone within treats you as an equal, not relying on terseness or dictionary-esque rigidity, but talking to you colloquially where possible. Not that the others are bad, by any sense.
2.) Know your limits.
I learned this lesson in a few different ways.
The first was one of my previously-mentioned chat sessions with my friend. It was after midnight and I was cranky. He sent me a link to how Sessions worked, and I had had it.
So I did what he said. I went to bed.
This was the first limit I reached — a biological one. Again, it sounds like easy thing to realize, but humans need breaks. Not just at 1am, either. If it is not urgent, and it’s stressing you out, take a break from it. Whatever “it” is.
The next day I booked an appointment and discussed my problem to the technical lead. I explained my issues cogently, and she agreed to take a look at my code. Turns out, I was missing a random header in my Fetch call that no document, Stack Overflow, or Gchat with friends could sniff out.
That was my second limit — everyone has a knowledge barrier. What you do when you reach that is important. Asking for help is ok, and not every answer is immediately apparent.
3.) Don’t force it.
With her help, I finally finished my login process. I was so excited, I immediate went to merge my branch with the master.
My screen immediately looked like this:
I don’t know where I went wrong, but something was ahead of something else, and something else was behind another thing. It was a mess.
“I know!” I thought. “I’ll just delete my current master branch, rename my login branch as master, and then push that. It’s what I want anyhow!
To anyone reading this that nodded their head agreeingly to the above sentence: NEVER, EVER DO THIS.
I did what I thought would work, then took a look at it. The application was running, everything looked in order, I may just pull this off. I pushed to Git. I deleted the local branches. I merged everything. I did one last pull, for good measure and I refreshed my localhost browser.
Everything was broken. All of the sudden, Git and IDE were supremely confused and out of sync. My changes were jumbled and my application would not run at all. I nearly cried.
Then I remembered lesson #2. So I went to bed. The next day, I remembered lesson #1. I found Oh Shit Git. I got my branches back in order. It took a full day. I got the work done. And then I kept going. But my impatience almost cost me a month’s worth of work. Just do things the right way, even if it’s not the way you want to do it, and you usually won’t have to redo them.
4.) Believe in yourself
When you get stuck, it’s so easy to become overwhelmed. There are a lot of people writing Javascript and Rails, and a lot of them do it really well. Sometimes, they don’t agree.
Sometimes, they are going to talk at a level that’s above your current knowledge limit.
But the operative word there is current. Everyone started at some point. You’re somewhere past that point. Be proud of that. You can do better, because you already have.
5.) Have Fun.
Because if you’re not having fun doing something, is it really worth your time to be doing it?
Ok, that’s cheesy, but’s actually important tool for helping yourself learn something. Put it in a context you love. My application is about tracking which Phish shows I’ve been to.
When I first started to rediscover my love for development, I made fan pages for Phish using hard-coded HTML:
See the Pen TREY by Sam Marshall (@srolandmarshall) on CodePen.
I’m here learning what I learned today because I wasn’t having fun. I wanted to do more in life, both in leisure and work. I wanted more freedom and I wanted to create. Web Development has allowed for all of that to be a reality. I just need to take what I’ve learned and apply it to the job hunt