cjcenizal

If you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.

I went through this process this year. Found solar installation companies on Yelp, got some quotes, chose an installer. A month later, I have Panasonic panels and a Powerwall powering my home. There’s plenty of info online. I live in the US and found this resource very educational: https://www.energy.gov/eere/solar/homeowners-guide-going-sol...

How old are your kids? I found it was really tough for me until they hit around age 3 or 4. Getting them into school helped enormously. As they grew older it became easier for me to reason with them and they also became more capable of taking care of themselves and even helping me with some things.

It’s just an abstraction for the idea of “this pattern tends to signal a problem”. The same way humans have learned that certain smells signal spoiled meat or rotten eggs. Sometimes those smells can safely be ignored, like when eating Limburger cheese or durian fruit.

Code smells themselves aren’t problems, they’re just useful track marks that might indicate a problem is lurking nearby. Worth looking into and making the decision yourself.

The article notes there are regions where "wild animals are popularly eaten."

Thanks for sharing this info. It’s helpful, and I will take some time to digest it.

I love your objective approach and, as an engineer, I appreciate its merits. But I’m afraid you might not like my answer because it’s based on lived experience.

I live in the area affected by the Eaton Fire. I’ve been here for 10 years. We experienced severe droughts and wildfires in the first 8, and though they were bad fires and made the air feel like we were living in Bladerunner’s LA, it established a norm. In the winter we got used to seeing rains. 2 years ago at this time of year we had snowfall (!). Last year at this time we had hard rain. This year, same time, we have catastrophic wildfires that wipe out neighborhoods. I’ve never seen winds like the ones we saw. They were terrifying. Like being in a hurricane.

Anyway, that’s how I know it’s unusual…

“Climate change isn’t the cause.”

The region experienced back to back years of high rainfall, spurring brush growth.

This year the region experienced severe drought, converting all of that growth into fuel.

Last week the region experienced 100 mph winds, which converted spot fires into fast-spreading conflagrations that could not be fought.

This pattern of instability is an outcome of climate change.

So yeah, it was caused by climate change.

I think this is a valid approach, but success is contingent on working with product-minded engineers [0]. I consider myself to be one, so I'm a fan of this approach. There are also many engineers who aren't product-minded, and they might prefer working in a culture where their job is to focus on execution.

[0] https://blog.pragmaticengineer.com/the-product-minded-engine...

You're describing symptoms but you don't know how to address them because you don't know the cause. Dig deeper. Ask folks if they feel a sense of urgency. If they say no, ask them why. Once you understand the root of the problem you'll be able to iterate on solutions.

According to The Phoenix Project [0], if you can form a model of how work flows in, through, and out of your team then you can identify its problems, prioritize them in order of criticality, and form plans for addressing them. The story's premise sounds eerily similar to what you're facing.

At the very least it's a fun read!

[0] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

Thank you! As snide mentions a few threads up, we built a documentation website for the library from day 1, which I think helped folks a lot. I'm not a fan of Storybook -- I prefer docs to present components in realistic situations, and to have code snippets live-side-by-side so someone can say "Hey this is exactly what I need" and copy and paste it into their codebase. For example, form docs should have an example of a complete form with validation, accessibility attributes, help text, and so on. This way the docs act as both an advertisement and as a resource.

Regarding tools, I recall a bunch of stuff. YMMV:

* A presentation to the wider team on the goals of the library.

* GitHub issues outlining technical design of the library -- this was useful for getting buy-in from tech leads.

* One of the consuming developers gave a presentation on how she had implemented a UI using EUI.

I think it just comes down to repetition and, as snide alluded, positioning yourself as a servant instead of an authority. Keep beating the drum, share success stories, and demonstrate that you're responsive to the feedback you're heading from the folks downstream. Good luck!

Hey Dave! I think your great design was a big factor in incentivizing people to use EUI. When folks can see how much of a boost the library can give a UI, they'll _want_ to use it.

I did this! I founded EUI [0] at Elastic and helped teams adopt it. I attribute success to a few factors:

1. Publish components, not styles. This has been rehashed in other HN threads, but the idea is to provide Lego blocks to help engineers build UIs more quickly. This might be out of fashion with Tailwind adherents but we found success by treating the framework's primary interface as React/Vue/JS, not CSS.

2. Be transparent and receptive. Share your goals with consuming teams and ask how you can help them. They might ask for specific components or might ask you to help them convert a UI to use the library. By demonstrating that you and the library are there to serve (as opposed to dictate) you'll earn goodwill and your work will have more impact.

