Are You A Perfectionist Programmer?

[@HealthyDev]

How have you coped with the tendency towards perfectionism when developing software? Leave me your thoughts and feedback below!

[@seesharper8913]

You are the most relatable programmer on KZbin. You talk in a way where I absolutely KNOW you are a programmer. Some people on KZbin just sort of seem like they spew programmer cliches, and don't give any specifics. Not saying I doubt other people on KZbin "are" programmers, but you talk about things so uniquely relatable, that I have no doubts lol.

[@HealthyDev]

I can’t speak for other programmers on KZbin, I just try to share what I think isn’t being talked about as much and might help people the most. Thanks for your support! 👍

[@ianedmonds9191]

Agree.

[@HealthyDev]

At 9:40 I meant to say we can OVER-estimate the simplicity of our designs. Oops ;)

[@afhostie]

Exposing examples as unit tests are an awesome way to document how software should be used. And because you should be running them as automated tests, you always ensure that they are up to date.

[@karoshi2]

Agree! Though in reality it's usually those hello-world examples as found in the documentation of the test lib. assertEqual(add(2, 1), 3, "Maths is broke!");

[@jonas3846]

Developing fast trumps writing the perfect program. This is common for all product creation (look at factory error rates). To increase productivity while keeping the project standard high, we do the following things: 1. Project coding standards. To avoid spending time writing your own, mix and match other companies rules. 2. Code reviews. Everyone can comment on any other developers code. You need other developers/architects approval before you can merge. No one is exempt to the rule, because everyone makes mistakes. Personally, I also think that (a little controversial): 3. Keep management minimal. 4. Employ architects. Good architecture is key. Make sure your architects are following up on code reviews - some tend to get lazy. If in need, your architects should be able to contribute code.

[@HealthyDev]

Sounds like a bunch of great things for teams to try. In the right situation, I’ve seen all of these be a benefit. Thanks for sharing!

[@basteagui]

i really admire you my friend i am learning a lot about dealing with others and true leadership.

[@gariking3895]

great video, sir!

[@HealthyDev]

Thanks!

[@irlshrek]

This was useful even outside the context of engineering. Thank you!

[@FromPlanet27]

I totally could relate with simplicity comments. As an experienced programmer, my code was corrected by another team member to make it readable and simple. He really did good job and I agree that code was really readable after refactoring he did, except that 70-80% test cases including positive and negative ones started to fail after(which were passing earlier) that!

[@BendyPenguin64]

I've never been a perfectionist programmer. I've always had the mindset of "Better to do a decent job and meet a deadline than do a perfect job and miss one". However, just about every single person I've ever worked with has been the opposite. Even to this day, I'm terrified of showing my work to other people out of fear that they'll say "Do it again. Just because your code works doesn't mean it's acceptable."

[@HealthyDev]

Yeah I definitely suffered from perfectionism in my code and others early on in my career. At least for me, I think it was a fear that the product would become a mess and hard to work with because I was always the technical lead. As I got more experienced I tried to accept that people work differently and make mistakes more, and put time in the team’s schedule to refactor things as we learn instead of expecting it to be perfect. Glad to hear you sound like you have a more healthy outlook. I can definitely relate to your having a hard time with showing other people your code! Thanks for sharing your experiences. 👍

[@heinzschlotter7304]

Just build in proto get it working but keep to general architecture practices getting it work then reactor later as part of polish process.

[@jrlanglois]

I copy/pasted the thought for my PR reviews. Thanks!

[@musandlala7991]

Yeah I used to be a perfectionist until I watched a KZbin video sometime ago. I don't remember who was it but long story short, the only thing that matters is that it works and the next developer can read your code. Obviously follow the architecture, make your code descriptive, avoid one liners and make your code easy to read.

[@Youda00008]

