Transcript

Jen

This is The Web Ahead. A show about changing technologies and the future of the web. I'm your host, Jen Simmons, and this is episode 113. I first want to say thank you so much to today's sponsors, O'Rielly's Fluent Conference, and Squarespace. I'll talk more about them later in the show. Let's get rolling. My guest today is Husani Oakley. Hi Husani.

Husani

Hi there.

Jen

We are looking at each other, which is always completely awkward for me. But once again, I'm in person. We tried to do this show over Skype, but apparently my in office recording studio that I use for Skype has given up.

Husani

I told you, there's a tear in the space time continuum right under where your recording equipment is. I'm convinced.

Jen

Yeah, I mean slowly, slowly, slowly, the sound quality of the show has gone down and down, as that studio has...I don't know, is rusting something, and then we got to this place where we tried to do this interview and it, I just called it. This, no. Hey! You live in New York, I'll just come to you. We used my portable recording studio.

Husani

It's very portable, by the way.

Jen

Yeah. So hello. You are, this is the other thing I'm going to tell the listeners, might seem awkward, I don't have a computer in front of me. You're the chief technology officer at Gold Bean, an online investing platform.

Husani

Yes. Gold Bean. We help people who are beginners to the stock market learn how to invest, and then invest in an easy to use platform. You can think of our product as having three main pillars. One is receiving personalized portfolio recommendations. I like to call that, "Buy what you know", and it's based on your current spend and a couple questions up front about where you live and your age, and your income. And we put all that into an algorithm and we look through your spend, and we say, "Hey, you spend lots of money at Company X, our algorithm rates Company X as a really good investment, perhaps you should buy some stock in Company X."

Jen

Huh.

Husani

Lots of people want to start investing and they'll make an eTrade account, or a Fidelity account, they've got a little bit of cash, and then then log into their account for the first time and then they don't know what to do. And they're sort of frozen there on these really confusing screens with lots of charts and graphs and aren't really sure how to get started. Our goal is to help them get started.

We do that through the second pillar, "Ongoing Education". So there's lot of really informative, really easy to understand content on the site and we push out a bunch of update emails a couple times a week really explaining what appear to be fairly complicated concepts, but they're not. It's like technology, right? Once you get past the hump of understanding something, it's really not that difficult. You don't need to watch CNBC everyday. You don't need to get a subscription to the Financial Times. You really do know more than you think you do just being a consumer living here and watching television and seeing commercials and seeing what your friends are buying. Knowing that airline tickets are going up. What does that mean? How does that translate to how the market is doing and how can you use that information to benefit yourself financially.

The third pillar, it's the boring one, but it's super important is "access to an easy to use trading platform". We spend a lot of time and a lot of mental energy trying to come up with ways to show a complicated concept and distill it down to its essence. So if you log into your Gold Bean account and you want to buy 20 shares of something or 5 shares of something, the interface is like an eCommerce interface. There's a shopping cart. There's an add to cart button. Using those metaphors that people are familiar with, it's like logging into your Amazon account and buying a book, and less like logging into the mission control panel and trying to figure out what gauge to press and which button to press.

Jen

[00:04:13] Yeah. Nice. So you're head nerd over there, and you also speak at a bunch of conferences, I think it was How, right? We were up in Boston that week.

Husani

Yeah.

Jen

Yeah, and I did three in one week. And I stuck around to see your keynote at the end of the day, and I really liked what you were talking about. So I wanted to have you on the show to talk about that stuff. What was the name, I should...again, I don't have a computer in front of me. What was the name of your presentations?

Husani

It was called, "Figure out what sucks. Don't do that".

Jen

Ah yes, right. It's easy! Just figure out what's bad, and then don't ever do that stuff...it's the secret to life.

Husani

Yeah, it's not that hard. It really isn't.

Jen

Yeah, it felt like what you were getting into was, it also just seems like this ongoing, ok I'm going to take what I remember from what you said and I'm going to blur it together with what I've been noticing in the industry lately, which is this on going feeling of angst, or something. Especially for a lot of us who have been doing this for a long time, it feels like a lot of people I know are untethered, and they're floating around going, "Why is it that we do this anyway?" And then the people who are new are excited and like, "Yeah, let's do this." But then they're also feeling like, "I'm never going to be able to figure this out. This is way too much stuff. It's way too hard." And it feels like you were talking about, you were describing that angst, or that situation that we find ourselves in, in a way that I haven't heard anyone describe it, quite. Because a lot of people are talking about this, I see a lot of blog posts, or other podcasts, or even other episodes of The Web Ahead, we've talked about this, but it felt like you were talking about it in a way that I haven't heard people talk about it. And you were describing some ways, not solutions, but just some ways to see things that maybe make it not quite so untethered or something.

Husani

Yeah, those of us who have been doing this for a long time, when we got started, we just made stuff up as we went along, and there wasn't that much to learn because there wasn't that much to be able to do. You pick up some basic HTML, maybe a little Perl for some CGI scripts or something, there was no thought about UXing and wireframing and such, it was just "OK, I'm going to go make this thing. We drew it out on a whiteboard, we're just going to go make it now and it's going to be awesome." And you could do it, I won't say fairly quickly, but you could do it without a lot of little niggly bits. Little tiny side trips to figure out what framework you're going to use and which cloud service you're going to host on.

Jen

Yeah, you opened up your FTP application, you dropped the files on your server.

Husani

Right, you just did it. And as technology changed, both client side, server side, hosting, everything, mobile, it's gotten more and more complicated, and more and more complicated, and more and more complicated, and I think one of the things that we tend to do is get lost in the complication. Complication for complication's sake. I won't call it busy work, but I'm totally guilty of this. You're working on a project now, because back then there were five things you had to consider, now there's 752 things you have to consider, right? And you get to consideration number 5, and you're like, "Oh, I remember the last time I had this problem, and I remember all the things I did wrong. This time, I'm going to do it better, I'm going to stop thinking for a second about the larger problem I'm trying to solve, about the larger thing I'm making, and I'm going to solve this problem. How do I load a config file," or something like that, and you spend four days living in your beautiful new config file. Semicolons? yeah. Single quotes or double quotes? I don't know, let me go over to stack overflow and see what the latest thought is on single quotes versus double quotes. You get lost in those details. And then the new folks look at how we do that, how we're getting all lost in the confusion, and they're like, "Ooooo, wait a second, I just wanted to make a site where my cat photo was in the header. I gotta learn...?"

Jen

Yeah, now you gotta spend four days on stack overflow to research single quotes vs double quotes, because clearly that's important.

Husani

You're spending time on it, of course it's important. I don't know, I'm a beginner, right? I see you spending hours and hours and having Twitter fights over this framework versus that framework, or little tiny details that, those details aren't really that important to the end goal you're trying to get to.

Jen

So it sounds like you feel we should keep our eye on the prize, keep it on the end goal, like, don't worry about single quotes versus double quotes, just use whatever you feel like because what you're really trying to do is finish this ticket that's about implementing a faster way to register for the website. Is that right?

Husani

Yeah, that's exactly right. And if the way to solve that ticket is changing from double quotes to single quotes, then knock yourself out, but you gotta know deep down when you're getting lost in some of those details, that it just feels good, so you're going to continue to do it, it doesn't actually, you can't draw a direct line from solving this problem to solving your client need, answering that ticket, changing that thing that you wanted to change two weeks ago. At least I don't think so.

