
Sign up to save your podcasts
Or


This week’s episode is a My JavaScript Story with Chris Coyier. He is from the ShopTalk Show and CodePen. Listen to learn more about Chris!
How did you get started programming?
How do you go from that to professional web developer?
Have to give up on it first. He almost got a degree in university management computer systems, which was more management focused than programming focused. He tried and gave up on Java. He then tried graphic design and ended up getting a degree in that. He got into digital prepress at print jobs where he designed documents. It was fun but it was not as fun as being a “real programmer” would be in his mind. He then got a job at an agency doing web developer work. During this time JavaScript was not on his radar.
How do you get from front-end work to building something like CodePen and starting a front-end podcast?
He has made his career his hobby. He loves doing this stuff. When he was building websites for the first time he started CSS tricks. It became really fun. He grew it over ten years. Because it’s his career and hobby he got better over time. All of his time was spent helping friends, writing, or at conferences. He then decided to build CodePen with some of his friends.
What are you working on these days?
Chris wants to be careful not to be working on too many things at once. His top priority is CodePen, which he says is hard to keep up with what developers want there. The second priority is CSS tricks. He likes to publish quality articles for people to read. This third priority is his podcast.
What’s the thing you’ve done that you’re the proudest of?
CodePen is what has been so continually rewarding. This last month he is all money accounted for. He is really proud of CodePen because they made a company from nothing. He and his coworkers have made the podcast over a decade of growing an audience and it feels entrepreneurial.
Charles’ most proud thing is the decision to go full time with his podcast for the last year and a half.
Picks
Chris:
Charles:
Links
This episode features a My JavaScript story with Helen V. Holmes. Helen has never before been a guest on the show. She is both a designer and front-end programmer who previously worked for Mozilla. In January, she started her own freelancing business. Listen to Charles Max Wood and Helen discuss how she got into programming, what made her decide to open a freelance business, and more!
How did you get into programming?
Helen started by making themes for herself and friends in LiveJournal using other people's CSS themes. Once she got to college she realized that although this wasn't a career, it was an aspect of a career. She then majored in graphic design, going on to do internships in both front-end development and design. Since college, she has gone back and forth between front-end development and design work.
How long ago was that?
Helen graduated college in 2013.
Did you graduate in computer science?
Helen did not even minor in computer science. At the time, she was focused on making stuff. The computer science major was too heavily focused on theory. She did take a couple of classes in it, but the graphic design major was more focused on building prototypes. Her graphic design major didn't teach her how to do anything - she said that you're on your own, and you have to figure out how to show off your ideas. The major appealed to her at the time because of that reason. Now Helen thinks majoring in computer science would have been really helpful for her career.
Charles points out that you don't have to have a computer science degree to do this work. Helen agrees; it can be wasted on you if you don't have the right enthusiasm to learn everything. Both say that you can get the education you want through self-education. Helen explains that so much of successful programming is good communication - this can be learned in college, while the specifics of how to code can be learned later.
How do you get from a graphic design major to "serious programming?"
Helen doesn't know how serious the programming she does is now. Her first real job was at Capital One as a front-end developer on their design team. She was doing prototypes and communicating between the design and production/engineering teams. She realized that nobody knew how to write JavaScript when trying to communicate between the two teams, so she decided that she should learn. A lot of the engineers came to the same realization at the same time. She started to write React as she was leaving Capital One. Everyone was trying to improve his or her JavaScript chops at the same time.
Did you get into Angular or React at Capital One?
When she first started at Capital One everyone was writing Angular. She wrote a lot of Angular in the beginning of her work. Most of the prototypes could be solved with React. Near the end of her time, she started using a lot of React.
What do you see is the difference between Angular and React?
Angular solves a lot more problems than React. It brings logic to the client side. React is only about solving visual problems. That's why it appealed to Helen. The design team she worked with was all about solving visual problems.
Why did you choose the front end?
Helen mainly chose it because she was a graphic design major. She believes that because the web is so accessible that it is the easiest thing. She also thinks the front end is fun.
How'd you wind up at Mozilla?
She met James Long through a mutual friend. Once they met, he thought she'd be a good addition to their team. He told her why it'd be a good switch for her - they were doing React work and they were looking for someone to understand problems that engineers go through.
What do they use React on?
She was on the browser team. The front-end of the developer tools was a JavaScript application that wasn't Angular. They were working on moving it to become a more documented framework. They wanted to use Redux and React. The team was converting it panel by panel.
What made you decide you were going to go freelance?
Helen had been missing things that she had done in college such as branding and illustration work. She had done some illustration work while at Firefox. She ultimately wanted to do a variety of different things instead of just product work. What gave her courage to go into freelance work was that James Long was also going freelance at the same time, so she thought that she was in good company. She also is related to a lawyer, so it wasn't as scary filing the paperwork because she had someone to ask for help during the process.
What contributions do you feel like you've made to the JavaScript community?
Helen believes that the highest impact work she has done has been on the Firefox browser. She didn't write a lot of code, but feels like what she did write is being used by a lot of people. She is most proud of the CSS grid because she says that it is exciting for people who do layout stuff on the web.
What are you working on now?
Helen started her own business at the beginning of the year. She is figuring out how she wants her skills to grow and with what kind of clients she wants to work. She has a lot of side projects, one being what she calls an art project. She is translating JPEG to Pixel art. She is taking NeoPixels, which are little programmable LEDs, and taking a matrix of values and displaying them on a sight board.
With everything that's out there in JavaScript, how do you keep current?
Helen answers that she doesn't. She tries to stay current with the tools she is using, which is React. She doesn’t try to be good at everything because she is also a designer, so she says that she has to pick and choose what she stays current on. Charles says that is what he tells people to do. There is so much out there that there is no way that anyone is going to stay current on everything. He says to keep current on what you are doing specifically.
Picks
Helen:
Charles:
Links
This episode can double as a My JavaScript Story and a My Angular Story and features Aaron Frost. Aaron has been on both JavaScript Jabber and Adventures in Angular. He has been a principal engineer for four years and recently organized his fourth NG-Conf.
How did you get into programming?
Aaron was working as a loan officer when he decided he needed a new career. He went to work at an accounting support phone center. There he discovered he was good at Sequel. He tried out for the QA team; the UA automation made sense to him. He became a senior QA and in 2010 jumped to working in development full time. He knew JavaScript; which made everyone wanted to hire him. He learned JQuery too.
What was it about JavaScript that really got you excited about it?
In Utah when he was working for a company, he had never learned JavaScript; he was told he had to learn jQuery to do browser extensions. The first night he learned jQuery he decided he loved the language. He stuck with it for three to four months. After that, he learned actual JavaScript. He explains that it just “fits in his head,” and made him feel well equipped and powerful.
How do you get to Angular?
He worked for a big, local corporation in Utah with powerful developers. The JavaScript community was strong there. They used Backbone and one day he emailed the developers. He suggested they Angular. One of the developers asked Aaron to help with the conversion. They were writing less code in Angular than in Backbone. It saved time.
Sometime after that, his friend Kip Lawrence suggested that they go to an Angular Conference. When they looked up conferences they couldn’t find any. They decided to start their own Angular conference after that.
How do you become a GDE?
There is a GDE app where you nominate yourself. In order to be picked, you have to meet a lot of criteria. You have to answer a lot of questions. There are things they want you to have done to prove you stand out and are a leader in the community. They want more than someone who is just smart. They want people who have presented at conferences, made open source contributions, written books, etc.
What else have you done in JavaScript or Angular?
One of the very first projects Aaron did is one that he considers one of the coolest. He built a browser extension for his twin brother’s real estate website that solved a captcha. He then marketed it to other people. He believes it is one of the most fun problems to solve.
What are you working on these days?
Aaron has a side project, which is a remote communication app for remote workers to use. He is working on how to make the NG-Conf bigger and better each year. He is also spending time being a dad.
Is there an overarching thing you’ve learned over the last 7 or so years of programming?
The thing that keeps recurring is that there is a need for engineers to focus on solving problems for users and less on having perfect code. He has noticed that developers make decisions to try to make perfect code that can sink a company. Developers should be more business focused than tech problems. It is more responsible for making a business profitable. Solve problems for the user first and don’t try to replace a language that’s working.
Picks
Aaron:
Charles:
Links
This week we have another My JavaScript story. This week’s guest is Laurie Voss. Laurie has worked with NPM from the start and has been a vital piece to getting it off the ground. Hear how Laurie got interested in computers, how Laurie got started with NPM, as well as a few things about the newly released NPM 5.
Laurie started by going into a computer camp, at the time Laurie hadn’t spent time around computers, and it wouldn’t be until the second time that he went to the computer camp that he would see a computer again. Laurie grew up in Trinidad where not many people could afford computers. He started making his first website in Angelfire using HTML before CSS became a thing.
Laurie had been writing JavaScript since it was invented. Laurie started a web development company in high school using JavaScript. Laurie met Issac while working at Yahoo and he introduced Laurie to Node which was a starting point to taking JavaScript more seriously for Laurie. When Node was ready in 2013, NPM Inc was on it’s way.
IN the beginning of 2014, Laurie was doing a lot of the JavaScript and was the CTO. Laurie says that part of his strategy has always been to hire JavaScript developers that are better at writing JavaScript that he is. Making him the worst JavaScript programmer at NPM. Laurie’s main job was doing what was needed to get NPM happen, including talking to layers and the business side of things. There are many companies that don’t understand how open source works, and in many cases it leads to run ins with lawyers. Many times NPM acts as an umbrella for open source tools that aren’t able to fight overzealous corporations.
Laurie expresses that it has changed over the years. A year ago he would say that he would have to say it leans towards the piece of software that is the registry. It’s very scalable and has worked great for small scale up to very large scale. Laurie works hard to gather funds and help make NPM grow as well as be scalable. He says that he is very proud that he build something that let’s others build things.
Laurie has been with NPM since the beginning. He tells us how Issac had been running NPM on donated hardware in spare time while working with Node. NPM would break a lot and be down due to the borrowed equipment. They decided that they needed to create a business model around NPM to help it grow. Laurie had just finished working on a startup and knew how to get funding and got their first round in 2014.
Laurie talks about making sure that their plan is in line with their customers. NPM could easily charge for many parts of NPM but they would rather charge for things that make sense to charge, so in this case the private packages. Enough people are using the private package to getting NPM to profitability. Laurie says that even if money stopped coming in they would have to git rid of a few employees but would be able to keep a small team and sustain the NPM registry, but would never build anything new. It’s always between being profitable or using money to build new things.
NPM 5 was just released and it’s much faster, five times faster. Laurie talks about being excited about the team and what they are putting into it. Things like making deployments easier. Many developers use NPM to put code together as well as to deploy it. If you didn’t have a lock file, it’s possible that it would change. But the lock file can take a long time, and you already know what needs to go there so they are adding npm store and npm fetch making deploys much faster. Additionally they will be adding a feature called insights. They are able to see information about different users packages, security information, performance information, etc. They can use that information to help developers with suggestions based off of data gathered by what other people are doing. Charles adds that it would be great for coming up with topics for the podcast.
Laurie reminds everyone about NPM Organizations as well as NPM Enterprise. NPM Organizations is a way to organize packaging as well as teams of developers and helps you to collaborate. NPM Enterprise allows for single sign on support, license auditing, and features that corporations care about.
Zite and NextJS
VMWorld
Twitter
On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned.
Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up.
Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus.
Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding.
Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation.
Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side.
Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web.
Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years.
Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests.
Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc.
Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated.
Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well.
A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind.
Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular.
Cory’s React Courses on Pluralsight Essentialism the book
Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter
Cory’s Twitter
From the publisher's feed

31,924 Listeners

16,046 Listeners

286 Listeners

45 Listeners

23 Listeners

1,093 Listeners

623 Listeners

581 Listeners

17 Listeners

67 Listeners

15 Listeners

62 Listeners

21 Listeners

4 Listeners

0 Listeners

983 Listeners

9,516 Listeners

960 Listeners

10,177 Listeners

1,345 Listeners

549 Listeners

104 Listeners

454 Listeners

31 Listeners