Takeaways from working my way into Software Engineering A Little History When I was around nine or ten years old, I discovered Microsoft FrontPage on my computer and my mind was blown. Who knew literally anyone could build their own website? (Answer: Everyone. I could have Google’d that at any point, but you don’t know what you don’t know.) I immediately got to work tinkering and learning. FrontPage was quickly replaced by Notepad, which was replaced by Notepad++. I bought a book on CSS and one on AJAX and read them cover to cover on a road trip. Unfortunately, I never got anything off the ground, but I did take my natural curiosity and attention to detail and applied them to something that would eventually become my vocation. As a kid, I was only into web development for a couple years, but I accomplished one huge thing during that time. I taught myself something. To be honest, when I came back to it all, I had to re-learn most of what I had mastered as a kid, but the confidence that it was possible lingered. Over the last two years or so, I’ve jumped back into it all and put in some significant work learning to be a developer. I used a variety of platforms, such as , , and others, but most importantly, I wrote thousands and thousands of lines of code. Rather than tell my entire story, I recommend you read a more in-depth article about where to start if you’re looking for direction, like . Free Code Camp Team Treehouse this one As soon as I decided to embark on this , I started looking for jobs in , and I quickly landed a job working as a Support Engineer at . HubSpot Support Engineer led to Support Lead at a small startup where I was also given the opportunity to write front-end code, and I was offered my first true developer job in May 2017 at a web development studio, but I wasn’t interested in working in the agency world. In November 2017, I was hired at a small company to work on marketing and communications projects. journey tech HubSpot I see this job as a significant step in my journey for a few reasons: I am uniquely qualified for this position. My familiarity with HubSpot and JavaScript development made me the best candidate. I wasn’t hired for my potential or because I’m a great culture fit. I was actually hired based of my experience. just I was hired to write code. While writing and troubleshooting code was a part of both of my previous jobs, they were, strictly speaking, not engineering jobs. I’m being paid as a developer. My job title, , was used to rate my position and determine my pay range. This matters to me more than the money. It’s a sign that the marketplace affirms my assertion that I’m a professional developer. Marketing Automation Developer Takeaways As a newcomer to the development world, I always want to be hyper-aware of the fact that I’ve made my way here through unconventional means. I had no formal education in my field, so I’ve learned almost everything I know from the discovery of others and their free distribution of their knowledge in a palatable form. I want to make sure that I’m both mitigating any disadvantages of that method and contributing to the education of the person behind me who is also on this path. To that end, I’ve compiled a few takeaways from my previous two years. Take them for what they are–my personal notes on my journey. Here we go: Periodically, I’ll run into a friend at a coffee shop who, upon seeing my code editor, will say something like, “Wow, that looks so intense.” or “I could never do that.” It’s always a bit awkward because I don’t want to downplay what I do as a developer by discounting the skill and experience it takes to understand and write code. However, I always try to encourage that well-meaning friend that, as with most things in life, code becomes less complicated with familiarity. Be careful, though. Familiarity breeds contempt. I’m not super smart, but I work really hard. Have you ever explained your technical job to your grandma? After you explain, she’ll almost certainly ask, “Is that with computers?” To some degree, I feel as if this is always my struggle. I’m a developer, but writing code isn’t necessarily my vocation. There’s much more to it than that. I gather and understand complex business requirements for a given project, solve creative and technically-demanding problems, do my best to bridge design and functionality, and I do it all within the limitations of a budget and an often-unrealistic timeframe. It’s almost impossible to accurately describe what I do. It’s so easy to fall into the trap of learning one library, framework, or even language, and calling myself by that name. I primarily do front-end work, but in the first few weeks of my job I’ve written scripts in Python (a language I previously had little experience with), done quite a bit of front-end work in HubSpot with HTML & CSS, and built a full-stack Express/Vue application from the ground up to be used by 100,000+ customers. This is my job. I’m a developer. As a developer, I’m expected to build things with technologies I’ve never used before–like Vue. I’m a developer–not a JavaScript developer. Here’s the deal–you will either be constantly learning or you’ll be a terrible developer. Technology changes at a ridiculous and awesome pace. Want to build a progressive web app for a drone that’s specifically geared toward following and filming the actions of self-driving cars in non-tropical climates? There’s a JavaScript framework for that. Maybe. Either way, there will probably be one soon. For all the encouragement you’ll hear (mine included) to focus on the fundamentals and stick to one thing and become great at it, it’s just as important to stay somewhat up-to-date with current industry trends. Good developers are well-informed and broadly-capable. Learning is the name of the game. Writing documentation is really difficult, which is probably one of the reasons why reading documentation effectively is hard to learn. This is one area where I still experience some daily struggle. Picking up a new library, framework, or language from documentation only is a challenge for me. As with almost anything, though, the more I use documentation on a daily basis the easier it is. If you need some examples of great documentation, take a look at a couple docs I’ve used extensively lately: , , and . Documentation is hard (to read and to write). Stripe Vue Python I’ve read a lot of posts about folks launching their tech careers in a matter of weeks or months. That’s pretty sweet. It took me two years, a ton of work, and even more luck. Thankfully, I was given opportunities along the way that let me prove myself, fall flat on my face, learn from my missteps, and keep moving forward. If you choose to move in the direction of vocational software development, be prepared for discouragement and disenchantment along the way. Make a decision that you’re in it for the long haul, and join a good community of folks going the same direction. (I recommend the community.) Becoming a developer is not easy or fast. CodeNewbie Along the way, I’ve been helped and encouraged by so many peers and experts in the field. As a part of my learning process, one thing I’ve tried to do is help others who are on the same journey by providing encouragement, resources, and feedback. Not only is that rewarding and helpful for my process, but I also see it as an imperative. I’ve received so much from the development community. The least I can do is give a little back. Giving back is a key part of the process. When you’re looking for the best tool, you should read what folks who have used that tool extensively think about it. It’s helpful to know the pros and cons. However, using one terminal or one text editor over another doesn’t matter. You can find endless arguments for the use of one tool over another. What’s important, though, is that you find what works for you. Personally, that’s Sublime Text 3 and iTerm2 with the Oceanic Next syntax theme. Make your development experience as pleasant as you can. I’ve experimented with different fonts and colors to find what’s easiest on my eyes while making me the most productive I can be. But, don’t forget what’s most important–looking cool. The superficial stuff matters (a little). really Oceanic Next Syntax + Operator Mono Conclusion There’s no secret to becoming a developer or to getting a job in tech. (Actually, there might be and I just don’t know it.) In my experience, it’s all about the effort you’re willing to put in. No athlete wonders how they achieved greatness in their sport. No soldier wonders how they became proficient in their tasks and drills. It was by design; it was intentional; and it was hard work. Get started today. Need some direction? I’m happy to help. DM me on . Twitter
