JS Party – Episode #169

Work environments & happiness

with KBall, Amal, & Nick

All Episodes

KBall, Amal, and Nick dive into key dimensions of what makes a developer work environment good – or bad. They discuss systemic factors, individual factors, what you can do about it, and a proposed scoring system for good work environments.

Featuring

Sponsors

Raygun – With Raygun Error and Performance Monitoring you have all the information you need at your fingertips to quickly find and fix errors and performance issues across your tech stack down to the line of code. Get started with a free 14-day trial, head to raygun.com and join thousands of customer-centric software teams who use Raygun every day.

Sourcegraph – Sourcegraph is universal code search for every developer and team. Easily search across all the code that matters to you and your organization: find example code, explore and read code, debug issues, and more. Head to info.sourcegraph.com/changelog and click the button “Try Sourcegraph now” to get started.

O'Reilly Media – Learn by doing — Python, data, AI, machine learning, Kubernetes, Docker, and more. Just open your browser and dive in. Learn more and keep your teams’ skills sharp at oreilly.com/changelog

Notes & Links

📝 Edit Notes

Transcript

📝 Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. 🎧

Hello, JS Party people, and welcome to another week’s fabulous JS Party, where we have a party every week, talking about JavaScript and the web. I am Kball, I will be your MC this week, and I’m joined by two amazing panelists. First off, Amal, long time no chat. How are you doing?

I’m alive, everybody… I’m alive! I miss being on the show so much. Life has just been super-busy… Maybe we’ll talk about that today, but happy to be back. Thank you for the warm welcome, Kball.

We are excited to have you. And then, the one, the only - Nick Nisi.

Hoy-hoy. How’s it going?

Going well. Glad that Mr. Burns is here with us… And will this week have stories from Disney movies, will it have song clips? Who knows…? You never know with Nick. But today’s discussion - we’re gonna be talking about work environments, and particularly what makes for a really good environment for developers. This was initially sparked as an idea because there was a Honeypot article which as of this morning is not loading, so we’ll see if they ever get that back… They had a developer happiness index where they were like “Okay, where are developers most happy? What are they doing?” And it got me wondering… We’ve all been in very different work environments over our careers… What are the things that make for really good or really bad work environments?

Is this like a trap?

It’s the ping pong tables, right? Like, that’s what makes or breaks it?

[03:58] Honestly, there’s so many factors that go into making a workplace healthy that are completely outside of the sphere of tech. So tech is like a circle in a larger sphere; there’s certain things that are unique to tech that I think can either exacerbate your level of unhappiness or at minimum keep your anxiety at bay, because it’s a nice place to work. But I think tech is like a really stressful industry for lots of reasons - constant change… We haven’t developed a lot of good social norms around best practices… It’s not like we’re doctors, where doctors have been doctors for centuries; people have been web developers for a relatively short amount of time, and I think we’re very much a young industry, and we’re still kind of reeling from that youngness, as everybody’s trying to figure out how to do something the best way… And then it turns out three months later you find out the hard way - not the best way. So I don’t know… I’m not really answering your question very well, because I think if I start answering it, I won’t stop, so…

[laughs]

I wanna hear from Nick, and then we can circle back a little more on that.

Well, for me it’s more of a foosball table. That’s the big key. Not ping pong so much. But to your point, Amal, there’s a lot of stereotypes that we have to overcome, too. A “typical” developer is a loner, who sits alone in a dark basement and works alone, and that’s really not always the case, as I sit here alone in my dark basement. There’s a lot of that. There’s a huge social aspect to it, but we don’t always prioritize that, and it’s not really “marketed” that way.

That’s an interesting thing to dig into, the social aspect… Because on the one hand, I think social connection and being connected to your co-workers is really valuable. And we pick where we work, at least partially, because we like the people there. On the other hand, the idea of “Oh, we’re like family here” and all these other things has been used to do all sorts of toxic types of work environments. So where do you all fall on that?

I would say that you kind of hit the nail on it. I would say something that’s very common in tech - you see the unlimited vacations, unlimited PTO, but nobody takes it… [laughter] FANG companies popularizing free food, and laundry, and “Why don’t you just live here? Let’s just maximize your day, so you’re productive to the N-th degree, and can be maximally efficient at work, so you don’t have to think about anything else?” We’ve kind of applied so much of that culture of over-optimizing; we’ve kind of taken that to another level in our industry, where we’re like “Hey, let’s help people optimize their life, so they can do more work.” I don’t think we need to that. I think we should be more inefficient.

I’m into going to the grocery, and feeling my vegetables, and stuff. That doesn’t have to be a universal thing, I just mean that I’m into giving myself some slack; I don’t feel the need to optimize everything, even though it’s an internal bias that I have as an engineer, so it’s something I’m constantly checking myself on.

So I think boundaries that work are super-important, and for me, the best way I’ve managed to avoid that, or have good boundaries at work is really I intentionally kind of pick companies and teams that are diverse, in the sense that folks that – you know, I don’t like working at places that have monocultures, so if everybody’s in their 20’s, has no kids, isn’t married or whatever, that’s a little bit of a monoculture, and it’s gonna skew towards a certain cult… Is cult the right word? What’s the right word…? I don’t know.

