Episode 20: Implement the Back-End Functionality (w/ David Knipe)

Hello, this is The Web Project Guide Podcast and this is episode 20, Implement the Backend Functionality. I'm Cory Vilhauer, director of strategy at Blend Interactive and co-author of The Web Project Guide. Later we'll be joined by David Knipe, vice president of product at Optimizely. But first I'm joined by the person who first taught me the philosophy of backend development and co-author of The Web Project Guide, Deane Barker. Deane, tell me everything, tell us everything you know about backend development.

So backend development is what I came up doing and I'm sure that we'll get into this with David later, but back in the day there was no dichotomy between backend and front end development. Everybody was just kind of a developer. And so us old folks have kind of watched this change, and the way the industry's work, you fundamentally have someone who implements the design on the front end, but then you have somebody who works on the back end. And I'm very solidly still in that category. I can't do front end develop to save my life. So backend development, back in the day there was no front end development. It was really all backend development and that's what I did at Blend. And what's still Blend does quite a bit is kind of backend development, taking a content management system and kind of wrapping it around your requirements, which I think is incredibly fun.

(01:22)
It's really neat to take technology and be able to modify it and change it in such a way that it really, really fits somebody's requirements like a glove, while at the same time giving them room to grow and change and do new things. I think there's an absolute art to it. It's one of my favorite things to do, and I'm excited to talk to David. David and I go way back. He was a solution partner just like Blend Interactive. He was working with Episerver at the time and then has moved on and now he is a vice president of product here at Optimizely. He and I worked together on Optimizely's CMS, so I think he brings a lot of interesting perspective. Corey, now I'm going to throw this back to you.

Great.

As someone who works at the content level, I mean, your job is to come up with requirements, come up with content and IA and plans and everything, what drives you insane about backend developers?

I don't think-

You can't see Corey, but he just gone very, very thoughtful.

I'm really thinking about this and this isn't, like, here's hard about it for me, I think is that because I've taken the time to try to understand the idea of backend development and I think that if anybody's listening and they are a content person or a design person or even just a project manager, it's really important to understand the concepts within and the structure around backend development and CMS implementation. Because most of the frustrations that I think I ever used to have were due to my misunderstanding of what backend development took, my sort of assumption that really anything can happen. And so when we would ask for something on the content level or when I was doing QA work, if I had asked, "Why doesn't this work this way?" And you would get a specific reason why it didn't work that way.

(03:05)
And oftentimes it wasn't because they didn't think of it. It was because they did think of it and they know that it wasn't going to work. So it was just purposely kind of left off to make sure the editor didn't run into those same frustrations that they would have if say you allowed them the opportunity to create any tag into a category and then create a custom feed based on that, et cetera, et cetera. All these different things that you know are technically you can do it but aren't necessarily in the best interest of that editorial team. So that's my pitch is to, like, "Hey, man, if you do content, you got to learn a little bit of development." You don't have to know how to do stuff. You got to understand how pieces fit together about the technical side of content modeling and creating an application.

I'm so glad that you said that. This totally plays into a theory that I have, not a theory, but I teach two courses at a university in Austria. It offers a master's degree in content strategy, which is very much, Corey, what you do. And I teach the two kind of technical-ish courses. I teach introduction to CMS and advanced topics in CMS. And on my second course, my advanced course, the theme for the course is what I call developer fluency, or should be really developer familiarity. You will be a better content strategist if you understand what your developers go through. You will be a better content strategist who can ask better questions, who can understand capabilities, can understand what will work and what won't work if you understand what backend developers go through.

(04:37)
You don't have to understand how to code the solution, but you need to understand what the solutions are capable of and you need to be able to gut check level of effort and you need to know is the thing I'm thinking about doing here a minor thing, or are we ripping this thing out to the roots? You will be a better content strategist if you understand that. So I believe that backend development is not just for backend development's developers. I think everybody involved in the project needs to understand to some extent how the system works and how you can get it to work [inaudible 00:05:07] want, so I'm excited to talk to David.

