CSS Preprocessors and Font-end Development, with Guy Routledge

Share this article

Versioning Show, with Guy Routledge

Versioning Show, with Guy Routledge

In this episode of the Versioning Show, David and Tim are joined by Guy Routledge, a front-end developer, teacher, and presenter of SitePoint’s AtoZ CSS video series. They discuss switching from Sass to PostCSS, the complexity of front-end development, jumping into frameworks versus learning the basics, building the Taj Mahal with Lego, and the joys of #HolidayCode.


Show Notes

Conversation Highlights

I’ve always been quite a visual person. People in my family have been very visual. They’ve been to art school or what have you. I always kind of resonated with that kind of stuff, but I always felt so frustrated that I couldn’t get something looking the way that I wanted it to look.


as soon as you commit like pen to paper, you can’t undo. But when you get into the digital age, if you put the virtual paintbrush to the virtual canvas, if it starts looking like crap, then you can undo as many times as you need to get it back to where you need to start from again. I think that has been much more interesting for me.


I think when anybody is doing something that they genuinely enjoy, and kind of satisfies them and ticks all those boxes of being — you know, you get kind of that internal balance, and then you just do your best work — because you’re working towards something that you really, really enjoy.


I much prefer to do new projects, start new things, and kind of learn new stuff as I go. When I left there and went contracting, that was actually quite satisfying, because I got to work on a lot of new things from scratch. I was able to bring that experience of kind of building something with maintainability and performance in mind.


It’s kind of just been this constant journey and desire to find a good, solid system that works. The funny thing is, that is kind of not really attainable, because even when you do get something that you think is good and working and solid, you then realize, Oh, I could just improve it here. Or, I don’t need that thing anymore, because I don’t really use it. You’re constantly in this kind of evolution of improvement.


When I first started, it was all on-click in the HTML. Then everyone’s like, No, this is terrible. This is not separation of concerns. Blah, blah, blah. Then now we’ve come back to Angular and React. You know, the modern JavaScript frameworks, and they’re all about putting JavaScript in the HTML, or even putting HTML in the JavaScript. It’s funny how things go around.


I think the web is changing so fast, that I guess the stance that I take is, instead of learning the latest framework and jumping straight into that, and being able to make something kind of by trial and error and working it out, then it’s always best to start with the fundamentals and start with a good foundation. Even though I love Sass, and that’s what I write all my CSS in on almost a daily basis, I advocate starting with CSS and understanding the fundamental concepts of inline and block, and how to style typography so it is readable and accessible.


Since I’ve found my groove in tech, I’ve been able to completely turn that around and like 10x what I used to earn. If I can help anybody else kind of find their passion and find something that can open so many doors for them — if I can do that even just for one person, then that’s amazing to be able to play a part in.


Fortunately, the developer community — also the design community — is so open and friendly and everybody shares everything. It’s quite unbelievable. It’s like you go to a conference with developers and they’re all like, Here are the secrets. All of the secrets! Have them. Go and make amazing things.

Guy Routledge on the Versioning Show

Transcript

Tim:

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

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number 20 — the big 2-0 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:

Today we are talking with Guy Routledge, and we’re going to talk all about CSS expertise and education. Really exciting stuff. Let’s go ahead and get this version started.


David:

Guy, I’m really excited to meet you. Thanks for joining us today.

Guy:

Thanks for having me, guys. Really appreciate it. Thanks for adjusting your schedules for my unfortunate timezone.

David:

That’s okay. Tim is in New York, I’m in San Francisco, and our guests are from everywhere, so we’re used to being a little bit flexible.

Guy:

Yeah, that makes sense.

Tim:

Multinational.

Guy:

[Chuckles] Well, I’m joining you guys from London today. It’s dark and cold outside, but it’s nice and warm in my office, so happy to be here.

David:

Fantastic. This is the The Versioning Show, and one of the things that we like to do here — it’s about the philosophy of web development and design. So we like to start by asking our guests a philosophical question. Your philosophical question today is, In your current career, what version are you, and why?

Guy:

That’s a tough question, you know? I’m probably in something like version 5 or 6. If we count by started and failed businesses, or started and failed careers … well, failed is maybe not the right term … Yeah, maybe 5 or 6. Something like that. I’ve done a few things, but very much enjoying the tech side of stuff now. I feel like I’ve found my groove.