It’s a good word…

Yeah. So I think for me a balance and having diversity of lifestyle at work really helps combat that… Because people have lives, and monocultures are bad.

[07:56] Yeah, for sure. I’ve definitely seen my priorities change as I’ve become older, and had kids… I used to want to code all the time, or go out… I remember specifically when I was younger, going out to get drinks or dinner with co-workers, and we’d be talking about work and we’d be making all these decisions about things we were gonna do, or ways to architect things, and then coming back the next day and like anybody who wasn’t there just kind of felt out of the club a little bit.

Now, five o’clock comes around and my focus is on my kids until they go to bed… And then usually, I just wanna go to bed after that, so coding doesn’t take a priority, or my job doesn’t take a priority after a specific time. There’s definitely more important things, and it’s been relatively easy, I’d say, to transition to that, but I know that it can be more difficult, for sure.

Yeah, I think that’s really interesting to think about… And especially in this world where now there’s a lot more remote work and people are in different timezones, and other things… If the expectation is you’re hanging out after hours at the bar, or whatever, that doesn’t work so well, not only with parents, but if you have folks who are in different locations.

Right.

Work is work, and I think if work is just work, anything beyond the eight hours or whatever you’re supposed to dedicate to it, five days a week, that’s the good start, right? I think when work starts to kind of blur, that eight-hour boundary… I personally think even eight hours is unhealthy. I would love to be at a place where I have a 32-hour workweek or a 30-hour workweek. I think I’m more productive that way, actually. I’d like to kind of compress my time, but I don’t live in France, so… What do they have - an official 34-hour workweek in France, or something?

I’d say when work starts to kind of spill over into the other parts of my life, that’s where I get stressed, or burnt-out… And I’m fairly good at putting myself in that cycle, personally. Maybe this is TMI for people, but I’m a little bit of an over-achiever, and I like working hard, pushing myself professionally, taking on more responsibilities etc. That constantly leads to needing to force myself to have some downtime, and reestablish boundaries. But I’m constantly fighting that for myself. I’m constantly fighting my boundaries with work, and it’s not often because of my boss or my team, it’s self-inflicted… So that’s something else to – sometimes you are your own worst enemy, in that regard.

That raises a really interesting question, because I think a lot of folks, both in this and in other knowledge-intensive industries fit in this sort of anxious overachiever model, where people are feeling – and this is where a lot of impostor syndrome and other things start to come in. You feel like “I’m never good enough, so I work really hard and push myself to be better and to get there.” But that leads to this blending of boundaries, and working too much, and whatever…

I had one of my reports be like “Oh yeah, I felt like we were behind on this, so I was gonna work this weekend”, and I was like “Dude, it’s okay if you’re behind. That’s not your fault, that’s actually part of the system.” So what I’d love to dig into here is what are the aspects of the work environments, what are the systemic factors that lead to these boundaries getting blurred or not. Because most of us in this industry push ourselves. We’re here because we were good at something, and we pushed, and we’ve spent a lot of time learning… There’s a lot of stuff you have to learn to do this. So we’re all of the character types that is gonna lead to poor boundaries if we’re not careful. What are the factors that go into a work environment that prevent that from happening.

I’m staring at what is possibly the chillest person on Earth, Nick Nisi… Nick, do you ever get stressed, actually? [laughs] I’m just waiting to hear Nick’s response.

I’m like the Hulk in the first Avengers movie.

Really? Okay.

I’m just always stressed. That’s my secret. [laughs]

[11:56] I feel like, Nick, your voice is a little ASMR for me, because you’re just soooo… Calm… So I love it. You are the yin to my yang. I’m like “Aaargh!!” and you’re like “Whaddup, people…?”

I just have this handy Mute switch ready, and I just scream into the void with that.

No, no, I do feel overly stressed a lot, and I think that that is one thing that really leads to the blurring of boundaries. If I was gonna think about when that happens regularly, it’s when I don’t feel like I was productive enough during the day, then I feel like I do have to come in and work after I get my kids to sleep, or over the weekend, and try and catch up a little bit… And I hate that feeling, and it’s not usually my fault. A lot of times it’s just I don’t have the knowledge or the understanding that I need to do what I need to do, like the requirements are poor, or things like that… And I take it on me, I put that pressure on me as being “Well, I should know this. I should know how to go and do this”, even though I may not have any insight into how to actually do that.

So I think that having that good support structure of clearly defined tasks, that are well groomed with all of the information that I need, really helps me to stay on track… Because the second that I’m waiting or looking around or asking somebody, then I’ve already got another tab open with the news, or Reddit, or something going, and then it’s just kind of like “Well, I surfed Reddit all day, I guess. I don’t have anything to show for the day, so I’d better go make up some time later.” I really hate that.