Yeah. All right, well, et's get over to that. But first we had to talk about the sponsor. And the sponsor is Blend Interactive, who is a web strategy design and development shop that's dedicated to guiding teams through complicated web and content projects. I know this because I work there, Blend's been building great websites for over 18 years and we're always looking for our next partnership. So you can visit us at blendinteractive.com. All right, let's welcome our guest David Knipe. Hi, David.

Hey.

So, David, let's start off, tell us a bit of your background. What have you done today? What's your position now? And then I know historically you have been on kind of the other side of the coin, so let's talk a bit about that first.

Cool. Okay, so I'm the VP of product at Optimizely, so basically I help our product teams kind of define the strategy and the direction that our products are going in and what we're building and hopefully meeting some of those customer needs. Before that, I was actually working in a solution architecture's team, and I was actually going out talking to customers. I love talking to customers. I love speaking to people who are actually implementing technology and solving problems because I love solving problems. And I did that for a number of years, and before that I was actually with an implementation partner as well.

(06:20)
So again, as an implementation partner, it's good to be in an agency setting. Always interesting, always kind of busy. There was always lots of new people and new customers and new clients to go out and speak to and that was great. That gave me a good grounding in terms of going out and implementing, optimizing solutions or Episerver before that. But also kind of a wider view of the world in terms of just technology as a technology set. And before that I'd spent a number of years basically in corporate land, essentially in corporate development doing backend loans processing and accounting systems and that type of thing. So I think I've slowly moved from the green screens at the back end all the way through to the fun, cool web technology bits at the front end.

So I think that's critical that you had a past as a user of the product that you now manage. I have a theory. My theory is that lumberjacks are not home builders. David, I think I've told you this before. A lumberjack cuts down a tree and he cuts down a tree that gets made into wood. A home builder then takes that wood and actually applies it and does something practical with it and makes a customer happy with it. And what I worry sometimes is that some organization are led by the lumberjacks in their organization. They're led by the developers that are building the tool, not by the users who have used the tool. Can you validate that expression a bit and tell me, do you think that your expression, using your tool gives you a unique perspective on someone who is now managing the tool?

Yeah. Yep. I think I would agree with that assertion, I think, because when you are a lumberjack and we're going to keep the lumberjack thing going here, when you're a lumberjack, you want the bestest, damnedest, sharpest axe out there to go and do that. And you're building and you're building those tools and chopping down that wood to go and deliver that. [inaudible 00:08:07] your job is then done, you're not then thinking about where that wood's going to be used. And I think you then hand that over to another set of skills, another sort of set of specialisms that's going to go on and do that.

(08:16)
And I think, for me, you have to be able to have a context of customers, and I say I love watching people watch you software. It's great. You can just learn so much and you see what people are doing with the software, where they're trying to do something and there's a video I think is on TikTok or something where it's like someone in QA and they're trying to put the shaped pieces into the boxes and they keep putting them into the wrong ones. And it's like we need to do that all of the time. We need to go out and understand what people are doing with the software, the solutions, how are they wanting to use it, how are they trying to use it? Because if we don't do that, you end up making something that, great, my car's got square wheels and the wheels are even squarer now, but no one wants a square wheel. But I've never seen someone driving a car so it's kind of ... Yeah, sorry, we're going to go strange [inaudible 00:09:03].

Being a lumberjack can be wildly theoretical, right? If I'm a lumberjack, I want to cut down a very tall tree and make a very straight board and just make the straightest most perfect board in the world, and that's important. I'm not saying that's not important, but then I send it off and I still exist within the world of theory. All I had to do was make a straight board. I actually didn't have to do anything with it. Where building a home is kind of the story of adaption, right? Well, this thing doesn't quite fit here so we're going to have to get kind of creative by cutting this a different way. There's a big rock in the way of the foundation. What are we going to do about that? And I feel like lumberjacks don't have to deal with that. You and me when we were developers both with solution partners because we both, David, we were solution partners. We actually built and then we came over to the vendor, we spent that time trying to make the boards fit.

(09:51)
We spent that time getting creative and trying to put together the house with these beautifully theoretical boards that were built for us. So let's talk about the dichotomy now between front end and back end development. We talk about this in the book, right? We split the back end out from the front end out. And I remember back in the day when I was coming up like in the late 90s, we were all just web developers. You did backend, you did front end, but now there's a very, very clear split. How has that filtered out into the product, into the implementations, David, in your experience? I feel like web development teams are distributing and there's no longer just one person that does everything.

