I recently overheard someone say that to be a programmer, “you have to be smart”. Putting aside the debate of what it means to “be smart”, I can say with absolute confidence, that this is not the case. A good programmer/developer/webby person will typically flourish with four traits (of which “smart” is not one).
- an interest in languages or math
- enjoys problem-solving
- learns well on their own
- works well on their own
While these are the four traits that have allowed me to earn a rewarding living as a developer, I’d say 1, 3, and 4 are even optional depending on your work environment.
The best programmers I know are the best because of personalities and traits that match well with the industry, not anything related to IQ. And like most work, human skills are the top of the requirements list to be successful and get things done.
create-react-app is a great little tool by Facebook that allows the creation of React apps with a single command. It’s extremely simple and very effective: in just one week of work, the authors removed a huge boat anchor to React productivity, being the initial setup of a diverse and ever-changing pile of development tools. I also love how a simple
eject command allows the developer to continue down their own path of tool customization without any sort of “lock-in”. It has nowhere near the power of a tool like Ember CLI, but it isn’t trying to at this point; while usable right away, there’s still plenty of room to grow and experiment with improvements in the future.
It immediately reminded me of what I call “the skateboard diagram” by Henrik Kniberg. Rather than building the “complete” version of a product first, build the most basic version that allows you to gather feedback, then improve in further iterations. The end result is a product that’s more stable, available sooner, and solves real problems more so than the traditional method of “build it then ship it” development.
(Photo by Salvio Bhering via Pexels)
Following their basic tutorial, I deployed an example app in seconds. Then after creating a CNAME record for a subdomain, I linked the two together, and had my subdomain live with a valid Let’s Encrypt certificate installed and ready.
Everything about working with Now is very refined and the essence of simplicity – from their CLI, to their password-less logins and modern, minimalist account interface. It feels light-years ahead of any other hosting and deployment tooling I’ve played with. (Note that mapping custom domains is part of their Premium plan, but they also provide a free OSS Plan that allows more human-readable URLs than those generated by default.)
Like many, I was curious to see how the Let’s Encrypt project would roll out in the real world. I remember looking at documentation for setting it up when it first came out, and quickly moved on – it seemed complicated and laborious (still, pretty great for a free SSL cert).
Now that it’s been around for a while (WordPress.com custom domains use Let’s Encrypt certs), I thought I’d check again how difficult it would be to throw it on a random domain of mine. I reactivated my DigitalOcean account, spun up a VPS, did some basic setup, and nabbed a new domain (a 6-letter domain, $8 for 5 years, wut) for fun. After waiting overnight for DNS propagation, I banged through three quick tutorials for Nginx, PHP7, and Let’s Encrypt – and had my cert up and running. Not a bad server setup for ~$5 a month and next to no effort.
(Edit, September 2, 2016: “my cert up and running” link is dead as I’ve deactivated my DigitalOcean account; turns out I only need ZEIT now.)
At WordCamp Montreal 2014, I gave a talk on fears. In it, I told of a story from the Drupal community, that compares two approaches of open-source contribution: collaborative and isolated. I was unable to find it at the time to properly credit it, but my coworker Kathryn Presner just happened to mention it today: it’s by Angie Byron, and can be found on her webchick.net blog: Diaries of a Core Maintainer #6: A tale of two developers.