That actually to me is sounding like support staff and well-defined roles. Someone who has a well-defined (probably) product management role, that is responsible for lining things up, figuring out dependencies, making sure that the right information gets to the right people… Separating out who’s responsible for figuring out the problem and who’s responsible for doing the work - I think that’s one place where… Those are two very different types of work, and when you blur those lines and have the same people doing both things, or at least for the same project…

I do both of those types of work, but when I’m in an implementation, I usually try to stay only in implementation, and be like “Okay, for this project, y’all are figuring out what you want me to do, and I’m gonna do it. And for this project, I’m gonna figure out what we’re gonna do, but I’m not gonna do it. You’re gonna do it.” Kind of having those separated, at least for me, leads to a lot less of that weird blurred lines, and that type of thing.

Yeah, I agree.

Yeah, I think that’s a really good point. A big point of anxiety in our industry is the fact that I think there’s so much discovery, and discovery is often coupled with design, and implementation… Our discovery phase is totally spread out. And if you’re looking at work as a little bit of a pyramid structure, where you have maybe more junior folks on your team, and with a few kind of mid-level people, with then even fewer senior people - you really wanna try to make sure that the decision-making is clear. If I have a junior engineer on my team, the decisions for them need to be really clear and laid out. They should have less decision-making while they’re doing their work. Things need to be very clear.

Whereas I think for senior people that may be on the bleeding edge of the discovery train. I think maybe you’re involved with making those decisions, or you’re more comfortable with uncertainty… But I think it’s really important to know where you fall on that line… Because some people really need to have clear decisions and clear instructions, and they’re more kind of like executers. So folks are more creative, they’re okay with figuring it out on the go… But both have their trade-offs, and figuring it out on the go is also extremely stressful and highly overrated, I think. Planning is something we’re just universally not good at as an industry, and I think it’s just because we’re often moving so fast, you have folks also committing to deadlines without engineering input; that’s a huge cause of stress, so there’s a lot of hero culture, trying to rise to the mythical deadline that was set by someone that wasn’t you…

[16:20] So there’s just so many causes for stress around planning, discovery etc. and a lot of projects are waterfall projects, in the sense of like there’s a deadline, there’s a set of things that they want, and go! But there hasn’t been enough discovery and planning to actually account for that waterfall, because folks are maybe doing fake agile, so they’re doing this scrumfall thing… Which is the most painful thing in the world, because you’re pretending to do agile and bite things off week by week, or in a bi-weekly basis, but really, you have a hard deadline and you can’t afford to spread out your discovery like that.

So I feel like what we need as an industry is some kind of a litmus test for what type of culture is on your team, or what type of project is this; where on the spectrum is this falling? Is this scrum, waterfall? And then combat that with the team cultures… You can kind of maybe come up with some type of a formula for what’s the healthiest way to operate given certain inputs? But here I am, trying to make a program out of this.

No, I think that actually will lead well into a next segment… So let’s take a short break, but then come back and start talking about – I think there’s two aspects of what you mentioned here that would be really useful. One is how do you know, when you’re looking at a work culture maybe you’re interviewing, what are some of the litmus tests or questions you can ask to identify what are you getting yourself into. And two is if you are an individual in a culture that is not where you’d like it to be, where it’s stressed, where all these things are there, what are some tactics that you can take to improve things, at least for yourself, and ideally for the rest of your team?

Well, during the break, Amal was sharing all of her great plans and ideas around – it sounded almost like industry code of conduct, or something that companies could say “Here’s the things we’re gonna do to make our work environments good for our engineers, or our employees at large.” Amal, do you wanna repeat some of what you were saying there, and maybe expand on it and let us know what you’re thinking? What is it that the ideal work environment would do, that would make for a great place to work.

I had this midnight thought last night… What it would take to change the culture in tech? This is gonna sound kind of morbid, and I apologize, especially for the newbies. Please do not let what I’m saying discourage you in any way… But I do think that culture in technology as a whole is a little toxic, and it’s not necessarily just intentionally toxic in terms of discrimination etc. it’s not the stuff that you would think of, typically. I find it toxic because I think we don’t really acknowledge the skill-building and the maintenance part of our job… In the sense that it takes a lot to become a software engineer, and it takes a lot to stay a good software engineer. And there’s culture around what it takes to support a thriving career, that I think we don’t acknowledge.

So wouldn’t it be cool if we had a set of standards that companies could commit to, to show that they abide by certain cultural norms? …as in like 40-hour workweek, for real; we give you personal development time at work, as well as a budget, because we acknowledge that you’re always learning new skills. We don’t set deadlines without your consent…

So all these things that are kind of like really common problems in our industry - what if we could just kind of nip those in the bud? Including diversity standards. Wouldn’t that be cool? So it would be nice to have a little certification seal of approval stamp for like “Hey, we’re a ‘healthy’ company. Come join us.”

Often, it’s really hard to know the company culture until you get there, and asking all the right questions in an interview sometimes doesn’t even get you that. So having some kind of a transparent, like you said, code of conduct for your tech employees, that have really hard, stressful jobs, that would be cool.