Completely agree. I think yes, it's the classical full stack or the mythical full stack developer. I think for a number of years, particularly web CMSs I think you had backend developers picking up markup that had been generated in some pristine land of the front end developer, they just go off and integrate it. But I think as front end technology has evolved, it's iterated and become more complex as a result of that and browsers and everything that you can do on the front end technologies. It's almost become the machine is too complex to integrate now as kind of one and the same thing. And particularly in front end technology, there's so many capabilities that you now have in the browser people don't understand why you wouldn't. I spoke to a developer a long time ago and when I talked to him about how head full rendering where you actually spit out the HTML on the server and he just looked to me as if I just told him the moon was blue and he said, "Why would I create HTML on the server?"

(11:27)
And that was my kind of aha moment. I was like, "Right, so is how things have moved on," and Deane and you and I are old enough to remember the times when that just seemed awful. It would be some crazy thing to do. But now it's very normal and I'll be honest, I've been there, I've drunk the headless Kool-Aid. I've tried it. I've actually instant refreshes playing on my Mac and things and it's a nice experience. But let's have no doubt about it, it doesn't get rid of complexity. Complexity still exists there and I think, yeah, Deane and I risk veering into a headless chat here, but it's a-

Deane and David. I'd hate to dump all over your lumberjack metaphor, but what it sounds like is that you're not giving the lumberjack or in this case the developer enough credit. I mean, in this case the lumberjack does need to add in some way, not just create a straight board but know that there are different ways to create that specific straight board and different versions of it. It feels as though every development question might have actually multiple different answers that are probably only solved at the development level.

But how you do that, Corey, you know how you make a great lumberjack? You start with a home builder. You find somebody who builds homes and then you say, "Okay, now that you know how to build a home and now you know how all these boards go together, now go out in the forest with an axe and cut down some trees and make boards," because that lumberjack is going to know what works and what doesn't. Sure, a lumberjack is going to be able to look at something in the forest and say, "Well, that's never going to work for someone building a home." And so I think it's very, very important to have that experience. And so then you have someone like David that was in the trenches building the homes, now he's lumberjack-ish. David, I know you're not like a line developer in our group, but you're helping direct the development of our product and I think that's important to do.

(13:18)
Let's pivot a bit to the fact that low code and no code and AI is going to put all of us out of business. That's what we're being told. We're being told you don't need really any server side or backend development anymore because there are low-code platforms and no-code platforms that do it. And now, I don't know, in the last three months I've been told that AI is going to do everything for us. I kind of call BS on that. I integrated enough situations to know that there are a lot of weird edge cases and idiosyncrasies that you just need human judgment And also I maintain that AI and low-code and no-code require users to clearly explain their requirements, which is often the core of the problem, is that they can't articulate what they want to do. David, are backend developers at risk of being put out of business?

I don't think so. I think what AI may be able to do is help accelerate particularly things with boilerplate. Let's be honest with ourselves, code generation utilities have been around for decades to help you write that boilerplate to help you write all the stuff that's been written before just to get the job done. And what I think AI is doing is lowering the barrier to entry between being able to instruct a machine clearly of what you want it to do, call it development or call it the manifest for whatever you're generating your code from. AI just says "Ah, build me a website that looks blue and it's got pictures of pandas on it," and it can kind of generate that type of thing for you. Doesn't mean that that prompt is correct or it's necessarily solving the right problem. And also the problem you have then is the code it spits out, you haven't got a clue what's written in it. You haven't got a clue how to debug it. You haven't got a clue how to fix it.

(14:51)
So again, at scale, if you have swathes of AI generated content, you're going to just have what a lot of people think of as tech debt or knowledge walking out the door issues just because the machine's written it all and well, written huge amounts of it. And I think you still need backend developers with proper architectural principles and guidance and to think about how you structure those things. So coming back to the house analogy, you've got to have a rough idea what is it you want to build. What's the footprint and what foundation type do you have because of the land it's on? Whereas you could just build something quickly but it wouldn't necessarily be right for the problem at hand. And I don't think AI's going to put people out of business.

