The Skills and Qualities of a Good Web Engineer

In this one-on-one episode of the Versioning Show, Tim and David talk about what makes a good engineer. Topics include the technical and soft skills of a good developer; the qualities of humility, curiosity, discipline and pride; time management and working effectively with others; exposing impostor syndrome for what it is; the challenges of HTML email; and … David’s intriguing leg day routine.

Show Notes

• The Power of Habit
• Slick Carousel
• Tim’s stale Angular Demos repository
• The Versioning Show interview Chris Coyier
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

I learned very early on in my career, number one, it’s OK to say, I don’t know something. Number two, to walk through your day-to-day job with humility, because you’ll learn a lot more that way. It’s easier to work with people that way. Overall, you become a better collaborator and thinker that way …

---

I’ve noticed a lot of the people that I follow who write code are always curious. It’s not a forced curiosity. They’re really enjoying what they’re doing. Even if it’s something that’s very tedious or extremely technical, they always have this wonder about what they’re working on.

---

The ability of an engineer to look at each challenge as it comes up and still find ways to say, OK, this is boring. This is unrelated to my own interests, but how can I find something about this that’s going to help me grow as an engineer and help me expand my horizons?

---

there are certainly days where I don’t really feel like writing any code. … I feel like if I approach those situations a little bit more disciplined, I might find something that I enjoy, but I will always get more experience and get a little bit better at what I do for a living.

---

some of the best engineers that I’ve ever worked with are the ones who are the most interested in sharing information about what they’re doing, bragging about the things that they’re successful at, going out and giving talks, giving brown-bag presentations inside of their organizations, or going to meet ups and talking about what they’re doing, but sharing that information out.

---

Everybody who I’ve talked to about this, has admitted that they don’t believe that they are as skilled as other people seem to think that they are. One of the things that makes a good engineer in my opinion is the ability to move through that, despite the fact that you feel that you are an imposter. Recognize the things that you know really do have value.

---

I feel that the imposter syndrome comes from looking at the grass being greener everywhere else, but you’re just looking at their best grass. You’re seeing what everybody has put forward for you to see, not the bad stuff, not the failures, not the mistakes. I think that’s where the imposter syndrome comes from. It’s because you see everybody dressed up in tuxedos and you think you’re wearing rags. It’s never the case.

---

I was genuinely afraid that I was not going to be able to get a job if I didn’t know Angular. I think that part of being a good developer is knowing how to not just avoid, but notice when you are steering towards a pattern of thinking like that, and reset and remind yourself that, all right, stick to these bases. These are the things that I’m good at. Let me develop my expertise there.

Transcript

David:

Hey, what’s up, everybody? This is M. David Green …

Tim:

… and this is Tim Evko …

David:

… and you’re listening to episode 17 of the Versioning Podcast.

Tim:

This is the 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.

David:

Today, Tim and I are going to be talking about what makes a good developer, and how does one become a good developer? Let’s go ahead and get this version started.

---

Tim:

In lieu of a philosophical question that we ask all of our guests, should we come up with one that we ask ourselves, since it’s just us on this episode today?

David:

[Laughs] That’s a good question. What would be a question that we could ask about being a good developer?

Tim:

Oh, man. If it has to be related to the topic, that’s a little bit difficult. I was thinking in my head, if you weren’t working with the internet, what else would you be doing?

David:

I would probably be banging sticks and rocks together.

Tim:

Maybe I’d be like a farmer or something.

David:

These days nothing doesn’t involve the internet. Every career that I can think of that I’d be involved in would have something to do with the internet.

Tim:

One thing I figured that we should remind our listeners before we dive in here, is that even if you’re not a developer — like, for example, if you are a designer, or a user experience professional, or if you build for the web in any capacity — what we hope with this episode is that it will still apply to you, because we’re going to talk about technical skills, but we’re also going to talk about soft skills like time management, and working with people, and things like that.

David:

As we’re starting to talk about what makes a good engineer, it has to do with how well they interact with the other people on the team. They’re going to need to interact with those people and get themselves available, make themselves transparent about the work that they’re doing, and be open to suggestions and ideas that come from non-technical people.

