Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Chris!

Chris Coyier: Yeah! It's Q&A time, just me and you, Dave. We had lots of new questions to go through. A reminder: Please go to ShopTalkShow.com and hit that "Ask a Question" button and send us in things. The meat and potatoes of ShopTalk Show is answering your questions. Let's do as many as we can in this one. This is a fun one; lots of good questions.

We have one here from -- what's that?

Dave: Oh, I just feel like we're getting back to the meat and tators.

Chris: I know. It's great.

Dave: We're getting back there.

Chris: Even when we have guests, we should do more Q&A. It's fun to get their answers to questions too.

This is a fun one. Steve Polito, I feel like Steve has written in a bunch of times, so thanks, Steve, for being a kind of long-time community member of the show. Steve tells us, "I love Ruby on Rails. I love it because I can quickly and easily build production ready Web applications with weeks or even days."

I feel like that's been the promise of Ruby. Not just Ruby, but Ruby on Rails from day one is the speed of it, right? It's mature, stable, has a great community. I think, as we speak, RailsConf is going on. That's amazing.

Dave: Yeah. Yeah, as we are recording this, RailsConf is popping off.

Chris: "Because of this, I have a hard time convincing myself to learn Node because I'm so comfortable with Rails. My challenge is, I don't know when and how to reach for Node when I could just use Rails and have the added bonus of having an end-to-end testing framework built in." Something he finds Node framework is kind of lacking. "Is there a stable, mature, full stack Node framework out there, even?"

I think Steve, in the longer version of this question, points to Meteor, but wasn't sure how full that was. What do you think about this?

First of all, whenever I read a question like this, I try to back up and be like, are we comparing apples-to-apples here? Is that a fair comparison? I think it's close.

Dave: I think so. I think its Ruby versus JavaScript is, I feel like, the core of this.

Chris: Yeah.

Dave: I agree with Steve. I love Ruby on Rails too. You fire it up. "Rails, generate model, pizzas," and now I have pizzas in my database and it's all set up. I didn't even have to configure it.

Chris: There's the thing right there. You need a database. That's a thing, right? We're talking things that need databases in this comparison.

Dave: Mm-hmm. Things that need databases. You have a very strict model, view, controller. Model is whatever connects, like, that's your database. That's your data structure. View is the HTML where your view works. Controller is kind of your logic, so like, okay, when I click "save," that's actually an update function, and so I'm going to write def update, do this stuff, save it, and then return whatever I need to return. Usually, you return--

Chris: Yeah, it's a nice separation of concerns there that I think it doesn't take people too long to wrap their mind around. I think if you're really heavily front-end, you might ignore the model because I feel like that's something you've kind of punted traditionally to back-end people, and that's fine. But then the crossover, the controller is where you both kind of have concerns because you might be like, "I need this data, but I need the data, I've been using this word a lot lately, "munged."

Dave: Munged.

Chris: Do you say the word "munged" a lot?

Dave: I love data munging. Yeah. I mung some data in my spare time. [Laughter]

Chris: We're always munging.

Dave: Yeah.

Chris: You might get stuff out of the database and then you just need to mung it a little bit to be ready for how you're going to use it on the front-end. Like, I need the array sorted or whatever.

Dave: That's what you're supposed to do, right? Take that logic out of the front-end, off of the client because then your templates get all messy or whatever, so you mung it in the controller or, even better, in the model. You pull out that munging into its own kind of whatever function in the model, so that manipulates the data.

Then you have things; things I've been marveling about is like Rails' flash notice or flash error kind of system. If a form doesn't submit, you can say, "Set the flash notice to 'Oops, I failed.'" Then on the front-end it'll render out, "Oops, I failed," if you have the flash block. You'd kind of have it by default. You have to turn it off, basically.

I'm just like, that's awesome because I'm in this weird legacy Java app land where they don't have that. Guess what we have. Session bugs. [Laughter] It's like, oh, yeah, so we figured out how show up that thing, but no one remembers how to turn it off, so we had to go, "Okay, now we have to wipe out--"

It has all these conventions for building an app built into it. That's what I think; when I think of Rails, I guess Rails is kind of a crack cocaine joke, maybe. [Laughter] It's a guideline. It's basically like, "Hey, these just help you go in a good path for building an application." That's been the whole intent for the Rails framework.

Moving over to Node land, I don't think a lot of that exists, right? There was sales or is sales, so you can use that. I've met some of the developers on that. It's a cool project, but I don't know a lot of people using it in production. If you are, I'd love to hear the success stories.

I also think things like create-react-app and Nuxt.js for Vue, I think they're kind of filling this framework void a little bit. I don't think it's as full featured as, say, Rails.