(15:31)
I think people who are good at technology today, the reason they're good at technology is they understand how to interface with the machine, and they're just going to be able to create great prompts for the AI now to be able to do things quicker perhaps. Yeah, I think we've all seen those blog posts that get magically spat out of the AI tools and it's magical, it's amazing but, god, if you have any responsibility for pushing those things out and publishing that, you have to read that and you have to understand it. And I think weirdly enough, I think humans have been always good at heuristics and rubbish at recall, but AI seems to switch that back around. It seems to do all heuristics for you and then not so good at recall because some of the facts are wrong. So I think it's a weird switch around.

I think you'll end up with the worst kind of technical debt, which is technical debt you don't understand.

Exactly.

We've talked about in the past two different episodes in the past where we talked about how to select a CMS and how to select an implementation partner. Now we're actually in this fictional project we're creating, we're actually starting active development on a project. What do we need to carry over from those past discussions as we begin this building process? What is it that we learned during selection of a CMS and selection of implementation partner that actually helps us as we move into developing the site?

Yeah, I think it's an interesting question and I think someone once said to me once that particularly when you're making a selection process, there's often a pitching process, it can often be like therapy. You get your pains out. You get your problems out. You're perhaps sitting actually in that room with people who've never sat in before. It's very common that people, particularly from marketing team will be in a room with someone from IT and I've been in scenarios before, you walk in front another customer and about halfway through the kind of meeting you realize that these people have never met each other, never spoken to each other because they're from different departments within the organization. So I think being that sort of coherent team and the building a common set of objectives out from the result of that process is really important.

(17:28)
Because again, if you're not sort of thinking about what is it we want to achieve from this and it isn't just about, you know, the question I always ask when I would speak to a customer, I'd say, "What's your site for?" And if someone says, "To publish news articles." I'll say, "No, it's not to publish news articles. You're publishing news articles in order to be able to educate your customers about X, Y or Z," whatever it is. I don't tell them this, but I think it's really important to ... I always think about the end objective as a team, what you're trying to achieve. The CMS and the implementation and the selection that you've gone through is ultimately there's a tool to help you further your kind of endeavors as an organization or a company. It's not there just to be a CMS implementation for the sake of it.

Hey, let's go back in time to when you were a fledgling, innocent young developer working in the trenches, building things with Episerver at the time, I think I came to London and you and I had beers at a London pub. I told you I wanted to get fish and chips and beer at a London pub and I think this was back when you were in the trenches before you came to work for the company. Tell me, what was your biggest frustration as a backend developer, trying to make customers happy, what was the biggest challenge?

Interesting question actually. I think as a backend developer at the time, and I was kind of an architect, I think there's always a toss up between that kind of desire for technical purity and all the marvelous trying to create the perfect thing every time with the need to compromise and balance that with customer needs. And I think to me, technology implementation is only ever about compromise because it's one of these things where I think it's just never having enough time to do the perfect thing you want to be able to do. And I think that was a bit of a frustration. I think working with Episerver at the time, I never found a problem with the product. I found that particularly the way Episerver has implemented it is that you can extend everything with code if you can. So I was fine sort of writing that code out and getting that done.

(19:25)
I got very comfortable in that position. And I think understanding the customer requirements for me was always interesting because I loved that, and I think it was then trying to articulate that to people who perhaps didn't want to speak to the customers or just wanted to be on the end of a specification. And then when you're then trying to articulate and talk about the concepts you've got in your head in a way that to me it felt obvious and I'm like, "Don't you understand this is how a customer would think?" And it's kind of translating those customer requirements and those user requirements into something a backend developer can not only implement but actually make usable and relevant to a front end user [inaudible 00:20:04] better word, but a web editor.

You have once again played into the common theme of this entire podcast series, and that's that the most important thing in an implementation in a project, it's not necessarily technical skill as much as it is your ability to connect with humans and understand them and make them understand the pressures that you're under. You talked about trade-offs. One of the most critical skills for a backend developer I feel like, is take a desire from the customer and explain all the different ways you could do this and what's good and bad about each different way. And this has been really the common theme of this podcast is fundamentally it comes down to communication and it comes down to empathy. In fact, somebody I know who may or may not be on this podcast can talk a bit about empathy as it relates to the practice of a profession. Can't you do that, Corey?