Jen

[00:09:47] So where, because it seems like in a way, what you just said could be interpreted as, code faster. Get the ticket done faster. Don't worry about the details, just do it quick. And, one of the results of that pressure, which lots of time developers, and other people too, it happens for designers, it happens for everybody, you find yourself under that kind of pressure, "Get that done faster, don't worry about those little details, it doesn't matter" that can end up in a pile of, let's call it technical debt.

Husani

Oh yes.

Jen

There's the G rated version of what that is, right? And then later you end up realizing, "Oh gosh, we have single quotes over here and double quotes over there, and curly brackets over here and square brackets over there, and tabs and, I don't know, it's not about tabs versus spaces, but it is about different people using different techniques perhaps and ending up with code that's all spaghetti crazy, versus taking time to say, "No, let's come up with some coding standards, let's even write a script that's going to enforce them, let's come up with a style guide, let's write tools that are going to make the style guide easy for everyone to use, including people who are not developers, let's come up with an editorial," I forget what it's called when it's "Hey, this is what you're supposed to write around here." Editorial style guide, or there's these systems that have been created for reasons, they have been created to solve problems, create efficiency, enforce standards, prevent bad outcomes, so how in the world, where do we find the balance?

Husani

Yeah, that's the question, right? At what point do you develop those standards, do you develop them before, do you develop them as you're going, do you get to the end of your project and then say, "Ok, we're going to stop and we're going to develop the standard, and then sorta back trace and then...

Jen

Redevelop everything?

Husani

Right right, I've done that.

Jen

Not gonna happen.

Husani

Yeah, I have. Well, I've attempted to do that.

Jen

Right.

Husani

I won't say it worked out well for anybody.

Jen

It's painful.

Husani

[00:11:50] Very. And I think in large part it depends on what the end goal is, right? Is this project, or this thing that you're making, whatever it is, right, is it meant to be used by other devs, are you the only one who's ever going to see this? What's the distance between the potentially minute problem and the end goal? How far away? If it's further way, it's probably not the most important thing. Again, if you can draw a direct line from, "Well, we've gotta have standards because we're all contractors on this project, and in six months it's going to be an entirely new team of people working on this, so we've got to get our ducks in a row." Then clearly getting your ducks in a row and doing the double quote versus single quote is a really important thing. So maybe it's not so much the specific details, and more, are those details really important for what you're trying to do.

Jen

Yeah, I guess there is something in there so often we talk about frameworks, we talk about tools. These days it seems like all we talk about is debating whether or not this tool is a good idea, or which one we should use, but I see very little discussion of what kind of context is this a good tool for. React! Ok, this is the context in which React is a great solution. Oh, versus Angular! Ok, here's a different context that's sort of similar, but also slightly different, and here's how it's different, and this is the context that maybe Angular would work better in. Ok, here's the context for saying, "I don't need to know what those words are, get away from me." These are the kinds of projects that you should not even spend fifteen minutes considering frameworks like this because there's no way you should use them. Here's the context where maybe you should evaluate them all. Spend a month doing it and reject them all and write your own from scratch based on bits and pieces, frakensteining different ideas together because over here you've got the budget of Amazon.com and over there you've got the budget of the restaurant around the corner. That is a way in which engineers and developers, it feels like what it means to be an engineer or developer these days means being no where near a place where you understand what kind of context you're in. I don't know, what do you think about the context?

Husani

I think it's hard to know the context you're in, and the larger your team is, the more people you're working with, the further away you are as an individual from the end goal. If you're a midlevel engineer in a 200 person organization, you've never met the client. You show up to work every day and there are tickets and you just kinda solve them.

Jen

Right.

Husani

There's a difference between being that person and being the lone gun.

Jen

Yeah, the person who goes to the coffee shop to meet the owner of the coffee shop and help them build their website.

Husani

Yeah, you're talking to them and you know that you start saying React and Angular, and they're like, "Yeah, but do you want a latté?" They don't know what you're talking about.

Jen

Right. And they shouldn't.

Husani

And they shouldn't. We do. That's why we spend...that's why we don't sleep. That's why we do what we do. We're the problem solvers, so the more understanding you have of, I want to say your place in the world, but that's so not what I mean, the more you understand where you fit in your team, where your team fits in with the client, or the end user even, you have to take all of those things in consideration.

Jen

Yeah.

Husani

Even for the minute details, because you have to decide whether they're minute details or important.

Jen

Right, I mean there are all kinds of things that over the years I've had strong opinions working with other developers where I think they're spending too much time on something or over-engineering something, and then other opinions where they're not spending enough time on something, they're not paying attention to something. I mean typically, I think people aren't spending enough time filling out help text fields, when they're building a Drupal website, and they could, or taking time to name things in a way that makes sense for the people who are going to be entering the content, and they could, they should. It's an ongoing theme in Jen's life. It's on the list of things I talk about all the time and I'm sure it pops up in the show. And then I there are other things where I feel like people completely over engineer things like, in the context of Drupal, any time anybody whips up Panels, I'm like, "What are you doing?" Odds are, you're over-engineering. There's a chance that you've hit on one of the situations where this is the right tool for the job, but history tells me you're probably over engineering. You probably reached for a cannon when you needed a knife.

Husani

Right. And can you find the time to stop after you've done that and be a little self reflective, and think, "Did I...." How often do you look back at your old work, two weeks ago, how often are you going back and looking at it.

Jen

Right.

Husani

Do you even have the time necessarily to take a second and be a little introspective. "Wait a second, I didn't need to write a hundred lines of code for that, what am I doing?" That might bite you in the rear a year from now.

Jen

There's a good chance you've moved on, but there's also a good chance, for anybody that's been doing this for two or three or five, or thirty, not thirty.

Husani

That would be impressive.

Jen

Twenty years. Lots of time, you do, you're asked to go back to a project that you haven't worked on in a year, especially if you're working for smaller clients, and they come and they say, "Oh, I've finally saved up $3,000 more and I want you to add this to my website," and you're like, "Ok, no problem, I'll open up the site I built for you two years ago and you look at it and you're just like, 'What is this'"

Husani

And you're like, "I'm in a fight with my past self."

Jen

Right.

Husani

And you spend, or at least I spend a little bit of time in this dark place of, "What was I thinking? What was wrong with me? Why did I do it that way?" And I think I do it that because I get caught in the trap of every time I'm solving a problem, I'm going to solve it in what I think is a better way, and it's not. Maybe it is, but there's been such distance in the mental model used to solve a specific problem between when I did it three years ago for that client and when I'm doing it now, you look back at it and, "What were you thinking, of course there's a better way to do it." I don't know that's necessarily accurate or not.

Jen

Well, I think some of that is going to be true about everyone who creates work, no matter what kind of work you're doing.

Husani

Yeah.

Jen

You make a painting and five years later, you're like, wow, I was a bad painter five years ago.

Husani

I'm terrible, what am I doing this for?

Jen

I think that's the nature of growth and learning, and I think in our industry it's accelerated. I also think that the industry itself is changing and growing and we're learning thing as an entire industry so we might have thought one thing about how to do responsive web design in the first six months of it, but then two years later, we realize those original ideas about having separate style sheets for each size screen--

Husani

