Front End Web Development Career Kickstart
The Web Development Industry
History Part I - Where It Began
History Part II - Everyone Needs a Site
Part 2 of our history lesson: Everyone needs a site. Up to this point when asked, what do you do for a living, one could really not tell someone that they did web development and expect to have any understanding from the other party as to what that meant. Then, what felt like overnight, businesses became internet aware. More and more people were online and learning the ropes of the internet, seeing it's potential. Businesses started to buy into the need to have an online presence. Thus began the rise of the web development shop and the first real declaration of a career based around designing and developing websites. As web shops opened up and started to find their groove, turning out site after site, they started to work on frameworks and architectures that they could reuse across projects. Content management systems, or CMS for short, were built that allowed for visual customization with dynamic content added via web admin tools after the site was launched. Use of the web and websites was on a massive rise. Sites were starting to feel the effects of heavy visitor traffic loads. A lot was learned at this time about web development in general and things like web architecture patterns and client and server-side performance that shaped the way we approach web development today. During this period, a career as a full stack web developer became a thing. Companies started hiring specifically for that focus, not just software engineers. Front-end specialization wasn't quite a thing yet, mostly due to the fact that the design of the web and languages used at that time involved writing a mix of server and client code delivered by the server at each action request. Web APIs had yet to become commonplace. With the rise of web shops came the market for companies to build products and solutions to meet the needs of web shops. The tooling for doing web development started to mature. IDEs started to turn up that focused on writing code for the web, with most centering on a particular language. Other web browsers started to come to market. Google launched its Chrome browser, and Mozilla came to life from the ashes of Netscape Navigator and released Firefox. Other players came to the field as well, like Apple's Safari and the Opera browser. Web developers quickly discovered that markup, style sheets, and scripting wasn't a write-once, run-everywhere scenario. In fact, there were little in the way of web standards, and browser vendors were so caught up in market competition that web developers faced many challenges when it came to creating and maintaining a website codebase that worked the way they intended on multiple browsers. Web design and user-interface design started to ramp up at this time as well. People started to explore how to make the web beautiful and more useful. Graphic design started to take a front seat, and with that came the need to understand how to translate mockups created in graphic programs like Photoshop into markup and style sheets for the web browser to render. As web design matured and advanced, the task of converting it into markup for browsers required a stronger understanding of HTML and CSS and its capabilities and limitations, as well as discovering and unlocking new combinations and approaches to solving design challenges within the render rules of browsers. This really set the stage for the need for front-end web development specialization and what would become the possibility of a career in front-end web development. In the next clip, we will discuss the rise of the mobile platform and how it changed the approach to web development.
History Part III - Mobile Support
Part 3 of our history lesson: Mobile support. With the dawn of the age of smartphones, internet users began to carry their browsers in their pockets, and all those businesses that got their online presence going quickly discovered that their sites don't look so hot on a mobile device. Some failed to even function correctly. There was a knee-jerk reaction to the problem that saw web shops building mobile versions of sites to fill the need for a different experience on a smaller screen. All of the sudden web developers found themselves needing to learn about browser rendering and functionality on mobile devices and determine ways to port over existing sites and web apps into mobile versions. And for a while there was a trend of having a www site and an m. site where www.thesite.com was the desktop version, and when visitors hit the site from a mobile device, code would detect that the client requesting the content had a mobile-like user agent string and would redirect the request to the domain m.thesite.com. But as developers worked to build out these mobile-site versions, they began to identify ways to craft HTML and CSS that would scale and change based on changes in the viewport size. Responsive web design was born, and techniques were established, documented, and shared as to how to craft one code base for a website that would look great on a desktop browser and would adjust the content and layout flow to look great on a smaller device all based on CSS and things like media queries and feature detection. So part of this web development achievement came from devs engineering new solutions, and part came from the standardization in specs for HTML and CSS and browser adoption of these and of new features. At this time, native mobile apps were born, took off at a rapid pace, and never looked back. These native apps were not initially constructed on front-end languages, so at that time they didn't provide a potential career path for those working in the web development industry. What they did, however, is drive the dependency of being online and always connected through the roof. And as people started to consume these apps, they wanted more. They wanted apps for all their things, including those things that they were previously consuming via websites. Social media, sites and services like Facebook and Twitter, people wanted a mobile-app version of those, and they got them. And when they did, the awareness of those sites grew tremendously. Then those social media sites started penetrating the mainstream. TV shows, ads for companies, physical products, they all started to promote Twitter handles and Facebook account URLs. The web, and the understanding of how to use it, as well as the expectations based on existing sites and patterns, had become commonplace. The average consumer of the web didn't know what was involved in making it work, but they were fully aware of it working and it being an everyday thing. So when someone would ask a web developer, what do you do, and they responded, I create websites and web apps, the response the developer got was no longer a blank stare. Instead, it was met with excitement and intrigue and even a bit of awe. The recognition and concrete establishment of front- end web development as a serious career was finally a reality. In the next clip, we will go back to the future and talk about what front-end web development is today.
Where We Are Today?
In this first module, we took a trip back in time and explored the history of web development and the evolution of front-end web development specialization. We got a feel for how things used to be and the origin of current patterns, frameworks, and architectures. Learning about the history of the industry aids us in connecting with veterans in the industry and allows us to build a stronger understanding of how and why frameworks are designed the way they are and what problems and challenges have been solved with existing tooling and software geared toward the web development industry. We also learned of some career-path options available to us in the industry. From working the full stack to focusing on front-end web development, we can look to do freelance work or take on building a site or product, or we could find a job in an existing company or startup. Taking a position at a company is the most common and highly beneficial start to a career in front-end web development. Instead of getting thrown into the fire when taking on freelance work, a position provides us an on-boarding opportunity, a chance to work our way into the nuances and workflow of everyday development and to interact with and learn from other experienced developers that have made the same journey we are embarking on. But to go on that journey, we need to come prepared. In the next module, The Web Landscape for a Developer, we will take a look at what we need to understand about the website experience as a whole, beyond just front- end web development, to be ready to work professionally in the industry.
The Web Landscape for a Developer
Look, let's not get it twisted. Just because we can now focus on the client side and become career front-end developers, doesn't mean we can turn a blind eye to the server side. After all, we still probably need the server side to deliver our client-side code, and we definitely need to rely on it to get our data and content. But as client-side developers, we don't need to concern ourselves with how it does all that, do we? Well, no. We don't need to have a strong grasp on how it does what it does, but we do need to understand how the client uses the server side, and we should have some basic understanding of how a website is hosted and served up. Let's begin with serving it up. We know that an HTML file can be opened up in a web browser and it will render, and we have probably spun up some sort of web server on our local machine at one point in learning front-end web development. Maybe it was using NodeJS or Ruby, or maybe we use an IDE like WebStorm to launch a site. All of these are what we refer to when talking about serving up a site. They involve some sort of web-server logic that will listen on a specified port on the machine it is running on, and when requests come in on that port they will make some decisions about what website code they should run. That code may just be an HTML file that the web server will read and return to the requestor, or it may be a server-side script or code that it will know how to run, which in turn will do some work like constructing some final HTML output or data. That code will tell the web server to send back a response, usually with a specified HTML status code and some content. So these are the ways that a website and website content is served up. But what about hosting? What does that mean? Well, a web server needs to run from some machine or service, and it needs to be connected to a network that can be reached from the web. The web server is hosted on a machine, and the hosting exposes access to the web server. The standard port that web servers usually run on in a host environment is port 80 for HTTP requests and port 443 for HTTPS requests. These are known ports for web traffic on hosted machines. As a result, users don't need to include the port in the web address to access the site. So, as front-end web developers, areas of focus for further learning include familiarizing ourselves with the web servers out there and how they are hosted and run. Understanding these, even from a high-overview level, will empower us to make stronger development decisions, as well as be able to diagnose and debug issues on our own without needing to call IT. In the next clip, we will learn what we need to know about the transport part of the network, how that web address gets routed to the right hosting machine, and how the response gets delivered back.
HTTP and DNS
Languages of the Web
Front End Development
Version control is like backup for our code. It also tells a story of the journey we go through when crafting a web project. Sure, we can work on project files located on our machine without a version control solution, but we would find ourselves way out of touch with the current state of the web development industry. To take on front-end web development as a career, we must learn how to use version control to manage our projects. Companies use it, individuals use it; we need to learn to use it. But what exactly is version control? Version control is an application or service tasked with storing copies of digital content, whether it be code files, resources, etc. Sets of digital assets, like a website project, are stored in a container called a repository. To send files to a repository we do what is called a checkin where we check in a copy of the files. Each time we check in we have a chance to add notes or comments about the file changes we made. Before we start to work on some project changes, we do a getLatest from the project repository. This lets us get the most current code base for our repository, ensuring that we have received everyone else's latest updates to the code. When we are ready to work on a file or asset, we do a checkout which indicates we are modifying a digital resource. There are several version-control options out there, like Git, TFS, Subversion, and more. We need to learn up on at least one of them and get exposure to the workflow and concepts. Git is a good one because it is used by GitHub and Visual Studio Online, services that offer free repositories and are easy to get up and running with. There's a lot to version control and it can feel a bit daunting to take on, but it is commonplace in the industry to be using it, and we will be expected to be able to use it from the beginning of our front-end web development career. So areas of focus for further learning about version control include, learn the terminology and try out a version control system like Git.
Getting in the Door
We have covered the history of web development, figured out what we need to learn when it comes to the landscape of the web, and have gone into detail as to what is needed to master it when it comes to the domain of front-end web development and the tools of the trade. So there are two things left to do: Go over the keys to land some work, and figure out a plan for how we can grow our career once we do. This module, Getting in the Door, will cover how we will go about landing a position in the front-end web development industry. We will cover what we need to be thinking about and what prep work we need to do prior to going out and interviewing for a position.
Company Career Path - Prep
Company Career Path - Interview
In this fourth module, we covered what we can do to prepare for an interview for a front-end web development position. We covered working on some side projects ahead of time and getting involved with the community, like attending a user group or being active on Twitter around web development topics. We talked about the need to brush up on our knowledge of the landscape of the web and be prepared to talk about it with confidence and understanding. All of these will provide content for a potential employer to view and research before they invite us in for an interview. Employers are looking for candidates with involvement and a willingness to learn. They want to uncover discussion points that they can have when they meet with them. Then we covered the interview process and what to expect when applying for a position doing front-end web development at the start of our career. We learned that employees will be weighing in on how much it will cost them to on-board us, so we should take every opportunity that we can to show them that we are already familiar with several of their daily workflows and tools, like IDEs they use and working with version control. We also learned that it is important to show a passion for the industry and an overwhelming desire to learn and adapt, as change is the most common theme in web development. In the upcoming final module, Growing Your Career, we will wrap things up with a discussion on the things we can do to always keep learning an adapting and give ourselves a plan for success as we launch into this great new career.
Growing Your Career
So we found a way to start a career in front-end web development. We landed that job and we are on our way. What's next? Is it all just about piling on experience as we go, and attacking each project as it comes our way? Or should we be looking to do more? In this module, Growing Your Career, we will learn about all the different ways we can keep on top of our game. The front-end web development industry, as well as the web industry as a whole, evolves at extremely rapid pace. If we were going to have a career in this industry, we too must be able to evolve and change at that same pace. Unlike other industries that have established practices and structure and rules over time that stand as the foundation of those industries, web development is fluid and adaptive. The establishments within those other industries allows for more training material, books, and lectures, which are concrete and have been around for years, making learning and skill-building paths abundant and easily acquired. With web development always on the fringe, we must seek out information in order to learn and master our trade. That means self-educating and discovering and constructing our own learning paths on a regular basis from before we enter the industry, to every day that we are in it. Yes, there will be many sources at our disposal to learn finite things about specific components, like Pluralsight courses, and podcasts, and conferences, and blog posts, and there are some certificate programs for certain tech. But we are not going to find any big-picture story, or go to some extended education program that will teach us the law book on web development over the course for four years. The rules and landscape just change too rapidly. Even the educators and teaching material have to adapt on a month-to-month cadence. So while we are diving into our new career position and working on projects at hand, we need to be self-educating and seeking out content in our industry and the tech that powers it on a daily basis. We can't sit back and wait on baited breath for our employer to send us to some career advancement training program; that's not the way this industry works. We need to be the ones to grow and cultivate our career and skills. In this final module, we will go over all of the ways that we can do that. From written, audio, and video material to consume, to networking with other devs in the vast web community, keeping our fingers on the pulse of the industry, and always getting our hands and fingers on the new frameworks and tinkering with different approaches to code and markup. So let's roll into the next clip and get started discussing how we can keep our skills sharp through constant self-education.
One of the great aspects of the web development industry is the community around it and the constant engagement opportunities, not to mention the willingness of its members to share, educate, and mentor. A lot of this comes from the pure enjoyment at the opportunity to talk shop with others that speak the same language. While the use of the web and websites is becoming commonplace, the discussion around what it is built on and what powers it, remains something that drives people to zone out when we get into the details about it. So we crave the opportunity to engage in discussion with others that speak the same language. And by engaging in those discussions, we get the chance to hear other stories - other approaches to problems and implementations. Networking with others in our industry is an important component of our continued growth as front-end web developers. Three solid avenues for networking are user groups, hackathons, and code camps. User groups are free-to-attend local groups that meet once a month or so to discuss a particular topic. Like a single session at a conference, a topic is usually presented on by a guest speaker, or a member of the group, and discussion ensues or even takes place during the session. User groups are a great way to connect with other developers in our area. They provide the opportunity to talk shop and learn on a regular basis. They can also be a great source for contract work and making connections for employment. Hackathons are usually a one-day event in which developers get together, sometimes in predetermined teams and sometimes teams put together on the day of the event, and take on a coding challenge. There is a theme for the challenge and sometimes a required tech or library, and developers spend the day coming up with an application concept and attempt to get as far as possible on it. Hackathons are a way to network and write code at the same time. They provide an opportunity to experience pair programming, working through pressure, and delivering a project as a team. Code camps are like a free conference. Typically held over a weekend to make it more accessible to working developers, code camps are put on by other developers in the industry looking to give back. The speakers at code camps are looking to do the same. They volunteer their time to put on a session or sessions, usually around topics that they are passionate about, or that they have experience with from their daily job. Code camps are a great place to converse with other developers. The production level of a code camp is on a much smaller scale than a conference, so the speakers and organizers are more accessible. When we network with other developers, we get a chance to query content from another human being that can interpret concepts we are attempting to describe, something a search engine can't do. Plus we get the chance to share excitement and passion for our craft and get energized to do more of it. In the next clip we will discuss some ways we can stay on top of the ever-changing landscape of the front-end web development industry.
Finger on the Pulse