Tech Stacks, Frameworks, Being Creative, and Being Real, with Tim Holman

By M. David Green , Tim Evko
We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now

Tim Holman on the Versioning Show

In this episode of the Versioning Show, David and Tim are joined by Tim Holman, a web experimenter and member of the CodePen team. They discuss the obsession with technology stacks, finding time to be creative and experimental, dealing with a short attention span, the pressure to keep putting things out there, supporting and encouraging beginners, being honest with yourself, finishing what you start, digging into frameworks and how they work, Good Tim and Evil Tim, and frogging the console.

Show Notes

Conversation Highlights

So I started doing small projects. I started basically deconstructing what they had built and looking at the code and remixing it. After a while, I just got on a roll with it and was making more and more things.


Some of my bigger projects I really try to break into pieces. Again, it’s like I’m in a sense fighting against myself because I’ll get bored of something very quickly and want to move on. I like to break out the projects that I’m doing into really, really, really small pieces and say, “Oh, I’ll build this menu very quickly, or I’ll even just do the HTML part and then I’ll go out.”


And of course, you can be excited by technology. It’s just I don’t get that excitement at all. I’m more interested in what we’re doing and where we’re going with that.


I’d like to see that extend into blogging a little bit. I think people maybe just feel a little bit overly critical when they look at their writing, or have trouble finding out where to start.


I’ve had a really wide variety of responses to a lot of the things I’ve made. I’ve had people basically delete all the code, and send in a pull request to be like, “This shouldn’t even exist” … which is a bit cruel.


never am I going to sit there and argue with you about any type of technology and stack. Never am I going to really judge a job based on what technology they’re doing, what technology they’re using, when I can look at it as what we’re making here and what we’re trying to achieve with that.


I do a bunch of talks at some coding boot camps and things like that, which I thoroughly enjoy. I never really turn that down, because I’m super happy to go there and speak to people who are just beginning to learn to code. They haven’t even really learned to learn yet, which is an interesting important part of development.


I always get a lot of nice emails back saying, “Oh, I was super insecure at this time. I was trying to figure out how to express myself with this platform and feel good about what I’m making.” The journey towards becoming a competent developer kind of goes through a lot of turmoil, I guess.


When you’re at the start of a journey and you can see like, “Oh, I understand HTML, and I understand CSS, and I understand JavaScript, but why can’t I make my website great like these other websites?” That gap needs a lot of bridging. I got there in the end. And that’s what I try to set out to do most.


There was definitely like a dark period, I would say, of framework-centric thought. I actually feel like people are moving out of that now, and realizing that again it’s the actual things that you make, not the way that you make it, that ultimately counts in the end of the day.

Tim Holman on the Versioning Show

Transcript

Tim Evko:

Hey, what’s up everybody. This is Tim Evko …

David:

… and this is M. David Green …

Tim Evko:

… and you’re listening to episode number 24 of the Versioning podcast.

David:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today, and planning where it’s headed in the next version.

Tim Evko:

Today, we’re talking with Tim Holman, who does a lot of cool and interesting things. He’s a fellow podcaster. He is on the CodePen team and he makes a lot of — I don’t know how to put it — ridiculous web side projects. We’re going to talk with him about all of those different things. So let’s go ahead and get this version started.


The Versioning Show is brought to you by Squarespace. Squarespace helps creative people stand out. With an all-in-one platform that lets you create a beautiful website without worrying about limitations, designer templates, and a simple interface, Squarespace is the best way to make your next move.

With Squarespace, you can run much more than a portfolio site. You can run your online store on Squarespace, with detailed analytics, domain registration, G Suite integration, and tools that help you scale your business.

Squarespace have a special offer for listeners of the Versioning Show. Try out their service for free. Then, when you decide to subscribe, use the offer code SitePoint to get 10% off your first website or domains purchase.

Go to SitePoint.com/squarespace to get started.


Tim Evko:

Tim, thanks for joining us. How are you doing today?

Tim Holman:

Good. Wow! That was a very professional introduction.

David:

Professional is what we do around here.

Tim Holman:

Of course. Yeah I’m doing great.

David:

Fantastic!

Tim Holman:

Just hanging around ready to chat.

David:

Well, great. In that case, let’s get the chat started. I’ve got a question for you. We like to start our Versioning Show with a philosophical question about versions. Our philosophical question for you is: In your current career, what version are you, and why?