I’m actually going to ask you this, Tim. You came up with this topic. What did you have in mind when you were thinking about that fabled good developer that you want to become, or that you might see yourself as, or that the qualities that when you do them, you think, That’s making me a good developer.

Tim:

Right. I’m going to save the obvious one for last. I’m not going to go into it, but the obvious one is being good at writing code. I’m going to save that one for last. I want to go with humility. It’s very important that I approach a project knowing that I don’t have all of the answers and that it’s a very real and present possibility that I don’t have the best solution to the problem in the room and amongst my coworkers.

Even if it’s something that I claim to be an expert at. For example, something that I do a lot in my career, is building CMS solutions for non-technical users. I’ve done that so many times I could do it blindfolded. That doesn’t mean that when I go into a meeting to discuss project details — even if I’m leading the project — that I’m going to dismiss other people’s suggestions. I should never do that.

I should also be aware of feeling over-confident about something — where, if someone asks a question and I fire off an answer, sometimes it’s not the right answer. I learned very early on in my career, number one, it’s OK to say, I don’t know something. Number two, to walk through your day-to-day job with humility, because you’ll learn a lot more that way. It’s easier to work with people that way. Overall, you become a better collaborator and thinker that way — at least in my experience.

David [3:54]:

I love that point. One of my favorite practices, when it comes to excellence in engineering, is the ability to pair effectively with somebody. When you’re pairing with somebody, the first thing that you notice is when you’re brushing up against one of their edges, one of the things that they feel like they know more than you about — or vice versa, they might notice one of yours. And there’s that point at which you have to realize that there’s added value to bringing in other people’s perspectives on how to solve a problem, even if you have a solution that comes to mind immediately, even if it’s time-tested and it’s tried-and-true and you know exactly what you’re doing. There can be a broader perspective that can come from listening to even a junior person, listening to somebody who’s approaching it for the first time — that kind of humility about your own coding can create a dialogue. And if it ends up being that your solution was the best solution, then the other person has had the opportunity to learn from you, instead of just having it shoved down their throats. It gives the opportunity for a back-and-forth.

Tim:

It certainly helped for me, and by no means am I perfect at this. I think it’s a struggle every single day as it is for everyone else in the world. The second thing, I think, that makes a really good developer is curiosity. The minute I stop being curious about what it is that I’m doing, the minute I stop thinking about How does this work? How does the thing that makes that work work? Things like that. The minute I stop letting that curiosity drive what I’m pursuing, I start to feel like I’m getting stale.

That could be just a thing that’s unique to my personality, but I’ve noticed a lot of the people that I follow who write code are always curious. It’s not a forced curiosity. They’re really enjoying what they’re doing. Even if it’s something that’s very tedious or extremely technical, they always have this wonder about what they’re working on.

David:

I don’t think that’s unique to you at all. It’s something I’ve noticed in some of the best engineers that I’ve worked with, and some of the best projects that I’ve worked on. One of the interesting challenges about that, is staying curious and engaged when the project itself doesn’t really catch your imagination.

Often, you may be working on something that is very similar to something that you’ve worked on before. It doesn’t intrigue you, or it may be something for some aspect of the project that you find uninteresting for whatever reason. The ability of an engineer to look at each challenge as it comes up and still find ways to say, OK, this is boring. This is unrelated to my own interests, but how can I find something about this that’s going to help me grow as an engineer and help me expand my horizons?

Looking for those things, finding them, and pursuing them, I think, is part of how people can maintain that curiosity, and that curiosity helps them grow as engineers while they’re working.

Tim:

It’s also a challenge sometimes. Right now, I’m working on building a set of HTML emails, which, if you’ve ever had to do, you understand just how difficult and tedious and annoying it is, because there is no standards body for email clients. Everything needs to be super-secure. There are a lot of features you can’t use, which pretty much means you’re writing tables and basic, basic HTML.

I personally am not very good at working with tables. At this point, unless your job day-to-day is building emails, you don’t really need to be super clever and advanced with tables. It’s very hard for me as I’m working on this project to get really into it. The thing I always need to remember is, Approach it with that curiosity.