David:

It doesn’t sound like you started out in tech.

Guy:

I didn’t. Actually, funnily enough, I did, because people ask me this annoying question all the time. It’s like, Oh, so, you know, what do you do, and how did you start? It’s just like the worst thing, because nobody has a simple answer to that question. Funnily enough, now I am working in web development primarily. I actually wrote my first line of code in QBasic when I was about 11 or 12, or something like that. Then I wrote my first HTML page in 1997, I think possibly before CSS was even invented, or possibly before I knew that it was invented.

Then I went off and did all sorts of other things in between. Then, kind of in the last 2000s, around 2010/11, came back to tech again. I ended up working … well, I did a whole load of crazy stuff in between, but then ended up working professionally in web design and development, and kind of haven’t looked back since.

Tim:

That’s really great to hear, because I don’t think we talk about QBasic enough on this show. I was going to bring it up to David earlier.

Guy:

[Chuckles] Amazing, yeah. We make these kind of — I guess it was kind of like command line games, way, way back in the day. Like drawing shapes and stuff with code, and these decision tree games and stuff. If someone showed it to me now, I would have no idea what was going on, but I’d probably pick it up if I had to.

David:

It sounds like tech was an early love, and then it drew you back in.

Guy:

Yeah, I suppose so. I guess maybe a philosophical answer to that is, the thing that’s always worked really well for me is a combination, in almost equal measure, of creativity and science. That technical side of stuff, and then the really creative stuff. After school and university, the first thing I did was I was a camera man. I worked in the film industry for like five years. I even have an IMDB page, which is kind of a claim to fame, I suppose. I did all sorts of very interesting, sometimes somewhat dodgy independent films and stuff here in the UK.

That was a really interesting balance of the creativity of storytelling, and lighting and framing, composition. That kind of stuff. Then, the technical stuff of, you know, you’ve got a camera with all these buttons or you’ve got to work out things like the f-stops and the focal lengths, and all that kind of stuff of the lenses that you’re working with. It was great. I really enjoyed it, because it had that, it really satisfied that combination of the two sides. The problem with it was that it wasn’t very well paid. That became a bit of a sticking point, and I ended up going off to find the next thing.

David [4:04]:

It sounds like you were doing visual stuff right from the start.

Guy:

Yeah, I think so. I’ve always been quite a visual person. People in my family have been very visual. They’ve been to art school or what have you. I always kind of resonated with that kind of stuff, but I always felt so frustrated that I couldn’t get something looking the way that I wanted it to look. Back in the day, it was like working with paint on canvas, or pen and paper, or pencil or something like that. I would do artistic kind of stuff.

But the trouble with it, as soon as you commit like pen to paper, you can’t undo. But when you get into the digital age, if you put the virtual paintbrush to the virtual canvas, if it starts looking like crap, then you can undo as many times as you need to get it back to where you need to start from again. I think that has been much more interesting for me. Again, the visual side of design and development is something I did a little bit of, but I think I was better with the code.

Tim:

How would you say that your work in the visual artistic space in the past relates to what you’re currently doing today?

Guy:

Good question. I think it’s just given me a really good baseline for doing things to a very high level of detail. Something that I hear a lot from employers and especially from designers is, people don’t seem to get it. They don’t get the details. They don’t see the nuance. They don’t see, sometimes, the patterns in the systems. Obviously, this is not the case for everybody, but it’s something that I definitely hear a lot. Being able to kind of approach something with that creative eye, and with a maybe a slightly more understanding of things like balance and composition and that kind of thing, has been really useful.

Yeah, for whatever reason, it’s gone quite well. I think when anybody is doing something that they genuinely enjoy, and kind of satisfies them and ticks all those boxes of being — you know, you get kind of that internal balance, and then you just do your best work — because you’re working towards something that you really, really enjoy.

David:

Absolutely. It sounds to me like you’ve brought a lot of your design philosophy into what you’re doing as well.

Guy:

Quite possibly. Everything is complex. There’s no one person or no one subject area or whatever, which is purely black and white. Everything is so many different shades of gray and shades of complexity. If you’re fortunate enough to be able to, then you kind of find the combinations and the palette, if we’re going to continue with some kind of philosophical artistic discussion, that works best.