Tim Holman:

Wow, that’s a big question right off the bat. I don’t know if I would want to put a number on it. I feel like so much development is a few steps forward and a few steps back at all times. The technology changes. Some things become obsolete. It’s not like your building — at least this is how I feel — I’m not really building a tower that I stand upon and get higher and higher. I feel like the ground is constantly moving under you. So, one, or zero, I guess. I never see somebody that talks about building their computer when they’re one year old or anything like that and think, “Oh this person is going to be a great developer.” I’m interested in what’s happening at the time. I don’t know. I’ll stick with zero. That’s different.

David:

Version zero. There’s a lot of room to grow from there.

Tim Holman:

Yeah, I guess so. Better than negative one.

David:

My other Tim told me, and mentioned earlier in the show, you’ve been doing a lot of really weird stuff online. You’ve been sharing it out. I’m curious, what got you started down that path?

Tim Holman:

That’s an interesting question. When I started doing development, there were a few people that were very big and inspiring to me. Hakim is one (his website’s hakim.se). And Justin, who was my housemate for a while (his website is soulwire.co.uk). And there’s a bunch of others. On their websites, they had these small web experiments. The more interesting thing was that they went back for a really long time. I could see where they started their journey and what they were making when they started their journey. And I basically wanted to imitate that.

So I started doing small projects. I started basically deconstructing what they had built and looking at the code and remixing it. After a while, I just got on a roll with it and was making more and more things. I’d share them out and get some attention. Some things I make get absolutely no attention. Now I get this weird twinge of anxiety if I haven’t released something or made something in a while. It’s like I was saying with that version zero, you’re constantly going down and you’re constantly pulling yourself up at the same time with new things.

David [4:20]:

Do you have a release schedule for these things that you put out?

Tim Holman:

This year I created a mailing list. You can find it on my website I guess. It’s just tholman.com. It’s called Tims Log. Nothing really special, but I decided that I wanted to start documenting each week what I’ve made and what I’ve got out there. That has helped me a little bit to push a schedule onto myself. But, then, at times it doesn’t really work out either. You’re working on a project that goes for a few weeks, then you’re only going to be able to release something at the end of that second week or third week.

So, I have a lot of little things that are going on as well. I have a website. It’s an open-source blog, inspiring.online. In that, I try to get a post on it every single day of something that I’ve seen, a website that I’ve seen or something like that and just share it out there. It’s slowly gaining popularity. It’s interesting to see something that you’ve spent a lot of time in be it like a slow, difficult gain, and then some things that you spend one minute on (which is something that I do a lot as well) that go insanely popular really, really quickly.

I actually found that I have a really short attention span. Fitting the work that I do into that attention span has been really beneficial. If I say, “Oh we’re going to do this podcast in 30 minutes,” and I have 30 minutes to make something right now, then that’s the kind of thing that I’ll make. And of course, in 30 minutes you can’t really do a whole lot of work, but you can make some pretty weird small stuff.

Tim Evko:

That leads me to my next question. I’m curious. David and I in previous episodes have been talking about contributing and just releasing things in open source and writing and blogging and stuff. How do you find the time to get all this stuff in there?

Tim Holman:

That’s it. It’s like the podcast that I’m doing is using an app called Bumpers, and they only last about three or four minutes. It’s random topics or random interesting things — that I found at Wikipedia article about — and I try to summarize that in a little bite-size piece. Apart from the research — which maybe takes 30 minutes or so, just to check all the sources and what not — recording that takes five minutes. There’s been a lot of times where I’ve been like, “Oh I’m going to go out tonight but I have five minutes. Let me just quickly do this and get it wrapped up.”

Some of my bigger projects I really try to break into pieces. Again, it’s like I’m in a sense fighting against myself because I’ll get bored of something very quickly and want to move on. I like to break out the projects that I’m doing into really, really, really small pieces and say, “Oh, I’ll build this menu very quickly, or I’ll even just do the HTML part and then I’ll go out.”

So I juggle a lot, which of course isn’t everybody’s style, but then I also have a lot of conviction towards finishing what I start, which is super important. I don’t know how many domains I have — maybe 10 or 12, or something like that — and every single one of those has what I bought the domain for on the domain, which I’m kind of proud of. I feel like not many people are like that.