I think your point about the amount of time that it takes to upscale and to then stay and maintain those skills is really important. There’s this constant toxic discussion about “Oh, you have to be passionate to be a developer”, and all these things… But I think some of where that came from is an overlay to this, or is related to that. It’s this sense that currently, in our industry, you are generally not given time to keep your skills up to date or to develop them. And to be successful in this industry, you need to spend a lot of time developing your skills and keeping them up to date.

Exactly.

If you are “passionate”, which I think is a terrible way to measure, and I saw a great article recently about “The dispassionate developer” and things like that. But if you are “passionate” you are probably putting a lot of time into doing exactly those things - upping your skills, maintaining your skills, doing those sorts of things. You should not have to be passionate; you should be able to do this work for a paycheck, because it’s a well-paying job, and it will support you and your family and various other things… But you should also know going in that you are going to have to continually invest quite a bit of time on learning and maintaining your skills, that will probably - unless you’re very lucky - not be supported directly by your work folks.

[24:10] So if you are not passionate about this and wanting to do it in your spare time, you need to account for that, and figure out how are you going to do that work to keep yourself competitive and up to date?

Yes. The amount of time it takes to stay viable in this industry, and the fact that we aren’t acknowledging that companies don’t actually build in time - it’s kind of ridiculous. Add the fact that companies don’t ever have the same stack; every company is a snowflake. So every new employee is walking in not only having to learn the domain, but they’re also having to learn the stack… And of course, it’s never, ever a standard implementation of XYZ. That’s just software. Software has cruft, and stories, and skeletons… “Oh, we’re using TypeScript this way, actually.”

So all of that is put on the employee’s personal time… And I have to wonder – as an industry, I just think by adopting more standards and practices around giving employees time to invest in themselves etc. what we’re doing is acknowledging that the current pace is not sustainable, and in order for all of us to go faster and do it sustainably, we have to slow down. So you have to slow down to go fast, and it’s counter-intuitive, but by reinvesting in people, you’re gonna have happier employees, who will likely stay there longer. As an industry, we all benefit; the collective industry benefits from this type of a change. So it’s a big one, because JavaScript is getting pretty complex these days…

Whaat…?!

And apps are always complex, right? Like you say, every application is its own special snowflake. There is almost not generic application out there. And I think – talking about standards, one I’d like to promote is it will take you six months to get up to speed and productive in a codebase.

Minimum.

We recently made that explicit inside of the startup I work at, Humu, where as part of our onboarding documents, we expect you to be still getting up to speed for the next six months as you get on this… Because what we’ve found is both individuals going through the process would get down on themselves, “Why am I still feeling slow? Why am I unproductive?” But then also, their teammates need to know what to expect. This person isn’t contributing as much, or they’re asking a lot of questions. Yeah, they’re three months in. We don’t expect them to be fully productive for another three months.

Also expect other teammates to have to slow down, right? And budgeting for that, and planning for that. Going back to the planning thing, where you’re looking more holistically at your inputs and outputs, keeping in mind that we should dedicate part of everybody’s time to go towards this new person, right? You should expect that.

Engineers are also… I don’t know what profession – there probably are professions that have more expensive onboarding, but it’s a pretty expensive process to onboard an engineer, given the stuff that Kball just shared, which I totally agree with. It takes long for people to become productive, and then it takes longer for them to become domain experts as well, which is this whole other thing that’s very unique to your company.

So yeah, retention is something that we have an issue with in our industry, and I have to wonder what it’s like for people, because people do seem to change jobs every 2-3 years. So every two to three years you’re learning a new stack and a new domain. You have to wonder how many times you can do that throughout your career… [laughs] So I don’t know…

For me, JavaScript is just becoming daunting, and “No, do not enter! We’re big and scary”, like Wizard of Oz… You know the Wizard of Oz? I feel like the level of complexity that we’ve added to JavaScript - or modern web application development, to be specific - it’s not friendly to newbies at all. It seems to only be getting more complex. Yeah, it’s just – we’re not giving people the time to really skill up… What are we doing? We’re gonna be left with nobody on the battlefield… Except for the nerds that made this mess.

[28:02] I think, kind of going towards that, and something that Rebecca said in the chat, is about hiring junior developers. I think that junior developers are a really good way to promote that culture of learning and keeping everyone humble, and possibly shaping the stack a little bit, because you don’t want it to get overly complex and take longer than six months to get somebody onboarded into… And having continuous junior developers coming in and the more senior folks teaching them, and really going through the pains of not being productive individually, but pairing or giving them a – I was gonna say a lecture, but that can be boring, too… Like, a lecture on why things are the way they are within this project, and how it evolved to this - that’s a really important and really good way to keep that going.

So we’ve talked a lot about the problems… What are some tactics that individuals can take to address this? And I’m interested at multiple levels. So if you’re an existing senior(ish) engineer, what are some things that you can do to help either yourself or your company improve? If you’re a junior engineer coming in, what are specific things that people can do to improve both personal situations and team situations?

