000ooo000

80 lines of licence comment

30 lines of class boilerplate

One explanatory comment for every statement

The revolution is here!

CEO of company with AI product says, in earnings call, that nontrivial amount of code is generated by AI..

Do people think an earnings call is some kind of secret meeting where the marketing stops?

>15 year old codebase

Is this what people think of when they think of an old codebase? Must be nice :')

Another day, another listicle about senior/staff/principal developer labelling disguised as a blog. Only insecure devs care about this crap. Devs who know their shit aren't coming up with definitions distinguishing themselves from devs who don't. They have better things to do (e.g. actual work).

Idea's can't exist? Legalism will tend towards might equals right? Dubious at best.

>I would protect the elephants because I like them. No use bringing rights into it.

Rights are rarely needed to protect x from y when y likes x..

>I have found that OOP with inheritance is actually a form of tight coupling and that it is best to not use class hierarchies [..] I just completely disagree with inheritance in all forms

This is pretty common advice (at least IME), usually distilled into the form "prefer composition to inheritance".

Is thunderbong a bot? The account posts around the clock.

Ironically, the author became a "senior engineer" after 3 years of professional software development, some of which was contract/part time (their LinkedIn profile is not hard to locate). IIRC the last article on the same topic that was posted to HN was nearly exactly the same scenario.

Your post history kind of makes this look like a bit of a(nother) thinly-veiled ad.

The article doesn't say or suggest that. It says it applies to engineers.

Splitting a team by interesting/uninteresting work is a comically bad idea. It's puzzling that it ever gets pitched, let alone adopted.

Edit: I mean an ongoing split, not a rotation

Curious how tech-oriented parents here are approaching TikTok et al with their kids. My kid isn't walking yet, but for when the time comes, I'm not sure how I'll limit exposure to what I'd call "pure trash", but also give them freedom and the ability to 'fit in' with (inevitably) the rest of their friends using this stuff.

>You know what happened? A few weeks later I saw a bunch of index.js files again, with the checks removed from the codebase, with no discussions about that and no concrete arguments about why using index.js everywhere is better

How'd this story wind up?

Not the same as manually implementing it in every component as a rule.

>However, we had a long discussion with one programmer who insisted it was a bad idea because of "premature optimization", the fact that React docs does not have recommendations about it, and "nobody does it that way". In my opinion, this was a clear case of a programmer resisting the system approach because he wanted to spend time fixing the same problems over and over and pretend to be working hard.

This article and advice is awful. The fact that the author ignores completely reasonable arguments made by the dissenting programmer, instead attributing their 'resistance' to some dubious, made-up notion that they would prefer to do meaningless rework, speaks volumes.

>However, I usually trust my intuition quite a lot, and before giving it up I decided to find some strong arguments in favor of Leetcode (LC) interviews, and here they are.

Sounds like confirmation bias to me..

Many words, little insight. Draws some weird lines, comes off as a little preachy. Overall, seems it could be summed up as "use the right tool for the job" and "the business' codebase is not your hobby project".

It is interesting how otherwise smart, talented people rationalise the donation of their labour to an entitled majority who have no idea about or interest in the person or motivation behind the work. Who cares right? Just keep the free shit coming.

Strange choice of language for the actions:

>To route traffic through the proxy to a web application, you *deploy* instances of the application to the proxy. *Deploying* an instance makes it available to the proxy, and replaces the instance it was using before (if any).

>e.g. `kamal-proxy deploy service1 --target web-1:3000`

'Deploy' is a fairly overloaded term already. Fun conversations ahead. Is the app deployed? Yes? No I mean is it deployed to the proxy? Hmm our Kamal proxy script is gonna need some changes and a redeployment so that it deploys the deployed apps to the proxy correctly.

Unsure why they couldn't have picked something like 'bind', or 'intercept', or even just 'proxy'... why 'deploy'..

If I can add to this, I think there's something attractive to many about the large, stable, slow-to-steer ship that is a large company: often there's low expectations (relative to startups), you can get "lost in the bureaucracy", and rarely do you get to make a real, influential decision because of the incredible amount of in-fighting and empire-building above you, so you can coast. Taking a different angle to your conclusion, these conditions set up the departure from "how do I contribute to the company creating the best product ever" to "doing more than the bare minimum to guarantee my paycheck nets me a low/negative ROI". Not the ideal attitude for your team to have.

I'm in an org at the moment and I'm watching new layers of middle management being created, excess processes being introduced, ICs being disempowered, consultants being engaged over in-house, eye-watering dollars being pissed away while penny-pinching on things that keep the lights on, etc. I have to wonder what are the conditions that mean these (what I consider to be) mistakes can go on for years before a company actually begins to be seriously impacted? Is it actually extremely difficult to kill a large enough org from the inside once it has enough momentum, provided the org avoids doing anything particularly stupid? I can't actually think of something an org has done that was particularly stupid and resulted in its end. Do big companies even fail?

Not all ICEs must consume fossil fuels. The tech could bring alternative fuels closer to viability.

>But I find it hard to believe that every company doing this would act against its own interests in terms of productivity

Ever worked in a company?

Stupid argument. With this logic, nothing new is ever explored, nothing is learned, no insights gained, or shared. This logic even questions the need for chezmoi - stow existed for decades before chezmoi. You think chezmoi sprang into existence with all its features? High chance it was someone's toy project because they didn't want to use stow.

Some responders here almost seem offended you wouldn't use chezmoi. Kind of strange. I couldn't care less about someone using chezmoi/tool x - big deal - but I'm always interested to read how people approach automation of their workflows, the tradeoffs, any cool tricks they employed that I might not have heard of before. Are engineers discouraged from problem solving now? It's not like youre doing this on company time; you are allowed to do things for fun/interest's sake..

I would actually be far more frustrated by mandatory 2FA at login than if my GitHub account were compromised. I use it to star projects, and because you can't code search without being logged in; it's a bottom-tier account for me and 2FA means I'll probably just not bother. Why can't they gate sensitive features behind 2FA?

As an aside, I'm surprised I've never seen an async authentication system whereby PW gets you in, 2FA code is sent, and you can continue accessing the system in a limited way until you submit your 2FA code, instead of sitting on some intermediary page waiting a few minutes for the code to arrive.

Guessing 'gippity' has been used by primeagen recently, so now you're gonna be tarred with the 18-23 React bootcamp graduate brush (at least that's who I imagine find him watchable).

Skip this. It's just some guy asking on GitHub in 2023, and 2-3 nobodies speculating. Why this was posted to HN, I have no idea.

Single-sentence paragraphs really set off my LinkedIn hot take/BS detector, and this article has no shortage.

I vaguely remember a doco (about a study?) where they established similar fear in crows using similar masks. They tracked these crows, waited for them to breed, and tested how the babies responded. Saw this over a decade ago now I'd guess, so my memory is fuzzy, but IIRC the takeaway was that the parent crows were able to communicate the knowledge to their offspring that these masks were bad news.

>Engineers have a low opinion of advertising—and of people whose job it is to create advertising

Yep. I have a low opinion of anyone who tries to manipulate others using deceit and trickery. Marketers just happen to have made a career out of it.

The irony here is that this 'article' is just an ad for this guy's consulting services.