Tim Evko:

I’m very impressed. I can’t tell you how many domains I have, because I can’t count that high. I can’t tell you how few of them actually have the content that I intended them for.

Tim Holman:

Yeah. I actually started buying the domains as a way to trick myself into getting things done. What’s the saying? The first 80% of the project takes just as long as the second 80% or something like that. [Chuckling] Once I get to that first 80% where you’ve kind of solved more of the difficult parts of the problem … As developers and problem solvers, I feel like everybody has that situation where they set out and have done what they needed to do, and that’s usually when I’ll buy a domain and be like, well, now I’ve just put — it’s not even much — $10, $20 into this, I should finish it, because I have a half-finished version of something. That thing represents me in a sense.

Tim Evko [8:27]:

Do you have a favorite finished or non-finished project that you’ve released or been working on lately?

Tim Holman:

That’s a good question. I’ve been enjoying these little podcast things, even though they have barely any audience at all. I have things that I’m particularly proud of: aquatilis.tv is a beautiful website that I built with my friend Tobias. Some things I made a redesign of those Fork me on GitHub corners — just an SVG of the Octocat, and it kind of waves when you hover it. That’s a very small, light project, but I see it a lot online. That of course makes me particularly proud. But, I don’t know … I’m always more attached to the thing that I’m working on at the time. Once it’s finished, I’m less in love with it I guess.

David:

It sounds like you’re good at working in small chunks. That’s something that a lot of developers find difficult. I’m curious if there are any particular techniques or processes you apply to the way that you work that allows you to break things up in that way.

Tim Holman:

Yeah … I think a big part of it was being honest with myself. I think you don’t really find that everywhere — where somebody will admit to being a little bit half assed and a little bit lazy when they’re trying to do something, whereas I’m very open and acknowledging about that of myself. When I break things out into lists or something, I have an app — Todoist I think it’s called … just a regular todo list app, which of course everybody tries and bounces around a lot.

When I write things out, I try to be very specific about the task at hand. It’s not go and get groceries. It’s like go to the shop and get apples and cheese. It’s like write the documentation about this particular feature — things like that.

I do also experiment with a lot of different ways of doing things like that. I wrote a library recently. It’s called console.frog. Instead of logging a regular log into your JavaScript console or your dev console, it logs a frog with the words. And in that instance, I wrote the documentation first. It’s like university teaches you to do that, and that’s the first time I ever really done it in practice. I don’t know. I didn’t enjoy it as much, but it was nice to play around and try those different methods of doing things.

David:

That’s interesting. Did you actually train at university? Do you study toward what you’re working on?

Tim Holman:

No, not at all. Like so many, I did go to university and I studied video game development. I actually take any opportunity to insult my university. I don’t have so much pride about it. They kind of got a lot of high school kids that, “I want to make video games. It’s going to be great. It’s going to be fun.” Really it was just a rejiggered computer science degree. What actually happened, which was very fortunate for me, is the financial crash happened in the States, and all of the video game companies in the city that I was living in (Brisbane) basically evaporated over a month. I had the good sense to be aware that I wouldn’t be able to work in that industry, and I pivoted towards web. Then I fell of course deeply in love with it and the community. So, that’s good. I was lucky.

Tim Evko:

Speaking about the community, we’ve met at CodePen talks and things like that. What are some of the things that you like to do in the community in terms of either open source or conferences or things like that?

Tim Holman [11:52]:

It’s interesting. When I go to conferences — and I feel like I could throw myself under the bus here — and go to meetups and things like that, I really try to look at how I fit into them. And I always have a great time, and we have great conversations. I feel like I learn a lot every single time, but something about me is that I have not really, really big opinions about a lot of tech. It’s like a pet peeve interview question of mine, actually, where someone will say, “What technology excites you at the moment?” And of course, you can be excited by technology. It’s just I don’t get that excitement at all. I’m more interested in what we’re doing and where we’re going with that.

That leads me into the big community focus, especially with something like CodePen. I’m not really worried about the stack that we’re doing. I feel competent enough that I’ll be able to pick something up, and I understand that some things have bigger strength than others, but never am I going to sit there and argue with you about any type of technology and stack. Never am I going to really judge a job based on what technology they’re doing, what technology they’re using, when I can look at it as what we’re making here and what we’re trying to achieve with that.