Tim:

For any of our listeners who aren’t familiar, what sort of things are you working on right now?

Guy:

I will endeavor to focus on the tech side of things, because I actually do a few other bits and pieces as well. Maybe we can talk about those later if you’re interested.

David:

Absolutely. Actually, it is interesting how the tech blends into the other parts of the work that you’re doing.

Guy:

Okay, sure. I’ll start with the tech stuff, and then maybe talk about the other bits and pieces as well. Currently, I’m working as a contract front-end developer, and have been for the last three or four years now. In that kind of work, I work with a lot of agencies here in London, and go in to do consulting type stuff, but also to go in and deliver projects for them.

Sometimes people come direct to me, and I help them with whatever they need help with — whether that be just advising them on how they can get started in their business, or how they can get from point A to point B, or point B to point C. Predominantly, it’s working with brands and building interactive websites. I do occasionally do some application-level stuff as well. Currently working on an Angular app. Yeah, kind of whatever is required is what we jump into.

Kind of on the side of that, a couple of years ago I was working on a side project which was an online teaching platform called AtoZ CSS. I just kind of had this idea one afternoon, and said, Hmm, CSS is kind of interesting, and kind of diverse and quite wide in specification. There’s all sorts of properties and values and sort of stuff. I wonder if there is one for every letter of the alphabet.

I kind of sat down one afternoon, and just made the list of A, B, C, D all the way to Z, and started trying to work out what property or value or concept might match with each of those. Then I turned it into a screencast series. It got picked up. It got seen around the place. People seem to enjoy it, and that’s actually led to me joining SitePoint as a channel editor. I’m now working with the SitePoint team to help other people contribute video for the HTML and CSS channel over there.

Yeah, quite a few bits and pieces going on. In the evenings and weekends, I teach in person as well. I’ve been teaching with General Assembly for the last three years or so. Pretty much exclusively front-end development. We do like a 10 week part time course. We do a JavaScript part time course. Then we do immersive courses across the full stack of JavaScript, a bit of Ruby, and all sorts of good stuff.

Tim [8:42]:

I want to talk about your education endeavors in a second, but before we do that, I’ve always found that agency work for me was a little bit challenging, because I’m someone who likes to invest in the long-term care of the projects that I release. Have you found that as in issue, or have you been able to overcome that? How do you really look at the long-term care and performance, and maintainability of the projects that you are working on for agencies?

Guy:

That’s an interesting question, because a lot of the stuff that I did to begin with — where I was full-time, at a single agency — they had retainer clients. They would bring somebody on. Sometimes they would pick up their existing site and just kind of tweak it and maintain it. Sometimes they would start from scratch. They were ongoing projects. For example, one of the big ones was a big cereal brand that we have here in the UK called Dorset Cereals. They produced a site for them back in the mid 2000s or something. (It was only recently completely redeveloped from the ground up.)

For about 10 years, it was an ongoing project where there were things being added, things being removed, things being cleaned up. Things being tweaked and monitored and all that kind of stuff. Even though it was an agency, there was an attention given to the long-term sustainability of a project. Which was quite an interesting angle.

The kind of flips side of that is that I really don’t find that kind of maintenance work very interesting. I much prefer to do new projects, start new things, and kind of learn new stuff as I go. When I left there and went contracting, that was actually quite satisfying, because I got to work on a lot of new things from scratch. I was able to bring that experience of kind of building something with maintainability and performance in mind.

David:

One of the nice things about being able to start new projects all the time, is that you’re constantly being exposed to whatever the latest technology is. I’m curious, how do you approach structuring a project these days?

Guy:

Structure and site architecture is one of the things I found really fascinating. I guess it was kind of getting into that nerdy end of planning and organization and logic and stuff. I pretty much only work with the front-end side of things, but one of the things I spent quite a lot of time working on was working out the best way to start a project. How best to structure the Sass. How best to structure the JavaScript modules. How best to run all the tasks and stuff like that.