Chris: Certainly not. Yeah. Maybe intentionally. Not like, oh, it's just early in the Nuxt land, so they don't have a login gem yet or whatever. [Laughter]

That's what I always think of. I've used Rails when there's a database involved and it's somewhat complicated. Not just like a key value store kind of thing, but a fully relational database kind of situation, and I need stuff like routing for one thing, although that is one thing that the next Nuxt land generally handles pretty well. That might be a Node worthy thing to have moved, and stuff like a login system.

I know that's not the world's most complicated thing. It's not like you need Rails to have a login system and there are plenty of Node JavaScript powered login systems that are probably pretty transferrable, too. I kind of take the point, though, from Steve, that they're not all baked together quite as nicely, maybe having end-to-end testing as a first class citizen of the framework. It's a little bit more piecemeal, perhaps, in Node land.

Dave: Yeah. Well, like a lot of React stuff. I'm generalizing here, so don't send angry emails. A lot of React stuff is like, bring your own. Oh, bring your data store, MODX, Redux, whatever, or bring your own authentication system, passport, or whatever you're using.

If I A/B things, that's what I like about the Vue community a little bit more. They have a bit more first party conventions kind of built in. That's, again--

Chris: We talked about that a lot in the Evan You podcast that Vue is tremendous at that, aren't they?

Dave: Yeah.

Chris: Just having blessed solutions.

Dave: In that way, that saves me a lot of mental energy, I'm realizing. I don't have to hunt around on NPM. I'm not an NPM scavenger. I just patiently work through the docs on Vue a little bit more and I'll usually find a first party thing, or you go to the forums and it's like, oh, these are really the only two things that do this.

You want to use tabs? Guess what. It's Vue tabs every time. [Laughter] That's it. I kind of like that.

But again, it's all about conventions, right? Ruby is the language, which is beautiful and I like writing in it, but Rails is just the conventions. People hate active record. There are a lot of haters on Active Record but, man, is it a really great way to get data from a database, like from a relational database. It's maybe being superseded by GraphQL or something like that, but it's really not so different, in my mind. It's kind of like English language gets stuff from the database.

Chris: Mm-hmm. Mm-hmm. Really good. Love it.

Steve was kind of asking about learning Node, period, though. I'm so comfortable with Rails that I can't even think of an opportunity to try Node at all. I would say I guess if there's no full stack super comprehensive Node thing and that's what's preventing your learning from Node, sure. Okay.

Dabbling in Node to learn it a little bit doesn't have to be a part of a massive overhaul operation of full stackedness. When I think of Node, most of my interaction with it is small, and it's largely through serverless stuff like Lambdas, which are wonderful at running node.

Here's an example. We have a Rails app. CodePen is a Rails app. We use Lambdas for all sorts of stuff, but here's one simple example that we're moving to.

We have a service for exporting a zip file of a Pen that you create. Right now, it's a route. It's a URL that you can hit. You hit /share/zip/whatever and you pass the slug of the Pen that you're exporting and Ruby on Rails deals with it. It goes and collects what it needs to do, and it writes some stuff to disk, and it creates a zip file. Then that URL endpoint returns a .zip file that your browser downloads.

Great, right? Except for that that's a Web server's job. It's like writing the disk and stuff. It's a little bit, perhaps, heavy of an operation to be doing that.

Now that we've written it that way, after all these years, we're like, that was fine for a long time, but it's not as separation of concerns as you might kind of expect in modern architecture. You might think, "Oh, an export service. That's a fundamental nature of this application." It's part of the workflow of using this application at all. Maybe we should think of export as a service on CodePen and communicate with that service via a defined API.

It's like this thing, like, okay, when any one part of CodePen talks to another part of CodePen, we should have a standardized API way of talking to it, even if it's just internal. Hopefully, at some point, some of this stuff becomes external in a way, but having your application talk to itself in standardized formats is cool. Maybe CodePen the Web server talks with CodePen the export service via this defined, really clean API. Then there's no reason for that export service to necessarily just live on the same Web server as everything else does. It could be a hosted service anywhere else.

A Lambda is kind of perfect for it. It's a little piece of Node, JavaScript code. Now, a Lambda can be Ruby, too, these days, so I'm not saying these things have to be written in any particular language. I think JavaScript is familiar for lots of people. It runs nicely on the server. It's kind of a first class citizen of a Lambda anyway.

We can write a Lambda function in Node JavaScript that takes this API. It makes the zip file and does that job. Now we've kind of separated that ability from the Web server, which is nice because this service can scale infinitely because that's what services are good at. It's wicked cheap, which is nice. Maybe if it reduces the burden of the Web server, that's just nice for reliability and stuff anyway.