Oh yeah!

Jen

That was a terrible idea. Or like, it took us collectively as a group, it took two, three, four years to figure out stuff, and that happens a lot. But I also, oh, you're going to jump in with something?

Husani

Yeah, when the world moves on like that and you have to go look at your previous solutions, what do you do? Do you live back in the world of the previous solution, or do you say, "Wait, we've moved on, I can completely revamp that to be much more in line with how we're thinking of things now." That's an open question.

Jen

Well, I think the answer to that question is what you said earlier, "What's the context that you're in?" If you've got $3,000 to add to the dentist's website, is that the best use of his $3,000? Refactoring the code that worked perfectly well? Yeah, probably not. Do you want to do it for free? Maybe you do want to do it for free. I have a client who I built a site for ten years ago and there's part of me that wants to go back and redo the whole thing as a responsive website using border-radius because we didn't have border-radius back then, and the things I had to do to get all these beautiful round corners were so crazy, and it would be fun to clean all that out and then make it all responsive and then build it in a much more robust way. But I clearly would have to do that for free. So, do I want that? I have a lot of ideas of free stuff I want to do, so you know what? That hasn't risen to the top yet. It might. But it's hasn't yet.

Husani

That's context, right, that's "I can spend the time doing this, or not."

Jen

But you could be in a very different situation where you have the budget or you should refactor it all, especially if you're working in a team and there's efficiency there to be gained by you spending two weeks refactoring something is going to save ten people hours over and over and over not having to beat their head against that wall.

Husani

Absolutely. That's the problem that you're solving, and you're not doing the refactoring because it's Tuesday and you're bored. You're doing it because you're saving the butts of the people who sit next to you in a couple of weeks.

Jen

Right. Or you're not doing it because you think you should. I guess in some ways, I've thought this myself, especially as I started read the work of the leaders of the web standards movement back when they were writing all kinds of amazing things and I was just barely trying to figure out how to make a website. I was reading their work, and I still to this day believe very deeply in it, and your HTML should be semantic, but then there's a way in which....It's almost embarrassing, "I don't want to use this CMS unless I can get in there and completely redo every little bit of the HTML because I want my HTML to be perfectly semantic and which element am I supposed to use...I'm not sure. Let me go see what HTML5 Doctor says about exactly how I should mark up a transcript, or...." Some of that is really good and I totally have done it within the last year and I will again. There's a good zone and then there's a way too much zone, and then there's this grey zone in between.

[00:22:13] So what does it take to have the awareness as we're doing this work? And we've been talking a lot about development, but I think the same thing comes up in all the other...design and everything else. How do you find out where you are in the zone of "Yeah!" and where are you in the zone like, "Ok, I might be taking this a little far," and then, "Oh wait, I totally just lost four days thinking about dts versus dl, dm, dd and unordered lists and...

Husani

You've got to be seriously objective about your work and honest with yourself. Which is a skill to have in life in general. I am the worst person at it. I tell myself such rationalizations and stories about my own work. I look back at my own code even code I'm writing right now, and it's "Oh no, I did that for a reason," but if I can't verbalize that reason or get into a conversation with someone and explain it, so maybe that's part of it, right. Can you explain why you think you need to go from 80% validating, yay! to 90%, you have to say it out loud. You have to talk to the person next to you and just say, "Let's do a sanity check here real quick. Do you think I'm losing it by wanting to spend the next two days doing this, or, what are your thoughts. Because what we do in creation in general, right, even if we're a team, at the end of the day, it's you. Your brain, sitting there, with all of your brain's strangeness and contradictory nature, getting another person's input is super helpful. Even a non-technical person, you start explaining what you're doing and why you're doing it and why it's important, and, "It's actually not important at all!" or, you realize, "This is actually super important. I'm going to spend the next week refactoring this stuff, or trying to get past different validation tools and such because it actually ladders up directly to an end goal.

Jen

Yeah, there is something about, especially for those of us who work alone....There are many people, perhaps, most people are making websites by themselves. I wish I had stats on that, maybe someday I'll do a survey. And of course, many people work on teams. You might be working remotely, so you might be alone physically, but you're in chat with your teammates. Or maybe you're sitting next to a teammate or in a mosh pit of 50, 100 developers working on something. But even then, you get your headphones on, and you're looking at your computer by yourself, you're not sitting next to somebody looking at a computer. It is part of where I think design doesn't necessarily go off the rails in the same way. More and more designers today work in a meeting room with post-it notes and they're talking to people, and they're putting things on the wall and they're drawing things and they're looking at them together on sketch paper. That kind of process when you're working, I wish it was easier to do that with development. Sit down with your team and put the computers away and just start architecting the things and just start making plan about what your technology choices are going to be, which tools you're going to use, and how you're going to build it out. Doing that physically, getting more physical abut it, because there is something about sitting in front of your computer by yourself, where we do, maybe there's something biological here, too, where you get more and more and more focused on the semicolon.

Husani

Right.

Jen

And the quote or the double quote.

Husani

Right, exactly. Exactly.

Jen

You can't even snap out of it. It's like you're in a trance, the double quote looks so wrong. You can't remember why we started using double quotes. We should be using single...

Husani

And you look up and it's like 6 pm and you're like, "Oh, ok, I started this at 10am and the quotes haven't changed. I've been going back and fourth in my own little quote haze." But maybe if you're on a team, if you're in a room, separate from computers, to your point, you've got a white board and some markers and you're talking it out and drawing it out and arguing over things, and thinking about things, and creating. I talk to myself, I talk to myself when I'm walking down the street just because I'm that strange person, but when I'm actually writing code, it's almost an interactive experience, me and myself. And when I'm sitting at home and doing it, it's great. The minute I'm around other people, I have to give the warning, "Hey, just so you know, I've got a really difficult problem to solve today, I'm gonna have a whole conversation, I'm going to be jumping up and down when I get something right." It's like performance art, it's really strange, actually. But saying things out loud helps me break that haze, and you hear yourself say something out loud, and there's a little part of your brain that's like, "Pffff, you know that wasn't right." Now that you've heard it, even just think it, or the opposite, right. "Hey, no, even out loud it sounds even better! When I can explain it with words, and less getting locked into the mental image rationalizations, it's a lot harder to lie to yourself that you're going down the right path or going doing the wrong path.

Jen

Yeah, though that's something I have to say about nerd fights. Like, when a group of nerds sit around and fight about stuff, verbally.

Husani

True.

Jen

There is a way in which no one stops and says, "Gosh, I just heard myself say that out loud and I think I'm wrong."

Husani

That's a fair point.

Jen

Right, there's a way in which everyone just grabs each other and shoves each other into their own haze, where "No, but I know thats I'm correct."

Husani

Emacs! Vi! Emacs! Vi~ is it V-I or is it vi?

Jen

Gif or Jif? Is it? Right? you can't even say it out loud because you can't even agree on how it's supposed to be said.

Husani

Right.

Jen

I wonder, it's a bit of a chicken and egg, is it the people who have these tendencies are drawn, or perhaps are extra skilled at those kinds of jobs, or is it that there's something about the job itself that draws out that quality that any of us have, that each of us have, that kind of hunker down nerd who has strong opinions about spaces and tabs and is going to tell you that your code is all jacked up because you used tabs and not spaces and they didn't even look at the code. I think we've all had experiences where we just walk away going, "Where do I live? What kind of universe am I orbiting in that other humans around me are behaving this way? This is painful. This is not enjoyable. This is hard to deal with."

