Article originally posted on InfoQ. Visit InfoQ

Transcript

Schuster: In this track, we were trying to learn, how can we become a better developer? How can we de-sacrifice ourselves from our terrible state of being? Let’s start off with the sins of our youth. To introduce yourself, I’d like to ask you each, if you could go back, let’s say 20 years in the past, can you tell us what would you tell your junior developer self to start doing or stop doing?

Copeland: I will probably tell myself to be nicer to everyone, and not to feel so empowered and entitled. Because I think a lot of us maybe remember the power of learning how to program, it’s amazing. Sometimes you cannot be so nice. Because getting along with everyone is a really great way to get good software written. I will probably say something like that. I also might say, don’t over-engineer things, so just keep things simple. Something like that.

Schuster: Why were you so mean to people?

Copeland: I was allowed to be. I have a very direct personality. You feel very powerful when you learn how to program, you can make the computer do stuff and other people can’t and they think you’re really smart. Then if you’re really direct and a little bit unkind, they let you get away with it, which is not good. I got smartened up eventually in my career to not do that, and that it was not ok. I wish I had gotten told that way earlier in my career.

Schuster: How would you say that to yourself? Because I can see myself hearing that, “Be nicer, other people are necessary too.” I can see myself saying, “No, I’m a genius. Why would I listen to you, old man?”

Copeland: I would have to frame it as a selfish benefit to my younger self, like you will get further if you’re nicer to other people, and not even nicer, just kinder and respect other people’s positions. I think I could have landed it if I had made it a self-benefit. I was 22 years old, so who knows?

Schuster: Just tell them, you catch more honey badgers with honey than with vinegar.

Van Couvering: I think I used to send too many soapbox emails, saying this all has to change, and we need to do this right away. This is a big mistake. That was fine when I was a junior engineer. When I became a little more senior, it had a real impact on morale. I couldn’t believe what people told me that people care what you say and take it seriously. I’m like, what? Learning how to think about the impact of my words. There’s a quote I have up here that says, “Your speech should pass through four gates. Is it true? Is it kind? Is it necessary? Is it appropriate to time and place?” I try to do that more, and be more thoughtful about the words I use, and also, when to pull the big trigger to bring in leadership to say something needs to be done here. I used to do it way too much.

Schuster: Was that ok when you were a junior, would you say, or was it not ok when you were a junior? I understand that you’re saying as a senior, you have an outside view.

Van Couvering: Even as a junior, I would send those emails to my manager, for example. I always felt safe saying what I felt, that as an engineer we were expected to say what we feel and damn the consequences. Like you said, as I was younger, I was given more permission to be that way. Maybe people just had compassion. I think it was something I needed to learn from the beginning even if it was back in the old days, and all I had was email, we were allowed to do these group emails and start a big Reply All chain, and things like that.

Schuster: Your soapbox messages in hindsight, were some of those warranted? Did you say stop using technology X and you were right? What do you think?

Van Couvering: You can be right and still be wrong. If you don’t bring the group along in the right way, then was it really a success? I was laughing because even recently, I still have this thing, I still have to be careful. I sent an email to the CEO at WeWork that we didn’t have any snacks. That wasn’t really necessary or useful. It’s not enough to be right. What I’ve learned the most is that, yes, it’s about technology but it’s even more about people being in software. That’s what it ultimately comes down to, is that it’s a bunch of people creating something, not just the technology.

Schuster: I’m hearing that being a better developer might actually be about people skills and understanding people, which is annoying, because I like the tech. Maybe Jordan, you can tell us it’s all about the tech. What would you tell your younger self, learn more Rust?

Bragg: I’ll try and learn more languages. If it was technology wise, I think that I wish I spent more time being mentored by people and seeking out people who had a lot more knowledge, when I didn’t at the time. I think I’ve been trying to course correct that over the years. David has actually been a great mentor to me. I think that you’re hungry and this is warranted, David, that CEO email. Outside of that, I think I wanted things perfect too much early on. You waste a lot of time like that. That’d be something I’d probably course correct. One of the things that I think I was fortunate in, was that I started off as actually a tester, not a developer, just because the job market was tough at the time. I feel like that built a lot of those soft skills of empathy and things. I do think it’s highly valuable. I always say that people should spend some time in another role to get empathy for those roles. Yes, I’m still in the soft skill bucket.