Yeah, the specific task, of itself, may not be that fun, but there’s always some new information, there’s always something to learn of a project, even if you have done it a thousand times. There’s always just a, I don’t really want to be doing this, but let me at least see what I can learn from this specific thing right now.

David [8:14]:

I’ve got a story about building emails in HTML that might help with that. I was tasked with building out a system for creating emails in a company where things were being moderated through a CMS system, so that people would have to update and constantly manage these emails who had no idea how to build even a rudimentary table, let alone how HTML worked.

I worked with a coworker of mine to develop a markup language that would allow people to create elements in a fake HTML, like a very simplified HTML, with a standard set of templates. Basically, build a compliant HTML table-based email using components that they could select from. We worked with them to create a library of components that met all of their needs. We worked with the designers to make sure that they met all of the graphics requirements of the company, maybe all of the branding standards and such.

We made sure that they were flexible enough and versatile enough to handle long texts, short texts, etc. By entering information into this CMS using these templates that we designed, we could have them generate HTML emails that were fully compliant with all of the email clients that we were testing on. That was one way of taking the project and making a very creative solution that allowed people to build on HTML emails without having to require an engineer to build every single one the way that you’re having to right now.

Tim:

That sounds like a really interesting project. Again, the CMS-type solutions are always very attractive to me.

So, I think a third thing (I’ll do two more things, saving the best for last again) this third thing for me, I think that makes a really good developer is discipline.

For example, outside of web development, a hobby that I like to do is weightlifting. There are days when I wake up in the morning and, again, I go to the gym before work. I wake up decently early, not super early. I feel like sleeping for an extra two hours rather than going and working out. This is something that most of the time I enjoy and I certainly want to get better at. Even on the days that I don’t super love it, I employ what little bit of discipline that I have to get myself there, because I know it’s going to pay off in the end.

Now, with web development specifically, it’s not something we always want to come face-to-face with, but there are certainly days where I don’t really feel like writing any code. I don’t really feel like working on something. I might be a little bit bored or stale, or something new and complicated comes out, and I’m like, Maybe that’ll go away and I won’t look into it. I feel like if I approach those situations a little bit more disciplined, I might find something that I enjoy, but I will always get more experience and get a little bit better at what I do for a living.

Yeah, it’s great to say, I do it because I love it, but there’s certainly days where I don’t actually love it. The discipline is what I think helps me get through that and come out better on the other side.

David [11:38]:

Discipline can be very hard to develop. I know from experience. I’ve certainly had times when I’ve been working on projects and I’ve felt burned out. Yet, the project wasn’t done, and I had to continue working on it. I know one trick that’s worked for me is the ability to develop trigger habits where an event in the day occurs. It can be like a time when the clock hits a certain moment in time, but these events trigger a habit and after several days, repeatedly of always doing the same habit in response to the same trigger, it can help me get over times when I’m burned out and when my discipline might not be working for me.

One example, in my house every day is leg day. You talked about working out. I have a trigger that every time that I brush my teeth, while I’m brushing my teeth, I’m doing squats. I started doing it to see if I could get the tooth brushing/squats habit as a trigger. Now, I can’t brush my teeth without doing squats.

Tim:

That’s some excellent balance and hand/eye coordination too.

[Laughter]

David:

There were no accidents along the way, I’ll tell you.

Tim:

Yeah, you have to be safe. Make sure the floor isn’t slippery.

[Laughter]

David:

It’s been great, because every morning, every evening, I’m brushing my teeth. I’m doing my squats. I feel like I’m getting pumped and the energy is coming in. It’s time that my legs would have been wasting that time and now it’s a habit. I can’t stop it, because it’s part of my routine.

Tim:

I actually haven’t heard of the trigger habits before. That sounds really interesting, and I’m definitely going to try it. I don’t know what my trigger is going to be yet, but that sounds really cool. Thank you for bringing that new information. It sounds like discipline is something that you struggle with, employ that scenario.

