7±2 Reasons Psychology Will Help You Write Better Code by Moran Weber

During the Cold War, the CIA knew how to expose Russian spies disguised as American citizens with 100% certainty. They used only a piece of paper and a few questions. How did they do that? Hacking your mind is easier than you think. Let’s explore how these mental hacks affect the code we all read and write. We’ll take a stroll through the world of cognitive psychology, and shed some light on some of our industry’s best and worst practices. We’ll have a few interactive examples of our mind’s limitations, examine how these limitations manifest themselves in real code samples and engineering practices, and take away scientifically backed techniques on how to write better code.
jsconfbp.com/speakers/moran-w...
About Moran
Moran Weber is the CEO & Founder of Women on Stage; a platform to showcase, book, and train women professional speakers for any tech event, conference, meetup, or webinar (www.womenonstage.net/). She’s formerly Tech Lead at Wix with 11 years of experience in software development, and also a Social Psychologist, holding an MA in Social Psychology, along with a BSc in Computer Science and Psychology from Tel-Aviv University. Moran used to have major stage fright and impostor syndrome but after she overcame her anxieties and became a public speaker herself, she decided to go on a mission to amplify women’s voices everywhere.

[@tvanantwerp]

I disagree with the idea of a cold code review. I absolutely don't want to start reviewing a PR without any context what the person was trying to do-it would dramatically increase the time it take to understand what they've written, and with very minimal benefit. The marginal gain of figuring out their code from scratch usually isn't worth the extra time and effort.

[@jack19820814]

I totally agree.

[@23stoir]

I think you got her wrong there. What she meant imho is that you should state WHAT you wanted to do with your code (i.e. intention) but not explain HOW you did it. Best example would be a feature commit - what was implemented. You wouldn't expect to read how that was achieved in the commit messag, right?

[@womenonstage3465]

Hey @Tom VanAntwerp, I'm the speaker. You didn't understand my intention here (see what I did here?). As @23stoir mentioned, the point is when you ask for a CR, you shouldn't start explaining your implementation and the architecture ("HOW"), or anything that wouldn't be clear when you're not around anymore to explain it verbally (when you leave the company or on sick leave for instance). You SHOULD definitely write a commit message that directs to the ticket of the feature + any other context about the business logic ("WHAT"). For the case of doing something that's not so clear on a first glance (for example fixing weird platform bugs or stuff like that), then your commit message should explain WHY you did that as well. The point is that if the purpose is making sure the next developer will understand what's written there, then they should track it on their own by annotating and reading it (and then we know it's readable)

First iteration of code review is cold. When you eliminate obvious mistakes, you can check if code is meeting the requirements - then you can take all information that you need to understand what code should be doing.

[@hwthwt9951]

Wish she went into more detail about the cold code review. Does that mean we should not be writing detailed commit messages? Or should I just start the CR first without reading the commit?

[@23stoir]

Best example would be a feature commit - what was implemented. You wouldn't expect to read how that was achieved in the commit messag, right? So just explain WHAT you achieved (intention) not HOW you did that in your code..

[@hwthwt9951]

@@23stoir I disagree. The commit should be a brief summary of the implementation details. The ticket the commit refers to should be for business specs.

[@womenonstage3465]

Hey @@hwthwt9951, I'm the speaker. As @23stoir mentioned, the point is when you ask for a CR, you shouldn't start explaining your implementation and the architecture ("HOW"), or anything that wouldn't be clear when you're not around anymore to explain it verbally (when you leave the company or on sick leave for instance). You SHOULD definitely write a commit message that directs to the ticket of the feature + any other context about the business logic ("WHAT"). For the case of doing something that's not so clear on a first glance (for example fixing weird platform bugs or stuff like that), then your commit message should explain WHY you did that as well. The point is that if the purpose is making sure the next developer will understand what's written there, then they should track it on their own by annotating and reading it (and then we know it's readable)

[@mdsafikulislam9113]

💬🌷