Where to Get Training on Personal Skills

Schuster: I do see now that apparently, personal skills are important. Once we’ve sold the personal skills to people, where can people train this stuff? Knowing that lots of developers are introverts, and they just hang out in darkened rooms, poring through IGs. Where can they get these skills?

Copeland: I got some appreciation by, I had this job, and for the first two years we were forbidden from ever talking to a user. The program manager was like, “The users are terrible. You don’t want to waste your time with them.” Then someone above him decided we were going to have a user group and they came in to use the software, and we’re going to watch them. It was amazing, because you could see the pain we were inflicting on these poor people with our software design choices. You can understand what they’re trying to do, and you start to empathize with them. Then that sort of, if I just think about what it’s like to use this software or to do the job, then I can start to empathize and interact with this person, and be a partner to them, and not be adversarial or anything like that. You can learn a lot. I’ve learned so much in that one day of watching people use this piece of software that I didn’t in two years.

Schuster: That’s a really hard one, when actually you write something that’s not a developer tool and you write it for non-developers, and you actually see your friends and family struggle through this thing that you thought this is ingenious, this is a perfect UI. I designed it. Then they just struggle. You feel so embarrassed. It’s, why do I not understand people apparently? You have to talk more to people.

Copeland: It turns out if you talk to them, you can start to figure things out.

Schuster: They’re not just a nuisance on the other end of a credit card. It’s a service role as a developer in a certain way.

Van Couvering: For me, similarly, I did engineering support for three years, when bugs came through, I was on the team that addressed those issues. That was really educational for me. I still get hackles in the back of my neck when someone catches an exception, and then just moves on without logging anything, because so many times I’ve been in this horrible situation where it’s like, what is going on? Three days, four days later, I find out that this exception had been silently swallowed. It really helped me understand that perspective of building code that is maintainable and high quality and has the right observability. I do agree with what both Jordan and Dave said, which is finding ways to put yourself in the shoes of other roles. Like I talked about talking like a suit, trying to put yourself in the shoes of the business person is also really helpful. I think there are also some really good courses on helping you learn how to communicate better, that are often offered by your organization, or LinkedIn Learning, or Udemy, and things like that, that if you’ve realized that maybe this is something that’s hampering you, as a developer, go seek out those courses.

Bragg: In that same world, networking across teams is also pretty important. I feel like spending a lot of time with product people and things and going deep with some of their events and things also helps you get context and empathy. Because I’ve been in multiple places where the engineering and product are so adversarial. They’re as happy as you are to have somebody seeing their view.

Van Couvering: It’s funny, I have to tell this story. I always try to get to be with customers, so I told the people at Castlight I wanted to meet with some of our customers, and we’re at a healthcare company. It turns out, they were just desperate to find anyone to fill in shoes for stuff they were trying to get done, and so I ended up being sent to South Carolina to a turkey slaughtering facility and sit in the cafe, and meet people who needed to sign up for Castlight. It was the strangest, weirdest experience I ever had sitting in this little dimly lit fluorescent cafe with people with all their butcher aprons on coming by. It did teach me that people had trouble logging in, but it was like, I don’t know if that’s the best way for me to learn it. I just always remember going there, like 4:00 in the morning when everyone starts piling in and having to walk through the sanitization pool and sit in the cafe.

Big Force Multipliers for Developers

Schuster: This was looking at the past, basically, let’s move on to maybe a bit more technical stuff. In your current job or maybe your recent jobs, what do you think are the big force multipliers for developers, maybe that you’ve seen happen or that you think will happen? Jordan, you were talking about code reading. Is that a really important thing? Do you see people struggling reading files, taking forever to understand code bases? Is there something new that’s coming or that you can recommend that people can become very efficient?