Husani

[00:29:11] I've hired developers from various background, people who were artists, people who are artists, the thing that they do other than banging out code, there's a violinist, there's a dancer, there's some other thing, and the pattern that I've at least found, is that the way that they create that other thing is the same way that they create this. And there's an underlying mental infrastructure of how problems get solved, or how problems don't get solved. The process of their creation looks like it's the same regardless of whether they're banging out some python or doing a sculpture. From their perspective, I've seen it, I've had conversations with my various teams over the years about this. I tend to, I like hiring people without formal computer science degrees. Because I did back in the day, maybe things are a little difference now as technology gets more and more intense, since there are so many more details to deeply understand, and it looked as though people who understand how creation happens can just go create. And the way they did it was the same, I've found that really, really interesting.

Jen

It's an argument as well for hiring more diversity in teams of people, not just thinking, "Oh, this is what a coder looks like, this is what a good coder looks like," both physically looks like and the way they present themselves to the world. The way that they talk, how nerdy they are. We need to get all people, not just this one flavor.

Husani

Yeah, that doesn't work. It doesn't work. I'm convinced beyond any doubt that the more diverse of a team you have in all forms of the word diversity, the better your product is. You have other human beings with other life experiences using those life experiences to make something. And those experiences are different than yours, they have a completely different perspective on things. Or, they have the same perspective on things, but it's coming from a different place. The better, who wants to eat a salad that just has lettuce in it, right?

Jen

Right, yeah.

Husani

I find it massively frustrating that we're still having this diversity conversation. It's like, "Really? You have to be told how many times for how many years that this is an issue?" And solving it isn't just because of karma reasons, right. Solving diversity issues and having more diverse teams get you a better product. If you can communicate with a wider group of people, and isn't that what you want to do? Solve the problem. Hire people who look different.

Jen

Yeah, and earlier we were talking about finding that line between getting too down in the weeds in something and not, and it feels like if your team is too monolithic, then everybody finds that line in the same place, and your whole team could go down in the weeds together.

Husani

Yeah.

Jen

And if you have more diversity and more points of view, if you have people coming from different places, then you're less likely to do that with both coding and with design. You see that with design, where the whole team gets so completely convinced that the way they want to design something is going to work for everybody in the world, and they go completely down this one road, and yeah. That one road.

Husani

The person who has color blindness walks into the room and is like, "Yeah, you made that the worst possible color choices, come on guys, you ever heard of the ADA?" And then it's like, "Ohhh, right. Hey, if you had a more diverse team in the first place, you might have come across that issue and solved it much earlier in the process."

Jen

Or if everybody is from one specific narrow slice of culture, and then you want to reach and target audiences much broader and you wonder why no one else wants to have anything to do with your product.

Husani

Right, right.

Jen

Because you actually only designed it for one very narrow slice and everyone else is either offended, or just bored, or they just don't care.

Husani

I spent a significant portion of my career in advertising, and yeah, oh yeah. Diversity is an issue not just in technology and startups and dev, it's a huge issue in advertising. On the creative side, on the media side, on every part of the industry, it's been a concern for years. There have been lawsuits, it's been a whole huge thing. I can't tell you how many times I've been in a room looking at creative and, you look at it, and, "Wow, you just offended 20% of the population, but you wouldn't necessarily know because there's no body in the room of that population." It's not saying that you're a terrible person, by any, well, some people are.

Jen

Some people. But more often they're just unaware.

Husani

Right, but more often they just don't know. And frankly the way to fix it isn't to yell and scream at them to yell and scream a them because they just made a mistake. The way to fix it is to make sure the right people are in the right room at the right time where you can just talk about it and it gets figured out.

Jen

[00:38:00]
So, one of the things you were talking about in your presentation was you were talking about full stack coders. Which, the words "full stack" it must be something about the way they sound, they sound so cool, like I want to be a full stack designer. What is full stack? It's like, getting badges in some sort of program. Like, I got three out of four badges, I want the fourth badge so I can be a full stack.

Husani

Something about those words, the number of letters, full stack, the number of syllables, it just feels like "RRRRRRRRR"

Jen

Yeah, that's what it feel like, "Full stack. Ooo, upper case!" I remember the first time I heard that, I've never heard that before and I love it and I want that.

Husani

Right.

Jen

What is a full stack engineer? And you were talking about a full stack thinker.

Husani

Yeah, so full stack. Question one. What's the stack? Right?

Jen

Right.

Husani

So ok, you're a full stack coder, what does that mean? It means you write client side, you write server side. What about design? Is the fact that you design via the tools of HTML of CSS make you a designer? I'd argue yes. So does that mean you're a full stack designer and a full stack developer? Where are the stacks in areas outside of just development? Full stack. Does that include user experience and user experience design and so on?

Jen

Yeah, we think full stack designer means they're talking about being a visual graphic designer and being a user experience designer, but then I would then wonder, are you talking about business strategy? Are you also talking about content strategy? Are you talking about where might that stack begin and end.

Husani

Exactly. So I'd argue that a full stack thinker is focused on the end goal, and that thinker knows how far to go down each of those stacks that they are a full stack thinker of...I was going to say that they're full of, but that would go totally south.

Jen

Their stacked, whatever their stacks are.

Husani

Yes. They know how far to go down them to solve the larger problem, right? It goes back to what we talked about earlier with details and when do they matter and how do they matter. As you go down a specific problem, you encounter another problem. And then you encounter another problem. And it's literally a linear path downwards in order to solve A, I need to solve B. Oh, but wait, in order to solve B, I need to solve C, and so on and so on, and so on. So I define a full stack thinker is somebody who knows enough generally about all of the stacks, whatever those stacks may be, to know how far down each one they have to go before they stop and say, "I've solved all of this that I need to solve for the problem at hand, I'm going to go back up and move on to the next part of the stack as I make my thing."

Jen

Right.

Husani

And it's like a unicorn.

Jen

I thought it was like a turtle?

Husani

Oh yes, well there is that. I use these animal metaphors that, I don't know. I use the phrase, "turtles all the way down" all the time. The basic gist is, what supports the turtle? A turtle. Well, what's supporting that turtle? A turtle. On to infinity. Every piece of everything that you work on has a supporting piece, and that supporting piece has another supporting piece, so the question is how far down the supporting pieces do you go before you're like, "Ok, I've done this enough to solve my problem and I get out. So, I'm gonna write jQuery, what's under that? Javascript. What's under that? The DOM. What's under that? Webkit. What's under that? Electricity. How far down...?

Jen

The operating system for the device.

Husani

Exactly. How far down do you need to go? You don't need to go all the way down to the bottom. Sometimes it's fun though, to go all the way down to the bottom. It's really satisfying. You might as well just write everything in assembly, if you're going to go down every single stack all the time, and outside of development, into design. Do you need to literally paint every single pixel? Probably not, but you probably want to go in to a certain level of detail. And this is a terrible analogy, but the point is, you go in as far as you need to.

Jen

