I see where this sort of take comes from. Reviews are not a place for subjective comments that just slow down or block progress, signaling, excessive nitpicking, etc. However, the reviewer should be thinking beyond the immediate "hey, this is progress", and also consider how this change affects the codebase and how it aligns with feature and technical direction. A few happy approvals and a great codebase becomes hard to work with, if contributors are inexperienced.
Code reviews are also an opportunity for learning, and provide real-life scenarios to inform decisions that are otherwise not grounded and mostly opinion. Of course, not all comments and discussions should block approval, but there is a balance. No one is going to die if this feature is delayed by a few days if you get a better result _and_ are investing in team growth.
The other laptops overheat soon after purchasing, often with just the bare OS running. There is a 3 yo laptop that my parents still use, but it has to always be plugged in, and the fans will spin loudly even in suspension.
My >10 yo macbooks also have bad batteries. One of them won't last one minute, and will also overheat with minor workloads. They were not immune to overheating when new, but unreasonable overhearing (for the time) definitely didn't become an issue at within 3 years of purchase.
And that's with Intel macbooks. My M1 from Dec 2020 works like new (I'm sure the battery life has shortened, but not in a way that I notice). It overheated a couple times running LLMs—that's it. That's how I know the fans work.
In my experience and my family's you are lucky if they last 3 years. If they last 5 years there's usually a subpar experience, e.g. they overheat significantly at 2 years. OTOH, we have a few macbooks > 10 years still working.
I like Ecto's approach in Elixir. Bring SQL to the language to handle security, and then build opt-in solutions to real problems in app-land like schema structs and changesets. Underneath, everything is simple (e.g. queries are structs, remain composable), and at the driver layer it taks full advantage of the BEAM.
It's hard to find similarly mature and complete solutions. In the JS/TS world, I like where Drizzle is going, but there is an unavoidable baseline complexity level from the runtime and the type system (not to criticize type systems, but TS was not initially built with this level of sophistication in mind, and it shows in complexity, even if it is capable).
Indeed. Catalan speakers have Spanish forced down their throat no matter if Spanish has never been associated to the Google account in any way, nor in the system or browser language preferences.
In my case, I live in the United States, but Google is determined to serve me Spanish results even for Catalan-related queries. E.g. preferring the Spanish Wikipedia. The search engine's behavior has had ups and downs over the years, but it has never been great.
This is very much a problem for my children, who don't understand Spanish, as well as for the Catalan-speaking regions of the world that are not in Spain, including Andorra.
In my experience, Gemini easily flags any Catalan content as unsafe and prevents the conversation from continuing. Even for prompts like "summarize this article". This may have improved lately, but still.
Google used to be an example in sensitivity to the world's diversity, being a responsible major player. Way back. Now, although I applaud some efforts multiple teams continue making, it is obvious this is no longer a priority.
Remembering bugs is not necessarily and indicator for passion. I know I love what I do, and have since I was really young, but I do not keep track of bugs or even feats—they just become a rolling base of knowledge (experience). At least in my case, it is just how my brain works.
This is so different from what comes to mind when I think about how to improve productivity:
- require engineers to present and justify engineering investments (and understand that what you don't accept has real costs)
- have engineers estimate the work in the roadmap, and provide clear risks and possible mitigations
- note all of the above means the goals are clearly defined first
- not everything you wanted to accomplish may fit; be prepared to distinguish essential from good to have, and to change the order of your priorities.
- have teams commit to dates based on estimates, a healthy error margin, additional responsibilities, meetings...
- plans change, things happen, life happens, engineering is hard. It's OK, it's expected! Make sure there are clear communication channels from engineers to the top, and from the top to the engineers, so that expectations are adjusted as soon as possible, and maybe make further adjustments.
- Communication should happen often. Be always available to listen, don't micromanage.
- managers should protect engineers and said communication channels
- managers and PMs do not set deadlines
- don't hire cheap; hire motivated team players.
- the primary role of your >Senior engineers is to be force multipliers (how is a whole different conversation), not to do superhero work
- communication, communication, communication; you'd be shocked how much time is wasted by engineers being unsure how to proceed and not sure who to ask of if the question will be well received; there are no bad questions.
I feel like I could go on and on and expand on many of these.
Yes: multitasking hurts; yes, procrastination is bad; but beyond looking at each "issue" individually, engineering leadership should provide processes and culture that protect, motivate and facilitate success.
I agree. Our kids are very much ahead, in part because when we travel, they learn a lot. They seen new places, new ways of doing things, learn history, apply their math and other acquired knowledge, they often learn things ahead of time just because they interact with other adults, they get to use free time to apply their knowledge and interests creatively. And with the right timing, they get to see their relatives far away without it draining our savings, which makes them happy, which is not only important, but makes them better students as well.