Dave: Yeah because, theoretically, it probably won't happen. But if 1,000 people just clicked that export button at the same time, CodePen would be like, "Oh, no. I have a problem."

[Laughter]

Dave: I've made a huge mistake.

Chris: Yeah, whereas a Lambda, you can hammer all day.

Dave: Yeah.

Chris: It's infinitely powerful.

Dave: Node is really good at these small, tiny, micro apps almost, but it can also be for big….

Chris: Yeah, I didn't need the Ruby on Rails of Node to write that.

Dave: Right. Right, you didn't need it.

Chris: Not at all.

Dave: Maybe the Ruby equivalent would be Sinatra. You just have a tiny app. Yeah; I think that's an excellent case. For me, the limitations of Rails, and I'm sure they're working on it, but there are always the, okay, I'm going to click this button, and I want it to be in an active state, like a setting. Let's say a toggle, right? I'm setting up my email preferences.

I click the toggle. Rails goes off and fires a thing and comes back. Then you're supposed to deal with that in the template. Sometimes you get into, if it's dramatic, you want to say, "Yeah, following. Update the text," or something.

You either have to do that in JavaScript for every single button, every single variant there, or you have to go refresh a partial from the server, just something like that, or you're relying on Turbolinks. I find that Rails sort of hits a limit there on interaction stuff. So, if you're in heavy, heavy interaction, you're starting to actually put more burden on the server than what you could do in the client using client side state. That's a situation where I'd maybe want to move off of Rails.

In my mind, what I think I actually want is maybe Vue inside of my Rails app, just a little bit of Vue just to help with these kind of stateful interactions. That's sort of where I'm thinking I would like to head.

There is stuff like that in Rails where you're kind of like, "Oh, actually, I'm not having a fun time building out this weird interaction." I've had that experience, and there are things like Node. Node doesn't just instantly solve that but heading over to JavaScript land helps kind of ease that, and all these JavaScript frameworks work very well on a Node client or a Node app, a Node server, so there you go. That's what I would say.

Another reason I'd use Node is concurrency. We built that game -- Right, Chris? -- Global Defense Club.

Chris: You built that game. It was very cool.

Dave: But it allows 600 people from a conference to play the same game all at once.

Chris: That's wild.

Dave: So, if you have 600 people show up and do a Rails app that's doing server calls to update every pixel real time, that's going to not go so well. Something like a Node server is really good at high concurrency. Rails has Action Cable, I think is what it's called, but my experience there was not so rad. I feel like the real time chatty apps, chat apps, financial real time data apps, those kind of benefit from Node services and high concurrent websocket sort of situations.

Chris: Sure. I think, high level here, it's that you're not wrong, Steve. If you're solving all the problems that you have already with Ruby on Rails, then whatever, you know. It doesn't mean that you can't learn Node in some other way and that there are all these things that Node is good at, like Dave just described and I talked about with Lambdas and stuff, that make it kind of like, well, reach for it when you need it for those reasons then, but not for Rails replacement reasons if you aren't interested in that.

Dave: Yeah. It depends, too, how much you like JavaScript. If you aren't a big fan of JavaScript--

Chris: That's a huge part of this.

Dave: --you're probably not going to have a lot of fun writing a Node app or stretch yourself. So, there you go.

Next question: Andrew Robinson writes in, "Does such a job exist where you're part of a design and development team? I enjoy both sides of the process and part of the fun is translating a design into a website that performs well and is intuitive to users. There are so many job titles out there that I can't seem to navigate and find something along these lines." Chris, is there?

Chris: Yeah. Well, I guess Andrew's question is, you know, he doesn't want to be one or the other. He kind of wants to be both because he likes both. Then if you look around job posting boards for jobs to specifically tell you that, maybe it's not going to be as easy to find.

Dave: Mm-hmm.

Chris: I don't see job postings like that very often, like, we need a both-y! [Laughter] Or whatever, you know, a designoper.

Dave: A magical unicorn.

Chris: Deviner.

Dave: Oof. Ugh. Devsigner, developer.

Chris: Yeah.

Dave: So, I feel Andrew's question here. I feel very much in that camp. I know a lot of people who kind of exist in this camp. They're good at design and development.

Chris: Right. That's not full stack, though, for the record. I think that's kind of interesting, right? Full stack has been thrown around way more now than it ever has been in the history of that term, I think, but it doesn't mean designer developer. It means front-end/"back-end."

Dave: Yeah, so this reminds me of Brad Frost, front of the front-end kind of thing, right?

Chris: Right. If you're front of the front, then maybe that design is more likely, at least, to be part of your--

Dave: Yeah, well, and I hope this -- yeah, it's interesting because there are kind of like designers and people just treat them as visual designers. It even goes into this Designer with a capital D, and we just think about the essence of the design. Then there's a developer, and it's just like code whatever I come up with. [Laughter]

