Increasing Productivity by Slowing Down, with Jason Lengstorf

Share this article

Increasing Productivity, with Jason Lengstorf

Increasing Productivity, with Jason Lengstorf

In this episode, Tim and David are joined by Jason Lengstorf, a developer and designer at IBM. They discuss increasing productivity by slowing down, work-life balance, avoiding burnout, knowing your limitations, dealing with public criticism, making tasks action-oriented, timely, ownable and measurable, recognizing that you’re not your code, coding first and asking questions later, and setting yourself on fire.


Show Notes

Conversation Highlights

I try to remember that my code is not who I am. The things I build, the things I write, those are an extension of my personality, but they are not my personality. They have nothing to do with my identity. If I’m wrong, I can look at it and if I’m willing to fight it, if I think I might be right, I’ll argue. If I realized that, Yeah, I’m wrong, then as long as I’m willing to learn from that mistake, and the next time that I write or if I make a correction to the article, then I think that that critique — even if it was a really evil critique, like if they’re mean about it — if the point they made was valid and I learned from it, it was still useful feedback.


I have this whole philosophy that I write about on my blog, and just call it setting yourself on fire. If you want to try something, you can think about it. You can plan. You can do everything to get ready and you’re still not going to be ready until you’ve tried it. At a certain point, you just got to light the match and see if it’s going to work out.


I was working 90-hour weeks, and it was insane. And I was totally doing that hustle hard, sleep when you’re dead kind of badge of honor thing. My agency was growing. I had awesome clients. I was working with companies like Intel and PlayStation and I couldn’t have been happier professionally, but personally, I was miserable.


I decided that I was going to just let everything go. I was like, I’m out. I will destroy my career if it means that I don’t have to live like this anymore. I sat down and I wrote out what was important to me. I was like, okay, I want to have a normal life. I want to have hobbies. I want to be able to hang out with my friends without worrying whether or not my email is going off.


I was like cool, this is it. I’m going to burn it down. My clients are going to leave. My income’s going to go way down, but whatever. I’ll be happy. When I did that, I got more productive. My business went up. I saw my productivity was way higher than it had been before and it blew my mind. I was like, what happened? I though this was the end for me. I thought I was resigning to make the bare minimum to get by, and that was my sacrifice for having a good life. It turned out that my professional and my personal lives got better.


if we look at specific tactics, what I’ve found is that, in a lot of situations when we find ourselves working 60, 65 hours a week, if we actually look at how we’re spending that time, most of it goes to waste.


for every task that you try to do in tandem, 20% of your time is lost. If you’re doing one task, 100% of your time goes to that task. If you’re doing two tasks, 40% goes to one, 40% goes to the other, and 20% is lost to context switching. Three, and suddenly you’re losing 60% to context switching. If you’re sitting in an office and you’re trying to answer your emails and you’re also trying to talk to this person over here, and you’re trying to work, you’re not going to get anything done.


I call it the ATOM technique: … everything needs to be Action-oriented, Timely, Ownable (single owner), and Measurable.

the Versioning Show, with Jason Lengstorf

Transcript

Tim:

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

David:

… and this is M. David Green …

Tim:

… and you are listening to episode number 25 of the Versioning podcast.

David:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

Today, we are talking with Jason Lengstorf, who is a developer and designer at IBM, and we’re going to talk to him about tech and speaking and writing, maybe a little bit about working remotely and working on the job as well. So let’s go ahead and get this version started.


The Versioning Show is brought to you by Squarespace. Squarespace helps creative people stand out. With an all-in-one platform that lets you create a beautiful website without worrying about limitations, designer templates, and a simple interface, Squarespace is the best way to make your next move.

With Squarespace, you can run much more than a portfolio site. You can run your online store on Squarespace, with detailed analytics, domain registration, G Suite integration, and tools that help you scale your business.

Squarespace have a special offer for listeners of the Versioning Show. Try out their service for free. Then, when you decide to subscribe, use offer code SitePoint to get 10% off your first website or domains purchase.

Go to SitePoint.com/squarespace to get started.


David:

Hey, Jason. How are you doing today?

Jason:

I’m doing well. I’m feeling good.

David:

We’re glad to have you with us today. And since this is The Versioning Show, we always like to ask our guests a philosophical question. Your philosophical question today is: in your career, what version are you, and why?

Jason:

Oooh, that’s a good question. I think at this point in my career, I’m probably version 12.0, maybe 12.3. If we’re doing Semantic Versioning like 12.3.157, because I release a hot fix about every 12 seconds. [Chuckles] I feel like the reason that I would say that — that my version number would be so high — is that my career has been a careening adventure from one pursuit to another, and they’re usually not that related.