This is something that has happened over a number of years, because when I first started I didn’t know about any of those things. It’s kind of just been this constant journey and desire to find a good, solid system that works. The funny thing is, that is kind of not really attainable, because even when you do get something that you think is good and working and solid, you then realize, Oh, I could just improve it here. Or, I don’t need that thing anymore, because I don’t really use it. You’re constantly in this kind of evolution of improvement. I think that’s important too, otherwise you end up getting stuck in the old ways and never progress.

Tim:

What have you come to for the current stack?

Guy:

What I’m using at the moment, I’m still favoring Sass. Although, we recently commissioned a series on PostCSS, which looked really interesting. It was one of those kind of things that, if you’ve got something that you feel is working really well for you, you don’t necessarily go looking for a solution. This thing came to me because we commissioned a short series of videos on SitePoint. It was like really interesting. I was thinking I want to get into this. It looks like it’s a bit more flexible and it can do some extra stuff, which is kind of cool.

David [12:18]:

Can you explain briefly what PostCSS means for our listeners?

Guy:

Yeah, sure. Sorry, I should have done that. PostCSS is like a JavaScript plugin. It’s a command line tool which allows you to transform your styles using JavaScript. A bit like the way Sass works, where it goes through a compiler. PostCSS will kind of pick up your standard CSS code. Not Sass, not SCSS, not Less. Standard CSS file name. It will pick it up. It will pass it into a node tree of all the different selectors, and properties, and values, and stuff. Then it can do stuff to them. It can manipulate them in some way, and then it spits out regular CSS again. It’s kind of like a two-way transformation.

Yeah, it kind of looked very interesting. The thing that is kind of conflicting me at the moment is I’m looking at it going, I’ve got a few projects on the go at the moment, and I’ve got a few systems that I’ve set in place for like boilerplate code, which I reuse all the time. I don’t know if I’ve got the energy to go back and change them all to just for the sake of experimenting. What I might try an do is find a standalone project where I can go and experiment with it as a one off, and see how it goes and see if it is something I want to transition to.

David:

These days, front-end code is becoming so much more complex. I remember the days when you used to just write a line of JavaScript, stick it in and you were done.

Guy:

Yeah, although things they go in circles. When I first started, it was all on-click in the HTML. Then everyone’s like, No, this is terrible. This is not separation of concerns. Blah, blah, blah. Then now we’ve come back to Angular and React. You know, the modern JavaScript frameworks, and they’re all about putting JavaScript in the HTML, or even putting HTML in the JavaScript. It’s funny how things go around.

Tim:

Speaking about some of the education that you do. I was a content or a curriculum advisor for General Assembly’s JavaScript course for a brief period of time, and I found that there’s something that sells in this industry, wherein you can get a lot of people to sign up for a course if you promise to teach them about the latest framework. Which is not necessarily something that I think is helpful for people who are actually looking to learn the most they can about web development. Have you found that there is, in the education space, a gap between what brings in the most students, versus what you think students should really be learning?

Guy:

I think there is certainly an imbalance between the kinds of things that people either think they should know, or want to know, and what they need to know. You’re absolutely right. There’s a lot of talk about the new hotness of whatever framework, be it a JavaScript app framework, or be it like a front-end framework — like Bootstrap or Foundation or something. It’s more often the case with people thinking they’ve heard of something, and someone said, Oh, this thing’s really cool. And without having done maybe a huge amount of research, they’ve just gone, Oh, this person that I know and trust, and like, and understand, and believe, says something’s pretty cool, so it must be pretty cool. If I have an opportunity to go and ask a question like, Oh, are we learning this?, or Are we learning that? then maybe it just comes out with too much thought.

I can’t really speak for the people who manage the curriculums and stuff at General Assembly. I think the web is changing so fast, that I guess the stance that I take is, instead of learning the latest framework and jumping straight into that, and being able to make something kind of by trial and error and working it out, then it’s always best to start with the fundamentals and start with a good foundation. Even though I love Sass, and that’s what I write all my CSS in on almost a daily basis, I advocate starting with CSS and understanding the fundamental concepts of inline and block, and how to style typography so it is readable and accessible. How to build up your layouts, starting with small things, moving on to things like float, inline-block. Then moving to positioning. Then all these other things. Just layering it on bit by bit.

David [16:17]:

