Interview question:

"What are your three most favorite design patterns?"

Me: "Huh? They're tools in a toolbox. If I want to drive in nails I use a hammer or a nail gun. Do I need to cuddle with them? I don't pick favorites and I don't try to solve everything with just a bunch of patterns. And I've work with a bunch, right now I'm drawing a blank though as this question highly confuses me and would like to do a Google search listing a few names as the only one that's comming to my mind right now are the factory and builder pattern. And no, not necessarily favorites."

While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

Just implemented a feature using Builder pattern .
State of mind : aaaghh fuck this shit , i am in hell . let's get some rest before integrating and testing this disaster

after some rest , while integrating " Oh you beauty my past self, i love you😍😍😍😍

Who actually started the reign of mixed character passwords? because seriously it sucks to have an unnecessarily complex password! Like websites and apps requesting passwords to contain Upper/Lower case letter, numeric characters and symbols without considering the average user with low memory threshold (i.e; Me).

Let's push the complaint aside and return back to the actual reason a complex password is required.

Like we already know; Passwords are made complex so it can't be easily guessed by password crackers used by hackers and the primary reason behind adding symbols and numbers in a password is simply to create a stretch for possible outcome of guesses.

Now let's take a look into the logic behind a password cracker.

To hack a password,
1) The Password Cracker will usually lookup a dictionary of passwords (This point is very necessary for any possible outcome).
2) Attempts to login multiple times with list of passwords found (In most cases successful entries are found for passwords less than 8 chars).
3) If none was successful after the end of the dictionary, the cracker formulates each password on the dictionary to match popular standards of most website (i.e; First letter uppercase, a number at the end followed by a symbol. Thanks to those websites!)
4) If any password was successful, the cracker adds them to a new dictionary called a "pattern builder list" (This gives the cracker an upper edge on that specific platform because most websites forces a specific password pattern anyway)

In comparison:
>> Mygirlfriend98##
would be cracked faster compared to
>> iloveburberryihatepeanuts

Why?
Because the former is short and follows a popular pattern.

In reality, password crackers don't specifically care about Upper-Lowercase-Number-Symbol bullshit! They care more about the length of the password, the pattern of the password and formerly used entries (either from keyloggers or from previously hacked passwords).

So the need for requesting a humanly complex password is totally unnecessary because it's a bot that is being dealt with not another human.

My devrant password is a short story of *how I met first girlfriend* Goodluck to a password cracker!

The builder pattern sucks shit.

There I said it.

after learning design patterns i realize that when they write "builder" on your profile picture, they actually have written the name of the design pattern used to implement that part D

i always get sucked into this "cute code" hell whenever i am working with a b2c codebase, and especially with kotlin code.

here's a scenario:

task : build a debounce logic for an input view where each user input is currently triggerring an api call.

my steps
1. read what debouncing is.
2. see if any code is available on the internet
=> found a code piece on the internet with some level of abstraction ( basically a simple final class that implements the input event callback and encapsulates the debounce logic)
3) copy it, run it , it wokrs

------

for any sane coder, these steps are hardly 10-30 mins and they can move on with life. but its your truly that made this task into a 6hour research only to come up at similar solution. my curiosity led me to stupid places

1) why this class is final? what if someone else wanna use it but with a different behaviour? lets try open(non final class) .

2) why even use a class? it extends an interface, lets try to wrap the logic in interface itself (kotlin supports interfaces that don't require implementation)

3) umm , the interface works but it looks ugly, with all its global overridden variables. what about we make it extension?

4) yeah the extension approach is also not very good, lets go back to open class.

5) but extend is super nice to look! lets keep the extension and open class too

6) can we optimise the implementation? why it uses an additional handler? what if we provided everything in constructor? how about builder pattern?

FUCK MY BRAIN! there are so much fucking options that i forgot that i spent 4 hours on this small thing

the simplest approach would have been tk just shove all the listeners and everything in activity and forget about it :/

senior devs on this platform, how do you stop yourself from adding every concept that you know into the smallest possible task?