I got my start as a musician, and that led me to design because we didn’t have any money, so somebody had to make our posters … and that fell to me because — I don’t know — when I was a kid, I used to draw pictures of Garfield or something. As I got into the design of the posters, that expanded into design of other merch, and then things like MySpace happened, and so I started learning a little bit of CSS. Then MySpace stopped being cool, so I needed to learn how to make a website. I built my first awful table-based website in the early 2000s, and I found that I liked it, and so I did that.

Then I tried to go off to college, and dropped out of college (it didn’t work out for me). So I came back and I worked as a graphic designer in a print shop. I worked as a product manager at a Kinko’s. I had all sorts of different jobs. From that point, I ended up in a web development freelance agency. I was kind of moonlighting. I had a full time job at Kinko’s, but I didn’t really want to stay there, so I started doing freelancing projects on the side — which, first it was just front end, and then I realized I needed a back end, so I started doing back end. Then I ended up writing a book on PHP, and then I ended up writing a book on jQuery, and so I had this really odd trajectory where I bounced from front to back to front to back.

Now I’m back on the front end. My official title is senior front end developer at IBM. Yeah, it’s been a lot of reinvention and deciding where I want to be with a lot of minor adjustments in the middle.

David:

What’s interesting about that is it sounds to me like you came into tech — like a lot of our guests, it turns out — self-taught. You didn’t go and get an engineering degree.

Jason:

I did not, no. I actually didn’t think I was going to like computers. When I was a kid, I wanted to wear eyeliner and tight jeans and play guitar. Computers were anathema to that whole image of being a rockstar. Yeah, it was definitely a roundabout way of getting into it, out of necessity more than out of an interest. The interest came after.

David [4:10]:

You started with PHP, I guess.

Jason:

Well, I started with HTML, and it was HTML, CSS and then when I realized that I wanted to not have to make all the edits for all of my clients, that was when I dove into PHP. It started to spiral, where I’d learn something in PHP that would make me want to learn something else in JavaScript, for example, and then that made me want to learn something else on the back end. Then I got into databases and all that, the database architecture. Then I wanted to automate more, so I got into DevOps, and then the build pipeline revolution happened with tools like Grunt and Gulp, and so I got heavy into that stuff.

I didn’t even talk about this, but one of my other side gigs is I do consulting on process optimization, getting people into build pipelines or teaching them how to do that front-end tooling and automate processes and force things like code styles. I got a lot of interests. I feel like they’re mostly gravitating toward that whole how can we do this better, more effectively?

Tim:

In the middle of writing this book on PHP, did you ever think to yourself, I could just go back to design right now and nobody would notice? I imagine it’s this massively different connection between writing a book on PHP and all in the deep, back-end type of languages and then design, which is on a much different scale. How did you manage that transition?

Jason:

To answer your first question about wanting to go back to design, I never did. To me, design and development have a lot of overlap in terms of the philosophical approach. With both design and development, you’re trying to come up with something that’s the right shape to fit the problem. That could be in terms of design, you’re trying to find a way to shape the colors and the presentation of information so that the person who comes to that website or sees that design gets the information that you want them to get, and feels confident that they got what they wanted out of the site. It feels high quality and they feel confident that if they were to purchase or ask for more information, or whatever it is that you’re trying to get them to do, they can do that without any concern that it’s going to be a rip off or incomplete or whatever — or worse, without them being frustrated and being unable to find what they wanted in the first place.

With development, it’s kind of the same thing. You’re trying to take — in the back-end sense — you’re trying to take information from the user and do things with it so that whatever comes back out the other side or whatever we store on the back end is going to be something that is extremely useful to whichever link in the chain, whether that’s the sales department or the customer service team or the customer themselves. What they get back is what they needed to get their job done. It all feels like design to me, but yeah, I don’t know. Sometimes, I abstract that quite a bit.

David:

What that makes me think of is the philosophical trend toward design thinking as a design philosophy these days.

Jason:

Yeah, that’s actually a big thing at IBM, which I didn’t know when I first joined. But I just sat through a whole workshop on it, which was really fascinating — the idea of looking at a problem and trying to actually think through the outcomes. They have this really cool map of, you take the problem as is, and then you try to get all of the steps. Because I feel like one of the shortcomings of a lot of designs is that you look at the exciting parts of it. You look at the cart, or you look at the home page, but if you’re not being thorough, you’ll miss the other links in the chain, like the thank you page after you’ve checked out, or the transitional pages along the way, or the little pop-up messages that let you know what step you are at in the process, and all of those things add up to a good experience.

David:

I think it gets even more critical these days when you start thinking about applications not exactly having pages, but more having states.

Jason [8:00]:

Yeah, yeah. I actually love that. That’s one of my favorite things about web design right now is that we’re away from the idea of a page being where information lives, but instead, we think about it in terms of state. It opens a door for so many cool things, like state-based UI testing versus having to spin up a whole phantom JS server to do that sort of thing. You can test your UI by feeding in a JSON object, which is I love that.

Tim:

I think you just blew my mind with how easily you transitioned from design to development in just one second. That was amazing. Excellent job. I’m convinced now. I have no more questions for you.

[Laughter]

David:

Well I have more questions, because one of the things that you also brought up was that you were working doing back-end engineering work on PHP and then oh, by the way casually, I wrote a book on the subject. That’s not something that everybody who’s working as a developer just thinks to do. How did you come to that?

Jason:

I have a philosophy, which is do it first and then ask if it’s possible. When I very first got into PHP — this was within months of me starting programming in PHP — I decided that I was going to write the WordPress killer; I was going to build a new CMS, it was going to kill WordPress, I was going to be famous. The whole world was going to change. It was typical 19-year-old hubris.

But my way of approaching that was rather than just trying to write the code, I wrote an article about the code I was writing. I went to Chris Coyier at CSS-Tricks and said, Hey, can I publish an article on your site? He was like, You can. This was before he had a lot of guest posts, and he said, I don’t pay for articles, but you can if you want. I published it and it exploded it. Before I talk about how well it did, let me preface it, this was a bad article. The code that I wrote was fine, but it was full of security holes. It was not production ready. This was definitely not a WordPress Killer. It was a proof of concept, hello world CMS. I wrote the article. Chris put it up, which was great. I owe my public-facing career to Chris Coyier, which I don’t think I’ve ever told him that, but hey, Chris, if you’re listening …

That article then went crazy. It hit the front page of Digg, and this was before Digg did it’s big redesign like back when Kevin Rose and those guys had that podcast that was huge. So it hit the front page of Digg. It crashed Chris’ site. Then it came back up and it got a ton of comments. Then it hit Hacker News (or one of those sites) and then those guys attacked it. They were like, This is terrible code. You’ve done a terrible thing. You’re a bad person.

It was really funny, because half of the people were like, Oh, my God, this is so great because I can understand what you’re saying, and half of the people were like, This wasn’t technical enough. You didn’t cover security. You didn’t cover this. This is bad code.

So I learned a few things, the first being I should do more research before I try to tell people how to do their jobs. The second being that there’s this huge want for beginner-level, in-depth material. That’s how the book came to be. I got emailed by an editor. Her name was Michelle Lowman. She worked at Apress (I’m not sure if she’s still there). She just said, Hey, I read your article on CSS-Tricks and it’s really accessible to beginners. Do you want to write a book about PHP for beginners? Now mind you, I was woefully under qualified to write this book, but I didn’t know that at the time, so I did it. Basically, what it was, was I went through the PHP manual from top to bottom. I built a bunch of sample apps. I learned as much as I could, and then I basically rephrased the PHP documentation in a way that was more accessible to someone who didn’t the background context of like I am a programmer.

The book did pretty well. I didn’t know how to edit at the time, so there were a couple mistakes in the source code that made it through. We had issues that way, but overall, the book was pretty well received and people liked it, which is why they asked me to write … I did two more after that.

But yeah, it was a very organic experience. I decided to throw something out there with Chris, and because I threw something out there with Chris, I got the attention of somebody at Apress, and because I caught the attention of somebody at Apress, that got me … for a while I wrote on Smashing Magazine, until at some point, that fell apart. Then I wrote for the Tuts+ empire for a while at Envato. I did a couple things like that; they were all just organic things. I met somebody who knew somebody and that led to me getting another spot as a writer or a speaker or an author.

Tim [12:38]:

You mentioned something that we talk a lot about here on The Versioning Show, which is critique — and angry critique at that — by people who try to tell you, You’re not good enough at being a developer, because they found a flaw with your code. How do you deal with that kind of intimidation when working on stuff that hits the public eye, especially for writing on things like Smashing Magazine and CSS-Tricks?

Jason:

The one time that I wrote for CSS-Tricks, and the couple of times I wrote for Smashing Mag, it was honestly partially that I didn’t know better, and partially being willing to admit that I am not the smartest person in the world. And no matter how well considered the code that I write is, there will be some concern that I didn’t think about. When I was younger, it was stuff like I didn’t fully understand some of the risks of XSS or SQL injection. At the time, things like PHP uses a database library called PDO, which is pretty good at handling SQL injection on your behalf, but I didn’t know that at the time. It was either new, or not very well publicized, or I just hadn’t been very thorough in my research. So I was using the old-school MySQL Query PHP function, which I think now they’ve just said, Don’t do this ever. It’s terrible. I didn’t know better. So I put it up there and somebody pointed it out.