[00:42:32] Yeah, I think this probably came up in the old school way of doing things where "design" was making Photoshop drawings of finished webpages, which honestly was a vague attempt to represent a much more complex set of choices, and to me, design is the process of making the choices, not the process of drawing the Photoshop documents. But ok, anyhow, end my interjection. The question will probably come up, well how much detail should you put in that Photoshop document, and the easy answer is, "All of it." You could draw everything. But really? Everything?

Husani

Do you even know everything when you're at the point when you even have Photoshop open?

Jen

Well, that's the reality. The reality is you don't know everything. You didn't put a hover color in there. You didn't put in when the title wraps to two or three lines.

Husani

The error states.

Jen

You didn't put in what happens when the image is not there in an instance of the same content. Yeah, you didn't put in error states. Yeah, there's an incredible amount of complexity that actually some of which you did need to represent, but you didn't represent. But also things like, ok, so you started out with a sidebar a decade ago that was 160px wide, and then you decided to make it 180px wide, and you've got ten documents and you changed it in six of the ten documents, but you didn't change them for the other four documents. Any developer who's been on the receiving end of that waterfall design process knows exactly what I'm talking about because you're sitting there with little rules measuring things and you've got six documents that say that it's supposed to be 180px wide and you've got four documents that say it supposed to be 160px wide...

Husani

So which is it, designer? Which is it?

Jen

And the developer, can easily, I mean I of course never did this, just get "rarararar, why didn't this person finish their work? They should have fixed it!"

Husani

Those designers, GRRRRR

Jen

You changed the font from 13px to 14px, but not in every instance! So there's tons of very specific to Photoshop, and very specific to...but it easily could be the exact same thing somewhere else. When I was the developer, my opinion was they should have gone all the way down, right? "Why didn't you go down further?" But yeah, I guess there are questions of what happens when this person tries to register. Let's go through the registration flow, which use cases do we want to make sure we've covered really well, of course the major use cases, there are these side use cases as well. Ok yeah, let's cover some of those, too. Ok, what about this very obscure use case that almost never happens, but it happens sometimes? How much time do we want to spend on those? There is a stack of turtles there and you could just keep going down the stack of turtles. Where is it that you stop with the turtles? Sometimes I think people do stop way too soon.

Husani

Yeah, I think some of that is going to depend on who you're working with. I remember being that developer, where I'd see those four Photoshop documents and two of them said one thing and two of them said another thing, "Well, you know what, I'm the decider. I'm the captain now, right?"

Jen

I'd be like, "Well, I am a designer, and you didn't finish your work, so I'm going to finish it for you. Good luck"

Husani

It looks better at 14px anyway, so we're gonna make it 14px and what are you going to do? Because you can't write the code, so.

Jen

Or, "You don't work on this project anymore." Because you stopped doing your work six weeks ago and I don't even know you. I can't even email you and ask because we never met.

Husani

My argument used to be that I take a designer's input, like I'm a musician. So I would take, "well that's what's written on paper, but I'm going to perform it now. This is my interpretation of your design. And you've got to trust me enough, you've got to trust my knowledge of the medium in general, you've got to trust my knowledge and experience in how your work is going to appear to a person, I get how that get translated, so just trust that I am making this in the spirit of the design. And with the designers that I was really close with, they really got it. From there perspective, it was. "I don't have to go down those 20 turtles, I can go down five because Husani has got the rest. He always come through."

Jen

Right, right that's true.

Husani

But then when you work with new people, or people who don't quite understand that.

Jen

Strangers.

Husani

Yeah, yeah, I don't like strangers.

Jen

They're always wrong.

Husani

Yeah, they're totally wrong, and I'm totally right. That's just the way of the world.

Jen

That's so not true.

Husani

It's like the opposite is true. You would get in these conversations, you didn't do this, you didn't do that. The wall that developed forever ago between design and dev and the contentiousness of that wall, in a large part is the designer thinking, "You didn't build what I designed, so you're not a good developer." And the developer thinking, "Yeah, but I can't build..."

Jen

You didn't finish your designs.

Husani

Yeah, right. You didn't even think of these certain things. I'm doing your job for you, designer.

Jen

Exactly.

Husani

But instead of people just kind of talking out their problems, maybe I'm naïve, right, I keep saying, "Well, if you just get in a room and talk through things..."

Jen

[00:47:46] Well, I think that as an industry, we realized what's wrong with what you and I just described. That that process doesn't work for exactly what we just said. It's much better when you actually just put the two people in the room together and then they can figure it out. At what point do you want to stop with your set of turtles and let the other person start with their set of turtles, and then you come back later. It doesn't matter if you're the designer and you don't know the developer that well. It's easier to trust them if you know that you'll have another chance to come back around, it's not a giant hand off. That you'll never get another say again. That the only person later is QA, if there's QA department, and whoever the client is agreeing that they like what the developer said, but then you're trusting the client to enforce your designs.

Husani

You can never do that.

Jen

So a better situation is just like, "Well, you design some stuff, then they're going to build it, then you're going to look at it and say, 'Hey, I think we should change it, and in fact maybe my designs aren't as good as I thought they were. Maybe now that I see them actually built, let's make some adjustments.'" That kind of humanity and back and forth.

Husani

Real collaboration, because you're not the one doing all of it!

Jen

Yeah.

Husani

Again, those of us who have been doing it forever. A few years ago, I was at an ad agency, and I was hiring some engineers, and the engineers who had been doing this for a long time had very specific ideas about silos and where things are, and that's been in my head since I started in year I won't mention. And then I started talking to some newer folks, and we'd talk about this idea of silos, and they'd look at me like, "What are you talking about? You mean, person A does one job and person B does another job without any sort of communication? It just gets thrown over a fence? How does that even work? How have you guys done anything ever?" And it's like, "Oh, that's right!" So I have hope that as more and more new folks do this, and come in with fresh eyes and fresh brains without being saddled with all the baggage that those of us who've been doing this for fifteen, sixteen years, that they're helping push along what should be more collaboration. I also think that the open source movement in general has at least, maybe changed the culture a bit where collaboration is more understood as being a base skill, just as important as how you write code, or how you design, or how you UX. It's critical, because what we said earlier, you're sitting there by yourself, but you're not really sitting there by yourself. Even if you're a lone creator, you've got a client you're doing it for, you've got a user you're doing it for, unless it's thoroughly just for you. No one's ever going to see it.

Jen

You're making a website that you're never going to put on the web, you're just running it locally.

Husani

If you make a website and it isn't on the web, does it make a sound?

Jen

Right. It's not.

Husani

It's not. It's a file.

Jen

Yeah. Also, I think there is something about, just the way that you were describing Photoshop. As soon as you start designing with prototypes and start designing in HTML and CSS, a lot of that starts to go away. That's my theory, at least, it might not be completely true. Maybe that might not be true. If I had more experience working on big teams where those big teams did use more prototypes, I would begin to see the cracks in them.

Husani

True, true.

Jen

[00:51:32] But to get back to the turtles, I just find it fascinating, this idea that there's thing stacked on top of stacks on top of stacks. It's our individual responsibility to pay attention to how far down am I going and where is it....I'm going to have to make my own independent call about where I need to come back up and get back over to the next thing.

Husani

Right. Which means you have to be aware of which turtle you're on when you're on it, and which ones are next, right? You're working on a little detail, and then there's this one other thing I've got to do, and then I can get out of this and I can go on to something else. If you have a plus or minus two turtles.

Jen

