This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code.
It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level.
You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.
> You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.
I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.
Of course this can vary wildly, but I've never felt afraid to defy management on that one. Half the time, they don't even need to know. And the other half of the time... what are they going to do? Fire me? Fine, then their project will be filled with nothing but wallpaper-patchers and I'll be somewhere else doing good work.
(And of course, sometimes just patching the wallpaper is the right course of action, but it's rare to find management capable of accurately assessing this trade-off.)
Yeah, at a certain point I just stop caring what management thinks and just doing what I think is right. I usually don't get the recognition I think I deserve for preventing future issues but no one complains either.
Part of being senior is figuring out how to work in those constraints. In that situation I would push back my manager and tell them why root causing bugs will save us time in the long run and if they still don’t relent I would sandbag some of my time doing sprint tasks to root cause the bugs.
Which is why it's so important for teams to agree with management on a definition of "done" well in advance, to avoid this kind of argument later. Also why it's important for management to understand that velocity/estimation are Descriptive for long term planning, not Proscriptive and short term.
I recently encountered this in a hardware context. To “fix” a bug, instead of understanding the root cause, the designer’s patch just hid the first symptom. In a domain where bugs are remarkably expensive, this approach was terrifying to see.
I’ve been using Firefox almost exclusively for years with two exceptions. The web dev tools in Chrome are really just better. And recently my work made the decision to only allow Chrome for security reasons. I’m annoyed about that but I understand why, it’s not necessarily that Chrome is more secure but the central management tools are stronger and if they were only going to support one, they picked the one more people use.
The most impressive thing about this story is that they figured out the answer. They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.
They found an answer that felt right to them. The reseachers weren't blinded to the context they were working in, and their hypothesis is essentially unfalsifiable so I would take it with a grain of salt.
Honestly, I'm kind of skeptical of the answer. I'm not saying that talking with Nyquist wouldn't be useful, probably it was, but what's stopping a dozen other things at least that useful from being part of the answer?
I'm not a huge fan of cutesey names but a lot of those names are variations on or homages to Kubernetes (Greek for "Helmsman"): e.g Skipper, Harbor, and Helm from your list.
Interesting, I had never heard of this tip before. How do you do this though? Do you just add it at the end like a flag? (e.g. "sparking water -best" ?) In general, I thought these kinds of search engine commands were being phased out, but it looks to me like it would filter out those garbage articles that would bring up results like "top/best 15 brands of sparkling water" etc.
That still works on Google. You can put it anywhere in the query. The "-" is a negation operator that tells the engine to exclude results containing the following word.
They've actually apparently introduced a few new operators since the old days, which I found surprising. For example, $ for prices, # for hashtags, and .. for ranges of numbers. https://support.google.com/websearch/answer/2466433?hl=en
I can only get to bes before it crashes, turning off safari suggestions fixed it. I think it’s maps/shopping related, old navy and Best Buy were the suggestions.
They compare its cost effectiveness to lithium electrochemical storage batteries, but it seems much more apt to compare it to large-scale flow batteries, which also use relatively cheap, easily available materials. How does it compare to those?
It's more apt to compare it to phase change heat storage. What somehow doesn't appear anywhere on the article.
(I do believe the article's design fares much worse, even on capex alone. I never saw some salt selection that melts at 600°C, but I imagine it would have better results even in a lower temperature.)
Vanadium flow batteries are about half but will not stay that way if scaled (vanadium production is too limited).
Iron flow is currently 'it will be dirt cheap later we swear, ask us about a demo project'. So probably substantially more expensive. No compelling reason not to believe them though.
I think this article vastly undersells the value of Java(script) interop. The ability to call out to a well-maintained library in two of the most widely-used languages in the industry is one of the major selling points of Clojure as a pragmatic LISP, versus e.g. Racket or CL. The reason why there are so many half-baked wrappers around popular Java libraries is that it’s reasonably trivial to write one yourself on demand, so that’s what people do.
reply