In our experience at Paravel, a good team is when people are functioning as both. I know enough UX that I can spot bad decisions, make good calls on my own, or know when to escalate a bad decision. Even Reagan and Trent, they both know how to code, so they'll hop into Web Inspector or code and commit code themselves. That's been super helpful for us because now we don't even open Photoshop, really. We just talk about code, which is so much more valuable.

If you have a good relationship with designers--I don't know--maybe you pitch yourself as, "I code your designs really well." [Laughter] Then you'll probably have a lot of design teams wanting to talk to you.

Chris: Perhaps. I think that pitch that you just said, that's pretty clutch, right? When you're looking for a job … throw your own. I mean, sure, you'll probably make a resume, but I feel like these days you're probably pointing people to URLs and those URLs are digested as the first major thing that a company considers when looking at you. At least I get that; I get that suspicion that they're putting more weight on some URL that they're looking at rather than your PDF or whatever it is.

I don't know. I put too much weight on that right now but, whichever route you take there or both, can it say, "Andrew Robinson, I like both design and development"? Can you have some tagline that sells?

I like that you have self-reflected to the point where you know that that's what you like. Tell people; tell the world that that's what you like. Maybe that job will manifest itself because you've told the world so clearly that you like the intersection of these worlds so much.

Dave: Blog your problems, too. Just talk about it. Drum this up. When we started this podcast, front-end developer wasn't even a term. I swear we just made it up.

[Laughter]

Dave: Not us made it up, but it wasn't really a term. It just was kind of like, "We do this weird. We're like HTML people," or whatever. Now it's very much a term, so this idea, a developer that codes, designs really well, makes them performant, and owns that kind of whatever Mina Markham was talking about, like I own the code that goes to the user. Man, that's going to be pretty valuable. Maybe there is not a job title right now, but maybe there will be in five years.

This is a problem I think a lot of companies have. How many hours are they spending on visual bugs or regressions? It's because they're just letting anyone code on the front-end. I think a lot of companies deal with that.

I think the challenge here is, a lot of times, in companies, there's a UX department or a design department, and then there's an engineering department. The design department can't even hire engineers because they would be in the engineer tier.

Chris: Hmm.

Dave: There are two different pay scales and whatever, job title elevations, escalations, or whatever.

Chris: Maybe the smaller the company the better for you. I don't know how early you are in your role, looking for jobs, or what, but I tend to find that jobs morph as you do them to match what you are good at, what you're producing, how you're presenting yourself at meetings, the work you're knocking out, and stuff. If you're truly a foot in both worlds kind of guy, especially at a smaller company where roles are a little bit less carved in stone, I find. Just get the job and then your job will become that job if that's truly you.

Dave: Mm-hmm. Yeah. I mean I'm at a small company and I kind of have to do this by default because we don't have other employees to do that. Maybe a three person team is where you want to be.

[Banjo music]

Chris Enns: This episode of ShopTalk Show was brought to you by NativeScript. NativeScript is a great way for front-end developers to start building native iOS and Android apps. You might have heard about NativeScript on ShopTalk Show before but, this time, they've got some exciting news.

NativeScript now officially supports Vue.js for app development. If you're a Vue developer, you can now build native mobile apps using the same framework you use on the Web while leveraging the power of NativeScript to tap into powerful mobile APIs. You can try it today at NativeScript.org. Of course, they've got support for TypeScript, CSS, and popular frameworks like Angular as well.

NativeScript lets you build awesome mobile apps with technologies you already know. You can start coding today with the NativeScript Playground, which is a 100% Web-based resource to help you get started in minutes. The NativeScript CLI is there for you when you're ready to take that next step. They've got a great tutorial on their website and then you can also get started playing with some sample apps like an animated search, a login form, music streaming apps, social fitness trackers, swipeable cards and animations, charts, tab bars, restaurant menus, flight booking UIs, moving listings. There are ones that show how to build a Tinder-like swipeable card UI, putting a native dialog box in front of the user, animated rotating menus, carousels, et cetera - lots and lots of stuff to check out.

Be sure to visit NativeScript.org to get started today. Our thanks to them for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Oliver Williams, another -- I don't know. There might be multiple Oliver Williams out there, but I just get the sense we've talked to a lot of Oliver Williams. Hey, Oliver. How are you doing?

Dave: Hey, Oliver.

Chris: "I would like to transition into UX. I've done a fair amount of UX work in my career, but I don't have enough to make a portfolio," so this Oliver Williams is early in their career. "How do I make that move?"

We get that; even talked to Jessica Ivins.

Dave: Mm-hmm.

