Hacker Newsnew | past | comments | ask | show | jobs | submit | vgrafe's commentslogin

I went a couple years ago in coutryside Rwanda, where locals brought me to a place where I could have some homemade banana wine, or "Urwagwa" (not sure about the spelling!). That place was someone's house with a few people hanging out and drinking, the wine was served in already-opened glass bottles.

For those curious, it is not very boozy (maybe around 7%-10% abv), but very yeasty - to a point where it kinda numbed my mouth. For those curious the yeast is the dominant flavor, followed by banana. Very earthy taste.

Later on I saw Urwagwa sold in a can at the airport, it was very different, no yeast but bitterness instead. I preferred the homemade one.


I love this approach and use it, but just realized it does not prevent Layout components from re-rendering upon navigation... have you found a fix for this?


I use this a lot when playing music for my kid, but unfortunately the feature is clunky: weird path to find it, self-auto-disable much later but with the song still loaded. Hopefully this changes someday.


You put into words my exact experience with his influence on someone in my team a while ago. It was exhausting to have someone add complexity to our react codebase i.e. through render props + “accessor pattern”. It had a significant cost in code reviews and refactors.


Once again Kent omits to warn his audience that such a codebase has a performative intent, and should be considered a weird exercise of thought rather than a model to follow.


Edit - he added a warning shortly after I posted the parent comment: https://twitter.com/kentcdodds/status/1447283294681194496


He is working for himself only. Too self-centered to put anyone/anything else above his interests, which makes him oblivious and predictable, with a massive amount of people profiting off that fact.


This is about ownership. I agree there's no need to be personally attached to your own code. I have no problem with someone taking ownership of my work (understand refactoring/abstracting the crap out of it for the sake of Engineering). But the one day that person leaves the team, you have no choice but deal with that person's mental model, as nice or convoluted it was while refactoring. I've had this experience in every team I've worked with...


Of course, we all have had that experience! So you have a choice... realize it is going to happen and learn to deal with it in a productive manner, or just continue to get upset about it. I know which choice I'm working towards...


Are you suggesting that a dev acting like this without consulting the team should be considered normal/expected? Not sure how to address a move which is unproductive in its nature "in a productive manner" unless being proactive and preventing those rewrites to happen, unless needed and discussed with the team. But in my personal experience the team's decisions were always ignored by the coder in question.

edit: I should remind for context, I have no problem with the rewrite, but I have one with the team being handed over-abstracted code; I found that this happens mostly with more junior profiles, the same that don't stay around for long.


Since this is a fairly common dev experience (rewriting code), that the team meet together to set a policy as a group. Similar to code format standards, why not talk about code maintenance standards?


I get you now, and this is definitely an approach I agree with. I guess I was ranting about my previous experiences... since the last departure I encourage the rest of the team to plan and discuss such changes.


My two cents, Apple Car edition: adding such detail increases the visual noise when glancing at the navigation display, where simplicity should be king when the user is driving.


The fact these structures are visible while browsing the map does not require that they are shown during navigation.


We have such silly silver-bullet-like talking points at my company. I don't follow them. It is to me too easy to make up/twist past experience to match what the interview wants to hear. Oh yeah I hit that wall and used that clever way to ship in time... Oh yeah I learnt from such and such mistake... not a fan.

Instead, prior to the ITW I define clearly (with myself or an other interviewer) the information I want to hear or the parts of the intellect/emotions I want to feel.

Example: wanna check if the candidate is autonomous? Instead of asking him if he prefers working in a big or small (or no) team and get a generic/boring answer, I will ask the candidate how they prioritize tasks when no workflow can help them. Do they rely on gut feeling? perceived ROI? ask the manager? the client? In this mindset I know directly if there's a clear match, and if not it is easy to dig in their way of thinking with a follow-up question (why/how?).

Takes a bit of improvisation/reactivity but at least I feel like I keep things interesting for everyone in the room when doing so.


I use google maps a lot. When I walk around, when I drive (1hour commute/day). Also use spotify (but most of the time offline-saved tracks). Twitter/internet browsing in waiting rooms. I consume on average 3 to 4 gigs a month.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: