Are You A Perfectionist Programmer?
In this episode, I want to ask you a question that might make you defensive: "Are you a perfectionist programmer?".
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
In this episode, I want to ask you a question that might make you defensive: “Are you a perfectionist programmer?“.
I can tell you, after many years of being a software developer, I’ve gotten much better at this. But one of the things I want to help you with in this video is to maybe think a little bit about how you work with others – and maybe make better decisions about what kind of expectations you have from software developers, technologists, and other people on your team so that you don’t get into a situation where you turn people off and you can’t really get their best work and cooperation because you might expect them to work exactly how you do.
A Story About My Perfectionist Attitude
So to start this off, let me tell you a quick story of earlier in my career some of the things I did that caused, I think, others to really dislike working with me – so I can kind of give you some ideas of how perfectionism can rear its head and really stunt you a little bit in your career. And as the video goes on towards the end, I’ll give you some tips that I think will provide some practical strategies so that you can avoid this and maybe enjoy working with people that are a little bit more diverse than you.
So very early in my career (I actually talked about this in the “my software development journey” videos), I was given an opportunity to lead a team in a very young age, and I’ve talked several times in other videos about how being so young and given that opportunity, I was under a lot of pressure, and there was a lot of fear that other people might find out that I didn’t know as much as maybe they thought I should. And I talked more about that in the video about imposter syndrome.
When I was given this opportunity, one of the first things that happened was as I started building this new software product, sort of the framework of the architecture for it. I believe it was in Java at that time. I shared some of the code with my manager, showing him what I’d been doing, and he wanted to get a more senior software developer to take a look at what I’ve been building. And he looked at it like “I’ve got a guy upstairs who’s been working here for 10 years. You’ve only been here for two years. You’re starting this new project. Let me connect you with him and maybe you’ll learn some things from him, and it will be a really good opportunity to maybe see if he’d be interested in working on the project as well?“. And I at that time I think subconsciously, I don’t think I even realized it – I was fearful about a few different things.
First of all, I was scared. Wow, there’s this guy who’s got way more experience coding than me. What’s he gonna think of my code? And also, I thought, you know, “I’m not done yet” or “my code isn’t perfect enough to share it with someone else“. And so I resisted this from my manager at the time. I I really didn’t want to share my code and have it looked at by the other gentleman. I’ve talked about this in my my software development journey videos, how I worked with this same manager under several other companies and we had a great relationship. But this was the first company I worked with him at and so he convinced me, not in a pushy way, but just in an encouraging way to to really give it a shot and try to meet with this gentleman.
Well, unfortunately, when I shared my code with him, I think what ended up happening was my boss had me send a drop of the code. This was before there was a lot of source control being used in our company. But I might have sent him a zip file or something that had some snippets of it for him to look at and kind of understand what was there, and I’d never really shared code with another person at that point. And so I didn’t even know really what to expect. But unfortunately, what ended up happening was once he’d looked at the code, he contacted my boss and said, “Hey, let me talk to Jayme. I want to share some things with him about the code“. And I had no idea when I heard this – was he gonna share positive things or negative things? And I was really uptight about it.
Well, when I got into the room with this gentleman, he started to basically kind of tear into me about how I didn’t have very good error handling. And I wasn’t handling a lot of situations where things could go wrong and thinking that through. And being where I am in my career now, having done this for over 20 years, obviously that was true – that WAS the case. But at that time, my pride and my ego, I think it was really hard for me to bear. Especially again, having been given the opportunity to lead a team. And so I really got pissed off. I started swearing at this guy. I started accusing him of being a perfectionist, which is some of what this video is gonna be about. And my boss actually had to grab me by my shirt and pulled me out of his office and tell me, “Jayme, you can NOT react that way to people! You’re taking it totally personally. You’ve been given this great opportunity. This guy’s been here a long time. He’s just trying to help you“.
And while I think the gentleman was a little more maybe brash than I would have liked, he wasn’t a jerk about it. He was just being very straightforward and very factual about what I hadn’t done well in my code, and I just got really defensive about it. And so that experience always taught me and stuck with me a couple different things.
One is that I think as software developers we have to often be prepared that what we think is our best work is never gonna be perfect. When sharing it with someone else we have to be prepared that they may shoot holes in it. They may say they don’t like how we did it, because we’re different people and we think differently.
And the other thing is, if you’re someone who’s on the other side of the table and you’re looking at someone else’s code, or this isn’t just code. You might be looking at their screen designs if you’re doing UX or something like that, or you might be looking at the continuous delivery pipeline and how it’s put together if you’re doing more DevOps related work, I mean ANYTHING related to software development – if you’re on the other side of the table, maybe you’re a little more senior or you’re just someone new and you’re being given an opportunity to look at someone else’s work. I think many software developers, we tend to cut other people down when they don’t code exactly how we do. And we don’t really find ways to communicate things that we think they could do better with a language that helps them understand that we appreciate them first.
So the second story I’ll tell you about before I kind of get into the tips here is on that same project a couple years in. You know, I had built a whole framework, and we had patented a couple aspects of it, and it was exciting. The company had given my team even more resources, and we had a pretty significant sized team at that time, and we’d been working on this project now for at least a year, and I was really excited about it. It was the first time when I got the opportunity to sort of have at least internally at my company’s somewhat of my own open source project. It was not fully open source. There were some libraries that we did put out on source forge. This was years ago. So this is before github and things like that. But this was my first framework really in my career.
And so when I created it, I took a lot of pride in that. I spent a lot of time at home writing documentation about it. At that time, I don’t remember what I used. It wasn’t a wiki, those weren’t real popular quite yet. But it wasn’t like Word documents. It was some other technology that was meant for documenting APIs and things like that. It might have even been JavaDoc or some tool that sat on top of it. But I spent a lot of time documenting this. And so once I had documented it, I shared it with my team and I showed them where the documentation was, and I was really proud of it. But I really had a somewhat over overly inflated opinion of what documentation meant to getting your technology adopted.
And so, as the team began to be “on the hook” for delivery using my framework, the management and the rest of the team got frustrated that they didn’t really seem to be getting people to produce the product or features fast enough. It seemed to have slowed things way down. And I kind of took the attitude of blaming everybody else. Basically coming to anybody who would complain and going – “Look, I wrote documentation for you. I spent all this time on it. Everything you want to know is clearly outlined there!“. Basically, like I had an attitude of – “If you can’t figure it out at this point, it’s your problem!“. And going back this was gosh 15, no like 18 years ago. At that time, I just hadn’t developed the soft skills and the attitude to truly lead a team. And I really looked at it like if I’m “brilliant” (or I think I am) and if I write down everything that you should need to know to use my framework, that’s enough.
So in this video, I want to give you some information that hopefully will help you not fall into that situation. And if you’re someone who has maybe created frameworks in the past and been frustrated they haven’t been adopted at the rate that you hope they were, I hope this information maybe gives you some things you can think about so you actually do get that adoption and really get everybody excited and successful and productive on your team.
Why Is Being A Perfectionist A Problem?
So first of all, why do we care if we’re perfectionists or not? I mean, I think many of us when we fall into this, it’s just because we take pride in our work. But let me talk about a few things that I think caused me to act this way. And it will probably also cause you to act this way at some point your career, if you don’t understand this.
#1 – Overestimating The Simplicity Of Our Design
So the first thing is, I think often we overestimate the simplicity of our designs. And by saying that, I mean we may design let’s say, an API or a tool kit or a code generation framework or I mean ANYTHING related to software development. Maybe this is a security policy generator for some cloud technology of some sort, and we are really intimate with all the things that that technology needs to do, because maybe that’s why we created a framework in the first place. We’ve thought “I understand so much about this little aspect of my software product, and I think I can make it simpler“.
But often times I think we don’t realize unless we involve a lot of other people during that design process that we’re still heavily biased on what we think simple means. And so I think one of the reasons that we can become perfectionists and we can fall into this sort of behavior is that we really don’t validate that. What we think is simple is really understandable and simple to everyone else. So I think that’s just one of the reasons. And you might want to check yourself why we can fall into this somewhat, you know, perfectionist, programmer mindset.
#2 – Fear Over Being Blamed For Someone Else’s Work
The second reason I think that we can fall into being really somewhat anal about everybody coding exactly how we do or using the same designs we do or appreciating the frameworks we come up with is a fear over us somehow being blamed for other people’s work. And this is just something that I just experienced in life with a lot of different things, but it’s it’s very prevalent in software development, and I’m sure it is in your career. But when you’re leading a team or even just working alongside a team of other software engineers or software professionals, it’s very common that we find something works for us, right? We might find “okay, this API really works well for me“, and we immediately jump to the conclusion that approach is gonna also work really well for everybody else. And so we have this feeling that if I can either force or convey or convince everybody on the team to use the same approach that I have, they’re also going to be successful.
And I’ve just found after working with many, many companies and doing this for over 20 years, that’s just not true. Some of the things that I think are just a slam dunk for the team, they DON’T work out well for the rest of the team. So as I get into the tips here, I’m gonna talk a little bit about how you can prevent that from also getting you into this perfectionist mindset where you kind of have a self-inflated sense of what you think is right for the team and they get frustrated with you. They dislike working with you, and then they can’t even produce deliverables fast enough that the business is really happy with you and the team.
#3 – Not Getting Permission To Invest In The True Cost Of Change
The third reason I think that we can fall into perfectionism around the way work is done, is often I think if we’re leading a team (or we bring a framework for a new technology into a team), we don’t do enough work with the people that we’re responsible to (our boss, and maybe his boss or her boss) on getting permission to actually have the time to get that adoption going. Getting somebody to use your new technology or framework, maybe it’s a simple as “I want to use a new logging API“, and you want to get everybody on the team to use. It takes time! I talked about this in the video on democratic software architecture, but one of the reasons I think you may find yourself falling into perfectionism and expecting everybody to code and work the same way as you is just this inability to really understand the time commitment that’s necessary to really get adoption going.
Overcoming Perfectionism on IT Projects
So how can we overcome perfectionism? How can we actually find a way to work with the others on our team and not have the way that they code or work differently than us, make it frustrating and make it where we just get upset? Maybe we’re constantly wishing other people would code more like us and still get value out of the team?
#1 – Separate Your Success From The Outcome Of The Project
The first thing I think we can do to prevent this is to find a way to separate the outcome of the project, whether it succeeds or not, or maybe meets all the all the things that you would like the project to meet from the work that you do. You can go back and watch a video on coping with failing software projects where I talked about this in more detail. But I found, especially as you move up your career and you get responsible for more and more people or more and more products or projects – It tends to be that we start to feel more of a responsibility for the outcome of the project. And it makes sense if we’re looked at as responsible for it. But we sometimes put our self worth in the outcome of the project, and I’ve just found that this is really a bad way to go about it.
I think it’s more healthy to look at the outcome of the software project as: you’re hopeful that it’s gonna be successful, and you lead people the best way you can, and you pick the best technologies you can, and you work together with people and try to encourage them the best you can. But ultimately, just because a project doesn’t meet the outcomes you hoped for does not make you a failure! I think if you can adopt that mindset, it might help you back off a little bit from laying into other people if they don’t code exactly how you do or look at the designs or the frameworks or the things that you propose as maybe as valuable as you do.
#2 – Include Other People Earlier In Design Decisions
The other thing that I think can help you combat perfectionism and just be a more effective lead and work together better with people is to include them earlier in design decisions that you’re thinking of making. It’s tempting to try to craft this perfect API or perfect framework or perfect pattern and get it exactly how you want it to be and kind of hide it from the rest of your team. Maybe even keep it in a separate feature branch of source control or something like that, and only when it’s absolutely ready share it with other people.
But I’ve actually found that’s not a great approach, because what it ends up doing is first of all, it creates a feeling in the team that others are excluded from design decisions and that you think you’re better than them. The other thing is that really just delays inevitably, any negative feedback or improvements that people want to provide until you’ve already invested a lot in it. And you may fall into feeling resentment or frustration and really just make it hard to work with your team and really get adoption going.
#3 – Embrace Diversity In Perspectives And Experiences Of Other People
Another thing I think you can do that will really help combat perfectionism is to embrace diversity more. Whenever you get an opportunity to do this, maybe if you have a say in the talent or the people who are involved in your team, try to bring more people on your team that are more diverse. People from different ethnic backgrounds, genders, life experience, work experience. The more diverse of a team that you have, I think the more creativity you’re gonna get. And you might be able to let go a little bit of looking at yourself as the one who has to come up with maybe the best designs and really embrace looking to everybody else as the source of that.
It will also help you really get some creative breakthroughs. I’ve talked about this in other videos of mine that, creativity can really help you come up with ways to design things or solve technical problems that you never would have thought of if you just surrounded yourself with people that basically think exactly like you do.
#4 – Fight For More Time To Do Things Right
And the last tip I can give you that will really help you fight perfectionism, is to really work hard to get support from management to give you extra time. I think some of the best software development teams I’ve ever been on in my career have been teams where everybody on the team is not loaded at 100% – not even maybe at 70%. Because it’s a realization that to really develop great software, we need to really bring out the best in people – and that will save your project huge amounts of time. Everybody can’t be pegged. Everybody can’t be underwater.
So if you can convince management to give you the time, the overhead necessary to work with the team and really build great relationships and make sure everybody has an opportunity to talk about the things that they want to add to the project, and document the things they want, and to be open and transparent with each other about ideas they have – I think that’s going to help bring down some of the anxiety you might be feeling about other people coding differently than you and some concerns and fears you might have about whether you’re gonna hit the outcome you want on the project.
If any of these tips have been useful to you, and you know some other leads out there or other software developers that have struggled with perfectionism, go ahead and share this video with them.
Resources
- My Software Developer Career Journey (Part 1)
- Can Imposter Syndrome Help Software Developers Grow?
- Democratic Software Architecture – Sharing Technology Decisions
- Cope With A Failing Software Project
- Creative Software Development – Explosive Growth By Letting Go!
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.