You mentioned before that it’s hard to find time and focus to do a lot of writing and things. I want to do with CodePen some things that really improve that. Of course we have blogging on there, and it’s just an interesting comparison. People make a lot of pens. You make pens on CodePen. I make a bunch of stuff. So many people kind of make a lot of things, and in a sense you feel like you do have time for that, because it is almost like a nibble on the edge of something bigger, and it’s like I can make a loader, or I can make this particular animation, or I can make this form look really nice.

I’d like to see that extend into blogging a little bit. I think people maybe just feel a little bit overly critical when they look at their writing, or have trouble finding out where to start. Of course, the tech community is also hypercritical, so you’ll see people pop up and criticize things. Those are all things that I’m interested in working on and building that community aspect.

David:

It’s a challenging thing as you said — getting yourself out there and putting your words and your examples and your code in front of a hypercritical and very focused audience like this. What motivates you to do that, and what keeps you going on it?

Tim Holman:

It’s funny to say. I’ve had a really wide variety of responses to a lot of the things I’ve made. I’ve had people basically delete all the code, and send in a pull request to be like, “This shouldn’t even exist” … which is a bit cruel. I made (it was very popular, actually) a library Elevator.js, that you would press the button and it would scroll you to the top of the page with a nice slow scrolling, but it would also play elevator music. It’s crazy to think that such a small library would be so popular. It kind of ended up on Hacker News, which is probably not the right place for it to belong. Even in that, there’s a lot of people being very critical about the way that it scrolls or the noise playing and things like that. It’s like jarring. Of course it was a joke, completely. It has that whole joke project. I think it ended up on the Google I/O website which was a funny treat.

David:

To be fair, you knew that that was going to upset a lot of people.

Tim Holman:

Yeah to be fair. But even in that, off the top of your head, I feel like a lot of people could scaffold out a library that will scroll to the top of the page. But when you actually build things like this, you find, “Oh, I have to do the easing algorithm to make the scroll nice. I have to do that on a request animation frame because I want it to be smooth, and performant, and I wanted to run over this time. So we’re using this equation to do this. If they close the tab, I want to scroll to the top.”

There’s so many little things that you don’t think about. Even with the project like that, when you finish it and you get it out, you realize, “Oh, I’ve written 200 lines to scroll somebody to the top of the page, and play some music, and to cover all those bases.” You learn always from everything you’re getting out there I like this. That’s something that I try to preach a lot. It’s similar at conferences. I go to a conference and I’ll be speaking. Of course, there’s a lot of people saying, “Here’s the new technology. This is a good way to use it.” I enjoy those talks a lot, but when I go up there, I really just try to show what it’s like to play around and explore with code — kind of discover things as you go. The project that you end with is never really the project that you set out to create unless you’re very, very rigid or have a good project manager.

David [16:48]:

That’s why we don’t write documentation first; that way nobody knows.

Tim Holman:

[Chuckles] Of course. I do a bunch of talks at some coding boot camps and things like that, which I thoroughly enjoy. I never really turn that down, because I’m super happy to go there and speak to people who are just beginning to learn to code. They haven’t even really learned to learn yet, which is an interesting important part of development. When I go there, you kind of … I don’t know if you remember so well when you started to learn development, but you find a lot of people that are really overwhelmed at these things. Of course, that’s kind of a part of learning — that you do something, and you’re not fully sure how you did it, but then in a week you look back and you’ll be like, “Oh, I know exactly how I did that.”

I find a lot of these really fresh faces, and I try to walk them through the last five years of things that I’ve made. That starts off with a really basic, 15-line canvas particle effect, or something, that I basically read a tutorial and created. It explores through like the arty that I’ve made, and then some of the more design-oriented projects to things like Aquatilis that are really nice and can win awards to the weird creations that I’m making now. I always get a lot of nice emails back saying, “Oh, I was super insecure at this time. I was trying to figure out how to express myself with this platform and feel good about what I’m making.” The journey towards becoming a competent developer kind of goes through a lot of turmoil, I guess.

Tim Evko:

You mentioned talking with and giving talks to new developers in boot camps. Do you see a lot of the same mistakes being made, or do you have a general piece of advice that you give to people who are just getting started in this industry?

Tim Holman:

Yeah. I think the big takeaway when I talk to them — and I kind of hover around afterwards and answer a lot of individual questions — is to not really feel so threatened. Web development is difficult because I guess it’s similar to painting in a sense, or I’ll use this comparison in this instance: you can make something and you can know how to make something; you could know how to build a library that will scroll you to the top of the page, and you can build it; but when you look at some of the things that other people are making, it seems very threatening.

When you’re at the start of a journey and you can see like, “Oh, I understand HTML, and I understand CSS, and I understand JavaScript, but why can’t I make my website great like these other websites?” That gap needs a lot of bridging. I got there in the end. And that’s what I try to set out to do most. At conferences, it’s very similar. When I show people that I was at their exact level and then show them all the individual steps over — not even that long — three or four years, it just gives you such as a nice big pretty picture.

Tim Evko:

Earlier, you mentioned Hacker News and the fact that people can be overly critical in this industry. Are there other things that you dislike about the industry? If you had one thing that you could say, “Hey, web in 2017, let’s improve on this,” what would this be?

Tim Holman [20:02]:

It’s a dangerous question, because it feeds straight into my desire to be agnostic about most things. I often don’t lash out online, and I try to keep things to myself or to a couple of friends when I want to be frustrated about something. There was the big satirical article that came out last year that was talking about what it feels like to learn JavaScript. Of course, it went over all the different, like, Webpack and all these modules for bundling. It went through this brutal chain of events that … I understand that it was satirical. I understand that, I guess, the hypothetical mentor in this situation was the worst possible mentor who basically just said, “No, you’re doing it wrong. Here’s a more complex way. No you’re doing it wrong, here’s a better way,“ the whole time.

A lot of people really bit into this, and I feel like there was a lot of sharing of that in a really non satirical, damaging way. And when I tweeted out about it, like, “Uh, I hate this stuff. Why are we all sharing it? Why are so many that I respect really jumping on this bandwagon?” Then seeing a lot of people who I work with at previous jobs who were back-end engineers, or a different kind of area of expertise, actually completely say, “This is what it’s like.” It just hurt me a lot to see that damaging spread. I actually feel a lot of people have bitten onto this now, and said, “Oh, let’s not insult CSS every time we bring it up. Let’s not rag on other people’s languages.” It’s still a long way to go.

David:

Absolutely. I’m curious, though, turning that the other way. What are you seeing about the web these days that brings out your optimism in the community and what we’re going toward?

Tim Holman:

That’s a much nicer question. Thanks Tim!

[Laughter]

Tim Evko:

Just doing my job.

David:

We are not in competition here.

[Laughter]

Tim Holman:

First of all, working at CodePen is a complete delight in this sense. I wake up most mornings, and we’ll have a coffee and I’ll just go through what people have been making and creating over the past night, and see what I can feature. I do that every single day. It’s such a bright beautiful way to start the day — by seeing how people are using their creativity and how people are learning from others and expanding things like that.

I’ve been around not that long, but definitely enough to see almost I would call them generations of people come in. I would see people just starting to create things on CodePen. I was super quick to that, because I was already in that scene, but I’ve definitely see people start to create things, and then get better, and then get better, and then I see these people at conferences. I can meet them and talk to them.

Then I can see them become advocates for particular technology and become … I feel like a lot of my friends now have become evangelists for companies. That kind of like generational stepping is something that I completely enjoy and adore. Everybody is getting a lot better at helping others up. Of course, it’s that whole standing on the shoulders giants. We can have all these websites and deconstruct everybody’s code and see where we’re going with it. I think people are getting a little bit more focused again.

There was definitely like a dark period, I would say, of framework-centric thought. I actually feel like people are moving out of that now, and realizing that again it’s the actual things that you make, not the way that you make it, that ultimately counts in the end of the day. Yeah, I don’t know if that even answers the question. That’s the joy that I’m getting from the community especially.

Tim Evko [24:00]:

On that note, thank you so much for joining us today. How can people find out more about you, follow you on Twitter, listen to your podcasts.

Tim Holman:

Yes. My website is tholman.com. That has basically everything that I’ve made on it, forever, including my Twitter, which is twholman. That’s the main one. Of course CodePen. I’m on there constantly. If you’re making something, or if you’re new, send me a tweet. I’d love to see what you got. Thank you.

David:

Fantastic! Thank you so much for joining us.

Tim Holman:

Cheers man!

[Musical interlude]

David:

What a great guy to chat with.

Tim Evko:

Yeah, seriously, I feel like every time I chat with Tim I come away learning the same lesson for me: I’m very opinionated about technology, and other Tim is not. I feel like it’s a good thing, and it’s a lesson that I keep trying to learn — that I should be way less dogmatic about the technologies that I’m using. That’s a difficulty for me. We can get real here. That’s something that’s difficult for me to do, because we’ve spoken at length about it before, David. I look at frameworks and practices and tools, and I have all these opinions. Like, “Oh we’re doing too much of this. This is way too complicated. This is why everybody feels overwhelmed.“ But, at the end of the day, you pick and choose what works for you and life goes on.

David:

So this is like I’m speaking with Good Tim and Evil Tim — like the parallel universe Tim. You’re the one with the Van Dyke, and he’s the one with the clean-shaven face.

Tim Evko:

I don’t often get to be Evil Tim, so I have to relish it when I can.

David:

I hear what you’re saying, though, and I think that’s something that’s come up a lot in the conversations that we’ve had with a few people. The sense of, are you learning the framework or are you learning the language? One of the things that I loved about the way that he talked about projects is the idea that you go into a project because you’re enthusiastic about what the company is trying to do or what the project is there for. Even the most ridiculous projects that he’s been working on, he gets enthusiastic about the project itself. Then it sounds like he goes and find whichever technology he needs to learn in order to make it happen, and he makes it happen even if he has to spend 200 lines writing the code to scroll somebody up to the top of the page effectively.

Tim Evko:

Yeah. I was actually thinking about this earlier today, in that one of the things I enjoy most about being a developer is that I get to actually contribute to the end product. It’s not just someone gives me a design and says, “Make this into code now.” I get to talk about, “All right, how should we word this thing here? How will the user feel if we give them this option over that one?” The times I enjoy my job most is when I’m contributing to an idea, not when I’m looking at a strategy for implementation.

David:

It’s interesting. I have to say I’m mixed about that. I do tend to get in love with technologies, and I’ll spend a lot of time learning something that, honestly, if I even think about it and I go back to the different technologies I’ve learned over the years, there are a lot of technologies that I’ve spent time diving into and learning and getting enthusiastic about and then never applying, and certainly never applying to their fullest extent.

There’s a certain passion that comes up in me when it comes to learning technologies, too. I enjoy figuring out how a new framework puts things together and getting into the mind of the developer who put it together and seeing, why did that person make those choices? Why am I being recommended to do things this way rather than that way? Sometimes that in and of itself can be fun, but it’s not productive in the traditional sense, in that I’m not creating things and putting things out there. I’m just enjoying myself.

Tim Evko:

That is true. There is definitely something to be said for looking into how the tools that you use work. I think you learn the most when you start to do things like that. For example, at my company right now we are using React and Webpack and Redux to build an application, which I’m pretty sure goes for every other developer out there.

David:

Let’s see. It’s January in 2017, so that’s probably true.

Tim Evko [27:52]:

Right. I have not yet had the chance to look into and React internals and figure out how everything works. I understand the concepts, and the methods, and what the general idea is, but I will probably learn the most about this specific framework the minute I really get into seeing how it’s been put together. That’s where you learn design patterns, and different optimization tricks, and techniques, and why this has this name instead of that name. You’re looking at the efforts of hundreds of people to make an excellent framework. How can you not learn a whole bunch from doing that?

David:

Absolutely. I think the first time that I really did that in earnest was when I tried to dig into the code behind jQuery, which John Resig just completely blew me away with some of the stuff that he was doing in there. Then over the years I remember trying to reconstruct Underscore, and then going through how they build all of their different methods.

It can be really fascinating to try to figure those things out. You learn things about your own code and your own approaches to coding that it kind of turns you and your head.

You think, “This person is doing this thing I don’t understand. I don’t understand why they’re framing this thing this way. I’ve lost track of what the code is trying to accomplish here.” Then you get this lightbulb moment when you realize, “Oh, there’s a reason this function is being put here and why this is returning what it’s returning.” That’s a practical thing to apply in the way that I work.

Tim Evko:

