Month: February 2018

Along with a number of my Sourcetoad coworkers, I’m taking a couple of hours off to see Apple co-founder Steve Wozniak speak at USF this afternoon. It’s the inaugural event in USF Muma College of Business’ Thought Leader series. It will be moderated by the school’s dean, and promises to feature topics ranging from entrepreneurship to issues with the age of supercomputers in our pockets. Woz and the dean will accept questions submitted via Twitter using the hashtag #USFMumaTLS.

Seats for this event “sold out” (it’s in quotes because tickets were free) so quickly that they had to move it from its original venue at the Muma College of Business to the Sun Dome (USF’s sports arena), and once again, the newly-added seats were snapped up quickly.

I cut my programming teeth on an Apple ][ with AppleSoft BASIC and 6502 assembly language. The first computer I bought as a newly-graduated I’m-a-real-grownup-with-a-job person was an Mac Quadra 660AV, and the first computer I was assigned at my first job was a PowerMac 6100/66 “FrankenMac” (it had a Wintel card in it, so I could switch between Mac and Windows development with a keystroke). Decades later, my work and home machines are both MacBook Pros, and I’m not just cranking out software for Apple platforms, I’m even teaching people how to do the same at meetups and conferences. I come by my Apple sentimentality honestly.

I’m pretty sure that the odds of my being able to get an autograph from Woz are slim, but I’m bringing my original Apple ][ Reference Manual just in case:

Click the photo to see it at full size.

Here’s part two of my notes from the 2-hour talk that npm COO Laurie Voss gave at Tampa Bay Startup Week, Stuff Everybody Knows (except you). Regular readers of this blog will know that when I take notes, I really take notes.

In case you missed part one, it’s here.

What is coding?

• Now that you’ve gotten good at the basics, it’s time to do your job: actual web development.
• Coding is:
  • 50% solving the problem
  • 50% communication — that means listening to the person whose problem you’re trying to solve.
• You have to understand the broader context of and the constraints under which you’re operating.
• You have to recognize priorities.
• Solving in the abstract solves a problem that you’ve invented in your head, but not the problem that you’re being paid to solve.
• Understanding the problem is crucial to being a web developer, as is communicating back your solution.
• Once you written the code, you should be able to explain what it does, what it doesn’t do, where the bugs are, how it’s documented, how to test it.
• If you write code that only you understand, you are its only user, and that’s of no use to anyone.

HTML

• Tim Berners-Lee’s original intent for HTML wasn’t the web as we know it today — he was aiming for something more like Wikipedia.
• He was thinking of a two-way editable database where everyone could share facts and link to them.
• His use of hypertext was an accident, but it turned out to be much more flexible.
• HTML is semantic — it’s not a language about how to display things, but a language about how to represent things and what those things mean.
• The tags in HTML have meanings: this is a list, this is a navbar, this is a link. It says that certain information isn’t just text, but has some meaning.
• The link tag is the best example of why semantic markup is important.
• You can implement links in other ways — e.g. <div> tags with onClick JavaScript that do the same thing — but that’s not actually what we do. We use an anchor tag — the <a> tag — because it says “the text in this tag relates to the web page at this URL”. You’re creating a semantic relationship, which the <div> tag with the JavaScript doesn’t.
• The web is the web because of the <a> tag!

JavaScript

• JavaScript is not a thing that everyone knows or agrees about.
• One important thing about JavaScript: you don’t always need an app.
• People love building rich web applications, but they’re big, take several seconds to load, and often, a web page will be more than enough to do the job.
• Rich web applications:
  • Are harder for search engines to parse
  • Load more slowly, especially on mobile devices
  • Add a lot of things that can go wrong
• The New York Times isn’t a rich application because it would be overkill for what it needs to do: present a news article, leave it onscreen for the minutes you read it, and then go away.
• Think carefully about whether you need to build a web application and bring on all its trade-offs, especially if you’re thinking about mobile users — and you should.
• As of 2015, about half of the web’s experiences happen on phones, whose processors run at speeds slower than laptops. Rich web apps make them even slower.
• You’re probably sacrificing mobile users’ experience because rich web apps are fun to build, but they’re not always the right thing to build.
• The other important things about JavaScript is that you should use it optionally.

• You should consider progressive enhancement. It progressive enhancement used to be popular, then it fell out of style, and it’s back now.
• Progressive enhancement answers the question “What happens is JavaScript is turned off?”.
• It may sound ridiculous until you consider that JavaScript is effectively turned off for the first 3 or 4 seconds while the page loads; it’s the last thing to happen. This is even more true with lots of people browsing on their phones.
• Your rich web application will stop working if it stop loading because your user has gone to a place where the signal is weak, which happens all the time. This won’t happen to the New York Times because it’s not a rich web app!
• Your site should be able to do something useful even when JavaScript hasn’t loaded. You ecommerce site should still display price and quantity even if the JavaScript for the “add to cart” button didn’t load. Your failure case should still be useful — your pages shouldn’t be all or nothing.

User experience (UX)

• Not what it looks like, but what it feels like, and that’s far more important.
• URLs are part of UX.
• HTTP is a stateless protocol, which is a fancy computer science way of saying “No matter who you pass a URL to, if they follow it, they’ll see the same thing”. If both you and I follow the same URL for a terrible article, we will both see the same terrible article.
• This seems obvious to people who’ve been on the web for a while, but it’s unique to the web, and it’s why the web is so popular. It runs off social networking and our deep-seated desire to share stuff with each other.
• If you’re building a web app, you need to think about how people share it. You can’t have a rich web app that has a single URL that is the home page and a bunch of random shit that happens when you click buttons.
• You should be able to follow a path into a site really deeply, and when you find something and want to share it, you should be able to copy its URL, send it to someone, and they should be able to follow it and see the same thing. That’s how the web is supposed to work.
• Support deep links because the web is social and people share stuff.
• Don’t break URLs! And remember, they’ll end up shared and embedded in everything.
• Your URLs from 10 years ago need to work today, otherwise you’ll lose people who are trying to find you.
• Supporting deep links isn’t just good social networking and SEO; it’s also crucial to scaling.

• Beware Twitter’s hashbang mistake, which they made when they tried to turn it into a rich web app.
• At the time — 2010 — they needed IE6 compatibility, and so they decided to make use of the hashbang.
• The problem with the hashbang is that everything after it in the URL is considered to be a page fragment — it means it doesn’t go to the server; it’s handled on the page.
• This decision means that now and forever, Twitter’s homepage has two jobs:
  • It has to be Twitter’s homepage, and
  • it has to be the location of any one of 1.8 billion tweets
• If you load Twitter’s homepage from scratch, you’ll see that it stays blank for a second while it tries to determine if you want to see a homepage or a tweet and if it’s a tweet, has to load the user interface and then dig into the database to get that tweet.
• It’s a 2010 engineering decision that broke everything; they’re stuck with a stupid one-second delay forever because they can’t break all those URLs that have been shared.

Solve the users’ problems, not your problems

• A general principle of UX is that you should solve the users’ problems, not your problems; you should be aiming for usability over impressiveness.
• Landing pages, interesting animations, and shadow effects look great the first time, but by the third time, the thing users remember is the slowness of your site.
• Carousels are a really great example of developers solving their problems rather than the users’.
• For some reason, the people who make web sites were under the impression that users would go and click arrows to view the pictures in the carousel.
• See this article from the UX experts, the Nielsen Norman Group, who point out that not only do people not use carousels, they don’t even know what  they’re for, they don’t know how they work, they don’t know what the little dots at the bottom are for, and so on.
• “Solving” the users’ problems with carousels by making them autorotate just enrages them, because the thing they were just reading disappears.
• The only reason carousels exist at all is because Apple uses them all the time. Apple can get away with it because they have an entire operating system built around carousels; your web page cannot.
• Carousels are there because they solve an argument in the marketing about which picture to put on the home page: “All three pictures are on the home page! It’s fine!”. That’s not the users’ problem.

Be predictable

• Links should go places. You click them, and you go to another web page, where you can click the back button and return to the previous page, and nothing has changed.
  
• Buttons should do things. It changes something — it buys something, or deletes something, or kills someone you love.
  
• You never get angry emails from users saying that you violated their expectations by making a link behave like a button or making a button behave like a link, because most users don’t have a UX vocabulary. Instead, they simply remember that your site behaved annoyingly, leave, and never come back.
• Another way sites behave unpredictably is by using horizontal scrolling. Nobody scrolls horizontally!
• On sites that scroll horizontally, users try in vain to scroll vertically, fail, and leave.
• Remember the principle of spatial memory: our instincts and senses are tuned to the jungle, and thus we have a memory for where things are in space.
• If I’m on a web page and I scroll three feet down the page, I remember that the login button was at the top of the page, three feet up and can find it.
• Developers mess with spatial memory by using JavaScript to make objects on the page shimmer into the background, or float away, or otherwise disappear someplace else, undoing spatial memory, and breaking the sense of where we are on the page.

Be fast

• Performance is invisible UX. It’s an overlooked aspect of UX.
• More than any other thing, the speed at which a page loads determines how good a user feels about it.
• If you have a web page that takes 10 seconds to load because it has a widget, and removing the widget still leaves most of the page useful but cuts the load time down to one second, you should absolutely do that. People like fast pages more than pages widgets on them. This is why Craigslist , with its ugly-ass UI is still popular.
• Fast sites encourage exploration, slow sites encourage abandonment.

Mobile first

• I’ve said this before, but I need to say it again. About half of the time spent on the web is spent on mobile devices. That’s a fact that hasn’t percolated down to the people who design for the web.
• You have to consider mobile first, and design for the case first. Then you can design for the desktop case. Don’t think about designing for the mobile web as responsibly squeezing things down for a small screen, think about the mobile site as they place they’ll go to first.
• The social nature of the web means that we get links to things when we’re walking around, when we’re using our mobile devices. Before we decide that we’re going to look at something on your desktop, we look at it on our phone, and that’s when your first (and likely only) chance to impress the user.

Accessibility is not an option

• Accessibility is not optional. It’s not a thing you later or a thing you add if you’re rich, or if you’re feeling magnanimous.
• Accessibility means accessible to people who view the web in a way different from you.
• 3.4% of web users have limited vision. If you add in people who have motor control difficulties (for whom very small buttons are difficult to use), and people who have cognitive difficulties, the number of people who view the web differently from you rises to a not-insignificant 8.5%.
• If you’re building an ecommerce site and the question you’re asking is “How do we grow our market by 8.5%?” the answer is to make it simpler.
• The answer to accessibility is to do less! Use built-in controls, because browsers, screen readers, and accessibility devices know what they’re for.

Also in this series

• Part 1

For those who missed npm COO Laurie Voss’ excellent talk at Tampa Bay Startup Week, Stuff Everybody Knows (except you), I took notes. Regular readers of this blog will know that when I take notes, I really take notes.

Laurie’s presentation ran for 1 hour and 48 minutes, not counting the Q&A session, so my notes will come in installments. Here’s the first one…

The images are a mix of Laurie’s slides, with some selections of my own.

Intro

• This is the 28th time I’ve given this talk
• If you’re a web developer, this talk is for you!
• I’m the COO of npm (which involves lots of yelling at lawyers and accountants), but what I really am is a web developer
• I started web development at 16, and I’ve been doing it for 22 years
• The purpose of this talk is to fill a gap that exists when talking about web development, especially with new developers
• We always talk about the new, exciting stuff
• However, there’s stuff from 20 years ago that we agreed was a good idea, and that we still agree is a good idea, and if you’ve been developing since then, you internalized that stuff. If you’ve been around that long, you just know it.
• How do you know that stuff if you just started three years ago?
• This talk is about all that stuff that we agreed was good, true and evergreen 20 years ago, and you should still know.
• The reason that this talk is called Stuff that Everyone Knows (Except You), because no one probably told you this stuff.
• Two hours is a long time, but not long enough to be a complete tutorial. It’s an index of things you should look up.

• A disclaimer: This is a ton of opinions, glued together and presented as facts. I have reasons and experience that leads me to think these things.
• It’s been refined over 27 versions – stuff that didn’t land got excised.
• Keep in mind that I could still be wrong. That brings us to…

You know nothing

• There’s something called the Dunning-Kruger effect.
• Dunning and Kruger studied how good people were at stuff vs. how good they thought they were at stuff vs. how good they thought other people were at stuff.
• They gave people basic tasks that were easily to quantify by performance and discovered interesting things about the people in the top and bottom quartiles:
• The top quartile were great at what they did, but they think they’re about average.
• The top quartile are susceptible to Impostor syndrome, and it makes them vulnerable to arrogant jerks, especially people whose arrogance comes from prejudice.

• Impostor syndrome lets white guys run roughshod over the rest of us.
• The bottom quartile is “the really dangerous shit”. They’re terrible at stuff, but don’t know it. They also think they’re above average.
• They’re also terrible at estimating how good other people are. They don’t overestimate or underestimate; they’re just random number generators.
• They’re like that because they have no idea what good and bad look like:
  • If they knew what bad looked like, they’d know they were bad.
  • If they knew what good looked like, they’d know how to get better.
  • They’re the kind who set the cake on fire, look at it, and go “I guess that’s baking.”
• The real problem is that they don’t improve until a neutral outsider says “That’s bad. Let me help.”
• Things like boot camps and conferences help you emerge from bottom quartile.
• You know you’ve emerged from the bottom quartile and realize “I’m so dumb! There’s so much stuff I don’t know!”

• The problem is that if you think you’re pretty good, you’re either pretty good — or the worst, unless you can find a good outside impartial observer.
• It’s very hard to find a good impartial observer.
• In general, when estimating your skill, be humble, but don’t take any shit.

Automate everything

• Tasks that take a small amount of time but do often will eat up surprisingly gigantic chunks your life.
• This was brought to my attention by this xkcd comic…

• …but Randall Munroe, who writes xkcd, doesn’t have a real job, so he doesn’t know how real jobs work.
• This is my version, which is based on an actual working day over the course of a year:

• Think of a task that you do every day, and suppose it take you an hour a day. If you’re a programmer or information worker today, that task is probably typing — you probably spend 8 hours a day doing that.
• If you type at 30 words per minute (the speed of a beginning typist) and speed it up to 40 words per minute, you’ll save an hour a day. Over the course of a year that savings becomes 1.5 months.
• If you had a startup that got a bunch of money that made up 12 months of runway and you were a slow typist, you could spend the first month doing nothing but taking typing classes, and you’d still be better off, because the resulting time savings from being able to type faster would give you two weeks more runway.

• Master the Unix command line — you have to live there; it’s where we deploy web sites. You have to be great at the command line; it can’t be someplace you go because you have to.
• You have to know how bash and grep work, and if you can, learn how find, sed, and awk and all those other weird utilities work. Those are where you save time, where you put together little five-line scripts that take you from a 15-second task to a 1-second one.
• There’s this myth of the 10x programmer — there’s no such thing. Everyone programs at the same speed; what a 10x programmer is someone who does only programming by automating away everything else in their job. They appear more productive.

Pick a text editor and master it

• It doesn’t really matter which text editor you use: pick one and become really, really good at it.
• IDEs are fine; don’t listen to people who tell you that vim is the only way.
• Don’t switch editors all the time, and don’t remap your keyboard to Dvorak. The act of switching is what will destroy your productivity.
• The people who are astonishingly productive at vim are like that because they’ve been programming in it for 30 years, even though vim is one of the worst pieces of software we’ve ever put together.

Version control: git or GTFO

• There are lots of version control systems out there, but git’s the only one that matters.
• git is how software is made these days. It’s how we collaborate, test, debug, and deploy.
• You need effortless comfort with git as you do with typing. You need to be able to branch, merge, squash, and do all the weird things that people do with it.

Also in this series

• Part 2

I’m going to start with a controversial statement: in theory, Tampa Bay Startup Week 2018 should amount to nothing.

Good — I’ve got your attention now.

It’s an easy argument to make. Tampa Bay’s cities — Tampa, St. Pete, and Clearwater — don’t have the sort of entrepreneurial or tech cachet that other places, from the usual suspects Silicon Valley, Austin, and Seattle to upstarts like Raleigh, Boulder as well as Toronto and Montreal. Tampa, St. Pete, and Clearwater are also  overshadowed by other, better-known Floridian cities: Miami and Orlando. Tampa Bay’s geography and horrible traffic fracture the area, and between bridges and drive times that are twice what they should be, locals are reluctant to travel within their own areas, never mind the nearby sister cities.

With these challenges, what could the well-intentioned team behind Tampa Bay Startup Week 2018 possibly hope to accomplish?

If we play our cards right — and by “we”, I mean the organizers and us, the intended audience , Startup Week’s accomplishments could be bigger than anyone dreamed. I say this because we’ve seen this sort of thing before, over and over throughout human history. Of all the examples I could pick, I’m going to take one that’s close to my musician’s heart: a seemingly unremarkable event in a failing city in England that would later be known as “The Gig That Changed the World”.

Manchester, 1976: The Gig That Changed the World

The Free Trade Hall in Manchester, England.

You could draw a number of parallels between Manchester, England and Detroit, Michigan, especially in the 1970s. Both were cities that grew to become industrial powerhouses in the first part of the 20th century, and both saw their fortunes decline drastically and become bleak urban wastelands after World War II. Both would also end up changing the course of music history in unexpected ways.

The Sex Pistols.

In June of 1976, a relatively unknown band called the Sex Pistols played a concert at Manchester’s Lesser Free Trade Hall. There were a mere 42 people, which is respectable for a band that plays at your local bar on a Tuesday night, but it doesn’t seem like the sort of gig that would “change everything”. What separated this gig from all the other Tuesday night gigs with fewer than 50 people is who were involved and showed up:

• Two art school student friends, Howard Devoto and Pete Shelley organized the event. They ended up forming their own punk band, Buzzcocks, whose single, Ever Fallen in Love (With Someone You Shouldn’t’ve) has wound up in some of the most unlikely places: covered by Fine Young Cannibals in the ’80s and Thursday for the 2004 video game Tony Hawk’s American Wasteland, and featured in the soundtracks for the 1986 film Something Wild and the 2004 film Shrek 2.
  • Devoto would later form the post-punk band Magazine, who would influence ’80s acts Ministry and Peter Murphy as well as late ’90s acts Radiohead and Jarvis Cocker (lead vocalist from Pulp).
  • Shelley went solo, during which time he recorded the synth-pop single Homosapien with producer Martin Rushent. The experience doing all the drum machine and synth programming for that single would serve Rushent well, as his next project was The Human League’s ground-breaking album Dare! (the one with their big single, Don’t You Want Me).
• Tony Wilson, who hosted a TV show featuring the still-new punk rock movement, and Martin Hannett were there. They would go on to become a key figure in the Manchester and alt-rock scene by:
  • Starting Factory Records, which featured a number of notable bands: Joy Division, New Order, A Certain Ratio, The Durutti Column, Happy Mondays, Northside, and (briefly) Orchestral Manoeuvres in the Dark and James.
  • Wilson would open the legendary nightclub, The Hacienda, featured in the movie 24 Hour Party People and a key player in the rise of the acid house and rave scenes.
  • Hannett who would go on to become a legendary record producer.
• Steven Patrick Morrissey was also in attendance. He’d ditch his first two names and go on to become the King of Mope and lead vocalist of The Smiths, who would go on to inspire just about every emo rock band that followed.
• Also there:
  • Mark E. Smith of The Fall, whose influence can be heard in later acts such as Pavement, Sonic Youth, Guided By Voices, Faith No More, and even the electronic act LCD Soundsystem.
  • Paul Morley, who would go on to become a music journalist for the Brit music magazine NME, promote the band Frankie Goes to Hollywood, and co-found Art of Noise
  • Mick Hucknall, who would go on to become the lead vocalist of Simply Red
• And finally, three young men named Ian Curtis, Bernard Sumner and Peter Hook. Inspired by the performance, Hook would buy his first guitar, and the three would form a band named the Stiff Kittens, which would later go by the name Warsaw, after which they’d finally settle on the name Joy Division. They would go on to become one of the best-known and influential New Wave bands. After Curtis’ suicide, the remaining members who would go on to become New Order, who’ve influenced anyone who’s ever plugged in a MIDI cable into a synthesizer. To this day, New Order’s Blue Monday is the best-selling 12″ single of all time.

The headlining act (the Sex Pistols) and the organizers (who’d go on to form the Buzzcocks) of this poorly attended, seemingly insignificant gig were so influential that they’d end up in Jack Black’s lesson in School of Rock…

You can see the Sex Pistols and Buzzcocks listed under “Punk”. Click here to see the full blackboard.

…and the concertgoers from that gig would go on to build the foundations of alternative rock and influence a lot of people who took up the electric guitar, synthesizer, or turntables.

In theory, this concert should’ve amounted to nothing, but in the end it changed everything in the music world.

The Gig That Changed the World brought together people with similar interests who were passionate about what they did. Its attendees saw that popular music was changing, and after being inspired by a group of troublemakers, decided that they could be part of that change. They went on to create music their way, and they made their mark on the world.

Tampa / St. Petersburg 2018: The week that could change the world

The people behind Tampa Bay Startup Week (the 2015 team is pictured above) may not look punk rock, but they’ve most certainly got its DIY, “we have an idea and we’re going for it” spirit. Like the Pete Shelley and Howard Devoto organizing the Sex Pistols gig, they’re a band of troublemakers putting on an event on a shoestring budget (yes, Chase is sponsoring, but without them, the budget would likely go from shoestring to none), and at the moment, it isn’t being noticed by most of the world outside “the other bay area”.

Like the music scene in Manchester the mid-late 1970s, the work-life dynamic in Tampa Bay in the mid-late 2010s is undergoing some big changes:

• People are moving here in droves,
• Forbes has put this area in the number two spot on their top 10 list of cities for young entrepreneurs,
• we’ve got both University of South Florida and University of Tampa teaching entrepreneurship,
• The Iron Yard taught motivated go-getters to code,
• We’ve got some interesting companies here in town — Malwarebytes, Jabil, Adjoy, AgileThought, Haneke Design, and Sourcetoad, to name a few,
• One Million Cups has consistently been gathering hustlers every Wednesday,
• we have more than our fair share of makerspaces, what with The Hive, Tampa Hackerspace, and Eureka! Factory,
• we put on a great BarCamp, CodeCamp, and Ignite,
• and we have a healthy tech meetup scene.

The team at Tampa Bay Startup Week have done their part by organizing their event for Tampa and St. Pete, just as Shelley and Devoto did back in 1976 by bringing the punk rock to Manchester. How the rest of the story ends is up to us.

I’ll repeat what I said at the start of this article: In theory, Tampa Bay Startup Week should amount to nothing. In practice, and as shown by music history, if we take inspiration from the event, make friends and connections, and take action, it could be that gathering that changed the world.

Further reading

Visit Tampa Bay Startup Week’s site to find out what’s up this week!

For those of you who’d like to know more about The Gig That Changed Everything, here’s the BBC’s special on the event, titled I Swear That I Was There:

This article is the 2018 revision of an article I posted in 2015.