Review : Web tooling and automation course on Udacity

In the last few weeks, I’ve gone through a few courses on the Udacity since I’ve been looking to update my JavaScript skills. The Udacity courses are mostly videos, but short and to the point. I often have trouble following along with videos when they’re too long and would rather have the transcript, but it was not a problem with those courses. It’s easy to follow along, and there are often chances to try out the material immediately instead of having to watch an hour of video before doing anything.

The courses are also not as close to the format of a university course than Coursera or Edx: the focus is on a specific subject, such as testing JavaScript or responsive design. There is no extra fluff beside the main subject, so you need to listen to the basic courses in HTML and JavaScript if you don’t already have a background in it.

Also, I was able to go through the courses faster than the posted times in most of the case: it’s easy to squeeze in a few videos and an exercise when you have a bit of spare time.

The Web tooling and automation course was the best out of the ones I tried. The goal of this course is to showcase a good workflow for a web application based on JavaScript. Since I’ve mostly worked in a .NET/Visual Studio environment lately, I’m interested in learning about the latest best practices and tools in the JavaScript world. It’s rarer to see a course that focuses especially on this: I often default to following a beginner’s course to get this information since they’ll teach how to get setup, but it’s not always representative of what someone would do to build a large application.

The course covers the following subjects :

  • Advanced editor features: The best plugins and tools to make Sublime Text a great editor for the web. It’s as good as Visual Studio once properly setup for a fraction of the system resources, and a lot faster. I’m sold!
  • Managing builds with Gulp: How to automates steps like generating CSS from SASS, minification, bundling/concatenation and creating a release version. It’s a powerful tool, and it uses JavaScript so there was no need to learn a new syntax just for the build tool.
  • Setting up live editing in the browser: It’s not something I had considered doing before since most of my projects require a session and some form of authentication, but it’s interesting to avoid copy-pasting modifications from Firebug or the Chrome developer tools while working on a complex layout.
  • Linting and unit testing: The linting, or validating the JavaScript syntax was easy to setup, but I had trouble making the testing tools work on my Linux laptop. It was not the fault of the course material, and I was able to make it work after reinstalling a few packages.

The only problem is that the downloadable examples start with the solution to the first exercise instead of the scaffolding to fill in. It’s only annoying for the first lesson since all the exercise build on each other, so you won’t miss much.

In conclusion, you must do this course if you’re interested in JavaScript and want to improve your workflow. It’s a very small time investment for all the tricks and tools you’ll learn.

To learn, you must ship your code

When working on a project, the temptation is strong to make everything perfect before showing it to the world, or even just to your co-workers. You know each and every line of code you wrote, but you have a long list of bugs to fix and don’t want to expose your work until you’re completed everything that was on your TODO list. Shipping is scary, so you’re holding back with the excuse that you need to fix another bug before finishing.

If you want to make software people use and enjoy, and not just write code for the sake of it, you must get over yourself and ship! I’ve seen people holding onto code for ages, polishing it to perfection, only to leave the job before anyone had time to see the results and give valuable feedback.

The same goes if you wish to get feedback on code you’re doing as a side project. If you’re not shipping, nobody will be able to comment on your code and you won’t know if you’re going in the right direction. Agile methodologies have the right ideas about this. Getting used to shipping small changes will help you fight the urge to keep your code to yourself and having to push huge modifications at once because you’ve been playing it safe.

Also, we tend to underestimate the value of our software. A tool that will help improve business processes will be used and appreciated if it does the job, warts and all. When an application makes people’s work easier, they won’t mind putting up with some bugs for a while until you have time to fix them.

You want to validate with your users that you built the right thing as soon as possible, and there are many flaws you’ll see only when people are using your product. What if the incomplete feature you were planning to spend a few weeks on is not really needed? Better to know right away instead of sinking a lot of time into it.

The caveat is that you must allow time to go back and fix those problems when they’re found. On the other hand, you don’t want to fall victim to “ship the prototype” syndrome: if every time you show a quick and dirty prototype it ends up in production, you must make sure that what you show is solid and well-structured even if it’s incomplete. Shipping something is an important milestone, but it’s not the end of the project.