I think if you’re a senior developer, you really kind of at this stage wanna start thinking about what you wanna have as your niche… You wanna start developing your T. Your T meaning your T shape - what is your breadth of expertise and what is your depth of expertise… And really start making strategic decisions, because we all know the shelf life of software. So you really wanna be strategic about what you invest in your time into.

I can tell you, I’m not the first to jump on every single new thing anymore. I’m very picky about what I spend time learning, and what I will invest in, because my time is really valuable… And I’ve noticed with folks that are newer in the industry, they’re just looking for something to latch on to, and they wanna learn all the things… Cloud, frontend, this, that… It’s like, “Awesome…” But for me at this stage it’s really about developing your expertise and your niche, and making sure you have breadth, but really focusing on areas of depth in a strategic way, that are gonna help amplify your career… And really looking for companies that you can grow that depth in, so making sure that the company that you’re at is able to support your plan for the next 2, 3, 4 years, and making sure that you can grow with the company and you’re not just coasting.

Unfortunately, there’s always gonna be a level of uncomfortableness… If you’re not uncomfortable as a software engineer writing modern code, tell me your secret.

Yeah, I was gonna say maybe for more senior folks on the team, kind of leading by example, in that you are an advocate for this type of learning; you’re always pushing for having the budget to do more things. You’re always trying to learn a different thing. It may not really make sense for your tech stack, but it’s going to help you in the long run… And helping others by being an advocate for them as well, for getting things like that done.

I have a couple of tactics that I use, that I recommend to folks… And I’m cognizant that some of them may work better for me because of various types of privilege… I’m an older white dude with a lot of experience, so these may or may not apply in your situation… But one is being very deliberate about blocking out what time I’m available and what time I’m not available. I work 5:30 to 2. Starting at 2 o’clock I’m taking care of my kids. It is blocked on my calendar. I tell folks I may be available on Slack; if you slack me, I might be able to respond. I’m not gonna be able to do much, because I’ll be on my phone.

[31:59] And part of that, sometimes other things come up… This came up a lot in the pandemic - working on a project, I’ll let people know “I cannot work on this for the next two days, then I will work on it”, and being very, very aggressive and clear about communication there… Just saying when I’m available, being open about that, but also very clear about when I’m not. Actually, going into the pandemic, I was not available a lot, because we were still figuring out our childcare situation, and I was worried that folks would take this badly, like “Oh, he’s not available that much. He’s not doing work” [unintelligible 00:32:29.17] But what I actually got was a lot of people commenting either directly to me or indirectly to my manager about how helpful it was to have that clarity, and to have that communication. So it may be once again that this is related to my situation of privilege, but I think it’s something that is broadly visible - we can be a lot clearer about our own lines, so long as we are clear about communicating them to folks. “I can do this”/“I can’t do this.” “No, sorry, I can’t take on any more today.” That type of thing.

The other tactic that I use that I definitely recommend to folks is I try to only commit up to about 90% of my capacity each week.

90% is a lot.

Well, I buffer inside of that, too. I reserve 10% specifically for learning and reading new things; 10% of my work time.

That makes sense.

Some of that is blocked on my calendar, some of it I don’t block on my calendar, but I just try not to commit as high. And this is something that I can’t do all the time. I’ve been in a crunch project the last two weeks, because we’re just sort of short on some skills that I happen to have, and so I was providing it in multiple places, and it was a crunch time, and that could happen. But deliberately under-committing as much as possible and reserving that time not just to make up for where I messed up in my estimation - which that’s another thing… That 90% is after I’ve padded my estimations, and whatever. Estimation is a skill that we could go into and go a long time on, doing better estimates and estimates upfront would improve a lot of people’s lives. But even after all of the estimate-related padding, reserving time that is there for me to read and learn and try things.

That’s awesome. You’ve got you time at work. You’re literally investing in yourself so you can invest in everybody else… So it’s literally going back to the company, and in exponential ways.

Exactly. It feels like “Oh, I can’t do this because I won’t be productive”, but if you do that for six months, at the end of that you’re already as productive as you would have been doing 100% of time at the beginning… And then the next six months you’re gonna be more productive, and the next six months even more productive… It adds up.

Yeah, 120%. I guess if we’re sharing specific tactics around happiness, I would say for me – I can tell you what I’m working on. It’s definitely similar to Kevin… Or sorry, Kball. Does anybody call you Kevin, actually?

Some people do. You can call me Kevin if you want to.

Kball’s like, “The government calls me Kevin…” [laughter]

My wife…

Your wife. Okay. That’s cute. For me it’s like learning to say no, and remembering that work is always going to be there. You have to adult, you have to manage yourself. No one is gonna say “Stop working.” Work is never going to say “Don’t do work.” We’re living in capitalist societies. Work is gonna always be happy with overachievers and hardworkers and all that jazz. We don’t have a culture here of looking at employees’ overall betterment. So until we’re there, you have to be looking out for yourself, be comfortable with no, don’t over-commit… Remember that there’s always tomorrow, and so it’s okay to just walk away.