Chris: She talked about having this document that even she keeps up to date. As successful and kind of established as she is, even she still does this, but she tells her students to do it, too, that idea of writing down everything that you do as you go on a week-by-week basis, so you don't kind of forget. The idea is that if you do that for long enough, you're doing that for a couple of months, that it kind of becomes your portfolio. It becomes the stuff that you should be talking about that you did.

I think people have a blocker sometimes that says, "I haven't done three production websites that I can point to, thus I don't have a portfolio." I'm like, I don't know. I don't know that that's necessarily always what a portfolio is. There are other ways to talk about yourself, even if it didn't become production. Who cares? It doesn't mean it can't go in that portfolio.

You can talk about other -- I don't know. What do you think, Dave?

Dave: Yeah. I think we are doing this exercise with Dan Mall. It's still going on. But we're kind of redesigning the ShopTalk website.

We picked up Afyia and Carrie, who are helping us redesign the site and they just sent their Dribbble portfolios and kind of just were showing they had a portfolio. Maybe not all the stuff was live and on sites and stuff like that, so I think it was good. It was just enough to be like, "Okay, I like what they're thinking here and what they're doing, so let's go with these people."

There were a lot of people like that who had good portfolios and just enough to show what they're thinking. It doesn't necessarily need to be something real and out there. That sounds terrible, but it doesn't. Every designer on Dribbble has made a weather app, so whatever. Come up with your version of the weather app.

Kind of like that Dan Mall episode, we should link it in the show notes, but his whole thing was, it's extra work but if it gets you a high five-figure job, is it worth it? It kind of might be if you just put in a little extra time to kind of, "I'm going to do my riff on a weather app or a color contrast picker." You've got to come up with different things. Maybe something a little more complex with a few more interactions. A banking app; just a couple screens from my banking app. Shoot. [Laughter]

Chris: You've got to do something, is the point, though. I don't know why this is so confusing, I think, to some people. Just to make an extreme metaphor, I don't get to decide, I want to pivot to being a doctor and it's annoying to me that somebody won't just hire me as a doctor off the bat and then I'll learn from there. I have to somehow prove that I'm doctor worthy first.

Dave: You know what, Chris? No one will let me plumb their house. [Laughter] No one is asking me. [Laughter]

Chris: There's just a path there, but I think people are saying, "Well, they won't even let me start that path," or whatever. No, you need to start your own path or get yourself into a situation somehow where you're learning what you need to learn without--I don't know--requiring somebody to give you the six figure job first, or whatever. You know?

Dave: Here I'm going to do my thing again, my standard spiel.

Chris: Mm-hmm.

Dave: Blogging is really good because it teaches you how to talk about what you've learned and what you're working through, so there you go.

Chris: And nobody does it. Nobody does it.

Dave: Yeah. You don't have to even get clicks. It's like self-practice. It's just like, "Here's kind of what I'm thinking about. Here's what I don't like about my Wells Fargo banking app. Here's kind of what I would like to, you know. Here's what information is important to me."

Hopefully, that helps, Oliver. Let us know how it goes.

Chris: Yeah. Sure. John writes in.

Dave: Mislowick (phonetic).

Chris: Okay. [Laughter]

Dave: I'm going to say Mislowick.

Chris: That's pretty good. "I've got a pretty solid foundation of HTML, CSS, JavaScript. The problem is that I know it in theory but, when I sit down to practice code or create a site, put it to practice, I get a big case of coder's block. I'm always second guessing the methods I use and asking myself, 'Is this the correct way? Am I putting too much code in?' Any tips to get around this wall?"

Oh, that's funny. Coder's block: I don't think I've even heard anybody use that term yet but, surely, it's a thing.

Dave: Second guessing yourself, it sounds like you're already a senior developer at this point.

[Laughter]

Dave: No, I mean you have to kind of get the Larry the Cable Guy spirit and just git 'er done. You can always make things better. Especially when you're learning, you're always going to regret your first take.

Just playing on, like, I'm just going to get it to a state and then I can always refactor. That's kind of like where you -- that's an important code skill to learn. You're just going to learn how to go back, fix things up, and find an efficient way to do that. I'm all about rough first drafts and doing that.

Chris: Yeah. It sounds good. You know it's a classic, "Just Build Websites" moment. I don't know. You're second guessing yourself, but nobody else really cares. They care about the output.

Is the code that you've written achieving what it's supposed to be doing? Yes? Cool. Ship it.

I don't know. People are a little more self-critical than the world is critical of them.

Dave: Mm-hmm.

Chris: So, just getting stuff done.

Dave: I'm thinking it could be a scoping issue. Maybe you're like, "I want to build a banking app."

Chris: Oh, sure.