For me, discipline is a thing that I was raised with. My dad went to military school. There was a lot of that in my life. It developed. I’ve never had to actually really struggle with it, but if you are listening and that is something that you find difficult, try that, try other things. Let us know if there’s something that’s worked for you in regards to employing discipline to be better as a web developer. I think that would be very interesting to share.

David:

I’m going to find the reference for those trigger habits. I believe it’s a book called, The Power of Habit, but I’m going to confirm that. We will put the link in the show notes.

Tim:

Sounds good. The last thing. Having a large amount of technical skill. Again, I’ve saved this for the last because I think it’s the most obvious one. It’s not the only thing that makes a good developer, obviously, but it is the thing that I think stands out the most if you say, Oh, man. Such-and-such is a really good developer. She can build all these very extremely technical things and seems to have the answer all the time.

I think that’s an obvious one, but it’s not something that you just wake up one day and say, I want to be a developer. Let me go just attain all of the technical information. There, I just checked that off my list. I think it’s more of this constant learning and trying things out and employing things like curiosity and discipline, in regard specifically to technical knowledge.

David:

It sounds more like it’s a composite of what happens if you have the other set of skills, because in some cases, one of the things we’ve noticed — and we’ve talked to a bunch of folks now on this show — a lot of them do not have technical degrees. They didn’t go to school for studying these things. They just went out and they were curious about what they wanted to learn. They had the discipline to spend the time focusing on something.

They had a project that drew their curiosity and kept them moving forward. As a result, they became good enough engineers that they were able to launch projects that inspire people who are listening to them here on the show and that engage open-source audiences and internal audiences around the world.

Tim [16:00]:

Yeah. That’s something that I always love hearing when interviewing others — that this was something that they fell into, and loved it, and just continued to pursue it.

I will share my — and I’m not claiming to have superior technical knowledge — but the thing that has always worked for me in terms of getting more technical knowledge, is that when I’m working on a project, if there is a thing that will take a reasonable amount of time for me to build myself, I will build it myself.

Let’s face it. If someone says, I want a slider, you can go download Ken Wheeler’s Slick Carousel, and it’ll work perfectly. It’ll probably work better than what you build yourself. But if you build it yourself, there is so much you can learn about different ways to instantiate objects in JavaScript, or maybe work with classes, or ways to lazy load images. What if you want responsive images on your carousel? There is just so much for you to learn there.

My strategy has always been, if it’s not going to derail the project, maybe I’ll put in some extra hours here-and-there, but I want to build this thing myself because I want to learn exactly how it works. I want to learn the common design patterns. I want to learn the mistakes and make those myself and learn and get better there. That has so far never failed to help improve the amount of technical skill that I have.

David:

It’s interesting. It’s a challenge, because sometimes you’re working on a team, and you’re working with other people who are relying on not only your speed, but also on the resilience of your code. I know you code with absolutely perfect standards.

Tim:

Every time!

David:

Nothing’s ever buggy. When you look at something you wrote five years ago, you can step right back into it as if it were yesterday. That’s not the case for all of us. [Laughs] There is definitely a skill to being able to take something out of a library and use it effectively, but it comes down to something I know we’ve discussed also in previous episodes of the show: the importance of focused, modular elements being released into the public domain, so that they can be used and understood and built upon, but the element itself is as focused as possible on the narrowest definition of the task. And then it can be enhanced.

I do love building on code that I appreciate and that I admire. I often learned a lot from reading other people’s code as well.

Tim:

Yeah. I have to echo that sentiment. The smaller the code, the better the code. I think I released a couple of things lately. Sometimes, it’s hard to keep them small. Sometimes, you just really want to add this feature, add that feature …

David:

It depends on whether you’re trying to solve a problem for yourself, in which case you know exactly what parameters you need to deal with, or if you’re trying to create something that other people can build on, in which case you want to build the foundation and then let them adapt it for their purposes.

Tim:

Yes, definitely.

So, what makes, in your mind, a good developer?

David:

I think we touched on a lot of things. I wanted to circle back to the very first one that you mentioned, which was the humility. One of the things that I think is missing — that some of the best engineers that I have seen have — is pride, completely on the opposite side of humility. A lot of working effectively in a team and in an organization, has to do with the ability to let other people know what you’re capable of and also let other people know what you’re working on.