Bragg: I think what I learned from my talk was that there was not enough tools for code learning and code reviewing. There’s a lot of tools for reviewing commits and things, but not a lot to have readability. I think that it is a common problem. I think, more and more we see people who just do Stack Overflow. I think there’s a name they call those people. Then it’s just like people who it’s too daunting to jump into this code base, and so they have to move fast. I think Stack Overflow was a big help for a lot of people. I don’t know if that’s the end all be all though.

Copeland: The last few years, like all the developer tools for just doing something more expediently, like Terraform makes it so much easier for me who’s not an operations person to get some basic things done quickly. There’s just tons of things like that, that make everybody more efficient, like design systems. One of the apps I work on was internally facing, so it doesn’t need a handcrafted design. I can just use Bulma, which is like Bootstrap. I could use CSS and make a nice looking UI if I wanted to, but I don’t have to, I can use this design system, and it is just way easier and makes it way faster. It eliminates all these things I have to think about. It reduces what I’m thinking about, to like what is a special problem that I’m trying to solve and not all these ancillary, like how much padding does this button need or things that don’t really matter that just need to be done.

GitHub’s Copilot

Van Couvering: I keep reading about how the new GitHub AI tool, Copilot, is actually really impactful, by people who I really trust in the community. Someone said, I wrote the method histogram, or a structure for a histogram, and it automatically generated the add method and the summarize method for me, not just a signature, but all the code for it. I suspect that we’ll see that grow. Getting rid of boilerplate work is always a good thing, and then in some cases is actually writing the code for you.

Bragg: I’d love to see Copilot be a good review tool for you too.

Van Couvering: What do you mean?

Bragg: Meaning like, you could give it your code, and it can optimize your code for you. It’s like, this is poorly formatted, or the names are bad, or whatever, because we’re all great at names. I know I’m pretty terrible at naming things.

Is Copilot Going to Replace Developers?

Schuster: Is Copilot going to end our profession? I hear that’s what you’re saying.

Van Couvering: No. I thought about this, but I see so much of what we have to do are these value judgment decisions about the right way to approach something and think about something and design something. I don’t see how an AI can figure that kind of thing out. We talked about having empathy for the user, understanding the best flows, things like that. I can see it getting rid of the more just banging on a keyboard stuff, just to get something working. I can see it getting rid of that.

Bragg: I could see it getting rid of a lot of the highly technical stuff, and you do more of the soft skills and designing to tell it what to create.

Copeland: I don’t know how to describe this notion, but it’s like you get to a certain level of experience where writing code to solve some problem gets to be straightforward within the scope of some set of problems. Once you’re there, you can start thinking about those higher level things you all were just talking about. For me, a library that did things would be great. If Copilot spits out a bunch of code that does things, that’s cool, that helps make that like, just getting the code written better. I would agree. The real meat of being really, truly effective is thinking about the higher, 1, 2, 3 levels up from that, which I’m sure some AI person can come up with some way they think will solve that wrongly. I don’t think it’s quite yet there.

Coding Automation Tools

Schuster: The thing I wonder about some of the Copilot examples, because I’m not sure if Copilot is just copy pasting existing code. I don’t think it is generating new code. If you Google for, how do I measure the length of a string in C? The first five pages are wrong, because they just tell you to use a strlen. I wonder how much crap is automated, is copied into our code, and how much can we trust this magic, Jiminy the cricket that sits in our IDE and writes our code for us? What countering tools do we need for that? Is it linting? Is it code review? These bugs sitting in our code?

Van Couvering: I think you still need to have code review. Garbage in, garbage out is what you’re saying. All I’m saying is I haven’t used it myself. I don’t know. As people who are using it, who are people I know and respect are saying, this is a game changer for me. They say it is very similar to code completion and the stuff that IDEs came up with 10 years ago, as that step function level of productivity for them. Yes, it could be a virus of bad code spreading everywhere. It’s a good point.