3. Have high-quality components. This applies to the UI design (both how the components look and how they behave) and software design. Are the props intuitive? Do the components compose well? We were fortunate enough to have a strong design and engineering team that did well on this points.

4. Seed the consuming codebase. Patterns in codebases propagate because engineers like to copy/paste. For example, start by migrating all buttons in the consuming codebase over. Then migrate over all forms, modals, and so on. It also helps to take a vertical approach, by migrating a single view entirely over to the library, or building one from scratch. This can get people excited about the library because they can see and experience the end result.

5. Ensure compatibility with the existing codebase. Make sure styles don't collide, make sure the underlying JS libraries are compatible. I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular. We needed simple guidelines to support the engineers who were doing that.

[0] https://elastic.github.io/eui

I think mature individuals will be able to overlook significant differences in one another and focus on the outcome: helping the team and the business succeed. If I picked up a signal that a candidate wouldn’t meet this bar, I wouldn’t hire them.

Learning how to understand, relate to, and collaborate with people who are different from you is part of growing up.

I don’t have information that explains your experience but I can give you concrete resume advice based on my own experience as a hiring manager: https://www.cenizal.com/resume-advice-for-engineers/

I think the point is that one group of people is imagining a change and saying, “That change will be intolerable!” And then another group is actually experiencing the change and saying, “Hey, it’s actually pretty good.” You won’t know how you really feel about it until you try it yourself, and speculating about the second group won’t net you any benefit.

I’m torn on litter. On one hand, I like a clean immediate environment as much as anybody else. On the other hand, throwing it in the trash is just hiding the problem. The garbage was still generated, and it still goes somewhere. If we were forced to confront the sheer amount of garbage we produce, maybe we would be compelled to produce less. But ah well… out of sight, out of mind.

My very modest claim to "fame" is having founded the Elastic UI Framework [1]. My experience with these kinds of design systems taught me two lessons:

1. You'll iterate towards the most useful version of your design system in the least amount of time if maintainers spend time consuming it, and vice versa.

2. Code is the source of truth, in the form of the component library. It's an unhelpful fiction to treat the non-code design system (whether that's in Figma, Sketch, or wherever) as the source of truth. This is because people build out new parts of the UI by copying, pasting, and modifying the code of the existing UI. If you want to make a change to the design system, it has to go into the code to make a difference.

[1] https://elastic.github.io/eui

The author might have meant “boilerplate.”

Congratulations! I went through a similar journey. Here’s my recommended reading: https://www.cenizal.com/reading/

I work at Vectara and I'm curious -- are folks here using Retrieval-Augmented Generation (RAG)? What's your stack and what kind of improvements have you seen in answer quality?

What I do is ctrl-f in the codebase to look for the name of the React component. This tells me how often it’s being used, and I can see exactly where and how.

This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive.

[0] https://react.dev/learn/you-might-not-need-an-effect

Folks, this article isn’t a criticism of the movie. It’s literally a “Oppenheimer, and…” not “Oppenheimer, but…” type of article. If you appreciate history, you will appreciate this article.

I also like exploring video games. I love hiking and the outdoors, too. To me, the difference in appreciation and experience is that one is art and one is reality. Art has been arranged by another person, typically for aesthetic effect, and so anywhere you look you’ll see something designed to elicit a reaction from the viewer. No such thought has been put into reality so despite the stunning amount of detail, it takes work and luck to find the beauty in it. One of the reasons we might say a particular moment in real life was “like a painting” or “like a movie”.

Instead of framing it subjectively (“People’s feelings are hurt by capitalism”), consider it objectively. What’s the effect on society when increasing your productivity doesn’t increase your wealth but instead is just a requisite for employment? Wealth accumulates with the wealthy, as the OP stated, and the rest of society grows poorer, sicker, less mobile, and less creative. Would you say that’s sustainable?

How much of your company’s revenue is earned through that product? If it’s significant then the cost of introducing regressions in quality or functionality goes up. As companies grow and mistakes become more costly, they become more risk-averse and invest more resources into reducing risk. This slows things down and requires more people.

I suggest you read Bret Devereaux's "This Isn't Sparta" [0] series. He dismantles the myth the "hard times" cycle you mentioned.

For contemporary examples, just look at North Korea or Russia. Life is undeniably harder for citizens living in these countries, but where is the expected "strength" and "good times" that should result?

[0] https://acoup.blog/2019/08/16/collections-this-isnt-sparta-p...