[35:45] One thing I’ve started doing a while ago, and it’s been working very well, in order to help with walking away is kind of developing a little bit of a rotunda, and when I say rotunda it’s like a “Here’s everything that’s in my head before I leave for the day.” I write it all down, and then I can just walk away. Because if I don’t do that and I’m not as strict about it as I wish I was, the days that I don’t do that, I’m constantly thinking about work, because I don’t wanna forget that thing… But if you write it down, you’re free of it, and in the morning you can come back and remember it.

So just free yourself, develop rituals for dethatching from work. That’s the thing, especially as knowledge workers. My company gets so much more of my time than they even know, because in your subconscious you’re solving problems, and you’re always thinking about the problem, so you have to consciously develop ways to remove yourself.

Yeah. There’s something – it might be from book-writing maybe… It’s like, don’t ever finish that paragraph for the day. Leave it halfway unfinished, so that you can just pick it up easily and jump right in the next day. That’s something that you can definitely do. And I try and do that with work, whether it’s doing that, where I know what I have to do to make this work, and I’ll just leave it for tomorrow, because that way I have an easy win when I start… Or it’s what you do, Amal, and that’s taking rigorous notes about what I did, and the thought tree that came to the actual conclusion that I’m at. Because oftentimes there’s a lot of thinking that goes into a very little amount of code… So it maybe looks like I spent all day writing 11 lines, but it took me a long time to figure out that those are the exact 11 lines that I wanna write.

Oh, yeah. Writing code should always be the last part of your process, too. Think of design, alignment etc. Then you write code. I totally agree, Nick. I guess the technique – and this isn’t obviously gonna work for everybody, everybody’s different, but it’s like a work journal. It’s like “What did you do today?” And having a ritual at the end of the day/beginning of the day, and taking notes as you go along for what you’re doing or not doing.

I’ve noticed that when I shift my focus around “What did I accomplish?” versus “What did I do?”, those are two different questions. I always have to check myself on “What did I accomplish?” Because sometimes you can do a lot and be super-busy, and I’m very unhappy when I’m constantly pulled into different directions, and I’m super-fragmented… It’s busy work, but without really accomplishing everything.

Well, you go to a lot of meetings, too.

Yeah, exactly. So I always have to check my accomplishments list, because that also is another way to make sure you’re moving in the direction that you need to be moving in… And that’s satisfying. For me, if I go extended periods without significant accomplishments, or enough accomplishments to feed my base level of internal happiness, that’s when I start to get miserable.

I have a tactic that’s almost the inverse of that, which is the priorities list. I start every day with a list of priorities between – I wanna have at least one, and less than five. And if I don’t have that at the beginning of my day, I write it. A lot of times I add it to my next day, or I know that day this is gonna be important, and I’ll add it ahead of time… But those are on my list, and trying to get those done. If I get those done, I’m good.

Yeah.

Other stuff is gonna happen. I’m a manager some of the time – or one of the things I do is manage, so I’ve got a lot of meetings… But my priorities list - if I get those things done, I’m good.

[39:33] I do that too, and I use the last 10-15 minutes of my day to make that. I have a cooldown routine that’s in my to-do list, and it just pops up at 4:30 or 4:45. It’s like ten steps, and they’re really easy to go through. Right now it’s about the next thing to do; push up any code that I have. Clean up my work area (which I sometimes don’t) and then write out what I’m going to start with the next morning.

Alright, so there is a whole set of tactics that you can use to make work a little bit better for you… Let’s take another quick break, and when we come back let’s talk about work environments we’ve worked in that have been either particularly good or particularly bad, and what made them so.

I was in a work environment one time… It was in a startup, it was quite a while ago… And the CEO would yell at his EA; behind closed doors, but he would yell at her. He could not seem to understand at the time… I think he did eventually – and credit to him, he grew a lot… But he could not understand why that would upset the rest of the company and kill everyone’s productivity for the day. And I think one of the things – or the lesson I would take from this, to generalize, is that people are leaky. We’re all embedded in these social networks at work. If one person is really unhappy or one person is getting treated very unfairly, that ripples out to all sorts of folks. And I think having in mind that if some people are unhappy, or are bad apples and treat people poorly, it’s actually probably better, even if they’re really important in one dimension, for them to leave the company.

I have co-workers that I love working with - or have had co-workers that I loved working with, where I could tell they’re getting unhappy and they’re just not a good fit, and I’d say “You know what - I really like working with you and I’d like to keep working with you…You’re unhappy; you should probably find a new job. We can maybe fix this, let’s talk about it, but if we try for two months and we’re not fixing it, let’s find you a better place to work, that’s gonna fit you better…” Because when one person’s unhappy, it radiates.

