Knock, knock. Race condition. Who’s there. Wait…

Thanks for joining us on Real Time Overview for Thursday, June 14th. I’m your host, Michael Fienen and I hope that you’re helping to build something awesome this week. Sorry we’re a day late this week, but we’ll be back to our regular schedule next week. If you’re just catching up with us, be sure to go back and check out episode 12 of the Drunken UX podcast from Monday where Chris Wiegman joined us to chat about web security. We covered a lot of ground that includes many of the basics that you need to chase to start thinking about your own apps and server security – skills every developer should at least tinker with at some point. But enough with my shameless self promotion, let’s get on with the show.

You know, as I sit here thinking about this podcast and my career as a web developer, I realize I’m no longer the youngest guy in the room anymore. Hell, we live in a year where there are kids about to start college that weren’t even alive in a year starting with 19. And if that doesn’t make you feel old, nothing will. But with as important as it is to encourage people starting in the industry to help them find mentors and track down learning resources, it doesn’t hurt to think about what the future looks like for new, old developers.

This is the topic that Anthony Delgado covers in his article “You’re Never Too Old to Learn to Code.” In particular, he emphasizes the accessibility of the industry to people who want to maybe consider a new career later in life, and the neat part about that is that the advice isn’t much different whether you’re young or old. The first point he jumps into, for instance, is one that I love to emphasize – that we work in an industry where what you can show me is as or more important than what you can tell me.

Another incredibly important key strength you probably have is your industry knowledge. Regardless of your background, if it isn’t in coding, that means you know a lot about something else that you could apply development skills towards. For instance, who knows what a small, independent realtor needs more than another realtor? Having that background gives you an enormous advantage over someone who simply knows how to code, and is either building what they think an industry needs, or worse, might just be combining bits of functionality in hopes that they’ll get lucky. That’s value that 22 year old Brad over there can’t replicate with his cute little digital art degree.

That’s not to say getting a new job in something you’re just starting to learn later in life is easy. It isn’t. But it doesn’t have to be any harder than anything else if you recognize the important skills that you have that can make you very valuable as a developer, along with how you sell those skills to a potential employer, even if you’re starting out back at the bottom of a new ladder.

We’ve been arguing about the importance of content being above the fold – or the lack thereof – for well over a decade. With mobile devices, this discussion takes on a new shape, as responsive sites get longer, and users have to scroll further to get to the content that they want. It begs the question, how long is too long, and what do we do about it?

Fabian Sebastian is prepared with an answer in his UX Planet post “Bidirectional Scrolling is Here to Save Responsive Design.” His answer centers on redirecting the question away from whether or not users scroll, but rather, how do we address bad design that forces unnecessary scrolling.

Desktop sites have a unique advantage where they can, at a glance, offer up a lot of real estate to showcase different content. Responsive design on mobile devices forces the context of the screen to narrow, focusing in on smaller units of content you must travel through to get to the rest. The content is the same, but your ability as a user to scan and skip isn’t.

As the title might indicate, Fabian’s solution to this problem centers on making use of scrolling on both axes. Even though we are only accustomed to scrolling up and down on most sites, it’s a convention begging to be broken in the right cases. As an example, one of those is Netflix, where the page scrolls up and down, but media categories scroll left to right.

What’s your take on the user experience of horizontal scrolling? Is a long, linearized layout preferable to one that forces users to think in two dimensions? Or is it the solution to a challenge we’ll see more of in the coming years? Let us know what you think in the show comments.

Over at UX Tricks, Daniel Schwarz has a Beginner’s Guide to Rapid Prototyping available. The guide is advocating the process of moving through an agile-like iteration, creating low-fidelity prototypes, and progressively improving upon them, while scrapping the ineffective pieces, until you end up with a well-tested, high-fidelity prototype that can move on into design and eventually production.

His argument is that too often, organizations try to push ahead straight into high-fidelity prototypes and design before they’ve fully vetted features and needs, which in the long run results in wasted time, money, and frustrated users. Your developers and user experience designers get stuck in a loop trying to correct and fix issues that could have been prevented from ever getting in front of users.

