If someone offers you an amazing opportunity and you’re not sure you can do it, say yes – then learn how to do it later. – Richard Branson
Recently, I was lucky to be trusted with a great amount of the back end work needed for a brand new site. As a junior developer, I’m used to being tasked with fixing what someone else built, developing small to medium features, or enhancing existing ones, so I was very excited at the prospect of actually building something new. Oh, but did I mention this needed to be done in record time? I’m not sure the specifics of why, but we had a very tight deadline.
Having such a short amount of time to get all the work done was tough. As the customer’s original requirements kept changing, more information was given in small increments, and even new requirements were added to the list, it became pretty hard to implement and make sure that nothing was left to chance. I don’t know if my previous experience in QA helped any, but I do know that as I wrote my code, I kept thinking and testing all the possible ways it could break. At times it felt that was all I could do. I didn’t have much time to write a complete test suite, and that made me feel very uncomfortable, but, sadly, days only have 24 hours and even excited coders need to sleep.
However, what I did enjoy thoroughly from this experience was the act of creating. Even on those days when I was exhausted after putting 12+ hours of coding and testing and coding some more, I found myself feeling exhilarated, proud of the work I was doing.
When the site was finally released on schedule and the customer expressed their happiness, I was beaming with pleasure. There’s no way to describe the feeling of satisfaction that comes from knowing that what you helped build is out there now, working exactly the way it was expected. That you were able to make it work, like iconic Tim Gunn would say. I may be on a stretch here, but perhaps it is the same way an artist feels when they see their piece hanging on a gallery. It’s awesome!
Now, I know for many devs out there this may not seem like a big deal, but it is when you’re a junior developer and you struggle with impostor syndrome from time to time. It is when you’re trying to claw your way out of that junior developer category, and you’re not exactly sure how to bridge the gap. There doesn’t seem to be a clear path between being junior and intermediate, or even a clear definition of who is a junior developer. It seems to me the category often includes recent grads, those that just taught themselves to code, those that just came out of coders bootcamp, and even those that have been developing code professionally for a few years. How many years? Are skills vs. time even considered? If so, what sort of skills make you intermediate? Not sure…
I hope to get more assignments like this one in the future. I’m beginning to think that they are the best cure for that pesky impostor syndrome. Even when nothing else has changed about who you are in the eyes of your peers, that feeling of “I can” simply stays with you for a long time. More building, please!