Yeah, I couldn’t agree with you more. It’s also just not only one person that’s unhappy… Sometimes when you have someone that’s just dragging the team down, that’s another situation. If you put someone who’s maybe – I hate using the word “performer”, but I apologize, I’m gonna use it. High performers/low performers - if you put somebody that’s a “low performer” with this high-functioning team, or whatever, you think like “Oh, the high-functioning team will affect this person and help them out”, but it’s like the opposite. That one person can throw the monkey wrench into the whole situation. The princess and the pea thing… You’ve gotta find that pea and take it out.

I’ll share some good example, good culture norms I got to experience. As folks being remote, and on Slack, there’s a lot of intention around when you ping people. This is specifically for a globally distributed team that I was on - folks would intentionally not mention their name in Slack, even without the @ sign. They would put the name and they’d put slashes in between their name, so that the Slack mentions wouldn’t pick them up. So these really thoughtful considerations around “Hey, this person isn’t working right now. We’re a globally distributed team, so how do we respect their timezone and their boundaries?”

[44:06] And in general, I would say lots of other good examples are for me around remote working culture gone right. I think that’s the true liberation for our people. When I say “our people”, I mean tech people. If every company could adopt good remote-first cultural standards, regardless of whether they’re remote or not, it just would help across the board with transparency, and communication, people not having anxiety, people being able to do their best work, respecting different communication styles… So I would say more of that, more examples like that would be really nice.

To what you said about Slack - everytime somebody uses something that’s not my name, like with N-ick, or something like that, I always add that to the list of highlighted words…

[laughs]

I go the opposite way with that.

Oh, that’s so funny… OMG.

[laughs]

At my current work we actually had a push – because folks were struggling with disconnecting in the pandemic, and they strongly recommended “Take Slack off your phone. Just have it on your work computer, don’t have it on your phone.” And I actually really appreciate this as something that the company was pushing, and saying “Hey, you are putting this on here. We’re saying don’t, because it’s stressing you out, and that’s our problem as a company.”

Yeah. If something’s really an emergency, they should know how to reach you.

We have an on-call system.

If you’re on-call, you can get paged on-call. I got paged by an accidental on-call at the beginning of this thing, and I slacked in and said “What’s the deal? Can somebody else take it?” They did. It was fine. But there’s an on-call system - that’s what should be reliable for off hours, not Slack.

And don’t be afraid to set up your Slack to have your – I forgot what they call it in the UI specifically, but they have off hours, where even if somebody mentions you, it’s not going to actually give you an alert. I have it between six and seven AM, or something like that.

Nick is like “I have it between six and six-thirty. Only 30 minutes in a day where you can’t reach me, everybody.” [laughter]

No, it’s a little more than that. I think it’s like 5 to 7, or something like that.

5 PM to 7 AM, right?

Yes, right. [laughs] 17:00 to 7:00. But it also gives you right there in the UI – or maybe it’s only if you’re DM-ing someone… But if you’re DM-ing someone who has that set up, it will say that they’re not going to get this message, and it gives you an extra little link that you can click, that will actually send it through… So it lets you continue on and carry on and mention them without it actually popping up on their phone. And if they manually go in and check Slack, it’s there, and they can see it, but it’s not something that is going to disrupt them if they’re not actually looking at it.

So I definitely set that up, and I kind of take the liberty of assuming that other people have too, and so I will continue – not that I ever message after-hours, but if I do, I’ll have it set up and just assume that they’re ignoring their phone, because it’s not actually going through to them. Maybe that’s a bad assumption…

Well, wouldn’t it be nice if your company had a standard around that though, where everybody had to set that up?

Yeah, yeah.

That would be nice.

I think that is overwhelmingly one of the messages we have here… It’s like, we’re all trying to do individual solutions, but this is a systemic issue, and the company needs to set standards and have things… Because otherwise you’re always wondering, “Oh, well if I’m not on, does that mean people are disappointed in me? Am I letting my teammates down? If I’m taking all this time for childcare, are they gonna be mad at me?” All these different pieces. Whereas if we address it at a systemic level, it’s a lot cleaner.

Yeah, for sure.

[47:55] For me the root cause of a lot of this also just comes from a synchronous culture. If you have a culture where decisions need to be made synchronously all the time, people need to have a meeting to make decisions, and they have to have a meeting about the meeting etc. which is super-common… But ultimately, if we could all start developing better habits around asynchronous communication, and having long-form discussions on forums, or GitHub, for example, where you have a history and a log of the decisions, you can refer to it over time, it’s there as a resource, it’s grappable for new employees - you’re able to take the anxiety factor out, because people don’t have to respond 30 seconds after they’re pinged on Slack. That’s another unfortunate expectation that we have now, where people are just glued to their computers and devices; if someone’s not responding, where are they…? It’s async. We should really make it async… Unless it’s marked urgent, I’m gonna respond when I can. You’re in the queue, but you’re not in the urgent queue, unless you put yourself in the urgent queue. But don’t abuse the urgent queue.

Yeah…

Do you think that that’s gotten better or worse in the pandemic and the rush to remote work?