I try to remember that my code is not who I am. The things I build, the things I write, those are an extension of my personality, but they are not my personality. They have nothing to do with my identity. If I’m wrong, I can look at it and if I’m willing to fight it, if I think I might be right, I’ll argue. If I realize that, Yeah, I’m wrong, then as long as I’m willing to learn from that mistake, and the next time that I write or if I make a correction to the article, then I think that that critique — even if it was a really evil critique, like if they’re mean about it — if the point they made was valid and I learned from it, it was still useful feedback.

David:

It’s difficult for a lot of people to put their egos aside like that, and really see through to that level.

Jason:

It takes practice. When I first got the feedback on that CSS-Tricks article, that was my first time of ever putting anything out in public. I didn’t cry when I got some of the more harsh feedback, but I didn’t not cry. You know what I mean? [Laughs] I read some of those comments and sniffled a little bit … like, Why does everybody hate me so much? It was like a trial by fire kind of thing. I have this whole philosophy that I write about on my blog, and just call it setting yourself on fire. If you want to try something, you can think about it. You can plan. You can do everything to get ready and you’re still not going to be ready until you’ve tried it. At a certain point, you just got to light the match and see if it’s going to work out. You just got to run that worst case scenario, and if the worst case scenario is that you look dumb on the internet, you really don’t have a lot to lose.

David:

That’s true. The internet has a tendency to make all of us look the way that it will make us look. But you mentioned your blog. I spent some time reading through that. What surprised me about that was that your blog is much more about the philosophy of work than it is about the technologies that you use, which is unusual I think in our industry.

Jason [15:48]:

I think I have industry ADD, because I also run a code tutorial blog. I’ve got code.lengstorf.com, which is my here’s how to deploy a note app with free SSL and put it on DigitalOcean automatically kind of thing. Then I have lengstorf.com, which is more of a blog. Whenever I make mistakes, whenever I screw something up, my approach is to process in public, and so I run it all through GitHub. I want it all to be open source. The drafts that I’m writing are up on GitHub, and some of them are, like, I’m totally uncomfortable with some of them, which is why they’re not posted yet, right. I feel like you need to process.

For me, the vast majority of making it as a developer or a designer or really any profession has nothing to do with the skill set that you’re using. Being a good developer, I feel, it’s like half knowing how to do the work, but most of it or half of it is understanding what are your limits as a human being? How much can you work? What makes you more effective? How can you make sure that, when you do your job, when you get finished, you’re not thinking, Oh, my God, I hate my job. You’re thinking, Man, that was awesome. I can’t wait to get back to it tomorrow. A lot of what I write about on my blog — my non-code blog — is more in the vein of …

Maybe I should tell a story. The reason I started that blog, and the reason that I really got into it, is that when I was in my mid 20s, this is probably about 2013 I think, I was working 90-hour weeks, and it was insane. And I was totally doing that hustle hard, sleep when you’re dead kind of badge of honor thing. My agency was growing. I had awesome clients. I was working with companies like Intel and PlayStation and I couldn’t have been happier professionally, but personally, I was miserable. I had gained 80 pounds. I was always tired. I slept maybe four hours a night. I was on my email when I woke up, and I’d stay on my email all day unless I was on my computer. I’d check email through dinners with friends or not hang out with friends at all, probably ordered two, three meals a day takeout. It wasn’t a fulfilling existence at all. I just lived to do my job.

Over Black Friday, in 2012 I’m pretty sure it was, I got this really big project for a huge client. It was one of the biggest things I’d ever had, and it was a Black Friday project, so it’s got a hard launch. You either get it up by Thursday night or you’re a failure. That’s it. It’s a binary operation. This project was slated for six weeks of design, development, QA and launch, and design took four and a half weeks.

They handed me this project with a week to get it up. I had to do the design, I had to do the development front and back end, plus the QA all in the span of a week. I decided I’m not going to drop the ball on this. I’m going to win. I stayed up 12, 13, 14, 16 hours working on this site every single day, and missed Thanksgiving with my family, and stayed up super late, and we got it launched. By commercial means, it was a huge success. The client did a ton of business. The site ultimately ended up winning ADDY awards. It was a really cool experience, a really successful experience from a business perspective.

But about February or March the next year, my girlfriend at the time saw me getting ready for work and she was like, Hey, did you cut yourself shaving? I said, What do you mean? It turns out that these patches of my beard had just gone white, all the way white. Over the next few months they started falling out. By July, I had two giant bald patches on my chin. My beard had just started falling out of my head. Of course, this raised an alarm with me, because when I don’t have a beard, I look like a fat baby and not in a cute way. I immediately start looking at all the things, and so what this was it’s this particular kind of alopecia that really, there’s no explanation for it. There’s no cause. There’s no treatment. It just happens, right. It could’ve been anything, but I’m pretty sure it was stress. Given the fact that right now, my beard is back and full, it was the stress, right.