Copeland: Or it could learn how each of us code individually and produce code like we would produce, like amplifying the problems that we have, and making it harder for us to solve our problems by just reinforcing all of us.

How to Maintain Focus as a Developer

Schuster: I love Dave’s comment about making sure you’re focusing on the right problem to solve. Given that you have that clarity, any suggestions for maintaining focus as a developer to stay in flow, so organizational stuff, time management?

Copeland: I do test-driven development, some version of that, which is, I write a test first on some way. I try not to get up or lose focus unless I have a failing test or a passing test. Because then if I forget what’s happening, I can just run the test suite and figure out where I was. Run the test suite, look at Git and figure out, where did I leave things off, if my brain gets completely empty. Then, if I’m not in those states, then I try to just shut out everything and just get to some form of interruptibility. I plan for being interrupted by structuring my work around getting to states where interruption is ok, and trying really hard in between to not do that.

Van Couvering: It’s like running mini sprints in your own head.

Copeland: If I had the test just pass, and then I could look at the code and be like, that’s terrible, but it’s passing, so now I’m in the refactor parts, so now I can make it better, something like that. That gets hard when you got 10 branches going. There’s a limit to how much that will work. That’s the basis for what I would do.

Van Couvering: The thing I often work on is applying lean principles to my own personal backlog. You’re talking about as like doing things incrementally.

The other thing is I really make sure that I haven’t taken on too many things at once. That I don’t have, like you said, seven branches going on at once, I really try to avoid that, and minimize my work in progress. That’s really helped me not feel crazy and have fewer interruptions, fewer meetings, actually, because I’m less involved. I’m involved in fewer initiatives, so I don’t have to be in as many meetings. That’s really helped me is being willing to say no to myself, as it were.

Bragg: I think that time management is like my enemy at all times. It goes by too fast. I try to do a lot of things like the Pomodoro Technique and things like that. Every day look and be like, what am I going to do? What’s my goal? Keep myself honest. Then there’s so many distractions, like identifying whatever things seemingly break you from concentration. To me, it’s Slack, I think drives me crazy. Dedicate time to completely be off there. I think for the Pomodoro thing, it’s like, if you can do 20 minutes dedicated like 3 or 4 times a day, that’s considered a productive day, which is funny. It’s one of those things where, when you’re reading code, you can just get down in like the depth and four hours later you still haven’t written anything, but you just have to keep yourself in check with something to keep you.

Copeland: All these developer tool things come back to this, because if you do need to get distracted to go do something, and you can do that really quickly and expediently without thinking a lot, then you’re losing less context. If it’s super urgent that marketing needs this button on some page, and I just have to stop what I’m doing and go do it, if I can just write one line of code to fix that, then I haven’t emptied my brain too much. If I got to open up some giant CSS file and figure out what is going on and learn everything from scratch, then forget about it.

Server-side IDEs

Schuster: I think that’s one of the interesting developments recently also is things like GitHub Codespaces and all of these server-side IDEs that really make it easy to just jump into a project. Everything’s set up. There’s no 5-hour yak shaving session to get MySQL installed and so on. What do you think of that? I think that’s a big change. Fifteen years ago if you had told me I would be writing code in a browser, I would have told you you’re on something, you had a bit too much Sherry, but it’s here now. I think all GitHub developers work in Codespaces now.

Van Couvering: I haven’t had the opportunity to do that yet. Every now and then, about every two years or so, I see someone demonstrate an in-browser IDE, and I’m like, “Yes, it’s a great idea. Not there yet.” It sounds like we’re there yet. I haven’t had a chance to work with Codespaces. Docker was the same idea, is like everything’s set up for you ahead of time, you don’t need to set it up. I think we’re talking about things that get rid of all the overhead and let you focus on doing your work. All those things can help you become a better developer.