The lack of transparency that I’ve seen in some engineers who keep their code hidden inside of a little box and don’t let anybody else know what they’re working on, they don’t bring other engineers into collaborate on things. It creates stovepipes of information inside of organizations. I think some of the best engineers that I’ve ever worked with are the ones who are the most interested in sharing information about what they’re doing, bragging about the things that they’re successful at, going out and giving talks, giving brown-bag presentations inside of their organizations, or going to meet ups and talking about what they’re doing, but sharing that information out.

It’s like the other side to humility. Be humble in terms of recognizing that there’s something you can learn, but also be proud of what you know and willing to share it, and willing to put it out there. I think that’s something that’s missing in some engineers.

Tim [20:40]:

I agree with that. I think there’s definitely something to be said for being proud of what it is that you’re doing and working on and wanting to show other people. When I build something that I think … [laughs] … I was about to say, when I build something really cool, and that’s probably never happened, but when I build something that I think is really cool, there’s so many times where I want to show everybody and say, Look what I did here with this new technology. Look how this works. It’s progressive. It helps users do this thing.

But, in showing it, and teaching other people about it, something really good and helpful could come out of it. That’s why I think it’s important to be prideful about the work that you do. Maybe not prideful, but to be excited about the thing that you’re working on, so that you can teach other people about it and show other people what you’ve been doing. Through that collaboration, something better might come.

David:

I’ve got no buttons on the word, pride. I like the word, pride. In particular, it speaks to an issue that I know I’ve suffered from in the past. I promise I won’t look. Everybody raise your hands if you’ve had experience with imposter syndrome, where you feel like, Oh my God! How did they give me this job? How did I get this responsibility? I’ve got no idea what I’m doing. I’m completely unqualified. How did I fool them into letting me take responsibility for this?

I think it’s universal among engineers that I’ve met. Everybody who I’ve talked to about this, has admitted that they don’t believe that they are as skilled as other people seem to think that they are. One of the things that makes a good engineer in my opinion is the ability to move through that, despite the fact that you feel that you are an imposter. Recognize the things that you know really do have value.

It ties back to the ability to teach other people. If you don’t value the things that you know, because you know them, it couldn’t possibly be worth learning if you already know them, then you won’t feel that there’s something that you have to teach other people. That ties back into what makes a good engineer — the ability to share that information and to be proud of the things that you do know.

Tim:

Can we talk about imposter syndrome for a second? I feel like I’ve had this long-standing bone to pick with imposter syndrome. See, the thing I hate so much about the idea of imposter syndrome — which I have experienced, and I think everybody in the world has experienced. It’s like only looking through windows and never at a mirror, because we build the tools that allow people to constantly have a window into other people’s lives. But it’s not actually a window. It’s like a window and behind it is a picture frame with all the best moments picked out.

When you see on social media or even out in the general world, you are most likely seeing a presentation of someone’s true self. You’re never seeing the complete picture. When you collect those pictures and best presentations of other people and you build profiles … All right, this person is this, that person is that. That whole time, even if you are looking in the mirror and saying, I’m this. I’m that, your best representation of other people is not truly them, it’s mostly them at their best selves.

I feel that the imposter syndrome comes from looking at the grass being greener everywhere else, but you’re just looking at their best grass. You’re seeing what everybody has put forward for you to see, not the bad stuff, not the failures, not the mistakes. I think that’s where the imposter syndrome comes from. It’s because you see everybody dressed up in tuxedos and you think you’re wearing rags. It’s never the case.

David [24:45]:

You’re seeing everybody’s demo reel, but you see your own outtakes.

Tim:

Exactly. It’s such a hard thing to identify, but I think it’s so important to remember that almost every single experience where you come into contact with another human being, there is a barrier in front of it. There’s a guard. That other human being is putting forth their best self. You can’t compare against that because only they know their full, true self. Only you know your full, true self. The minute you try to say, Oh, well, that person is just better, and I am just an imposter — the minute you fall into that trap of comparing everything you know about yourself to seemingly nothing you know about the interaction with the other person; you know everything about yourself, but you only know what that other person has shown you. I think that’s where the imposter syndrome comes from.