I think it’s worse, because you now have literally dozens of Slack channels that you’re monitoring. There’s a lot of chatter for companies that are new to being remote. There’s FOMO… But the reality is even if you are in the office, are you literally going to every single meeting? Are you part of every single team’s discussions? You can’t be all in one place, so in a sense, being physical somewhere limits you. Your humanity is a limiting factor. But Slack - it just gives you this window into everybody, and everything.

So for the information lovers anonymous, aka most software engineers, feeling the need to read every thread, or respond to everything - it’s anxiety-inducing. I see it all the time, people are constantly eager to jump on things and be helpful, when really, they should all just be stepping back from Slack and chilling out. We don’t need to be so connected.

I listened to a podcast recently about this… It was Ezra Klein interviewing Cal Newport, who’s the author of Deep Work, and his new thing is a book he calls “The Hyperactive Hive Mind”, describing exactly this phenomenon, of like “We’ve started organizing work in a way where we’re all doing this real-time pinging back and forth. There are various systemic reasons that push us there, but it makes us less productive and less happy. And figuring out how we can better organize our work so that we are doing more of it in batched manners and in asynchronous manners.”

Because I think there is value in synchronicity for some types of work. One of the reasons we fall into this is that–

Collaboration.

Collaboration, rapid iteration, do this, feedback, go back and forth… There is value in that for classes of work. But when all work is done that way, it’s miserable. So thinking about how we organize ourselves so that we batch together our synchronous work and do it effectively, or doing it at roughly the same times, or roughly the same time windows… And then we have long periods of time for deeper work, for focused work, for stuff that is not getting interrupted all the time. I think it’s super-valuable.

I can’t believe we haven’t talked about deep work and focus. This could be like a series. This could be its own podcast. Literally, every week, we could pick a topic and just go deep, because… No pun intended.

Thomas in the chat highlights I got the book name wrong.

I was gonna say, can we put the book in the show notes?

Definitely. The book is called “A World Without Email.”

Oh my God, yeah.

The podcast was great… He overpushes a little bit. I think he is more hesitant to acknowledge some of the value points of this mode of working, but a lot of his points are just so, so spot on.

Yeah, I’ve never heard that term “hive thinking.” That sounds so appropriate from what I’ve been seeing with remote teams. It’s a little much.

[52:01] Yeah. When the pandemic first started over a year ago now, it was really hard. I was in the same situation as Kball, with figuring out childcare, and all of that. It was really hard to try and figure out how to work productively. It’s gotten much better now, but one thing that I am going to be thankful for, I think, post-pandemic, if that’s such a thing, is that everyone – like, at my company, where 90% of the people go to the same building every day, and I am not going to be one of those people, I am thankful that maybe they won’t forget about me and the 3-4 other people who are remote… Because they have seen, they have lived that for a year.

[singing] “Don’t you… Forget about me.” Do we have to do copyrights for this too, if I sing it? “Don’t… Don’t… Don’t…” Just kidding. I won’t. I’ll stop now. It’s less than 25 seconds.

I don’t know how many episodes we have in a row now of someone singing, but we should keep this streak rolling.

It’s okay…

Release a soundtrack.

The need for me to sing was so strong that I had to interrupt Nick.

[laughs]

I think you’re spot on. I think moving to a world where remote is more part of the thinking is gonna be helpful for everyone who works remote… And moving back to a world where we can actually be in-person some of the time is gonna help some of our mental health.

Yeah.

Alright. Well, this has been wonderfully therapeutic, hopefully helpful. Do either of you have – actually, let me put you on the spot. Each of you, one final parting thought. Something that you would put out there to the Universe for people to think about, try, or do with related to making work environments better.

I’ll go first. Shameless plug - I work at a company focused on this. That’s one of the reasons I’m so excited about it. Check out my company, Humu, both as a potential place to work, because we are hiring engineers, or as a place to help your place of work get better. There is so much involved in this, and there are so many different systemic aspects that it really helps to be thinking about it systemically, and not just trying to do it as an individual.

Mine is be kind to yourself. Cut yourself some slack. It’s been a really difficult - not just year; I think several years. So just take it easy, yo. This is a really hard industry to be a part of and stay a part of, and so just acknowledge that you’re doing your best, and your best is good enough, actually. That’s it.

Alright, I’ll build on top of that and say acknowledge that your co-workers are doing their best, too.

Just sitting in silence, or reading things on Slack… I read everything with a very snarky tone, so I assume that everybody’s mad at me… Or it can feel isolating not getting any feedback ever. So go out of your way to get feedback.

Can I give you some feedback right now?

Oh, no…!

No, you’re awesome, Nick. That’s my feedback to you.

Thank you.

Put that in a while loop. It’s just gonna infinitely run. So that’s forever feedback from me.

Thanks, Amal. And likewise.

You’re welcome.

Excellent. Well, thank you both. I appreciate both of you, as feedback… And this has been another fun episode, JS Party. Check us live Thursdays, 10 o’clock Pacific, 12 Central I think is what folks say, since so many of you are based Central. 1 o’clock Eastern. We record live, you can just us live, streaming on YouTube… Woo-hoo! We’ll catch you next week!

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00