Copeland: I think Codespaces, there is a non-browser way to interact with it because I think the underpinnings of it are some container VM Docker thing. I was talking to someone at Salesforce because they’re working on some write code in the browser thing, too. I was like, why? Who wants that? They’re like, developers that work at a big company where they’re not allowed to install software, can then get VS Code, which is probably better than whatever they’re allowed to install. That absolutely makes sense. I don’t know that that’s the right solution. I get why someone would do that. I think it’s the underpinning of everything is set up, and you can just go and a bunch of decisions are made, and you got to be comfortable with those decisions. If someone’s like, you have to write VS Code in the browser, I would be very unhappy. I suppose over time, I would learn to love it. We all have our preferences about what we want. If your team has 20 different preferences, it’s hard to leverage that to take advantage of consistency.

Schuster: That’s the interesting thing about all these browser based tools using VS Code, because I think VS Code is the fastest growing IDE over the last couple of years. They snuck it in by the backdoor, because VS Code is already the browser. In Electron, it weighs 500 gigabytes. There we are, going to the browser is not much of a difference, which is a move I didn’t see coming. Microsoft is a developer company, it turns out. Who knew?

Bragg: I think they’re trying to put a lot of their tools in the browser. I think that’s a lot of the Microsoft move. One of my previous jobs, we actually had to do all of our development through a VM that we SSH’d into, or remote desktop’d into. As a developer, it can be very frustrating when you’re trying to type and it lags on just creating a method name. I will be curious to see if we’re past that, like it is pretty smooth. I do think that the containers and Docker and stuff made it a lot better, at least for me. You get into this environment where they don’t trust you, but at least they let you have Docker. Then it’s like, I can spin up MySQL, I can spin up all these things without having to beg.

The Qualities of a Bad Developer worth Improving or Removing

Schuster: What are some of the top few qualities of a bad developer that would have the most impact to improve or remove? We’ve already talked about your bad habits, maybe something that you see in others.

Bragg: I think people who just sit in the silo, they just run off and do little. There are some of these projects where you don’t hear from them, and all of a sudden, they have a fully built thing, or they don’t have any incremental releases of anything. You’re waiting two years for something that they told you was a big deal. I think that is like being kind of practicing incremental and not having perfect stuff.

Van Couvering: Yes, the massive PR.

Copeland: We also see the, “That couldn’t possibly happen. I’m having this problem. There’s no way.” It is like, “Did you check x?” “No, but that wouldn’t be it.” There’s some sort of you got to get over this attitude that things are impossible that like a lot more things are possible, and that things are explainable. Literally everything can be explained in the computer that’s like, what’s going on. You just have to get that mindset. It’s just really hard, especially when you’re starting out, to not just go straight into, “That could never happen. I don’t think that would be it.” You should check. Trust me.

The Happy Path Mindset of Designing

Van Couvering: I think another one that came to mind for me is the happy path way of designing. It’s just like, I wrote these few tests, it works. We’re good, and the design is good. I work a lot with junior engineers like, think of all the horrible things that could go wrong here, and how are you planning to address them. You may decide that you’re not going to address them right away, but at least you’ve thought of them and your design is prepared to address them if and when you need to. Especially messaging systems.

Schuster: “Dave, that’s really boring, I want to move on to the next feature.”

Copeland: It is like getting out of the happy path mindset. There is no happy path at all. Let that concept just go. What could possibly happen? Did you handle everything that could happen? If you didn’t, it’s cool, but like you said, if you thought it out, that’s fine. How could my code get interrupted in this one line? Trust me, it will happen.

Bragg: Even when you think it through, you’re still going to be surprised. There’s still going to be things that happen. You’re like, I never thought that would happen.

Embracing Continuous Learning

Schuster: It’s a motivational problem, as a developer, because you just want to finish your code and have the cool stuff work. You don’t want to find the flaws. Is that a job of QA? I always call it the bastard’s mindset. You have to think in some way that makes your own tool break and just say, what if I hit the backspace button like this?

Copeland: If you’re on-call to fix it when it breaks, you’ll change your mindset. That’s not necessarily pleasant, and we can all get in an on-call situation that really sucks. I learned a lot by being on-call for something that there was no one else to ask to fix. I learned a lot about designing things by having to figure it out. Which, I don’t know if that was the right way to teach me that, but I definitely learned.