Yeah, I did it once a long time ago. I'm writing a book about it hopefully. So yeah, this idea that when it comes to communicating complex disciplines and complex practices, that the biggest disconnect is between a client and the client might be somebody in a different department, it might be a stakeholder, it might be an actual client who's paying you money and the practitioner who has to try to balance their own language and balance their own knowledge with the actual real world application of certain things. And David, I do have a question when it comes to that. When you're talking about being able to get a client or somebody who's leading a project to communicate user needs and communicate actual functionality and how you translate that into some kind of development code, are there, I don't want to say tips and tricks because tips and tricks are hard to just come up with on the spot, but is there anything that you recommend for a client to help you understand what they need in a way that allows you to take their idea and the potential 13 or 14 different versions you could create and make it work for their specific site? Is there a way that they can easily communicate what might turn into a development implementation idea for you?

I think for me, I love trying to state requirements as given when then. Given I am someone, when I'm doing something, then I do something else and trying to help customers refine that down as well. So given I'm a web editor, when I hit the edit button, then I can publish content. You go, "No, no, no, actually given I'm a web editor, when I create a new article, then I can communicate with my customers to do something." So I was trying to sort of drive it back to something, what's the meaning, what's the reason for doing this thing in the first place? Because we've all seen the requirements where someone says, "Turn the button blue." Why? I was ask that question why it is? And also I think asking customers where if you allow them to talk, that's the best thing you can do because you can help them.

(23:17)
Like I say, coming back to that therapy point, if you can speak to your customer, speak to your clients and say, "Why are you doing this? What are you trying to achieve? What does your boss want from this?" And that helps you at least understand that requirement. And for me then translating that into something that you implement at the back end is a very different thing, because at the back end of [inaudible 00:23:36] you've got technical purity and you've got all the kind of stuff where a developer's mindset comes into play and "Ah, we're not going to repeat anything and we're going to reference everything." And you go, "Yeah, but as a web editor, this makes no sense." "Oh, it's really good because if we're not repeating anything." "No, as a web editor, this makes no sense." And I think that's the point in that if people are using these things every day, you know, when we implement CMSs, we're building machines for people to do their jobs.

(24:01)
We're not implementing code. So what does that machine have to do to help them do that job? And if we can't think or answer that type of question, I don't think we can have a very good outcome for it. And I think, again, coming back just to using software and using solutions, I think one thing that I realized even when I was implementing, you never actually get to see people use your software a lot. A lot of the communication, particularly when it got to the hard bit of actually implementing and putting content in was around QA and tickets. And I think just sitting, I used to love going out to the customers and just sit with them, listen to the conversations and actually see what they were doing. And then you get a good idea of what it is you're trying to achieve with that implementation.

I drove to Minneapolis this week and on the way home from Minneapolis I was listening to the Hamilton soundtrack and there's ... Corey's wondering where I'm going with this, but there's a line in Hamilton where George Washington tells Alexander ... Alexander Hamilton is kind of young and idealistic and George Washington is older and more seasoned, and he tells them something like, "Winning was easy, governing is harder." There's that line, "Yeah, the winning, the Revolutionary War was the easy part. Governing a new country is the hard part." And I maintain that writing a new CMS is easy. Making existing one work is harder, actually getting in there and making it work over time. Because when you're writing something new, when you're creating something from scratch, everything's theoretical. And I think the opposite of backend development is theory, right? Theory versus praxis. Backend development is just 100% praxis. It's trying to make two boards fit that weren't designed to go together because this is what the customer wants.

(25:37)
And Corey talked about empathy and he did this great talk about empathy. And I think that really applies here because our job as backend developers was to listen to what the customer wanted and try to understand their need and understand what they want and manipulate the system in such a way to provide it. And it may be in such a way that doesn't do exactly what they want and that's part of being empathic, because as a backend developer, don't do what the customer says, do what they want. And it's your job to dig through the layers of what they say and figure out what they actually want and implement it that way. That sounds weirdly philosophical, but that's kind of the way I've always looked at it.