A word of warning to anyone who starts to feel imposter syndrome grip them is to remember that every single interaction you’ve had with another human being has been carefully combed over and presented to you in the right way. To compare yourself against that, it’s not real. It’s not logical. It’s not a thing to do that actually has any value. I know that’s easy to sit back in my chair and say that, especially as someone who has experienced imposter syndrome before. But I would say, just try to remember that. If you struggle with this and it’s something that you often find yourself thinking, just remember that you’re comparing yourself to someone else’s best moments.

David:

And of course, everybody knows that the Versioning Show isn’t at all edited. You’re hearing us completely raw and exactly the way that we spoke with no edits and no cuts. It came across just as perfectly as you’re hearing it today.

[Laughter]

Tim:

Back to good developers. Here’s a question now. I am just starting out in my career. I’m new to all of this — either just out of college, or just out of high school, and I want to be a web developer. What steps do I take to be good at web development?

David:

Well, let’s go back through our list of things that we discussed.

Tim:

We had humility, curiosity, discipline. Then, of course, technical skill, which is those other three things help you get the fourth one. And pride. If I want to learn how to be humble when I walk into a room of peers, and someone either asks me for an answer for something, or I’m brainstorming with other people and I don’t want to steamroll anybody … Yeah, how is it something that I develop that behavior?

David:

I’m going to punt on this. What I’m going to say is that I think it’s a false equation to say that you can separate these behaviors out and look at them independently in isolation. I think that that’s a phenomenon of trying to apply the human mind to something that is more holistic than that. The things that we’ve discussed, while they’re facets, I don’t think that they can be looked at in isolation. I think, for example, that humility, the way that we’ve defined it in this context, comes out of curiosity.

Tim [28:13]:

Wow! You made this circle. It totally makes sense. Yeah, that’s very true and very interesting. If you’re constantly staying curious about what it is that you’re doing, then I think you will be less inclined to jump to an immediate answer that you would otherwise be unsure of, or to not let someone else answer a question that you think you know better than. Yeah, I definitely see curiosity as being something that really helps that. That’s a very interesting point.

David:

As engineers, I think that we want to divide things up into categories and look at them objectively. But really, when you think about the people you’ve worked with who have been the mentors that you’ve wanted to work with, or the people you’ve learned the most from. It’s not really about, I want to learn humility from this person. I want to learn creativity from this person. I want to learn discipline from that person. I think these tend to be things that, if it’s somebody we admire, and somebody that we want to benefit from interacting with, these are people who usually combine this set of things, and it’s because they go together.

Tim:

Yeah, very interesting. So, we’ve talked about the characteristics and qualities of a good developer. If we’re going to talk about how to become a good developer, what suggestions would you have?

David:

Well, I threw out the word mentor.

Tim:

Yes.

David:

I think that modeling is one of the best approaches to developing an approach that you don’t have at the moment. If you recognize and can see in somebody else the behaviors and characteristics that you want to adopt, the ability to find somebody you can learn from, somebody who might be willing to mentor you, or somebody you can simply gain mentorship by observing or by researching. Then, modeling the behaviors that you see.

The whole fake it till you make it concept is actually very applicable, because if you put yourself out there and embody the characteristics that you want to see in a good developer by putting them on; figuring out ways that you can project those characteristics and put them into your highly curated stream of information that you share with the world, people will start to see you that way, and they’ll start to treat you that way. You can develop those abilities, those super-powers, simply by embodying them.

Tim:

I’ve taken the fake it till you make it path. It can get rocky. When I first started out, I was a consultant, which means I really knew nothing and I was cold emailing people on Craigslist for work for the web. I told them I knew what I was doing. I had no idea what I was doing, but I stayed up sometimes all night figuring it out, and I got it done.

Most often, the most challenging parts of those situations was when I actually got started working on it and realized, there’s a lot to this; there’s a potential bit-off-more-than-I-can-chew situation, but because I needed to pay the bills, I bundled right through it.

David:

I can see that. It’s important to challenge yourself. You wouldn’t have bothered to learn a lot of those things if you didn’t have a project that was forcing you to go through them. Discipline is one thing, but I find for myself at least, unless there’s somebody out there who’s expecting something from me, I’m probably not as likely to go out and learn that new framework, unless there’s some project that I really want to build with it, or unless there’s something specific I want to do with it.

Tim [31:52]:

Yeah. I think that touches on another thing — the ability to prevent yourself from getting obsessed. What I mean by getting obsessed is in a dangerous sort of way. There was a time when I was getting started again where I thought that I needed to read every single article and try every single technology. If I didn’t know this thing, then I was a bad developer because of it.

That led to a lot of working on weekends and not going out with friends on a Saturday night because I thought I really needed to know this thing so that I could put food on the table. In reality, it turned out to be a thing that I never used. I actually have a very stale repository and GitHub called Angular Demos, wherein I thought that I was just never going to be able to get a job if I didn’t know how to write code in Angular. And now, there’s not a lot of Angular news. I’m sorry if you’re an Angular developer. I’m sure it’s great.

David:

There are Backbone developers out there. There are jQuery developers out there. All of these … It was the must know technology of the day.

Tim:

I was genuinely afraid that I was not going to be able to get a job if I didn’t know Angular. I think that part of being a good developer is knowing how to not just avoid, but notice when you are steering towards a pattern of thinking like that, and reset and remind yourself that, all right, stick to these bases. These are the things that I’m good at. Let me develop my expertise there.

You may notice trends are pivoting. For example, if I decided this ES6 / ES2015 thing is a fad, that’s probably a bad decision, but it’s good to be able to recognize patterns when, all right, a new framework is out. Everybody’s saying it’s all the rage. What has history told us? This happens a lot. This may not be mandatory for me to learn right now.

David:

Very difficult to learn these things in the abstract anyway. It’s so much better to learn any of these, if you have a specific project, or a specific client, that you’re working toward. Ideally, it’s something that lends itself to the use of this particular framework. If you’re going to build Basecamp, you want to use Rails. If you’re going to build a to-do list, probably you want to use React these days.

Tim:

Yeah, definitely. I don’t think I’ve ever had a really intense learning experience just working on a demo. Again, I have to quote the ShopTalk show mantra. I know I’m bringing in another podcast, I’m sorry, but we interviewed Chris Coyier, so I think this is fair. To just build websites, the thing that you hear in every intro now to their podcast: that never fails to be true for me. Every time, I feel like I want to learn something new, when it’s a part of a large project, is when it really sinks in and when I really feel that, OK, now I understand, and no one can use this new thing.

I fall into this pattern where I’ll see something new. I’ll make a to-do list thing with it. Then, I’ll say, I know this thing now. I know it. I made the to-do list. Now, I can use it on a production application. Never been the case.

[Chuckles]

David:

Never been the case, and it never will be the case. Yet, those things keep on getting published. People keep on trying to learn things that way. Ideally, you have your own project. You’ve got your own challenges that you’re trying to solve. You have decided that this framework is the best way to approach solving this particular problem.

Tim:

Yeah, I agree.

David:

We have rambled.

Tim:

We have. We have editors and I’m sure they’ll sort this out.

David:

It’s going to be an interesting challenge, I think.

Tim:

I was thinking of the idea of micro-exchanges, where we release like Episode number 12 and a half, or something. It’s like a quick little thing. I thought maybe that might be fun. I’m trying to be creative about podcasting, in general. I think our podcast specifically is not really one that’s not the type of subject matter that I usually hear being talked about. I’m trying to see what else we can do differently.

David:

I love that one of our listeners called it The Philosophy of Web Development.

Tim:

That made me very happy.

David:

Yeah. It made my heart warm. I stole that, and I’ve already started telling people that that’s what the show is about.

Tim:

Perfect. Excellent.

David:

Being the only show out there about the philosophy of web development, I think we’re in a good position.

Tim:

Yeah. Market domination!

[Chuckles]

---

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

David:

We’d 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. Let us know how we’re doing.

Tim:

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