At the start of this year, I became a mentor for Underdog Devs. Without saying an intimate amount about my past, it is a group that resonates greatly with my life and I felt called to contribute my knowledge to help others in the community who were overcoming immense hardships in life. Many of our members are just beginning their programming journey, and they face the challenge of not having much direct programming experience.
You should always highlight the skills you feel comfortable with and any projects you have been involved on; I am not trying to downplay the importance of those sections of the resume. One thing I have seen many people trying to break out into the industry struggle with is if they should post past jobs on their resume. As someone who has hired several people in the past, my opinion is that experiences outside of the programming world are fine if you can definitively prove that those skills are applicable to development.
I'd like to give some examples from my own life. I dropped out of a Computer Science program to become an Emergency Medical Technician, and eventually made my way back to the software world. Some of these show things you can put on your resume directly, while others are things you can use in an interview to solidify your skills.
My first job ever was working as a cashier for Banana Republic. I loved the discounts, but there are only so many times you can fold every shirt in the store before you start going insane. Nevertheless, I learned some important lessons.
I used to spend several hours a week going through various fashion blogs and saving pictures of styles that resonated with me. At sixteen years old, I was already awkward enough and trying to suggest fashionable items to people twice my age felt incredibly intimidating. I had very opinionated views of style, and sometimes those views didn't vibe with the customer.
I learned to separate style, which I consider as guiding rules in the world of clothes, from fashion, which I consider as an individual's personal expression of themselves. If I didn't see eye-to-eye with someone on their clothing choices, I could at least try to guide them with general principles and recommend some awesome basic staples we had.
How in the world does this relate to programming? If you become deeply interesting in software development, I hope you develop some very strong opinions on craftsmanship. Not everyone will see eye-to-eye with you, and some of those people will unfortunately be the paying customer. Let passion drive your career, but understand when your opinions and experience may not apply to someone else and see if you can apply some less-intense guiding principles to the situation.
If you caught that this this sub-heading is the name of a biography of the Clash, I want to high-five you and hope you friend me so we can nerd out about punk rock!
My second job would eventually land me as shift manager for an amazing burrito chain in the South that I feel I should not directly name to protect the innocent. I was insanely naïve going into this job, and even if it isn't something I would put on my resume, it taught me incredible lessons on my journey as a human being.
My duo on most shifts loved to party, and I will never speak ill of someone who shares the same passion. But he slipped up sometimes, arriving late for work and generally intoxicated. Please never do that at work. The only reason he didn't get fired was that he was willing to come in early every day to get the kitchen going, and absolutely no one else volunteered to deep-clean the kitchen.
As I write this, I feel like it is kind of a cynical example. Don't give employers reasons to can you, but if you are willing to do the work no-one else volunteers for, you become an indispensable asset. Try to volunteer for everything you feel comfortable with. Unlike the food service, we developers have a wonderful trick for repetitive tasks: automate it!
If a job ever makes you morally uncomfortable, I encourage you to leave it without a second thought. My general manager verbally harassed me after taking a shift that wasn't on my schedule because the above coworker was too intoxicated to deal with coworkers. If that happened today, I would laugh in his face and walk off the job. As a developer, you provide a valuable service and I hope that you know that you are a wonderful human being worthy of respect. If anyone ever makes you feel otherwise, you need to get away from that immediately. I promise you that there are other employers that respect your worth.
If you have read this article, I feel you might be most curious about my time as an EMT. It was the most exciting, terrifying, and traumatizing thing I have ever done. If I did it today as opposed to six years ago, I probably would choose it over software. But at the time I wasn't cut out for the job and I am grateful I am able to see some lessons from it.
What I did, or didn't do, could literally mean the difference for life and death for my patients. In most of software, we don't have this pressure, although there are a few specific domains where it is still a prescient matter. There were times that I had to admit to my paramedic that I did not feel comfortable performing a skill. It felt shameful at first, but it shouldn't. Knowing your limits is far more valuable than arrogance or ignorance, and I hope there are still a few people alive today as evidence of that.
I love the old school paramedics who taught me my trade. I was in absolute shock the first time I saw a cardiac arrest, and the only thing that brought me to action was my paramedic shoving me forward to take command and start delivering CPR. There's times where even if you know your limits, you will be forced into uncomfortable situations and you can choose whether to flounder or grow. Great leaders are incredible motivators. After 40 minutes of CPR, I was exhausted beyond belief. But that paramedic inspired me to reach deeper into myself than I thought was possible, and that patient ended up living.
I learned as an electrical engineer that the two best problem solving strategies were to start from a known good and divide the problem in half, and I have yet to meet a situation where those two guides didn't lead to a definitive diagnosis. It got my through calls where neither my medic nor I had any idea what was going on when we walked in, and it has served me well in the software world since.