That's the margin of error, plus or minus two turtles.

Husani

Exactly! If you have that in your head as you go up and down the stack of turtles, you at least have a sense of looking over the cliff, I'm mixing metaphors here, looking over the cliff, I don't know where that ends, I'm just going to continue to go down forever. You kinda know it's up to you to trust your instinct or not.

Jen

I also think that this is where agile, or at least agile as I've seen it used, really comes in and it's really helpful, because a SCRUM master / product manager, not project manger, a product manger, is basically a turtle manager.

Husani

Yes.

Jen

Who comes in and says, "Ok, here's all the..." This is what I love, when I've had the chance to use Jira, what do they call it now, Jira Agile, which they've finally fixed. They're not sponsoring the show, but I just feel like it's such a great way to manage a project because you're not managing tasks, you're managing outcomes. You're saying, "It's not that you need to get the such and such library and hook up the flunk a flunk tool, it's that you need to make this build process more efficient because we don't have efficiency here," or, "You need to speed up the website by fixing the fact that we're loading three copies of jQuery." Whatever, it's not a task, it's an outcome. So tickets are given to developers, and a developer has all the freedom in the world to figure out how they want to do it and what kind of tasks are needed for the outcome. The outcome is what matters. Then there's this person, the product manager, who sits down and looks at 150 things on the to do list and says, "Here's the priorities." And it's not developers who are 15 turtles down.

Husani

Right.

Jen

Focused on the quotes and the semicolons, or even having a good day and focused on building out that new build management tool, or creating the new whatever, or setting up the new flunk a flunk. It's the person who has the big picture in mind who says, "Actually, we really have to fix the registration flow and the accessibility before we add these three new features. And even though the three new features are much sexier, you guys are much more interested in working on them and if you were making your own decisions, you would totally do this first and ignore these other things. Lack of accessibility means we can't get any of these contracts, which is our total business strategy right now, and the other thing," I forget the other thing that I already said but, "that needs to get fixed because of these other bigger reasons."

Husani

Yeah, that's an interesting role too, because you have to have such a full stack thinker role.

Jen

Yeah.

Husani

You've got to have so much of an understanding of all of these areas. You've got to understand that this outcome that you desire is going to take a week and not going to take a year. You've got to understand enough about how the technology works to know that it's not some ridiculous large scale outcome. It is a very tangible, can check off a checklist of a list of outcomes.

Jen

Right.

Husani

You've got to understand the business strategy.

Jen

You've got to understand the users.

Husani

Yes. Exactly.

Jen

Most importantly.

Husani

That's what it's for. You have to understand to get in their head.

Jen

Yeah.

Husani

And say things like, "we" and not "they", like I just did. You're going to have enough of an understanding, but not a deep enough understanding that you get lost in the details, too. You don't need to also be a developer to manage developers.

Jen

Right, right you don't need to know how to build out this stuff. You just need to know how talk to the people who build out this stuff.

Husani

Right.

Jen

Well, and you need to understand a lot of customer service, as well. If you've already launched your product, if you have anything launched whatsoever, to be able to get feedback and study how people are actually using it compared to what you think they were going to use it for, and find pain point stat you didn't thing were going to be pain points, and then focus the whole team, the team might be four people, the team might be four hundred people, the team might be four thousand people, to get people focused on that bigger picture and keep an eye on whatever the results of this are going to be.

Husani

Why are we here? Why are we doing this? These sound like existential questions, but why are you working on this thing right now, there should be a reason why you're working on it right now. What you just said about getting user feedback and taking actions and running outcomes based on user feedback, that layer of a product person, full stack thinker type, is a nice layer to translate user feedback of "This thing doesn't work. You're all terrible people and I hate your brand."

Jen

You should die in a ball of fire.

Husani

Right. How dare you...

Jen

Exist.

Husani

Yeah, what's wrong with you? I can do this better. My little cousin can do it better. And it gets translated into, there's a problem with our login system.

Jen

Right, our registration flow doesn't work, people are feeling bad about life, and are very frustrated and angry.

Husani

And it's helpful for a developer to not get the anger.

Jen

That part of it first hand.

Husani

Yeah, that's harsh, that hurts.

Jen

Yeah, you need the buffer.

Husani

Yeah, you need the buffer.

Jen

Yeah, because it's probably not any one developer's fault, it really is...

Husani

You know what I do, I've noticed this about myself recently, when I encounter a bug in a piece of software, or something doesn't work as expected. Software, or even sort of physical things, I try not to be angry at the people who made it, because as an outsider, I don't know why that was made that way. There might be, for the team, a very valid reason why they didn't add feature X, or why feature Y works a certain way. It might be annoying to me, but there could be a business reason for it, there could be a personnel reason. Somebody got sick. I'm trying more and more in my personal life to be cognizant of the things that we use, people made them, people with their own...

Jen

Humans.

Husani

Yeah, other humans made them.

Jen

Not robots.

Husani

Even robots.

Jen

Humans using robots. But still, it wasn't...robots didn't make it by themselves.

Husani

There is a last turtle down that, and it's that we're human, so, you wouldn't want people to react to your working a certain way, so...

Jen

[00:58:50] I also realized one of the things that I think a functioning agile system helps is the sprint review at the end of a sprint and the sprint planning at the beginning of a sprint. I've watched some folks, and maybe this was me, too, I don't remember, I feel like it's sort of a waste of time. I don't want to sit in a meeting, we've got this four hour meeting, or this three hour meeting on Friday and then we come back on Monday and we have another three hour meeting, I could have been coding Friday afternoon or Monday morning. Why are we doing this? I've seen a lot of developers feel like this is a waste of time. But I feel like that time, which I guess if a sprint is two weeks or three weeks, that it's a whole day every two weeks or every three weeks, once you get done, it's a chance for the humans to connect back with the humans, and a chance for the developers to remember, especially if it's well facilitated, which probably normally, it's not, but in an ideal situation where the person running the meeting really understands the purpose of the meeting. It's not just about pushing turtles around, it's about looking at the stacks of the turtles and figuring out where priorities are and helping the people who are going to be sitting in the chair and getting hypnotized by their spaces and tabs and quotes and double quotes, to stick your head back above the water and remember, "Oh, right, we're all working together and we're making this thing, and this is what the thing is about. We care about the people! Look at this! We're build a financial, an investment tool, people can make smarter investments, whatever it is that we're making," and to see each of the tickets as what they're really for.

Husani

Right.

Jen

And to spend the sprint review meeting as, "Ahh, yes, look at what we accomplished," and also, "Ah yeah, I went down too much in the weeds on that," and not just a matter of, "Well, you aid it would take four hours and it took five hours, what went wrong?" or "You need to be more efficient," which I think is the normal way that we think about those meetings. And sometimes you get resentful because, "Oh my gosh our corporate overlords, could they please stop being like this?" but maybe there's a way to run this so that it's more about, "Ah yeah, I did get down too much in the weeds on that," or "Maybe I didn't get deep enough in the weeds on this. I accomplish that, but maybe I could have gotten a more robust result." Who knows. A chance for the team itself to have that reflective time on what we've just done, and then to turn around and plan the next week. There is something really nice about that weekend between the Friday and the Monday, you get to go home and not think about any work because there's nothing on your plate. You're responsible for nothing for one weekend. And then you come back on Monday and you start fresh again with a new sense of why is it that we're actually doing the work in the first place. What is it that we're actually making.