Schuster: I hear you saying that DevOps is a good thing.

Copeland: Yes.

Van Couvering: Yes. It is frustrating, you feel like you have to know the entire stack up and down from CSS down to Kubernetes, and how the network works and what it means to have a multi-core CPU, and all the different levels of caching. Plus, you have to think like a suit, and so on. Over time, you do have to learn all those things, but you don’t have to learn them in depth.

Copeland: Be willing to learn when needed. You don’t have to know it all when you started but be willing to dig in, growth mindset.

Van Couvering: I think that’s a really great thing that I had to learn is not being afraid of something I don’t know, and being willing to dig in. It’s a really great attitude to pick up, and be less afraid.

Schuster: This developer job sounds like quite a nuisance. It’s a lot of learning, lots of stepping out of your comfort zone, but it is fun.

Chaos Testing

Talking about breaking your own stuff, what do you think about chaos testing, and that sort of thing?

Van Couvering: I always want to do it, I never get to do it. No one’s ever ready for it. That and pair programming. Everyone is like, yes, we should totally do that later.

Bragg: I think we’ve also moved into where developers own their own stuff, and are on PagerDuty call. They don’t want to send chaos monkeys in production, because it’s going to call them in the night. It’s a good technique. I haven’t got to do it yet.

Copeland: Same. It sounds great. It seems like it is advance band. Like you have to have a lot in place even to figure out why is your code breaking. Even if you know how you broke your code to know what actually broke, like you need a lot of other stuff there. Even getting that and understanding that can be really hard. To come back to what we were talking about in the beginning. If you have that, then you can figure out what your software is doing more quickly and feel more effective and feel more in control. That’s good. Getting there is a journey. It’s also an expensive journey.

How to Get Unstuck from a Blocker during Development

Schuster: How soon should the developer ask for help when they struggle with an issue? How important is the early communication of a blocker during a development phase? How do you get yourself unstuck, more or less?

Copeland: It depends on how much experience. This is really hard. Because if I say as soon as you know your blocks, because we’ve all worked with developers who they literally won’t try. The second they had a problem, they’ll go ask. Then you got the opposite, which is like they will never ever ask. It’s really hard. I think as the person who might get asked, you maybe need to be proactive and see what’s going on with them more often. I think never asking is always wrong. You have to be ok asking at some point.

Van Couvering: There’s got to be a way to measure enough is enough. The Pomodoro Technique is nice in a way because if you spend one Pomodoro trying to figure something out, and you still haven’t figured it out, or maybe two, you could gauge it that way. It’s like time box it in some way. It’s like, ok, maybe I’m stupid, fine. Maybe I’m just missing something obvious, but I’m wasting time at this point. I’m thinking about, for me, probably a day. If I was at it for a day and still hadn’t figured it out, then I would probably reach out. Yes, try for 15, 30 minutes before asking for help. It depends on the size of the problem.

Schuster: I always think, I should apply myself more. If I just loaded that problem deeper into my brain some pattern metric will find the solution. If I give up then I’ve given up. Then, on the other hand, there’s always the shower solution. You just get yourself showered, and there it is, there’s the problem. What am I doing? That’s one thing I learned is that usually going for a walk is my shower solution. It’s astonishing. I go for like a 2-hour walk every day, and every day, within 20 minutes, I have to stop and take out a notebook and say, this is solved. Why didn’t I think of this before? It’s a remarkably low-cost solution, you don’t even have to buy a Pomodoro Timer.

Bragg: Walking is good. Actually, that’s a great way that I’ve done in the past, where I get really stuck and I just walk away. It seems like you had a good idea to bring a notepad with you, because for me I get like a mile away, and I’m like, “No, write this down.”

Van Couvering: I still remember telling my son who is programming in Minecraft, it’s like, “You need to take a break,” he’s like, “No.” I was like, “You have to take a break.” It can be so hard.

See more presentations with transcripts