I decided that I was going to just let everything go. I was like, I’m out. I will destroy my career if it means that I don’t have to live like this anymore. I sat down and I wrote out what was important to me. I was like, okay, I want to have a normal life. I want to have hobbies. I want to be able to hang out with my friends without worrying whether or not my email is going off. I turned off all the notifications on my phone. I set do not disturb timers, it was 8 p.m. to 7 a.m. or something, my phone wouldn’t go off, just things like that. Then I started setting times when I was going to check my email.

I was like cool, this is it. I’m going to burn it down. My clients are going to leave. My income’s going to go way down, but whatever. I’ll be happy. When I did that, I got more productive. My business went up. I saw my productivity was way higher than it had been before and it blew my mind. I was like, what happened? I though this was the end for me. I thought I was resigning to make the bare minimum to get by, and that was my sacrifice for having a good life. It turned out that my professional and my personal lives got better.

This blog, to get back to the original point — that was, what was that, three hours ago we started talking about that? This blog was my attempt to dig into what it was that changed, and what it was in my philosophy. Other people have already figured this out, and I just hadn’t done it yet, right. I’d heard the advice and ignored it. I wanted to dig into some of what happened along the way that led to that type of success, and like why is it that if I work fewer hours, I get more done? Why is it if I ignore my email during the day and don’t bring a charger when I go to work in a coffee shop, that I get more done off my to-do list? What’s happening there? So that blog is more of an exploration of what’s happening in my life and what I’m trying, what works, and what doesn’t, and all that good stuff.

Tim [22:06]:

I have so many questions about this, particularly how that works — because sign me up, please! But most importantly, I feel like there are plenty of our listeners who are probably not privileged. I know I certainly am, right. I work at a great job. I have a good work-life balance. I’m not struggling to feed a family of four. It’s just me and my wife, and we’re great. Do you have advice for people who are struggling a little bit in the areas of I have to work like crazy so I can help get by, but I’m also overworked and stressed and overtired?

Jason:

There are so many factors at play because obviously, I’m speaking from a place of intense privilege. My upbringing was not hard by any means. Being just a normal white dude means that if I walk into a situation and say, Hey, can I have a job? I’m probably more likely than anybody else to get it. I’m definitely coming from a place where like, hey, my life’s pretty easy.

But if we look at specific tactics, what I’ve found is that, in a lot of situations when we find ourselves working 60, 65 hours a week, if we actually look at how we’re spending that time, most of it goes to waste.

There was a study that was done about the 40-hour work week and what happens inside of a knowledge worker environment. It was something like three and a half to four hours out of the day is all that was productive work. You would have to go to work for eight hours to do three and a half hours of actual work. There are a lot of things that happen in there, and a lot of it is distraction, things like that, but there’s some studies that have been done about context switching.

The guy’s name, I’m going to forget it right now of course because I need it, I think it’s Gerald Weinberg I think. He has this whole thing on context switching costs, and for every task that you try to do in tandem, 20% of your time is lost. If you’re doing one task, 100% of your time goes to that task. If you’re doing two tasks, 40% goes to one, 40% goes to the other, and 20% is lost to context switching. Three, and suddenly you’re losing 60% to context switching. If you’re sitting in an office and you’re trying to answer your emails and you’re also trying to talk to this person over here, and you’re trying to work, you’re not going to get anything done.

A lot of what I try to preach to people is the idea of giving yourself really thorough time boxes. If you work in an office, find a way to shut off your email and your phone for 90 minutes, and in that 90 minutes, give yourself one task that’s a high priority task, because the world is not going to end inside of 90 minutes. If you shut out everybody and you give yourself an hour and a half to work on something important, you’ll knock it out. Then after that, take 10 minutes or 30 minutes or whatever you need to clear your inbox, answer any phone calls, do the meetings that you need to have and then do it again. Do another 90 minutes.

If you can do three 90-minute blocks, that’s four and a half hours of work. If you also pick up maybe another 30 to 45, maybe an hour’s worth of meetings and clearing email and all that kind of stuff, you’ll have put in at most maybe six hours of work, and I guarantee you’ll get more done than you would in a 12-hour day where you’re trying to do email and work and phone all at the same time.

David [25:20]:

I definitely recognize those concepts. As somebody who’s coached teams on how to apply Agile, one of the things that that makes me think about is you’re talking about the ability to work independently from teams and get things done, and I know that that can really be a challenge when you’re trying to work within an organization.