Dave: And so you're like, "All right, so I've got to do this and this and this." I think it's figuring out, especially in limited time or whatever, "Okay, what can I do here? What improvement do I need to make right now?"

Like a banking app, it's a list of transactions. Okay, I would just spit out a list of transactions on the page. Great. Got it. Okay, cool.

Well, the money part is kind of the most important, so I'm going to try to make the money part look cool. Okay, done. I did the money part.

Okay, but I want to be able to--I don't know--click a dropdown and filter out only deposits. Okay, now that's the part I have to do.

I you have to think in those sort of steps, those checkboxes. I write Post-It Notes all the time. I've got six Post-It Notes just taped to the bottom of my monitor right now. Just write off a Post-It Note task. Then when you do it, crumple that mother up and just chuck it in the trashcan. It's so satisfactory. That would be my--

Chris: We don't talk about that enough, that scope of ideas thing. I wonder. Do people get discouraged because they want to build this idea that they have, but they aren't as experienced in understanding what the scope of their own idea is?

Dave: Mm-hmm.

Chris: Maybe their idea is too big. It's cool to be a dreamer, but at some point, because you haven't built enough websites, don't know what's more complicated than the next thing.

Dave: Mm-hmm.

Chris: I remember talking with somebody who had this idea to build -- it had to do with reviews. They're just like, we'll just build a Chrome extension. Then when you happen to be on a page that has this type of content on it, we'll just go pull. It'll aggregate reviews of that content from somewhere else on the thing.

We'll just build it at a hack night. We have three hours to build it. We'll just knock that together.

As this idea goes, it was okay. I don't know. I'm not going to [explicit used] on your idea, but what it isn't is thought out, like, where are you going to get that data? I don't know. There are a million questions along the way that was like, the scope of this idea definitely isn't three hours and they didn't know that. That was the interesting part of that that the idea just was an idea. It wasn't a scoped to three hours kind of idea. Just the fact that they were oblivious to that was interesting to me.

Dave: No, I think that's the big challenge, right? I feel like there's some muscle memory there too. What would that be? Intuition, I guess, you're building. Gut just to know, oh, that's a big one or that's a little one.

Have you ever estimated complexity on a Jira ticket or something like that, Chris? It's like, how many story points do you think this is? You're just like, "Uh… I don't know. It's probably a three, but if it's on that page, it's like a ten because that page is a nightmare." You've got to know those things.

Chris: I read the intro to this book recently, and it started with this quote from Neil Gaiman, you know, the author who wrote "Coraline," "American Gods," and all that. He was talking about -- and I didn't realize that this was a famous writer's problem. He was like, "Every writer gets this. Somebody will come up and pitch their idea."

So, they got the idea for a novel or something, and they're going to cut you in on it. It's going to be great. They've had the idea, which is the hard part. The ideas, you know, they only rarely occur to people, so that's the deal. Then they'll have Neil Gaiman write the novel based on this idea, and they'll split it 50/50. It seems fair. [Laughter]

Neil Gaiman is like -- it's one of those--

Dave: Hey.

Chris: --unbelievable things. Like, no, the ideas, everybody has got a thousand ideas. They're worth absolutely nothing; 99% of everything is the execution of that idea.

Dave: Right. Neil Gaiman is just like, "Yeah, I'll execute your idea. I know how to do the execution. The idea doesn't even matter to me."

Chris: Yeah, I'm just a novel factory. Yeah, whatever your idea is, I'll do it.

The translation to Web development of all that is, I get ideas all the time. I'll have old great friends from college write to me like, "We've got to sit down and talk about this. Please meet with me." It's like, "I need a way for the moms in my mom group to schedule playdates together. I have this app that we'll call Play Dates or whatever. Everybody will join it. Then we'll pick times together. Then the playdates will happen," or something like that.

They're like, "This is such a good idea. If you design and develop it, I'll cut you in like 5%, 10% on this Play Dates idea."

It's kind of like the early thinking of it. You're like, this is -- I don't even know where to start. You're just kind of like, "Oh, this coffee is great. Do you want to go see the new "Avengers" movie later? That'd be kind of fun." "Oh, I'm just so busy. I don't think I can do the Play Date idea thing."

"But it's such a good idea! Please!" Keep trying.

We have to let them down softly because what they've presented to you is so asinine, but you don't want to lose the friendship over it.

Dave: Yeah. You don't want to poop on ideas.

[Banjo music]

Chris Enns: This episode is brought to you in part by WooCommerce. Today, I want to tell you about three exciting updates to WooCommerce. The first one is that WooCommerce version 3.6 shipped recently and added product blocks, so you can build rich pages with blocks in sites running WordPress version 5 or higher that show products by category, bestselling products, hand-picked products, newest products, and products with specific attributes, and more. It's super handy if you're using the new Gutenberg WordPress editor.

