alphanumeric0

> excels at the part of the job that was my favorite (writing code)

AI excelling beyond a human at writing code is not an objective truth.

I would say even without AI, a manager telling a developer what to code or how to code, will never be better than that engineer themselves being the driver and the developer.

For me personally, quality code has a strong human component. Only I know what's best for the code, based on:

1. my deep understanding of the long history of the organization and of its mission and concepts 2. my intricate personal relationships with the users and the other developers 3. all of my hundreds of unique, personal experiences troubleshooting problems, which are always a combination of code and interpersonal relationships, the open source community, and opposing stakeholders.

Until AI becomes AGI (and that's a big if) and you can train it on 43 years of experience, it will just be an approximation of a true person's holistic engineering pedigree. It will always be asymptotic to true competence. It will always be second-best, even with a human driver.

I worked on an Elm project professionally for a few years, and I just finished upgrading an old React app to version 19 on my own, which took a greater part of a year.

I can appreciate even more now why Elm is so opinionated. As much as Elm is a unique technical, research language, it is a huge cultural change, and I think that is why so many people left. Allowing libraries to be thin wrapper over ports is one example that goes completely against the Elm philosophy.

I'm happy to see Elm is still around, and I hope one day people will see more value in it.

That's great news.

Do we have any idea if they'll have something ready before September?

Even the simplest of projects have these engineering challenges, but people cannot see the forest for the trees when it comes to maintenance.

Since I did not enter the industry with a computer science degree, I was relegated to less desirable maintenance work for the majority of my career. I have twenty five years of experience reading other people's sometimes great, frequently benign, and occasionally really bad code.

Unfortunately, most of my experience is wasted and not well respected. Most people do not care to look far ahead, they are far too consumed with 'just getting it up and running'. It's all engineering in the end. The house building analogy holds. Make smart tradeoffs. Don't paint yourself into a corner. Build exits for yourself: from platforms, APIs, libraries, and seldom trodden code paths. If you can write it yourself and it's not that complicated, write it yourself. Dependencies are a nightmare from a security and long term use perspective. They might be good for starting out, but you really have no idea where your project and organization will take you.

If I were a hiring manager I would value this experience more than anything else. It's nice if you can bang out some algorithms, but I think it's much more useful for most organizations if you can make forward-thinking engineering decisions.

Ah cool to see this on HN! I'm taking a numerical calc class right now and it's nice to get some historical context around something you're studying. I'd recommend checking out some cool graphs about Runge's phenomenon and Chebyshev polynomials.

- What is it? - What does it do? - Why does it do that?

This could all easily fit in the top-level comments of a main() function or the help text of a CLI app.

- What is the API?

This could be gleaned from the code, either by reading it or by generating automatic documentation from it.

- What does it return?

This is commonly documented in function code.

- What are some examples of proper, real world usage (that don't involve foo/bar but instead, real world inputs/outputs I'd likely see)?

This is typically in comments or help text if it's a CLI app.

The code, tests and comments convey what actual business rules are implemented.

While documentation is someone's non-precise natural language expression of what (to the best of their imperfect human capacity) expected the code to implement at the time of writing.

“While our study did not differentiate between methods of cannabis consumption, cannabis is most commonly consumed by smoking,” Kokot said in an email. “The association we found likely pertains mainly to smoked cannabis.”

So yeah if you inhale smoke that can cause cancers. Sure seems like a hit piece when you bury this sort of information.

Sounds like the future is bright for the field and that it has lots of applications. I'd imagine future aging treatments would employ several of these methods together, say cell reprogramming for your organs, along with resetting some of those aging biomarkers.

It's funny that it was considered a pseudoscience for such a long time, when there's lot of clinical applications outside of trying to live longer. For me, as someone with celiac disease, I know the age of my intestines are probably older than most people, after constant damage from gluten. It'd be nice to have a cell reprogramming treatment for intestines.

This reminds me of gömböc

A good SWE salary doesn't necessarily elevate you to the same strata anymore. Most of the programmers I work with have parents that supported them, especially monetarily. I myself, could not rely on either parent. Well-off parents can help you with a down payment on a house, be a better present grandparent, and be a reliable source of financial support in hard times. For most people in these well-paid positions, a job doesn't guarantee buying a house anymore, or a stable future. Only generational wealth does.

This is why you use a datetime library.

These prices are pretty meaningless. They said the same thing about Hyundai Konas but dealer prices are substantially different. Used/new car purchases continue to be a terrible value proposition.

I only rent EVs, if possible. I've gotten by just fine. Plugshare app makes it easy to find working chargers.