Jason:

Yeah. IBM, for example, is an enormous company. I think there’s 400,000 people who work there. They are all at various levels … They use Scrum, the Agile technique Scrum. We’ve had to work really hard to get people clear on how asynchronous work works, and a lot of that comes down to getting clear expectations.

I have this framework that I use for planning, where any time that we are going to have a meeting, there needs to be an agenda and a desired outcome, or else I decline the meeting. When we’re talking about planning projects, anything that goes into the queue needs to be … I call it the ATOM technique, which is it helps me remember what I’m going, I’m breaking tasks down into small pieces. But it’s an acronym, too: everything needs to be Action-oriented, Timely, Ownable (single owner), and Measurable. It needs to be not website sucks. That’s not a to-do item. It would need to be fix header on the website. Great. Then you want to have it be timely. Make it something you can do inside of preferably one of those 90-minute blocks, but if not that, like one day. If it’s longer than one day, break it into two tasks.

Then make sure that it’s something owned by a single person, because if you only have one owner, then there’s no passing the buck. Then measurable means it has a true/false criteria for being complete. If it’s not true/false, you need to have more discussion about what’s going on there, and what’s expected, because otherwise, you’re going to find any uncertainty is the seed that procrastination grows from, right?

So, whenever we do that well, we are all really good at working independently. We kick ass. Our velocity is great in our sprints. Whenever we don’t do that, we find that we’re always at each other’s desks, bothering each other on Slack. We’re basically finding excuses not to do the work, because we’re not clear on what we’re supposed to be getting done, which I’m sure sounds familiar to you, David.

Tim:

I am just sitting here taking notes and learning a whole bunch about my life and having some sort of existential crisis, because I thought I was a productive person!

[Laughter]

Which brings me to my next question. I go to conferences every now and then, but I’ve never heard — and I’m sorry if you’ve given this talk before, please forgive me — but I have not heard a talk about how to be the most productive developer that I could be. Earlier you mentioned doing a lot of speaking and coaching. Please tell me you speak and coach about these things, because I feel like I could triple my productivity just by attending one of your talks.

Jason [28:10]:

I actually haven’t. Maybe now I should be taking notes. No, so I’ve done talks on teams in that sense. I’ve got one talk that I’ve given called Happy People Do It Better, which is a talk about building the results-oriented environment, and not overworking people, and making sure that everyone is given the best opportunities to succeed. But I haven’t given one that’s more self-driven, and I probably should do that, because I actually do think that would be … I would really enjoy it. As I’m sure you guys can tell, I like talking about this stuff.

David:

You do a good job of presenting it, too. I like the way that you encapsulate these concepts.

Jason:

I appreciate it.

David:

I’m sure that our listeners are going to want to find out more about you, and more about how to find out the things that you’ve talked about. Where can people find you online?

Jason:

I have a lot of stuff up on GitHub. My username on everything is jlengstorf. You can find me on Twitter, GitHub, Facebook, all those social media things. I also have a website. My blog is at lengstorf.com. That’s L-E-N-G-S-T-O-R-F.com. I got a code blog at code.lengstorf.com.

David:

Fantastic. Thank you for spelling that for us, too.

Jason:

Yeah. It’s a tough one.

David:

Yeah, we’ll also be putting links to those things in the show notes for the show.

Jason:

Great.

David:

Thank you again. Really exciting talking with you and learning about all of these things and I’m fascinated to learn more.

Jason:

Thanks for having me. I had a lot of fun. That time flew.


[Musical interlude]


Tim:

So I feel like I have learned just a ton about productivity, which before Jason started talking, I thought to myself, I’ve got it all wrapped up. I’m a productive person. I know what I’m doing. Now, just I’m clueless. David, I’m clueless. Help, please.

David:

[Chuckling] I think we’re going to have to turn to Jason to help, because it sounds like he’s going to take your suggestion and maybe put together a talk on productivity.

Tim:

I would hope so, because I feel like specifically when you go to conferences, you hear about new technologies. You hear about diversity. You hear about just a lot of important things. But I feel like I really need someone to just slap me in the face with knowledge about working better, after hearing some of the things that Jason had to say. And he spoke at length about his back story and how he got into really focusing on productivity and getting more work done. Here’s somebody who really learned the hard way. I’ve pulled maybe one or two all nighters in my career, but doing it continuously to the point where hair falls out of your face and then, just lighting a match and starting over and successfully, that’s quite a feat.

David:

It’s a terrifying story, and to recognize that the industry really does not have a lot of protections for people and that when you’re working for somebody else and you’re on their deadlines and you’ve committed your salary and you don’t get paid if you don’t do the work, it’s challenging. People really can work themselves practically, if not literally, to death.