The second cool WooCommerce update is the new WooCommerce mobile app for iOS and Android. You can track your store to see which products are performing best, check revenue, view and manage orders, and get real time alerts notifying you about store activity like new orders or reviews. Be sure to search for WooCommerce mobile app on the iOS app store or Google Play today.

Finally, if you're running a WooCommerce site right now, you should check out the new dashboard for WooCommerce Admin that the team released as a feature plugin. It's what's going to eventually be the default dashboard in WooCommerce, but you can check it out right now. You get all sorts of data and analytics on your WooCommerce store with completely customizable dashboard, new reports, and a new activity panel to alert you to what's happening right now in your WooCommerce store.

If you'd like to see a WooCommerce store in operation, go check out the CodePen shop at blog.codepen.io/shop and try ordering yourself a shirt. The CodePen shop is running on WooCommerce and the shirt is one of my favorite shirts that I wear each week.

Our thanks to WooCommerce for sponsoring this episode of ShopTalk Show.

[Banjo music]

Dave: All right. The next question. Amy Ethridge, a long-time listener. Thank you, Amy, for writing in. "I am the only developer at my company directly and the rest of the team is outsourced, including the tech lead. I work on bugs and features like normal, but because of the outsource barriers--language, time--I'm finding I don't get to overhear or participate in conversations I might normally do on a dev team, like talks about best practices, how we're solving X, and so on.

"We have a daily standup and it's very standup-y and has too many participants that need to -- that the need of dev talk for the project to have dev talk on it. I've spoken with my direct and I've mentioned, with time, this might change as our company begins to take over the project, et cetera. I imagine this must be what it feels like working as a freelance developer on a big project. I'm wondering if you guys have any ideas how I can feel a little more vested in the project in the short, but probably long-term."

Chris: Yeah, so I like this. First of all, it's a weird situation. You're the only developer that directly works for your company and all the rest of it is outsourced, but you're just lower down on the totem pole of development work. Even the tech lead is outsourced, so you kind of report to them, but you also report to a manager that's at your own company, so you're caught between two worlds there and you're not even hearing about best practices.

I feel like, in a sense, they've made you code monkey. They're like, "Fix this." You're like, "Uh, okay. I guess I'll do that in a bubble. Here's the fix."

Companies are complicated. Everybody has been in some kind of situation like this at some point. It might be kind of dysfunctional/functional. Who knows?

It sounds like you don't want it to be like that. You're not happy with that situation. In some way, I don't think you'd be writing this letter to us if you were.

How does it evolve? I think that this letter was even longer. Amy said, "My direct manager said, 'Hey, things might change. Six months from now, maybe things will be different,'" kind of thing, which is a long time say something might happen to an employee of yours with a straight face. [Laughter]

What you want is best practices. What you want is more talk and stuff. You might have to demand it, in a way. Demanding it might not be marching into somebody's office and demand it, but you might say, "Listen. There has been a problem with this. I'm not sure what the best practice is, so I made a best practices document. The document is what I think they are, and I'm requesting feedback on that."

That's kind of a way of demanding that type of thing happen. If you're writing some code and you have no idea if it's how code should be written at this company or you're worried that three people are writing it three different ways and that that's long-term problematic, it might be at you to lasso that in. If you have no idea how some problem is being solved, then use documents.

I feel that Notion, not to sing their praises in every single episode, but it is really nice software that I like. It's helped me in situations like this because everybody in the company has access to it and it's just this hive of documents that there's kind of a clear place for documentation. You can always just spin up a new Notion doc, write up what you're thinking, and place it somewhere nicely in the Notion. You can point people to it and be like, "Here. Here are my thoughts on this." This serves as a basis for documentation for this project that we're working on, or the application as a whole.

Dave: Yeah. I mean I very acutely feel this, dealing with the offshore teams. I think the time barrier is tough because you come in and you actually can go through all the Git commits, but you kind of have a log of stuff to kind of read through, decipher, and figure out what's going on. No one is there real time to kind of answer questions and stuff like that. Language can be a barrier, too. It all depends on who and what, but that could be a problem.

Yeah. Hedging your bets, can I do the HR side of things? [Laughter] Be sure to write this down. Send emails. Don't just talk to your direct manager but send emails. Have it on paper so that if a performance review comes up, you can be like, "Yeah. No, I talked about this in this email."

Chris: Love that! Good idea.

Dave: Get some receipts going, Amy.

Chris: Yep.

[Laughter]

