messit
I've seen pretty horrible code constructs that actually seemed to work without bugs. What should I say? That the author of that piece of code should completely rewrite it to my taste? It would not only frustrate him/her but also slow down the entire team. So I often accept what is rubbish IMAO. And not me alone, have you ever seen two code-buddies in a team always doing each others code review and(quickly) accepting and merging everything they produce before anyone can make a comment?
I've had numerous pointless discussions about why I wrote a specific piece of code where (a junior dev) the assessor just wanted me to do things by the book as he learned it, not really understanding why I did it that way. But there was no way to convince him, it ended up in an unresolved conflict that I only could solve by messing up my code to his taste.
All these pointless discussions that particularly affect the relationship you have with your co-developers in the team you work in, are not always fruitful and can be quite destructive if you're not careful enough.
I do believe code reviews can be very important and valuable, but at the same time I've seen huge amounts of wasted time and frustration for nothing. It's not always and only a good thing is my conclusion, it depends on the variables.
That sounds pretty horrendous to me, I would wish her all the best and leave.
I miss the simplicity, readability and power of Coffeescript. -> function without context binding, => function with binding. That's it! does?.this?.prop?.exist, nope still not possible in JS. Ah well, the community hates CS and loves all the amazing new features of ES+. Until you look at a random codebase out there of some outstanding JS dev's utilising all the latest features. One big mess of conflicting strategies, unreadable code, poorly documented, bloated, etc.. etc.. But hey, we're using promises, reducers and spread operators everywhere, we're super smart!
When will the JS community start improving on the quality of the code instead of adding new language features, tooling, frameworks and so on? Try to think of better names for your identifiers to start with, using an intuitive naming system throughout a large codebase so it becomes actually readable. No, will not happen, too boring I guess.
I'm writing Typescript now to pay the bills. Adding even more complexity, it scales so well, mainly because you can use the 'any' type. Said enough?