allyjweir

I felt very similar when I started working in Go last year. Coming even from languages like Typescript and Python which are most definitely _not_ functional but do have some of the niceties like map/filter/reduce, I was missing it a lot in Go.

What I also found was that there was a whole class of errors that I hadn't seen in years due to mutable state and poorly written for loops/ranges when compared to map/filter/reduce usage.

We introduced `samber/lo`[1] which provides a lodash-like library, generics compatible, to Go. This has been a big step-up and has improved my experience with writing Go immeasurably.

My colleagues now (kindly) joke every time they see a PR from me that includes a lot of samber/lo usage that I'm slowly replacing every for loop I encounter.

[1] https://github.com/samber/lo

Yep I’ve had this recently too. Three devs joined the team who had no experience in relational databases, didn’t even know what SQL was for.

A few weeks later they told this story of using MongoDB and how they had layered some rules on top to ensure data consistency...

"The only good diff is a red diff"

Yes I agree. Bad engineering led them to not accepting the reality that technical debt is unavoidable. In a misguided attempt to avoid it, they overengineered ironically leading to more debt than might otherwise have accrued.

From my recent experience in a new team, this article strikes a chord.

Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily.

We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.

I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those.

The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.

This is one of my favourite technical sites. It is very clear and to the point about its good use cases while being clear where an alternative would be a better choice.

In a similar vein, VueJS has a comprehensive exploration/comparison of itself compared to other frameworks[0].

I really appreciate open source maintainers that have the humility to compare their work fairly with others within the domain while still taking pride in their own acheivements.

[0] https://vuejs.org/v2/guide/comparison.html

How mean spirited. This attempt at humour undermines Laravel's developer's efforts unneccessarily.

Also an ASL (in Scotland) and can confirm that it is incredibly rewarding helping to shape young people's approach to leadership and teamwork.

It's very hard and can consume A LOT of time (to a detrimental effect on my career no doubt) but I love the sense of community and fun that the young people get from it.

Great job on the project! I had this exact same idea about a week ago and put it on my Trello.

Will definitely be taking a deep dive into your website for inspiration. Congratulations on shipping!

Luckily they also thought about that! You can replace both the religion and reference to the Queen with:

"To uphold our Scout values, to do my duty to the country in which I am now living"

What country did you have that experience in?

I'm an atheist and a Scout leader in the UK. When writing my programme I always include a spiritual component to it but leave it non-religious. We definitely discuss and explore different religions (in past year visited a Mosque, an Abbey and a Synagogue to learn about their cultures) but never focus hard on a religion or even suggest that holding a religious belief is necessary to be a Scout.

Recently at an event where I renewed my promise I took the Atheist promise which is as follows:

I promise that I will do my best Uphold our Scout values Do my duty to the Queen Help other people And to keep the Scout laws

I find the majority of Scouters I meet, despite saying the original promise follow this non-denominational one throughout their Scouting. We promote the "worldwide family of Scouts" more than a religious grouping.

If you do look for a Scout group for your son, make sure to talk to the leader there. Different groups approach the issue differently so try to find one that suits you and lets your son avoid being 'forcible subjected to the propaganda' though it can be good for a young person to experience it and make that decision for themselves.

For the JQuery, it is more about separation of concerns and keeping a maintainable an clear codebase. If all of your JQuery is in one file and somehow a small change to one part breaks another page's code that can be very difficult to catch/fix. It's just good form in general to separate it out.

You're also right about performance. Loading unnecessary stuff on a page is just going to slow everything down.

It's a great idea and also being a relatively new starter myself I can relate. Hopefully you can take all the feedback everyone is giving and make your project better!