heyparkerj

I've expressed this to others as much as is reasonable - but the phrase "vibe coding" shouldn't be used in any serious discourse about agentic tools. We can't control the lens under which a given person first heard the term, but that moment (combined with the mountains of memes they've consumed since) is going to color a lot of folk's personal definition of vibe coding. It's not realistic to expect everyone to have a shared definition of it, despite the inventor of the phrase immediately giving it definition.

“Every song ever” is a frustratingly inaccurate summary, as someone who’s had their songs pulled off the platform with no notice that I wouldn’t hear them again.

Did Reddit actually make that threat or was that just a fearful suspicion from the userbase?

It does happen in practice, but unfortunately because it doesn't happen in practice on average, the WHO has opted away from educating people on the nuances and instead continue this maddening war about which is worse.

The other issue is that there's so much variance. Are you making an effort at improving the quality of your food and made up that 200 calories with nutrient rich items? Too bad, you still aren't losing weight, so WHO declares that diet soda is ineffective for weight loss, articles summarize and declare that artificial sweeteners are bad for you, and you still get people thinking that diet soda is worse for you than regular soda.

Which blows my mind, because when all else in the diet holds equal, swapping two sugar'd sodas with two artificially sweetened sodas will save you (using my old vice Dr Pepper as an example) 54g sugar and 200 calories per day. It's just a little annoying that WHO (or this article, not sure who's most at fault) decided not to get into the nuance that people tend to make up those missing 200 calories in other ways.

  Location: Denver, CO
  Remote: Remote/Hybrid/In-House all acceptable
  Willing to relocate: No
  Technologies:
  In depth recent experience with:
  React, NextJS, NodeJS, Typescript, Express, HTML CSS, Webpack, SPAs & state management, react-testing-library, Jest, WGAC 2.0 Compliant Web Accessibility Standards & Development, AWS (S3, Lambda, Gateway), Terraform
  I've used these before but either not professionally or it was a long time ago:
  GO, Clojure, Python, Java, Elisp, GraphQL, PostgreSQL, MongoDB, Spring

  Résumé/CV: https://flowcv.com/resume/vdsvg8neue
  Email: parkerjohnsonwebdev+hn@gmail.com

About me: I'm currently a 9 YOE senior full stack engineer at a nonprofit education organization, but I'm looking for a change. The last few years I've provided the majority of my value on the Frontend in React, Node, Typescript, but I am very interested in opportunities that expect me to be more Full Stack and I'd be very motivated to get up to speed quickly with oneOf[Go, Python, Clojure, Rust], as I'd like to extend my breadth of knowledge.

While not having this isn't a deal breaker by any means, a "cherry on top" type fit would be an organization where I can provide value to you with my current bread and butters (React, JS, Typescript) while expecting me to get up to speed in a new backend language quickly.

  Location: Denver, CO
  Remote: Remote/Hybrid/In-House all acceptable
  Willing to relocate: No
  Technologies: 
  In depth recent experience with: React, NextJS, NodeJS, Typescript, Express, HTML CSS, Webpack, SPAs & state management, react-testing-library, Jest, WGAC 2.0 Compliant Web Accessibility Standards & Development, AWS (S3, Lambda, Gateway), Terraform
  Moderate or aging familiarity with: GO, Clojure, Python, Java, Elisp, GraphQL, PostgreSQL, MongoDB, Spring
  Résumé/CV: https://flowcv.com/resume/vdsvg8neue
  Email: parkerjohnsonwebdev+hn@gmail.com

About me: I'm currently a senior full stack engineer at a nonprofit education organization, but I'm looking for a change. The last few years I've provided the majority of my value on the Frontend in React, Node, Typescript, but I am very interested in opportunities that expect me to be more Full Stack and I'd be very motivated to get up to speed quickly with oneOf[Go, Python, Clojure, Rust], as I'd like to extend my breadth of knowledge.

While not having this isn't a deal breaker by any means, a "cherry on top" type fit would be an organization where I can provide value to you with my current bread and butters (React, JS, Typescript) while expecting me to get up to speed in a different backend language quickly.

The post itself covers in the intro that they made the conscious decision to go with a monorepo, accepting the downsides of it. Much more than this article though, I'd like to read one discussing that decision and why they went that direction.

Typically the function has access to whatever props or state it needs because it's in the scope of the component. It's not pure, but it's rare that I need to verbosely pass props into the function call and then accept them in myFunction. I don't typically test these functions in isolation as the component itself is pure and I test the output of the component as a whole instead.

I've personally rarely even needed to useMemo, I just write a function that returns the JSX I need and { myFunction() } in the functional component's return (given React).

I learned skiing at ~8yo and did it until ~16, where I picked up snowboarding. I loved the change of pace, but now that I'm 30, I'm heavily considering switching back to skiing for a few reasons:

- My hips simply can not handle being twisted asymmetrically while waiting in line and sitting on the lift. Lifting and waiting to lift is probably 2/3 of your time spent on the mountain if you go fast, and my body is starting to hate it.

- A lot of my friends are picking up snow sports, and I've probably spent around half of my days in the past two years watching and helping a beginner learn. This is incredibly taxing to do on a snowboard - making your way around the bunny slopes is exhausting and requires constant booting in/out, which is a huge pain compared to skiing.

- I'm falling more. As the mountains have grown understaffed, I'm starting to succumb to the classic "fell because I was riding heelside and hit a surprise jump because of an un-groomed patch of snow." I know from experience that I'd carve right through these on skis.

- More mountain accessibility. As time goes on, I'm realizing how much of the mountain I simply stay away from because the conditions for snowboarding are rough. I stay away from moguls now, and un-groomed or icy runs provide a lot bigger of a challenge and risk when boarding. Further, commuting across catwalks is a lot less taxing on skis than a snowboard.

"Fairly easy" is never language I would use to describe showing/proving anything to the IRS

My organization's most recent hack day was won by the UX team signing up for a free demo of a chat bot service and demoing it - not a single line of code. We haven't had one since, nor do we use chat bots anywhere in our org a few years later.

I see where you're going - but I've personally noticed that there are a lot of things coming along with these cloud infrastructure paradigms that have made me feel like my localhost text editing workflows are going to make me look and feel even more like an absolute dinosaur as time goes on. I can't speak eloquently on this as I'm still an amateur to these cloud infra configuration concepts and their real limitations on how I'm used to thinking about application development, but I hope this comment sparks some inspiration for someone else to do so.

I listened to Joe a lot when I was doing manual labor in 2013-2014ish. Like almost every single episode. I was always able to intake the things I thought were interesting and laugh off stuff I thought was dumb or unconvincing, but I do remember thinking that one day the greater internet will realize that his podcast is littered with content that people could easily misconstrue and start a real uproar about with sufficient motivation. Based on this, I think people shining a light on some of the dumber things that a self proclaimed dumb guy says while recording himself talking for 10 hours a week, and becoming a bit of an internet meme in the process was inevitable - and that's before he started saying whatever the hell he's been saying about vaccines and masks.

ACAB is another poorly chosen slogan for its best interpretation. The most moderate explanation is that to bastardize means “to change something in a way that makes it fail to represent the values and qualities that it is intended to represent” - the rest of the implication can be assumed from there.

From what I've been reading (disclaimer - over the past few hours) the types of stocks you target during periods of inflation changes. You're also playing a bit of a guessing game, because your return will be less than other investments if an inflationary period does not actually realize.

I think it would be fair to interpret that as "failing to change as many minds as they could"

The most common problem I see is not echo, but software audio ducking that happens as a result of using onboard speakers and mic.

Some people have a hard time realizing that they're interrupting someone else because that other person's audio is getting ducked while the laptop prioritizes mic input over speaker output - with the intent to reduce echo.

> it seem to me like meds are the only real treatment. This could be wrong.

I'll comment on this, as a neurologically tested ADHD 30 year old with 2 decades of on/off medication experience.

"Treatment" is a spectrum, unsurprisingly, and a bit of a misnomer. While I'm not completely on board with the "ADHD is actually a superpower" train of thought, I do believe that there are some interesting tradeoffs that having it can benefit in some ways - obviously that's different for every person. If you start throwing away the concept of being binary "treated" or not, you can start thinking in terms of "what is working for me right now". Sometimes being medicated is a life changing benefit, and other times in my life I'm waaay better off without medication.

It's important to distinct the two, because what medication can get you is a better understanding of the daily patterns that work best for you, and it is (in my opinion) the best way to start building that understanding. Sometimes medication is the only way for me to reach a certain place I want to be, and no medication can do the same, but I firmly believe that the habits I build during medicated periods of time help me make the most out of my non medicated periods.

For what it's worth, when I talk about on/off periods -- I was medicated in middle school through high school, took my first two college years off, got back on the next two, final year of college was no medication, got back on for 2ish years when I entered the workforce, then took the next 4 years off. I'm back on it now. I don't really consider week or weekend breaks an off period.

You should watch the talk - I actually happened to do so yesterday so it's still in my mind.

The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness.

To quote/paraphrase from the 5:10 mark of his talk...

"If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."

I've always been rubbed weird by CSS for these reasons:

1. Often times, someone will do something that should be done programmatically with CSS instead, leading me to finally come to the realization of "holy shit the bug was hidden in the CSS!".

2. I've (very cattily) referred to CSS as Cascading Sideeffect Sheets. You can do things to mitigate it, but trying to wrap your head around an application's vanilla CSS declarations and which elements are effected by what is an enormous pain compared to what it could be. My team has switched to CSS Modules, and the scoping relieves sooo much of my aversion to it.

3. The final reason is that CSS proficiency just feels like memorizing a collection of "Gotchas" that don't make sense in isolation. It's not very programmatic, and lots rules aren't grouped or named in a way that you can understand what's going on by reading. For every CSS rule you need to understand for whatever reason, you're going to have to dive into some documentation to figure out exactly all of the effects/sideeffects it will have, and sometimes also have to grok their interactions with other rules.