Problem is that by letting the quality go (especially in the beginning), you're potentially creating big problems for the later stages of the project. I joined a project, whose main developers and the leaders had exactly this mindset - "just make it work, customer doesn't care about quality of code anyway". And it worked in the beginning, but after 2 years when the skeleton and main features had been finished it turned into a nightmare. Everything is an unreadable mess, making a simple change takes a day or two, it's randomly crashing in production all the time and we can't find why. Touching the old code is basically impossible because every change or refactoring would break something else. One of the two main developers have left the company and the second is busy with administrative stuff. And we are stuck debugging crashes, and investigating misbehaviour, not even able to add a feature when asked for it. Now I just wish i was there in the beginning so i could tell them to write it properly, but now there is nothing i can do. Worst feeling ever.

[@bitwisedevs469]

This is a very good episode in a while.

It's funny you mention that getting satisfaction in the outcome of the project is a remedy to technical perfectionism, because for me it's the opposite: I learned that I can't control the outcome of a project, or most of its non-technical design, so instead I have the tendency to want the parts I can control - the technical aspects - to be perfect. The technical part (code design/architecture) is our biggest responsibility as programmers (this is the only part where only programmers are expected to do it, and have an opinion about it), and I can't part with the feeling that if it's not exactly how I would do it personally, maintainability will suffer in the long term. I know I have to let go at least a bit, but it's so hard and frustrating! (Especially when sacrificing a bit of quality for speed is probably the right thing to do in the context of the reality of a business, but it still feels wrong, even if it might never be an actual issue in the particular context of the code)

[@HealthyDev]

Sounds like you're making some big revelations and struggling to decide your next approach. Good for you! You're right I realized early on I couldn't control the project and I believe that just fed my perfectionism...

@@HealthyDev I think the big revelation I need to come to terms with is that I can't control all of the technical aspects of a project either (because I'm part of a team), and I need to find a way to be ok with that :)

[@HealthyDev]

@ for real - it's tough! I'm not sure if any of this will be useful to you, but here are a few other videos related to our conversation: "Lead Software Developers Better By Letting Go!": kzbin.info/www/bejne/fKGYoISvg7uSrdU "Accepting What You Can't Change on a Software Project": kzbin.info/www/bejne/m2nJioxml751eqc "Coping With a Failing Software Project": kzbin.info/www/bejne/pZTGg3R3p9CNp8U

@@HealthyDev Thanks, I already saw at least one, and I'll check the other two :)

[@feildtheory]

You deserve way more subscribers.

[@HealthyDev]

Thanks for your support. You can help me reach more people by sharing any videos you find valuable with individuals or your networks. No pressure though, this is a niche channel that’s not promising snake oil so I assumed it would be hard work to reach people.

[@oscareriksson9414]

Good points on diversity in teams and that the lead does not always need to come up with the "best" ideas. I have seen this a lot, during education and past work places. It's just as I always say; last word is not the same as best word.

[@udirt]

This was damn useful - i come from a sysadmin background, for us an aligned working style is super important. but it's hard to transfer. then i did architecture etc. and there it can get worse... we supplied great docs - but noone else did much of that, so the dozens of people were already trained to NOT use documentation, and picking that up with their management would have been the right choice.

[@ianedmonds9191]

I only discovered this channel the other night but you are right on point on lots of situations. The old Joel test of corridor tester is a good counterpoint to perfectionism. Luv and Peace.

[@dmitriyobidin6049]

15:31 This is very hard to adapt. Especially in a small teams(up to 4-5 people). How am i dealing? I found a hobby where i can apply all of my perfectionists tendencies(leathercraft), and during work i feel less stressed to be perfect every time. And i try very hard to learn not to identify me as person with me as a software developer in X company, by not that successfully.

[@L1da77]

I think I'm sort of a perfectionist. Not in the way you describe it though. I want to show my code, I want people to tell me what I'm doing wrong and why. I may not always agree but I will always listen and learn from everything I talk to people about. I figured out pretty early on that if I want to become a really good programmer I need to have my code reviewed.

[@HealthyDev]

Just my opinion but you don’t sound like a perfectionist. You sound like someone willing to be vulnerable with others so you can learn faster and become a better programmer. That’s an awesome attitude ☺️

[@L1da77]

@@HealthyDev Thanks :) I guess the attitude has come with age. 😅

[@Generic_text871]

I think you can be a perfectionist and be willing to be vulnerable. The two are not mutually exclusive. Perhaps you are referring to a sort of anxiety and defensiveness that stems from the ego. Idk, not a psychologist.

[@juliushuck]

I can not even write comments because there is no strict rule for them and no strict syntax

[@karoshi2]

Also sometimes I just cringe due to the requirements set up. My favourite: every line of code needs to have one line of comment. -_- Thus there were things like i++; // increment i by one But also double v = 0.25 * pow(2.1, a) - xdiff(a, x, sqrt(3)); // do the math °oO( Thanks a lot for the extra information. )

[@alexischicoine2072]

Yeah these are funny. I like to put comments that add something you couldn't get from reading the code. Things like weird code that's a work around for a problem with the tech, a design decision, business logic, a tricky piece of logic. Otherwise if it's simple don't comment or refactor as a function. Another nice thing is if you work in a technology like notebooks where you can add markdown through the code you can use that instead of comments and can format it nicely.

[@Fcycfvyvvyvtfutg]

You are so relatable. Why isn't this guy posting anymore? :(

[@afhostie]

Most of the issues I've run into with code reviews are symptoms of a toxic work environment. Especially so when there's lots of pressure from the business about meeting requirements "on time" or when there's lots of politics at play and devs feel like they are in competition with each other for promotions.

[@SailingYachtSaltyLass]

Years ago I subscribed to Jerry Weinberg's concept of "Egoless Programming". It stopped a lot of arguments ...

[@HealthyDev]

Have not heard of this. Sounds like something I could have used a long time ago just by the title. Thanks I’ll check it out! 👍

[@SailingYachtSaltyLass]

@@HealthyDev - find a copy of his book "The Psychology of Computer Programming" which became an instant classic back in the day. The idea behind "Egoless Programming" is really simple - dehumanise the program. It is not "your" program, it is "a" program so criticism of it is not criticism of you. The book is about 50 years old now, but they re-issued it some years back. If you read it you we see that we are still making the same mistakes today that Weinberg saw in the 60s and 70s I am semi-retired these days and just dabble with PHP and LAMP stack stuff and wryly watching all the fads in software come and go... No one seems to realise that IT is about people.. ;-)

[@HealthyDev]

@@SailingYachtSaltyLass sounds fascinating!

[@aaroncook5928]

I'm not a programmer... however i do feel your commentary is very relatable. especially in other fields part of IT. I hope you start posting new videos eventually, i will be staying a subscriber.

[@axa.axa.]

i get very frustrated not progressing from constantly trying to make my code 'perfect', but trying to brings me a lot more pleasure from writing it. That said i don't need to make money creating this 'perfect' code, most often the code that makes me money isn't code i care too much about. ironic isn't it.

[@daviddickey9832]

I liked everything you had to say except for when you said that ethnically diverse people will think differently. I don't really think that's true in general, particularly if you and that other person have been in the same domains for a long time. I would think a better indicator for different thinking would be to bring in someone from a completely different field, like art, or steel working or a field completely unrelated to stem or the application domain.

[@CynicalOldDwarf]

I once heard someone describe corporate diversity as "People of all colours, creeds, genders; all saying the same things"

[@gummydogs]

Yes.. I suffered from this greatly my first few years on the job. Part of the blame could go to school, where you mostly just work alone and have plenty of time to perfection-ize your projects. I've been mostly desensitized now, but it's taken a while. This would've been a helpful video a couple years ago (:

[@HealthyDev]

gummydogs good for you to have realized this earlier in your career! I wish someone had shared it with me sooner :/

[@aikafuwa7177]

What do you do with people who refuse to make use code written by others because they did not write it themselves and refuse to spend time to understand it. And then they tell you they don't mind learning but they do not want to be taught?! They insist on learning the hard way, reinvent the wheel, and then stumble and fail at the obstacles that have already solved and provide them a framework that would have saved them time?

[@HealthyDev]

Try to interact with them as little as possible I guess. That sounds really frustrating. I’m sorry you’re having to deal with that. Hopefully someday they change the way they work with others. I was pretty rough around the edges too.

[@monad_tcp]

I'm only frustrated by the way I write code, I care less about others. Why am I reasonable to others but not myself...

[@440766tg]

The other side to this is when you see a class or method and you know who exactly who wrote the code without even looking at the check in history and you know what the problems the code is probably going to have. The application should be uniform and should be written like the team writes not various individual styles. If an individual finds a better way to do something they should share and convince the team to make future code use the better pattern and come up with a plan if there's value to refactor.

[@HealthyDev]

I agree that conformity, when supported by all team members, is preferable. With that being said I also personally believe those agreed upon conventions need to evolve (in a controlled manner). I expand on this in another video about software developers and how creativity impacts our work: kzbin.info/www/bejne/m2WbfIOvodyUeJY

[@musandlala7991]

Yeah I used to be a perfectionist until I watched a KZbin video sometime ago. I don't remember who was it but long story short, the only thing that matters is that it works and the next developer can read your code. Obviously follow the architecture, make your code descriptive, avoid one liners and make your code easy to read.

[@Youda00008]

_"the next developer can read your code"_ well this is the biggest problem. It's very hard to write readable code and not be a perfectionalist at the same time.

[@musandlala7991]

@@Youda00008 Ah the dreaded catch 22. What I do is consistent naming, dry and never ever deep nest (if I can avoid it, never nest at all), I would rather write another function than nest. I have seen experienced developers struggle to understand nested loops, but the second I write a function that recursively does what the nested loop does, then bam they get it.

[@DavidKing-wk1ws]

Im right and i can prove im right with my trusty shotgun :)

[@pavloburyanov5842]

Yes, and I hate my code on the next day. Perfection sux

[@BspVfxzVraPQ]

Pfff I've never seen other people write good code. Or my own code if it's more than a year old.

[@JoelChristophel]

Amen

[@alexischicoine2072]

Aha yes we learn a lot and then older code seems bad. Sometimes it's worth rewriting it if the gap is large.

[@DavidKing-wk1ws]

It only needs to be in assembly, everyone else has wasted their time learning high level languages :)

[@heinzschlotter7304]

I sincerely hope you are being satirical in that statement. Else you are showing a huge lack of actual programming knowledge.

[@DavidKing-wk1ws]

@@heinzschlotter7304 that was suppose to be funny :) Thats what the smiley face was indicating :)

[@EconaelGaming]

Multiple of your videos boil down to the advice: "get rid of your inflated ego"

[@HealthyDev]

That's definitely one of the themes. Hopefully I've done a decent job explaining why it's hurting us (and others) and not coming off like some sort of holier-than-thou virtue signaler. I've had a huge ego over the years, it bites you hard over time...

[@EconaelGaming]

@@HealthyDev How you come off, depends on the viewer's ego ;) Inflated egos are a difficult topic, since they do hinder individuals in every aspect of their lives, but toning down the ego to a healthy size is a lengthy process, which isn't easily explained, and further more, the reception of the necessity to town down the ego, get's blocked by inflated egos. I'd say to people, that inflated egos are a crutch for self worth, which are not nearly as good as actual self worth, born from a connection with one's own body and emotions, as well as bonding with other people. But I guess most people need to hit a wall, in order to realize that their ego is a hindrance. You're doing good! These topics need more attention in the IT crowd.

[@HealthyDev]

@@EconaelGaming You described my experience perfectly. I needed my ego to be smacked down by difficult life circumstances to even start to have some humility - it wasn't by choice! But now that I see how it was hurting me, I'm at least trying to get people to consider the drawbacks. It's hard, I'm not sure I'd listen to me until that happened ;)

[@EconaelGaming]

@@HealthyDev It's likely more fruitful to aid the people who have already realized, than to try to get the others to realize at all.

[@HealthyDev]

@@EconaelGaming good point, that makes a lot of sense.