Yeah, yeah, I agree. And I think it's kind of getting to the bottom of what it is that they want. And I think to switch to almost like a technical viewpoint as well is that I've seen many brilliant developers, and I would call them just developers, not a backend developer where they approach particularly CMSs as just another development tool, but all they then end up doing is almost trying to abstract away everything good about the platform to the point where they just write code because that's all they want to do. So yeah, I think for me, I was called a good CMS developer as a platform developer, one who can get the empathy not only with the users, but actually with the technology you're working with, understand that's the way it works. And developer developers will, "Oh, I don't like it. This is rubbish, I'm going to do it my way."

(27:06)
But then you change the mindset, you change the implementation pattern, you change what people are used to when they go out and implement. And what you end up with is just this huge layer, this abstraction between the CMS and the platform and what's actually happening out in the real world. You go, "Well, is there any point in putting a CMS in here then?" Because I think that's the way they approached it. So I think for me, when I was working with developers, I was always conscious of are they a developer developer, or are they a platform developer? And platform developers will know that they can get the best out the platform by knowing all it can do. And if that means compromising on the way something is done, storing it in a particular way that's not technically purist and perfect, that's fine because it's still meeting the customer needs. And I think that just switching that back around from a mindset of the developers are working on the platforms and implementations as well.

I think it's great that you brought that up because I always say that is you need to work with the system, not fight the system. For instance, I did when I was working in services, did several implementations with Drupal and if you've ever used Drupal before, it's a very capable system, but it's also a very quirky, idiosyncratic system. I always maintain, there's like this weird kind of religion to Drupal. You need to submit yourself, you need to surrender yourself to the Drupalness of it all. And if you try to implement Drupal, like for instance Episerver or like many other systems out there, you're going to go slightly insane. And there's an arrogance to that. It's you saying, "I don't care how the system works, I'm the developer dammit, and I'm going to do it my way." And I think there's an arrogance to that that will come back and sting you.

Yeah, yeah. I agree and I think it's a hard fact as well I think that particularly a lot of codes in general, particularly in the MarTech community and in CMS as well, is that if people write the code as if it's going to live forever, it's probably going to have a 3, 5 maybe 10 year lifespan if you're really, really lucky, so it doesn't have to live forever. It has to solve the problem in hand based on what we understand today and not think about what could happen to tomorrow. I think you guys know more about this, but I think was it Obama or something when some technology and there was literally abstractions on abstractions and abstractions and abstractions because people didn't like the way it was being done or something? Was that a story about Obama or something?

The health care dot gov fiasco I think is what it was.

Yeah, exactly, and that's the same thing to me. It's like, "No, just work with API directly because it's going to do what it does and the vendor's going to support it," as long as you do it in the proper way, like you're saying, then it comes back to saying if you follow what the documentation says and you follow how the vendor says it's going to be done, then you're not going to go too far wrong from the truth. If you go off on your own path, then you're kind of on your own because then you're supporting your own code again. And that's when you get into trouble.

When we talk about the arrogance of developers, and I say that because I have been a developer and I have been arrogant and I've tried to pummel a system into doing it the way I think it should go and with disastrous results. I think another key for a backend developer is understanding when to cut corners. And by cut corners, we think cutting corners or take shortcuts or maybe do something that isn't ideologically pure, and I think that's universally a bad thing, but sometimes it's not because budget and time pressure are real and there are times where you can engage in what's known as yak shaving, and yak shaving is when you spend way too much damned time doing things that are going to provide no practical benefit.

(30:32)
It's a form of procrastination somewhat. And I always found that one of the greatest skills in the developer is to know where the bodies are buried, know where to dig so you don't hit a body. Because really knowing a system is knowing the good parts of the system, but also knowing the bad parts that you sort of need to work around a bit and knowing what parts really matter and what parts really don't. And that just comes down to leadership. One of the greatest skills of a leader is the ability to know what matters to an organization or a mission and what doesn't. And I found that's really important in backend developers knowing really what matters in the long term and what doesn't.

Yeah.

Well, David, thank you so much for joining us. We always ask this kind of question. We always ask is there anything that you want to promote or anything that you're doing? But consider you and I work together very closely, I pretty much know everything you're doing. Is there anywhere, David, that we can see you on the road? I guess here's a chance for you-