Absolutely. If you don’t understand those things, it’s impossible to really make to take advantage of what Sass or the other frameworks. If you don’t understand Ruby, you can’t really take advantage of Rails. If you don’t understand JavaScript, you can’t really take advantage of Angular.

Guy:

Yeah, absolutely. I put myself in a situation once where I started a business. It was probably not the best decision given the team that we had, but I was like, I quite fancy learning Rails, so we’re going to do the MVP in Rails. I didn’t really know much Ruby, but I was able to throw something together in a week, a couple of weeks, a month — whatever it was. I was able to get an understanding of Rails through doing that. It wasn’t something that I really understood on the ground level. It was an interesting exercise, but it was doing it the wrong way.

Tim:

One of the things that helps me best in my career was the progression between learning more JavaScript syntax and how the language worked, to learning design patterns in software. I think that helps so much. It really is easy to reach for the latest framework, and you can probably get a lot done in that. Just learning the design patterns of software along with the fundamentals, syntax, basics, things like that, really helps you to get a better grasp of what it is that you’re working on, and common pitfalls, and where something might go wrong in the future.

Guy:

Yeah. One of the examples I’ve often given in the classroom is if I went to the shop and bought like a Lego set. Which was how to build a Death Star in Lego. You have all the pieces, and you have the instructions. You could probably build that just by following the bits and pieces along. Following all the pictures and whatever. That’s cool. You made a thing and it works and maybe it looks good. Maybe you show it off to your friends. Whatever. If then you kind of say right now, Get rid of all the instructions. Here is another set of bricks. Different colors, different shapes, different sizes, but there’s no instructions. Make the Taj Mahal out of Lego. You’d be like, I have no idea how to even start.

Understanding what the tools are, understanding what the building blocks are, allows you to then make whatever you need, through your own creativity rather than just blindly following along and going, Oh, step 1: put this here. Step 2: put this there.

David:

Absolutely. I think I’ve made the joke before, that if you want to build Basecamp, start with Rails. Knowing what a framework is good for, kind of implies what you’re going to be creating with it.

Guy:

Yeah, quite possibly.

David:

One of the things that interests me about your career is a lot of people get into tech, and they love developing the stuff, but you’ve actually made a point of going out there and teaching, and educating, and getting in touch with the community, and sharing your knowledge. I’m curious how that started for you.

Guy:

It’s a good question. It’s something that I don’t think I sought it out intentionally. I was working at an agency at the time, and I was their lead front-end developer. We had an intern come in for a short period of time. Couple of weeks or so. She was allocated to me as someone who can teach her a thing or two on a project that we were working on. I got her to help out with some fairly low-level stuff. Kind of watched. It was like we were pet programming together.

She was really good, and I was a bit surprised, because I had been told, Oh yeah, we got this intern coming in. She’s interested in code and wants to kind of see what it’s like to work in an agency and stuff. She was really genuinely good. I was chatting to her and I said, Where did you learn all this stuff, because it seems like you kind of know what you’re doing, and you could probably be paid to work here, rather than interning for free. She said, Oh, well, I went to General Assembly in New York. Yeah, I think it was in New York that she actually went. I said, Oh, what’s General Assembly? She said, Oh, well it’s this place where you go and learn about this stuff. It’s like bootcamp style where they take you for three months and it’s pretty intense every day for five, six days a week. Now I’ve come back to London and I’m actually assisting on one of the courses that they’re running here.

I said, Oh, that sounds pretty cool. Do you think they need any other front-end instructors? She said, Yeah, I’ll ask the question. Why not? About a week later I was having lunch with the producer of all the courses. The following week I think I was teaching my first lesson. It was just one of those things. You see an opportunity, you ask the right question. Yeah, the rest is history, as they say.

David [20:35]:

You’re teaching for General Assembly. You were writing that course that you released yourself and that’s now part of SitePoint. You’re running channels for SitePoint. It’s wonderful to be giving back to the community. Also getting back in the process, I imagine.

Guy:

Absolutely. There is something really satisfying about being able to help people. I think that’s where it comes from. It’s just having a genuine interest in a topic. I get this kind of huge sense of pride for my students when I see that similar kind of spark in them. They come in and they say, Oh, I was working till like 3:00 in the morning on my homework. It was really tough, but then I did it and it was amazing. It’s just so rewarding to hear somebody get excited about that kind of thing.