Husani

And that reminder of context being built into a process. When it's done right, it's great. It's great! For the team and the individual. And then you look back at your own way of thinking over the previous couple years of having those sorts of conversations every couple of weeks and you can see where you've made mistakes and where you've grown and where your weaknesses are. It really helps just taking a moment to reflect. It's good. Makes the project better.

Jen

[01:04:45] I think there's something in there that applies to regular, every-day, life, too. Where i feel like I struggle with, I feel like we all struggle with, what do i want to get done this weekend. I've got this extra free day, what am I, I know, I'll just watch all the TV, right? Like, no, I don't want to watch all the TV, ok. What am I gonna do? Am I gonna clean my kitchen, or am I going to do my laundry, or am I going to buy new stuff? Am I going to redecorate? Should I redecorate, or should I? For folks, I'm talking as a person who doesn't have any kids, right. Like, I'm aware that people with kids are like, "what are you talking about?

Husani

There's no time. There's no free time.

Jen

I think that in the moments where we have the chance, and new Years is always this moment where you do that collectively for the year, right? What is it I want to do this year, or how do I want to change my life? But there is something about, I think in my own life I haven't renewed, well, not renewed, first time ever, respect for, you can't do all the things that you just thought of. I can make a list of all the things I want to do. All the things I'd like to change, all the things I'm excited about, and that list would be like, five lifetimes long. And I can't do them all. And just having shame about that, or feeling bad about that isn't really a solution. How do I decide that yes in fact, it's very important to me to change what I eat, so I'm going to put a lot of time and attention and effort into buying cookbooks and buying new things that I need. Setting myself up and getting my kitchen going, and really....And then it's going to take me, because this is something I'm doing right now, I'm spending at least three months on this project. I'm going to clean out this one cabinet and chuck all the white flour that's in it, clean all this up. And I bought these new containers and I got beans, and rice, and actually four kinds of beans and two kinds of quinoa, and I'm learning how to cook it all and.

Husani

That's awesome!

Jen

Right. But that's a major giant life project. It's kind of fun, and it's invigorating, and it's something to do, and it's something that's hopefully going to have a big impact on my life. Where, "Ok what am I not doing?" There's another project, there's some other project that I could have done instead, like finding a different apartment to live in an moving.

Husani

There's only so much time, there's only so much mental energy in any give time period, and you can only do so much.

Jen

And by just choosing one thing or two things or ten things, whatever the number is, but choosing a really reasonable amount and going at it slowly, with a lot of space, it's actually really fun, and that's true for both work and life. We're going at something with like tons of, "Oh my gosh, I have to get this done and this done and this done" and "Ahh!! Oh, I set myself up with eight weeks of work and I'm only giving myself three weeks to get it done. So I'll just go really fast!" is no fun. It's no fun at all.

Husani

It's stressful. And the work suffers, or the thing that you're doing suffers because you're so laser focused on getting it done in those three weeks and not why you're doing it in the first place. New Years and New Years resolutions, you know, last no more than two weeks into January, but even if you take it along further, even if you do the whole year, do you at the end of the year, have that post mortem? Do you look back at your own personal work. That's a lot of work, right?

Jen

A lot of people actually do last to December. There were a lot of blog posts that were going up about that.

Husani

It's really nice, and if you're able to look at the things you want to accomplish and you split those up and you project and product manage those non-work things, I want to accomplish A, B, and C, alright, and we're going to do that in two-week or three-week increments, and at the end of each of those two or three week increments, I'm going to look back and ask, "What did I do?" I've my resolution, though I hate resolutions, really this year is attempting to get a little more scheduled focused, so that we all have that Evernote of 7,500 ideas that you must get done this year otherwise you're failing as a person.

Jen

[01:09:05] That's why a lot of people "give up" after two weeks. It's not that you actually give up, it's that it's completely unreasonable to go at it like that and you can either beat yourself with shame into trying to keep doing that, or you can say, "I'm going to stop, this hurts." But, you also could just not believe that the Evernote of 725 things is actually realistic, or is going to happen.

Husani

Right. Pick the ones that are important based on the context of how they appear in your life and smaller chunks. And if you treat this stuff like it's work, in terms of divvying up schedules, and I don't mean like, you've got a Gant chart suddenly of how you're clearing out your cabinets and buying quinoa, right. But if instead of 725 things, it's three things, and those three things are all split into sub things, but they all ladder up into one of those three big ideas, and it's spread across time, you can integrate it a whole lot more into your day to day life, or your week to week life, and your routines. I spend time every Sunday afternoon-ish, "What's this week going to be?" Not just work, work, personal, everything, what are the overriding themes of the week. Not so much to do this task stuff, because that's just a day-to-day thing, but when it's Friday night, what do I fee like? Do I want to feel like I spent the whole week deep down in code, do I want to feel like I spent the whole week going to the gym, and that's so not me, that's a really bad example. Is this week a week where I'm in investor meetings all week, so I need to be in a headspace of talking to people and less in a headspace of down and dirty in code. And then, decisions that happen during the week that might seem like minor decisions, like, "What am I going to have for lunch today?" you can run it through the filter of those week priorities, and this is again outside of just work stuff, it's like, "Well, am I going to have drinks with my friends tonight? Yes, because this week I had it in my head I'm not going to focus on X, Y, and Z." Looking at these things, using how we think of how we work and applying that to things that are not work, I have found so far this year, however granted it is early in the year.

Jen

Well, I do think that what matters the most is that we each notice, we each kinda know what we want, and that we each make our own decisions of trying to change, to use the methodology that works for us.

Husani

And then we look back and see if that methodology worked.

Jen

For a long time, I was a big fan of slash person-tending-to-any-minute-start-using, properly, the Getting Things Done methodology. And, I don't really want to explain it for people who don't know about it, but in my particular experience of it, what it translated to me, what it meant to me was, this idea of sit down and write down every single thing that you possibly should and could be working on, and then prioritize everything, and then start making choices about what to do. I think where it broke down for me was, I never wanted to open up any piece of software that had a list of everything that I was supposed to be working on. Because it was embarrassing and overwhelming and shame-inducing. It just felt like I was never going to accomplish it. And i didn't really think about that. I just never opened up my program. That was one thing. And then I also think the theory, the David Allen theory, and it probably works for certain people, and he coaches executives, like CEOs of major corporations, maybe this works perfectly for them, because they have assistants and it's more about managing a whole bunch of balls in the air because they, any of those people can assign those balls to different people, but in my life, the only person who is ever going to get assigned those balls was me. So to make a giant list of all the balls was completely overwhelming. And I think at the end of last year slash beginning of this year, whatever, several months ago anyway, it was like, "No, that doesn't work for me. It doesn't work for me to make a giant list of all the things that I want to feel bad about." I like your idea of just have a theme for the week. One thing. Just one thing. I will never run out of ideas of stuff I should be working on. I don't need to note it somewhere. I'm not going to forget it. If it's important, I'll remember it. If I don't remember it, it wasn't important.

Husani

But do you really want to have in your face a constant shameful remainder of how you've just wasted months and months not doing the things that you're being shamefully reminded of, all the time.

Jen