Tim:

It is challenging, and I think a problem within our industry is that it’s still rewarded. I think there are a lot of us who realize that it’s bad behavior, wherein encouraging people to have a GitHub graph that shows they’ve committed code every single day for a year, a lot of us realize that’s not a good thing to do, but I still see it every once in a while that it’s an encouraged thing. Real great developers code every day … I don’t believe that for a second. If you feel like coding every day and that’s something that refreshes you and charges your batteries, so be it, but to be honest, encouraging and rewarding this always working habit, that is … First off, it’s a very American thing. That’s not this global — if you work every single day and skip holidays and lunch and you only sleep for three hours, then you’re some sort of superhero. That’s very unique to our culture sort of attitude, but secondly, it’s very damaging, both physically and mentally — at least for me, and I’m sure you’ve felt the same.

David [32:02]:

I’ve definitely been on those death marches, and it’s one of the reasons why I took my own career path out of full-time employment working for somebody else and into the gig economy, where I’m picking up consulting roles, picking up coaching clients, picking up writing and teaching opportunities just as I find them, rather than letting one single source of income be the only place that I rely on for my sustenance — because, then, you’re locked into that. Then if they insist on something that’s unreasonable, you don’t really have this very strong negotiating position. It exposes you to the fluctuations of the marketplace, but it also puts you in control of your own time.

Tim:

Yes, yeah. Speaking of negotiating, I was talking to someone I know today, and if you feel like you might be stuck in this position of just being forced to overwork yourself, I was telling my friend when you’re an employee and someone is trying to dump an enormous amount of work on you, you have a little bit of a hand to play in terms of a negotiating position. This isn’t always the case for everyone, but a lot of times I feel like — and correct me if I’m wrong, David — but I feel like employers will tell an employee, I need you to answer emails until 1 in the morning, and I need you to work this weekend to just get all this stuff done because you’re the only one to do it, and all of this stuff is on your shoulders. The employee often is forced into this position of feeling like, Oh, my goodness, if I react to this, if I say anything but yep, I’ll get it done, I’m going to get fired, which tends to not always be the case.

Most of the time, when someone is trying to push an enormous load of work onto your shoulders, it’s because they are a little bit nervous about losing productivity, right? They realize that you may be the only person to get this done. They have to push it on to you, because if they lose that work, then it’s the end of the world for them. Maybe there’s a pressing deadline or whatever, but the position of negotiation that you have from there is when you push back (and I think you should in these cases), the employer’s not going to say, Okay, you’re fired, I’m going to find somebody new, because that is extremely expensive. It’s months of finding another position and training someone and then that person eventually getting as productive as you can. And then, hopefully, they don’t push back either.

The long-winded point I’m trying to make here is that employers will do a lot to not fire somebody, and if you are in the position where you’re being overworked and persuaded to do way more than a 9 to 5 in a traditional salary position, pushing back is okay. You have that leverage and we should use it when appropriate.

David:

The point that I took from what you just said is that the person who’s working as an employee, they’re the talent.

Tim:

Yes.

David:

They’re the ones that the employers want to find and retain. They’re the reason why interview processes are so long — that there are channels inside of organizations that help human resources that are just dedicated to trying to bring those people into the company, and the costs that are built up around the interview process and around recruiting are massive. Even the percentages that go to the recruiters, it’s amazing how much companies pay in order to bring in a person. It’s easy to forget once you’re there just how valuable you are based on how much they’ve already invested in you in order to get you in the door.

Tim:

If you are on the other side, if you are overworked by habit, which I once fell into that death trap. Actually, it’s kind of funny, David, because I was the opposite. I was the type of person who was overworked when I was doing my own thing in consulting and I could just not say no to anything. I almost wrote a book. I know nothing about writing books. I’m very thankful that I declined that, by the way! But that being said, I was busy by choice, and just trying to take on everything, and working the weekends away and not hanging out with friends, much like Jason said.

I started to realize I do the best work, I bring my smartest brain to the table when I’m most relaxed, when I take a break, when I don’t try to learn what the next thing is and ahead of everybody else. In fact, I am the best at what I do when I am the last to look at the newest thing. I’m just now writing a in-production application with React. I also don’t know if I can say that. That might make me unemployable, admitting that right now, but to be honest, those are the types of behaviors that have just helped me to chill out and at the same time get better at my job.

David [36:34]:

I think I have an advantage, because I started doing remote work when I was a full-time employee back way, way, way before remote work was even something that people were thinking about — when telecommuting was something that you had to actively pitch your employer for, and you had to negotiate for it, and you had to make all sorts of concessions. But I started doing remote work as a full-time employee. I was at Apple Computer at the time. I found that because I was working remotely, the day never ended. I just started working as soon as I got up in the morning. I kept on working until I went to bed and then I started working again the next day as soon as I woke up.

Part of it was trying to prove to my employer that, as a remote worker, as a telecommuter, I was actually doing productive work. But part of it was because I didn’t know how to set boundaries for myself. And it was in that role that I learned about the importance of setting boundaries when you’re controlling your own schedule. That’s carried me well into my own consulting work, because now, I know better than to let myself have my day just stretch off into my evenings, stretch off into my night. I know what my productive hours are, and what my nonproductive hours are, and how to distinguish them.

Tim:

I think it’s important to remember that we all fail at this at times, and we shouldn’t get too discouraged either. Humans are not made to sit in front of a computer at home for nine hours. This is a very new thing. A lot of us are just getting ripe. If you do find either telecommuting or working at your job and if you get discouraged because you find that either you’re not getting enough work done or you’re overworking yourself, you’re not the only one, definitely. Because it’s not just oh, you should do this. It involves how you as a person work, right? It involves what you’re own quirks are, how easy it is for you to focus on a specific task. It’s a very nuanced and difficult thing to figure out, I think.

David:

So you don’t think that we are the first of a new species that is optimized for sitting in front of the computer and eating pizza?

Tim:

I hope to be optimized to do that one day, because I feel like if I was optimized to do that, I could just sit in front of a computer, eat pizza, and because my body is so productive, I’d still have a six pack, but I’m very far from that even without the pizza, which is discouraging.

David:

You can always drink a six pack.

Tim:

I can. I can do that. One of the things that really impressed me about Jason was how easily he transitioned from talking about designing informational systems to page state and how you can test for different page states with different JavaScript frameworks. That was amazing, and it’s very interesting when you work with people who have been on both sides of front-end design and development. They’re not like me, right. They don’t see design as one solid thing over on the left side and then, development is its own thing completely distinct from design over on the right side. They see how these things blend, and it’s really helpful to look at a project in that way.

David:

Do you think that Jason is the real mythical unicorn?

Tim:

Yeah, I would say the Minotaur, right, because it’s like a half … Isn’t that what the half horse, half human is, but instead it’s like half developer, half designer?

David:

Interesting, interesting. That’s going to be the next icon for the industry I think.

Tim:

I would really, really enjoy that. Dear Versioning Show listeners, if you like to design badges or icons of any sort, please, please make us a Minotaur. I will make it my Twitter avatar if you do that.

David [39:55]:

The other thing about Jason that really catches my attention is the fact that he wants to put his information out there in front of people, and he does write, and he does speak, in addition to the work that he’s doing. In fact, when I went to his website, it took me a while to figure out that he also codes, because he’s got so much information there about his speaking and his coaching information.

Tim:

Yeah, and that reminds me of his philosophy of setting yourself on fire. When he spoke about his article on CSS-Tricks and how he got a lot of just angry internet people thrown his way — because the internet is not the trusting, nurturing place that we expect it to be. For some reason we always get surprised when the internet comes to bite us, but that being said, he took it as a point to learn and he said, regardless of how mean spirited the feedback was, if there was a legitimate point that ultimately benefited him, because he could learn a lesson from that. I think, for me at least, that’s a really good lesson to come away with. I do sometimes see it looks like when someone is critiquing my work, it’s like, Oh, you know, you used some sort of smug tone there, and why should I allow myself to get upset at somebody else when at the end of the day, even if their intention is to be mean with their feedback? They’re still teaching me something. I think that was a very helpful lesson.

David:

It’s the sort of thing that it’s easy to avoid if you stay in your bubble and you never share any information, and you just you write little things for yourself and you don’t put them out there. But as soon as you start sharing things out there, you immediately get exposed to public opinion and the rest of the world. Getting comfortable with that, getting familiar with what that experience is like, and recognizing that there is value for you there, it’s incredibly important, and I was glad to be reminded of that.

Tim:

People will be mean. That will always happen. I don’t think there’s a single user of the internet who has not ran into a mean person before, but the internet has a very short memory — which I, personally, am very glad for, because I don’t think anyone would take me seriously if someone saw the first website that I built or the first article that I wrote. So, yeah, get out there and share stuff and get 10,000 Twitter followers, and then make a podcast. That’s what you should do.

David:

Yeah, and then tweet us about it, and we’ll listen to it.

Tim:

We will.


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

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @VersioningShow — and give us a rating on iTunes to let us know how we’re doing.

Tim:

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

M. David GreenM. David Green
View Author

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

Tim EvkoTim Evko
View Author

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

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