I guess the reason that really kind of brings it home for me is that, when I was doing my first thing out of university, I was trying to pursue this passion of making films and being this kind of creative technical person with the cameras and stuff. I was making no money, quite frankly. It was like, there was maybe a week’s work, and then a month off. Then a couple of days’ work, and then a month off.

Since I’ve found my groove in tech, I’ve been able to completely turn that around and like 10x what I used to earn. If I can help anybody else kind of find their passion and find something that can open so many doors for them — if I can do that even just for one person, then that’s amazing to be able to play a part in. I don’t even need to know if I played that part. It’s just if somebody else can reap the benefits themselves, well then that’s awesome.

David:

Where do you think people should get started if they wanted to get involved in the type of work that you’re doing? In terms of publishing information and sharing it out with people?

Guy:

I think the barrier to entry is pretty low. It’s something that you could just pick up a text editor. If you’re already writing code, then you already know what one of those is. You can just crack open a new tab, and just start writing down — even just start writing down topics that you’re interested in. Then from there, take one of those and start writing a blog post. Then before you know it, you’ve got something which is unique and interesting and valuable. You can post that anywhere online, or join a forum. Get a Medium account. Break it up into 140 character bits and post it on Twitter as a Twitter stream of consciousness.

The barrier to entry for actually putting stuff out there is really low these days. The issue is, that it’s really hard to get noticed, so it can be a bit demoralizing if you’re putting stuff out there and nobody sees it. But it depends what you’re doing it for. Are you doing it for yourself? Are you doing it to help other people? Everybody will have a different stance on why they’re doing something.

Fortunately, the developer community — also the design community — is so open and friendly and everybody shares everything. It’s quite unbelievable. It’s like you go to a conference with developers and they’re all like, Here are the secrets. All of the secrets! Have them. Go and make amazing things. You go to like a standard car salesman conference. I don’t know if they have those, but maybe they do. They’re like, We did this amazing thing. We made all this money, and I’m not telling you any of the secrets. Go and work it out yourself. I’m guessing, but I imagine that it’s maybe not as friendly and open as our industry. So yeah, embrace that. Embrace the fact that people love learning stuff and love sharing stuff. Just dive in.

Tim:

That is certainly sound advice, and if you are one of our listeners just getting started into this and are looking to learn more, just do exactly what Guy said. I don’t have anything to add to that. Guy, thank you so much for joining us today. How can people connect with you, find out more about what you do, and learn and attend your courses?

Guy [24:10]:

I’m kind of a bit dark online at the moment. I haven’t even opened my Twitter since about May last year. Normally I would say that was the easiest way to get ahold of me. Yeah, you can tweet me @guyroutledge. You can check out the stuff that we’ve got on SitePoint, and I think there is ways to connect with me on there if you want to — well if you just drop us an email. Drop us a comment on one of the posts, and we’ll find it and we will be able to start a conversation.

David:

Fantastic. Well I’m hoping a lot of those conversations get started as a result of this. Thank you so much for joining us today on The Versioning Show.


Well, you pronounced his name right. I was impressed by that.

Tim:

I did. I was very nervous that even though he told me how to pronounce it, I was still going to get it wrong.

David:

I’m sure he gets that all the time. It’s amazing the stuff that he’s publishing out there. Have you seen his AtoZ CSS thing?

Tim:

I have, and I’ ha’ve learned a few things. CSS is one of those things — I don’t know if I should call CSS a language, but I’m going to do it anyway. CSS is one of those languages that no matter how much you know, there are always so many different things you can continue to learn about it. One of the things I find interesting is with certain properties that take multiple values, like border, for example. A lot of people are like border: 1px red solid;, but I just learned recently you can just write border: solid red 1px;, and it just knows where to put all of those values in the right places.

I think his series definitely brings to light some of those lesser-known things about CSS. It’s always fun when you get something like that just to — it just helps you write better code at the end of the day.

David:

It’s sort of like the fun that you get when you’re browsing the stacks in a library. Or looking through a dictionary. Looking for random words that you might not know. It presents the information in a different way than you would expect. You’re exposed to all of these obscure little properties and things that you never would have thought about in CSS. Once you know that the opportunity is there, you learn about them and then you find a way to apply them because, of course, as soon as you learn about something, you realize immediately, Oh, I should have used that!