The process he outlines takes the reader from paper prototyping, to wireframing, and into prototyping tools. He also shares some tools along the way that can help. One is a wireframing utility called Balsamiq. It’s one I’ve used myself that I really enjoy for low-fidelity brainstorming. And you also have Adobe XD at your disposal now, a tool that will likely become indispensable to designers now that it’s free to Adobe subscribers.

Run by UX Tricks and check out Daniel’s piece. If you like it, check out the link to Product Hunt at the bottom of the page. This article is an excerpt from a larger eBook they’ll be releasing, so you can sign up for updates there.

Whether it’s your job or a hobby, as you spend more time doing it and improving your skills, you slowly learn how to add different, useful tools onto what you have. You start basic, with cheap tools, and items designed to handle many things at once in broad ways. Web development is no different as you learn to build sites, and figure out how to set up your own server, SSL, build processes, elastic search, and other tools.

DJ Walker extends that idea with the article “For Static Sites, There’s No Excuse Not to Use a CDN.” Adding a content delivery network to your web development toolchain is one more refinement to your process that can improve speed and reliability for your site. And in fact, if you’re listening to this episode right now, it’s thanks to the CDN we use for the Drunken UX Podcast to help ensure our audio is easily available, quickly, to all our users.

CDN’s tend to get a lot of attention when you start talking about the growing interest in static site generators – web application toolsets design to create fully rendered pages, rather than pages that are output programmatically when you visit a site. That’s how a content management system like WordPress works. In the static site generator world, it’s tools like Hugo or Jekyll.

With a static site generator, you save your content to a repo, point it at various template files, and it generates all the flat files needed to serve up your site. No database, no PHP. Since it’s all static, it makes it easy to use a CDN to handle the heavy lifting you’d normally set up an Apache or NGINX server for.

There are a lot of ways to benefit from a CDN, even with dynamically generated sites too. DJ looks at a number of the performance metrics that show how much more quickly your visitors will get those first bytes of data. It’s well worth considering for any site you create.

Hit us up on Twitter and let us know what your favorite CDN is, if you’re already using one. Maybe it’s CloudFlare, or CloudFront, MaxCDN, or Edgecast. Let us know what you’re using and why!

Stop by Femgineer.com to review an episode of Build with Poornima Vijayashanker and Jay Hum about what technical debt is and how to manage it.

Whenever we build tools, over time, it’s inevitable that we will accrue technical debt – that’s anything in your code base that keeps you from fixing or changing code, because you have to make other changes to either keep something up to date, or improve its flexibility to support the other updates that you want to make. For instance, perhaps you built a tool to scrape your Twitter account, but it has stopped collecting data because of a change to the Twitter API. Your tool itself doesn’t have a bug in it, but correcting the issue will require you to update your API library, and fixing your issue might be blocked because of what’s now available to you in the update.

Technical debt is unavoidable, because we rely on dozens and dozens of tools to create websites that will be updated over time, whether that’s WordPress and plugins, jQuery, Node, and so on. The natural aging of those codebases will always result in eventual incompatibilities. But we can also create debt ourselves, by taking shortcuts in how we code, or simply by writing code one way that we eventually learn a better way to produce.

Jay makes a good point about this, noting that there can basically be good and bad debt, and the trick for you as the developer is to prioritize how you’ll resolve it, and have a plan in place that helps you determine what you’ll do about it when the time comes. If you’ve ever gotten caught needing to completely rewrite a tool because it has too many dependencies to just patch some versions, then you know what it’s like to not deal with that debt. Rewrites are costly and time consuming.

Run by the Femgineer site to check out the episode. They have both a YouTube video of it, and also a transcript available.

Thanks for listening to Real Time Overview, I’m Michael Fienen. If you want links to any of the stories in today’s episode, be sure to swing by our website at drunkenux.com, they’ll all be linked in the shownotes there. Stay tuned for a new episode of Real-Time Overview next week, and maybe keep your eyes open Monday, I have it on good authority a surprise is on the way. In the mean time, find us out on Facebook and Twitter at /drunkenux, and remember, always keep your personas close, and your users closer.