Yeah, so maybe I'll do this at some point, Let me go ahead and clear everything out of Omnifocus, and just put in five things, and then do two of them and put in one more, and then do three of them and put in four more, and then do six of them and put in one more, and not make Omnifocus...but anyway, in a way also, it's like, I'll do that, I'll use that tool if and when I need a tool to help me organize things. But I don't think I need that tool right now. Right now I just go home and open up my pantry and clean it out. And then I don't for two weeks, and then I open one more and clean that one out. Like, I'm not even...somebody else might just spring clean their entire kitchen...I'm just like whatever, I don't feel like doing that. But it's nice to step back and see overall, like, "Wow, I've really transformed this space physically, and what I'm eating, and whatever." This intention that I set, I've actually made a whole lot of progress on it without making a new list, at all. And that's valid.

Husani

It works! What works for you works for you, right? And the sense of getting lost in the details, getting lost in the tool selecting, getting lost in designing the process.

Jen

[01:15:14] Or applying technology! I feel like one of the tragedies of our generation, or really it's like three or four generations put together, this transformation that is happening, I guess it really started in the 80s, and it's going to end, well for each of us listening, it's going to end whenever we die. Each of us dies. So this particular transformation, this switch from the 20th century to the 21st century, there's an assumption in here, and actually it started back in the 50s, every problem is better solved by applying more technology. We need more food? Well we should process food more. More technology involved in the food system means better food. Oh, we need to organize our household, like the six people who live in the home, we need to organize what we're doing? We've been writing it on a calendar on the wall. What's a better way to do that? More technology!

Husani

Let's get an iPad and put it on the refrigerator door and so on and so on, right?

Jen

What's wrong with driving around in our cars today? Well, it's because we don't have enough technology, we need more technology! I want to be able to watch TV while we're driving and let the robot drive for me. And it's not about any one of those things. It's about human beings at this moment in time, this century, this hundred year span of time, we think more technology is better, no matter what, and I think that's not true.

Husani

Yeah, yeah.

Jen

Sometimes it's cool. Sometimes technology is awesome. But sometimes, less technology is better.

Husani

Sometimes setting up the technology takes longer than what you're setting up the technology to solve.

Jen

Yes.

Husani

To do lists, and such. And then...

Jen

Run gulp. Like, you spent so much time re-engineering your build process that you actually take way longer to push a website out than it used to.

Husani

Exactly. When will we realize that throwing technology on a problem doesn't necessarily solve that problem or make it easier.

Jen

It doesn't necessarily make it better. And I think that's part of what's wrong right now with our industry, to bring it back to that. Where, we're in this age where, "more complicated is better. More complicated is better." And for a while, on the web, going from 1996 to 1999 to 2003, to 2005, the addition of those technologies as they rolled out, was better better better better, absolutely. But I feel like we've hit peak technology. Like, last year we hit this point where it was, ok maybe we have enough technology.

Husani

Right.

Jen

Maybe more isn't better.

Husani

And there's something really interesting there. Up until, I'm going to throw a year out, because it feels right, like 2011, moar, M-O-A-R, technology, was good! It solved problems, but it feels like right around 5 years ago, ish, it's technology for technology's sake, or the problem that's being solved with the addition of technology, is very very minute, but we solve it with lots of pieces of big moving technology.

Jen

The tools are bigger and bigger and the efficiencies that we gain, each problem that we solve, is smaller and smaller.

Husani

But we think that we're solving the problem, that we're doing something with the tech, we're not just in there changing config files, configuring the new plugins to download, we're going to get patches and get all this stuff together, to solve that little minute problem, and by the time you've done that, you could have solved the problem in another way, or the problem wasn't that much of problem that needed all that tech.

Jen

Right. Now it takes you 45 seconds to build instead of two hours to build, but you know what else? It takes each new engineer to the program, it takes them a week and a half to get started instead of half a day to get started. So is that better? Maybe. Maybe not, you should count. How often do we ship? How often do we roll on a new person. Is there a process to get that new person to get on board? No, no process. Can we make one? Nope, it's never going to happen, well, maybe we want to make our build process a lot simpler because....There again, we get back to, "What's the right solution, it depends on the context." In this company, the sys admin team never changes what they do, so it's better to not change anything. This company, there's three engineers, they're never going to change, they're the cofounders, they all know how to use these build tools, they're never going to have problems using them, so absolutely. And they want to ship a new build every evening, then fine, absolutely build a new build process.

Husani

But for your cat blog? I always use the cat thing, and I don't mean to offend cat fans. I'm a dog person now, for the record, but I used to be a cat person, so I get it. We have to look back after we've applied the technology, to see if it was worth it. We see the problem, we assume there's a tech solve, we dump moar tech, roar tech on it, and then we move on to the next problem, we don't actually stop and say, wait a second, let's look, we can quantify this stuff, right? That took X, it now takes Y, is Y greater than X, yes no.

Jen

Right. Especially if you're a development shop and you're dumping it on a client, or a client's IT department and you're like, "Oh, good to go! Bye!" Maybe the IT department is completely overwhelmed because they've never used these tools. The evaluation may require going back and talking to the people that you've made this stuff for.

Husani

Talking to people? I don't know...

Jen

And not just being like, "well, not my problem anymore." Right, there's a temptation there, not temptation, just possible reality.

Husani

It's easier.

Jen

Yeah. I do think we're going to hit this moment, as humanity we're going to hit this point at which we stop. It feels like we're gorging. Like we got to an all you can eat buffet, and we started eating and we're like, "Mmm, this is good. And look, we can get more!" But we're just gorging ourselves and sitting there and going, "I don't feel very well"

Husani

"Why don't I feel very well, I just had seven pounds of shrimp cocktail. Why does my stomach hurt. Who's to say?"

Jen

"But there's more, let's get more off the buffet"

Husani

Right.

Jen

And I don't think it's just a few people who feel that way. It feels like everybody feels that way. Even people who invented our industry feel that way.

Husani

Right.

Jen

And when I see them and have private conversations, and hang out with them privately, and talk to them privately, and they're like, completely done, or overwhelmed or....I'm just like, "Wow, this is a thing."

Husani

Who would have thought, back in 1998, that this would be where we ended up?

Jen

Yeah.

Husani

Too much technology. It's weird.

Jen

[01:22:20] Yeah, well thanks for being on the show.

Husani

Thanks for having me. It was awesome.

Jen

Yeah, so, where can people find you, follow you, read about your work?

Husani

I'm on Twitter, it's @HusaniOakley, I tweet a lot about everything, so be warned. I'm also on the web at husani.com, and you can check out Gold Bean at hellogoldbean.com.

Jen

Cool. And people can go, of course, to thewebahead.net/113 and we'll have the links to all the stuff that we just said, and info about you, and any links in the show notes. Although I don't know, it doesn't feel like we have any show notes. But as always, leave comments. Comments are open on thewebahead.net. Bucking the trend. I've had no reason to shut them down, and I really like reading what people say.

Husani

That's excellent.

Jen

Even though it's only like one or two or four comments, I've never had very many, but maybe because people who are listening are driving in their cars right now.

Husani

Maybe there should be a technical solve right for that.

Jen

Oh yeah, we should build an app! Yeah no, that's not going to happen. I'll finish that after I've started a farm. I have some pigs that I'll uh, yeah....Anyway, that's enough for this week. Thank you for listening.