Tim:

Yeah, and that brings another point to mind. This is something that I touched on. In our industry, all the secrets are out in the open. I remember realizing that for the first time. I thought to myself, why? Why does everybody just give away everything they know? In regards to other industries where there are trade secrets is a literal thing. David, why do you think that’s a thing in our industry, and not a thing in others?

David:

Well, for one thing it’s very difficult to hide anything in this industry, because everything is out there on the web. It’s published. You can download somebody’s code. Well, at least for front-end, anyway. You can download somebody’s code and look at it, but actually in terms of back-end, I think the people are just as open about sharing. It can’t just be the fact that the technology encourages that environment. I wonder if it has something to do with how quickly things move, in that you may have a trade secret, but that trade secret is only going to last you for a short period of time. Whereas the industry that you’re in is moving so quickly, that you can share everything you know right now, and in six months everything that you’ve shared may or may not be as relevant. The fact that you shared it is always going to be there. That in itself has value.

Tim:

I also have a theory of my own. It’s probably stupid, but I’m going to try and just broadcast it. I think because of the distribution of what we do. For example, I’m here writing code on my computer in New York. You’re doing the same thing in … San Francisco.

David:

San Francisco.

Tim [27:48]:

San Francisco. Yes, I remember things. [Laughter] Then there are people all over the world doing this. There’s just so much work to be done. It’s not like I can grow my website building empire and handle all of the websites on the eastern seaboard. That’s just not a possibility. If I’m a car salesman, for example, that is a much more realistic possibility. I think if you could start your own car business, with nothing but a computer or some small tool that everybody, or almost everybody, had access to, I think the willingness to share secrets would be a lot more open. Because, let’s face it, the work’s going to be available for you. There’s room for everybody, and there’s just no way that you would be able to sell all of the cars on the eastern seaboard. Does that kind of make a little bit of sense?

David:

I suppose. It actually it brings to mind there are other industries where information sharing is similar to what I’ve seen in tech. For example, in education, I was trained to teach English as a second language. One of the things that impressed me about that community when I started getting involved in it, was how freely people share lesson plans and ideas and books. People are always out there sharing, This is what worked for my students. If you’re teaching English to somebody who speaks Turkish, then these are the specific things that are different between this language and that language, and the places where you’ll need to focus. These are the pronunciation issues around Arabic.

It’s an area where there is, as you said, an unlimited supply of students. There’s no way that one teacher could monopolize that entire industry, so sharing the information not only spreads that knowledge around, but it also builds up the reputation of the person who’s sharing it. Which I think is a key point.

Tim:

Yeah. It just helps you get better at your job, at the end of the day. The other thing that I really like that Guy touched on, was his illustration of building the Taj Mahal out of Legos, without any steps. Every day I believe this idea more — that following steps can be helpful in some areas, but if you really want to get better at building things for the web, knowing the fundamentals, and the building blocks, and the patterns, and the syntax, gets you so much further than copying and pasting codes and just going through the motions or going through the steps.

David:

That stuff isn’t sexy, but it’s very important. It’s something that if you don’t know it, you’re going to find yourself lost at some point. You will know how to build as many Death Stars as you want out of the Legos, as long as the Legos are configured to look like Death Star pieces. As soon as you’re presented with a Taj Mahal, you have no idea where to go.

Tim:

Sometimes it’s a trap I get caught in myself. You know, I store a lot of boilerplate code for example. Every once in a while I’ll be building something. I’ll be like just copy paste this to step one, and then I stop and I’m like, Wait a second. Why does this work? Why is this thing doing what I want it to be doing right now? Why is the code all falling into place? I know the steps, but I don’t know the background. The behind the scenes stuff that’s going on that’s making this thing do what I want it to do.

It’s helpful, because when I learn that, I can branch out. I can tweak things. I can get more results by changing how this one function runs, and tailor it to the specific type of application that I’m building. The customization becomes a lot easier and better for each project. Instead of just following a boilerplate.

David:

That’s what terrifies me about starting any project these days, because you’ve got this whole stack. You’ve got this Grunt project, you’ve got npm installing all of these different pieces, and they all work together. It’s like you’ve created this complex tower that’s based on these fundamental building blocks that you have no idea about. You can go in and you can learn the APIs for these things, but you don’t really understand how they’re doing what they’re doing. You’re not really in control of your own project. Yet, if you don’t do that, you have to build so many pieces from the ground up, that you never get anything started.

Tim [31:53]:

That’s why I think, again Guy touched on this. He touched on a lot of things. He’s a very smart person. I think that 2017 is going to be the year of simplification. The year of fewer tools and maybe doing a little bit more work with the trade off of being not having to manage yet another dependency. I’ve always favored in my work, as few dependencies, as few single points of failure as possible. There’s always another tool that you can use. I use Gulp for most things. I use Sass for most things. I use npm for most things. I try to keep those things doing as little work as possible. I try to make sure that if I had to remove one of those tools, I could still use my project.

That’s not always possible if I’m working on an Express application. I need npm. That just has to work. But if I am, as I’m doing right now, I’m building basically just a brochure site for a company that my brother works at. I spun up Gulp just for Sass, and then I realized that I don’t need any JavaScript for this site except for this off-canvas menu. I just basically inlined the three lines of JavaScript to make that off-canvas navigation transition.

I thought to myself, I could have over-tooled for this very easily, but in keeping things simple, that there’s so much less stress. So much less things I have to worry about. It’s not the most beautiful and elegant thing, but it gets the job done and someone can go and maintain it, and it’s going to be fine.

David:

You used the word over-tooled. I think that it’s a word that people have not been using enough. That it’s a word that people are going to start using if we push this, in 2017. When people are going to start realizing that over-tooling is a very dangerous approach to the way that we’re building these things, and we’re creating these monsters that are going to be very difficult to step into and maintain in the future.

Tim:

I think we should push this concept. I think that developer convenience should not get in the way of building maintainable — and I’m not going to say long-lasting — but software that lasts as long as it needs to, and benefits the users first. I think tooling can get in the way of that, and I think maybe we haven’t seen it happen yet, but I think we’re getting to that point. That’s just a theory. If you disagree, if you love tools, let us know, because we want to hear more points of view. We certainly don’t want to live in an echo chamber.

David:

Yes, and if you’re out there developing the next tool that everybody’s supposed to be using, you might have an opinion on this. So tweet us at @VersioningShow and let us know.

Tim:

Yes, definitely. Because tools are interesting. Tools do make things fun, but yeah, again, I’ve always favored doing just a little bit more work on my side so things are better for the other person. That’s that.

David:

Well, cool. I was glad you brought up the issue of code maintainability and agency work in particular, because I think that relates to what we’re talking about here. It’s about how long the code needs to last, and putting the user first. With agency work, I think you get the opportunity to be exposed to work that may not need to last as long, but that needs to address specific needs for specific user bases.

Tim:

Very true, and in those cases, you do have a little bit more room to experiment, as Guy mentioned. He really enjoys trying out new things and new approaches. You know, if you’re working for an agency that says, Hey, we need a website for Thanksgiving that markets our product. Damn it, go have fun, because that’s always a good fun thing to maybe try using the next module bundler or something.

David:

I like that. It’s like holiday code. It’s a holiday for the developer, because they get to play. It’s a holiday for the user, because it’s only going to be relevant for that holiday, and that’s the opportunity to experiment with all of those deep stacks and strange tools.

Tim:

That’s a real thing, holiday code. Especially if you work in ecommerce, for example. Wherein you have to put up a landing page to sell six products that are discounted just for the holidays. You know what? Also listeners, aside from tools, tell us about your best experiences with holiday code — or worst, because both of those things exist.

David:

Hash tag #HolidayCode.

Tim:

All right. Now it’s going to be in the show notes, and I can guarantee that’s going to be a thing when this episode releases.

David:

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

Tim:

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.

David:

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

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

Tim EvkoTim Evko
View Author

Tim Evko is a front end web developer from New York, with a passion for responsive web development, Sass, and JavaScript. He lives on coffee, CodePen demos and flannel shirts.

PodcastRalphMsitepointversioningVersioning Show Episodesweb
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week