Dave: That's pretty crucial. But I think, too, yeah, like you're saying, Chris. If you're on Jira, there's confluence. Start up a wiki. Every GitHub project has a wiki in there. You can just start documenting best practices and leave a message in Slack and be like, "Hey, I'm trying to document some best practices, just so it's all clear. If anyone has ten minutes to look over this, that would be awesome."

Chris: You know who does that? Tech leads do that.

Dave: Yeah.

Chris: You're kind of like subtly saying, in a way, "Maybe I should be the lead on this thing. I'm the person reining people in and making sure communication is shared, and that things are being done in good, correct ways."

I feel like a lot of people's goal in the world, and I wouldn't doubt it that it's your goal, too, Amy, is to kind of level themselves up in this world. Sometimes leveling up happens by demonstrating the behavior of higher ups.

Dave: Occupying power vacuum by force. [Laughter]

Chris: I've never heard that term before, but I love it.

Dave: Seizing power vacuums by force. No, but that's true. I think Amy's situation is usually the inverse of what I've seen in the past, just companies I've worked for. Usually, it's kind of like -- there's usually a tech lead on the offshore team, but they are kind of more like they're the air traffic controller for issues. Kind of like, okay, this goes to this kind of squad; this goes to this squad.

That's sort of been my experience. Not exactly, but everyone's situation is different. I would say, I think if you're having trouble finding this information, everyone else, is, or it's too folk knowledge. Is that what we call it where it's just too, you know, you need to get that knowledge extracted, so I would take up that task. I think it would be very good.

I was going to say, Brad Frost has a really good front-end developer guidelines, which I think is really nice. It can kind of be a conversation starter. I have found, just personally on that, it's such a big document that maybe you take it a chunk at a time so it's more digestible, but that would be my only advice there.

Chris: Yeah. Some of this stuff, I feel like you need to get to the meaty logical bits of it are almost more important to talk about and document than it is to have, "Okay, let's have a two-hour meeting about tabs versus spaces," and stuff like that. Uh, those are -- I guess you have to do that, too, but that feels like almost a distraction to deeper problems.

The stuff that you need to tackle is the--I don't know--just meatier stuff than that, whatever it might be, like, "How are we organizing components? What is our API structure like? When I solve X, Y, and Z problem, how is it best to communicate how I solved it to the team so that that knowledge is there? Are we using a code comments kind of thing or is there a document I could put it in, so that knowledge isn't lost, kind of thing?"

I feel like the earlier, like, "Should I use semicolons?" stuff is fine to get established, but probably should be enforced by tooling rather than extensive code reviews, commenting, and stuff. The meatier stuff just has a lot more value there.

Dave: Mm-hmm. Mm-hmm. No, I think you're on the right track.

Chris: Yeah.

Dave: You're asking the right questions, I think, at this point. That's what I would say is you're sensing there's a disconnect. I think A) get receipts of you talking to your manager because it's ultimately their job to make you a better employee. That sounds wrong but let me reword that. It's their job to train you and make you provide more value for the company, just from a purely business standpoint. If they can't do that, then you need to be like, "You are failing me as an employer, so what can you all do?"

I would definitely -- I don't know. In regard to being a freelance developer, it's great, but you have the opposite problem. It's like now you have to do everything, so it's a little bit different. Let me know if you go freelance. Ping me. That's all I'd say.

Chris: [Laughter] All right.

Dave: [Laughter]

Chris: That's a great place to leave it for this episode, I think.

Dave: Yeah.

Chris: Please join us next week. Send in your burning questions about front-end Web design and development questions, and we'll take them.

Dave: Yep, and you can follow ShopTalk Show on Twitter. We tweet a little bit. [Laughter]

We also have transcripts. We talked about this before. Pham Transcription is doing our transcripts. They come a little bit late, but there they are. We're starting about--I don't know--Episode 345-ish.

Chris: Right. Right. Instead of piecemeal, they're all of the episodes have it, which is great.

Dave: We're doing it, so thank you all for listening to the show. Thank you, sponsors, for supporting because that's what pays for that, so we really appreciate it.

Chris: We have a special job shout out for you this week. It's at a place called We the Collective. They're in Vancouver, British Columbia. It's an agency. They help entertainment brands build websites, engage youthful audiences with digital experiences. Good, fun stuff.

They're looking for people like you, people with experience writing semantic and well-formed HTML. Nice. Modular CSS, JavaScript, proficient in SaaS. Pug is good, experience with Gulp, NPM, Git, and all the things, the things that you know about because you've been listening to this show for a long time, leveling up your skills as a front-end developer.

That's what the role is. It's for a front-end developer in Vancouver, British Columbia, in Canada. The place is called We the Collective. It looks just like a really good job for anybody out there looking to pick up front-end development work.

Dave: All right, Chris. Do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.