So, as a sidebar, I’m a little bit curious how you get started into breaking down a large library or framework to see how it works, because that can be an intimidating thing. React, for example: there’s like 90 folders you have to click through just to find some code. Do you have any suggestions for people who are interested in doing that but don’t really know how to go about it?

David:

I would start with a framework that is well documented, that’s designed to be broken down. It’s not worth trying to decompile something that’s either intentionally obfuscated or simply not well documented by the developers. If something is not well documented, that’s a red flag right there. It’s not the place you want to be going to learn coding techniques.

Tim Evko:

Do you mean documentation in terms of comments inside of the code, or outside of the code documentation?

David:

Actually, a combination of both. There are frameworks out there which you go through the documentation for the code and you can just toggle out and see the code itself that was written to support this particular method so that you can learn how that method was written and understand how it works. That’s the sort of framework that is really interesting to dig into and find out more about.

Tim Evko:

Yeah, WordPress actually does that really, really well.

David:

Yeah. My number one tip around that would be that’s the place to start. Fiddle with code that the developer has put out there with the intention that you should be able to read it and understand it and learn from it. The developers who are working that way are probably the ones who are writing the code that’s going to be the most useful in your projects, because it’s going to be the one that you’ll understand best.

Tim Evko:

Well, I’ve certainly learned something. I’m going to take those tips and dive into React with them. That’s something I should write about, but I just don’t have time right now. Speaking about time, I really like how Tim talks about splitting things up into small chunks like that. When I look at projects that I’ve worked on, it’s not small chunks. Usually my method is let me make a demo of something working on CodePen. Once I have a hashed out idea, I’ll buy the domain and write the code and just sprint through to get it done. I’m building a stupid battle ship game thing with just not professional instructions and it’s hilarious. I’ve been attacking this as just one giant mountain to climb over instead of several small pebbles to pick up.

David:

That can be very intimidating. I get frozen when I’m confronted by a project that’s so big that I can’t see the little tiny pieces. What Tim said about breaking things up, it strikes me as very familiar from testable modular code development. If you think about your code as a set of individual, independent modules that may be reused, that each needs to be documented and each needs to do one thing, and ideally each function returns one return value and it’s very consistent.

If you approach your projects that same way and you think, “Okay, what are the components here? How do you break things down into individual components? This is not just React talking. This is an approach to development in general. If you think about your code that way it can make it approachable and it can also make it modular enough that you can work on a small piece of it, get that small piece done, and then put it aside so that when you come back to it, you’re ready to move on to the next step.

Tim Evko [32:22]:

Learning design patterns definitely helps with that. Actually, the first time I learned anything about design patterns I was reading a blog post of Chris Coyier on CSS-Tricks, where he talked the module pattern and how you could not have one main.js spaghetti thing with just all of the code that you need inside of it but you can break things out into objects that have their own methods as functions. That kind of just turned my world over, because I was suddenly able to write code in such a way that I could write small independent reusable functions that go where they need to and are interchangeable — and a lot easier to test, I might add.

David:

I have to admit, I have a trigger point on the question of design patterns, because I learned them back when I was doing Java, and I’m never doing Java again. Don’t approach me with Java projects. Stop emailing me about Java projects. I do not want to do Java again. I learned about design patterns … I think it was Kathy Sierra book, Head First Design Patterns, which was an amazing introduction to how design patterns worked. If I can get myself past associating them with that particular language, I can certainly support what you’re saying about that.

Tim Evko:

Outside of JavaScript, one of the design patterns that I’ve really been into lately is — and I’m sorry that I keep saying it, David; I feel like I could see you sweating [laughter]— it’s ITCSS by Harry Roberts, which stands for Inverted Triangle CSS. It’s basically a way of organizing your Sass file structure so that you have the least amount of specificity. At the top of the inverted triangle you have functions that don’t do anything. They don’t output any specificity. Then you get on to things like color variables. From there you go down to resets, and then raw elements, and then classes. At the very last you have overrides, where you add important stuff. I’ve been using this, and I’ve started to notice that I don’t have CSS conflicts anymore. It’s miraculous, really.

David:

One of the things that really amazes me, there were a lot of really hard core programmers who, as we’ve mentioned before, had to dis CSS. But it is remarkable what people who work in CSS have to do to structure their code effectively, and the things that they’ve contributed to the community in general about how you can approach structuring and modularizing and componentizing your code. That’s just another example. This came from an area where it used to be relegated to the people at the very end of the chain, who would just make things pretty, and now CSS is elemental. It’s fundamental to the way we’re designing and developing our code. I love the way that that’s turned around.

Tim Evko:

I almost feel like — and this would probably be a very hostile and maybe it’s a terrible idea, so tell me please — but I almost feel like we should chat with someone who really dislikes CSS, because I love it. I love it because I started first learning HTML. Then I learned CSS. And then I learned programing. I learned how to write JavaScript and a little bit of PHP and the fundamentals around that. I feel like because I entered into the landscape that way, CSS makes sense to me. But if you come from a software engineering background and then you pick up something like CSS, I mean it’s barely a language. It’s this declarative thing but it cascades and I can understand how coming from a software engineer perspective into something like CSS can be really strange and awkward.

David [35:56]:

I like that challenge. I think we should definitely talk to somebody, perhaps somebody with a back-end focus, maybe some DevOps people. We haven’t had any DevOps people on the show I don’t think. It’s revolutionizing the way that things are happening in development these days. But yeah, absolutely, we should get somebody like that on the show.

Tim Evko:

We could even go as far as talking to someone who advocates for writing CSS in JavaScript and handling styles that way, instead of writing — I hate that I have to say this — instead of taking the traditional approach, which is to actually use a style sheet, because that’s something that still strikes me as weird, and I’m unsure of why someone would do it. I haven’t done it, so all I know is that aside from the tool chain — I don’t want to say issues — aside from the tool chain barrier, because you need a lot of specific and complex tool chains or tools to enable CSS and JavaScript. Aside from that, I don’t really understand why someone would do it, and for that reason I want to learn the mindset of someone who advocates for that way to build websites.

David:

I think that there’s a lot to learn from it. Going from web components that are completely self-contained with their CSS, to componentized elements inside of React. The need to contain their inline CSS in order to function effectively; what parts stay inline, what parts need to be universal … it’s a complex science these days. It’s not as easy as saying, 100% it needs to be inherited, or 100% it needs to be inline.

But yes, we should definitely get more experts on the show to talk about these things. Let’s get the audience involved as well. Are there people out there you want to hear from who are really working on this and really advocating for the position that you have that might be different from what the mainstream is thinking? Give us a tweet. Let us know. We’re @VersioningShow.

Tim Evko:

Yes, we do keep a very active Twitter account. So, yeah, please do let us know. On that note as well, I think there’s still a large part of the industry that really despises seeing something like JSX syntax, which is basically a part of React that is a preprocessor. It enables writing HTML inside of a JavaScript file. From what I’ve seen, every once in a while there is an article or a tweet that resurfaces of someone who’s just livid — and I mean like clenching the left hand fist and typing with one hand angry about this principle. I was one of those people (I’m not going to lie). But I started to understand that if you are writing a JavaScript-driven web application wherein you are rendering dynamic content, there is no separation of concerns between HTML and JavaScript. Those two things suddenly become one thing when you are doing that.

David:

And similarly, if you’re building web components, that CSS becomes part of that as well.

Tim Evko:

Oh man! I’m not ready for this sort of …

David:

[Laughs] Well, we’re back to Good Tim, Evil Tim. We’ve got our Good Tim telling us about focusing on what we’re trying to accomplish, and our evil Tim being attached to our technologies.

Tim Evko:

I’m not ready for a light bulb moments, okay? This is just supposed to be an interview. Anyways, Tim would be very upset right now if he heard us talking in this way. Which reminds us, we should focus as a community, as an industry as a whole we should so much more focus on the types of things that we’re building, instead of getting lost in the minute and tedious details about building — which are important, but at the same time when you switch your focus over to what is this goal that I want to accomplish, man that can really be liberating.

David:

Well, kumbaya. We’ll get there.

Tim Evko:

Yes we will, if we press on.

[Musical interlude]

Tim Evko:

Well, thank you so much for listening everybody. We always enjoy getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @VersioningShow — and give us a rating on iTunes and let us know how we’re doing.

Tim Evko:

We’ll see you next time, and we hope you enjoyed this version.

The most important and interesting stories in tech. Straight to your inbox, daily. Get Versioning.
We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now
Login or Create Account to Comment
Login Create Account