Life suddenly became less complicated. Thanks devRant 😊

If all you have is a hammer, everything looks like a nail!

This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.

Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.

While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.

Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.

I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.

Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!

When I take a break from ranting, this is where you can find me.

When you spend a weekend building your custom rig, but the inner fanboy conscience takes over 😜

I thought meditation was more like putting myself in “airplane mode”. But in reality it felt more like a DDoS attack!

Team: Qt doesn’t let us build the UX we have in mind. Web is the future.

Me: what do you guys recommend ?

Team: Electron! We vote for Electron!

Me: Alright, who know JavaScript here?

Team: ...

Just arrived! Time to ingest some common sense 🤓

When notifications decide to play hide and seek on iOS 11 beta!

God: you qualify for reincarnation. What advice from past life do you want me to retain in your memory ?
Me: never forget to write those unit tests!

!Rant

I'm going to be teaching my roommate how to "code" soon. Or rather, I'll be teaching her how to use Scratch, so she can have a leg up when she applies to work at a children's code academy that uses a Scratch-like environment. Should be fun!

I love that Scratch exists. Such an accessible way to teach basic concepts like loops, conditional statements, etc, with results that are way more fun than "oh look I output the fibinacci sequence"

!rant
We were finishing another sprint of our grocery shop site at school and it was time for a demo.
There we are, showing our work before the other students. Our teams have a healthy habit of always checking each other not to leave some stoopid mistakes in the final versions, so everybody always regExes and validates THE SHIT out of every input field, both in the view and on the server side. But this one team found out that sometimes it's not enough.

Like every team, they're asked to buy a negative value from their shop. The guy clicks through the process, buys exactly -1 of a banana. He clicks the button to purchase and the site returned "Added banana to the cart!" and we're like "haha n00bz". But someone asked them to show the cart and everyone stopped immediately.

There were 9999 bananas in the cart.

Turns out the member responsible for purchase validation made it add 10000 if the quantity of a bought product was negative.
To this day I can't understand why he did that. xD

Full stack isn’t about knowing just a backend and little bit of JavaScript. Turns out a bunch of them who applied this week seem it have derived a new meaning for it!

Throwing around terms like “I am exploring MEAN” doesn’t make you sound cool unless you have some working examples that you have built with it.

I just became the CS tutor for my university...the one thing I have learned:
Don't let them ask questions explain what they need to know and walk away. Let them down and find the joy of problem solving.

I'm so sick of "senior/lead" developers pretending they know how to write tests and ending up with these unmaintainable test suites, full of repetitions and incomprehensible assertions.

You should take some time to learn from your mistakes instead of just continuing to write the same shitty tests as usual!!!

Every time I arrive at a new team I spend weeks just trying to understand the test suites for what should be fairly SIMPLE applications!

UNIT TESTS SHOULD TEST UNITS OF CODE!
If your unit test tests seem to be repetitive, they are not unit tests. Repetition is expected in integration tests, but that is why those are usually DATA DRIVEN tests!!!

Spent all not fixing someone's errors because they used XML and hard coded values, couldn't even work in the application I was going to work on