Are you going on tour?

We're not going on tour, but we will be able to see you stateside later this year, won't we?

Yeah. I hope be at Opticon. There's going to be talking about some good exciting stuff there from Optimizely and, yeah, certainly over the summer months as well, if there's any sort of developer meetups, particularly around Europe, trying to get to those as well. But yeah, if not, I'm hoping to be an Opticon and probably all of them as well so I'll be at the European ones as well. Probably not the Australian one, but that'll be, I don't think we have ... Do we have Australian? I can't remember now, but it's this year. I haven't checked. But yeah, I think I should be in San Diego. I hope so. It'll be good to meet everyone who's listening to the podcast there.

That was a huge setup just to promote Opticon.

Thank you, Deane.

Thank you very much, David. I appreciate you joining us.

Thanks, David.

Thank you. Cheers.

Deane, we're back and I have one comment. You should have talked about yak shaving in episode 24, because I know you had talked about it before and I was trying to figure out when it was, and you spoke about it at the very first intro of episode one of The Web Project Guide when we had Bill DeRouchey on.

Oh, that's right, because I brought it up. I actually read, I did some research on yak shaving and I actually did some research about where the term came to and it was popularized on a Ren & Stimpy episode.

Sure.

But yeah, yak, shaving, very, very important thing to understand. It is fundamentally a form of procrastination. That was a great conversation with David. I love David because he's got a very kind of upright English sensibility about him. I always feel like he sounds like James Bond no matter what he says. It sounds incredibly wise and sage. And I just think it's funny, prescient that we keep coming back to social skills and human skills.

Yeah, yeah. It's all about that sort of idea of, and I've been talking about this a lot lately because I just gave a talk at Confab about it. But this idea of demystification, of how do you boil down what you do in a way that helps other people understand so they can actually help you make decisions? Like, this idea that you can develop anything you want without constraints and just go hog wild and create whatever you think is going to be perfect, but it's not going to work unless other people are involved in helping you boil it down.

And I think that a developer who doesn't know how to communicate and who doesn't know how to balance the different constraints. Technical purity and technical cleverness is not always the most important thing. It's fun to be clever as a developer, but sometimes being less clever is helpful, especially if you're handing the code off to somebody. If you're building something for higher and then handing it over to the organization, maybe be less clever, maybe kind of dumb it down a bit and that's a requirement, or have to understand the future. Budget is a requirement, schedule is a requirement, so many things are requirements. And the key skill for a backend developer is being able to communicate, being able to empathize and be able to correctly balance different requirements and know what those requirements are. Too many developers think requirements are just the milliseconds of rendering time or computational time or something like that. No, there are human requirements and too often we forget those. So good conversation, good perspective.

That wraps it up for us. Thanks to our guest, David Knipe who is vice president of product at Optimizely. You can read some of his thoughts on development and specifically on Optimizely development at david-tec.com. That's D-A-V-I-D-T-E-C.com. I found that he's got a website. He does update it. He didn't promote it, but he does have it and he does update it so [inaudible 00:34:52]-

He does. David publishes all sorts of Optimizely code. He's a sharp guy.

The Web Project Guide is a product of Blend Interactive, a web strategy design and development shop that builds websites and guides teams through complicated web and content problems, from content strategy and design to CMS implementation and support. We are dedicated to making great things for the web, and this is one of those things. This is episode 20, Deane, of The Web Project Guide, which also corresponds with chapter 20 of the book, implement the backend functionality. You can read the full text of this chapter at webproject.guide/implement-backend.

(35:27)
Listen, if you're hearing this for the first time or if you've been listening and want to better understand the scope of what happens in a web project, it's time to order your own copy, The Web Project Guide at order.webproject.guide. You can get a physical copy. You can get a digital copy, you can also just read it, but you should buy a copy of it because it's a beautiful book. And then finally, go to your pod catcher and give us five stars or head to Amazon and find The Web Project Guide and give us a good review. It all really, really helps get the word out about the concept and the podcast in general. So with that, thank you for joining this month, subscribe, share. We'll be back next month to talk about the most harrowing task of any web project, migration. And until then, go do amazing things.

Good luck.