koreth1

I kind of hate the fact that the term "API" has lost its generality in the minds of a huge number of practitioners, and people now assume it refers to a set of network (usually HTTP) request and response formats.

It's great that we have a succinct word to describe programmatic interfaces built on top of HTTP. It's not great that there's no longer a universally-understood word for the original more general meaning even though, as this thread demonstrates, the original meaning is still as relevant as ever.

By way of example: when I worked on payment code in Java, we accepted numeric JSON values in request payloads but they were deserialized into "BigDecimal" fields in our payload classes, not "float" or "double".

That's an excellent point too. Some payment systems have abysmal technology. The product I worked on was focused on international payments and in a couple cases, the "API" was literally, "Upload a CSV file via FTP, and at some later point, another CSV file might appear on the FTP server with some of the payment results, but if it doesn't, call us because we probably just forgot to upload it."

Right, Stripe is a middleman and part of the value they're giving you is that you don't have to work directly with the underlying payment companies. If you had to support the same range of payment options without a middleman, you'd need to have business relationships with a bunch of payment companies, which would be a lot more difficult and time-consuming.

Hope that's clearer!

Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide range of countries without a middleman. You'll probably also get much better support from a tech-focused company when an API starts freaking out.

> If you hate writing code but do it for your job, then you are going to really hate writing code in two different languages with their own syntax and paradigms.

I don't wish for this, but sometimes I wonder how different the industry would be today if dev salaries had remained in "respectable but nothing amazing" territory.

Maybe it's just nostalgia goggles, but when I was getting started ~35 years ago, I think it was rare to run into someone who hated writing code but did it for their job. There were other much more profitable jobs for people who were looking to be paid as well as possible for work they hated.

What killed Quora for me was that they decided to prioritize quantity of questions over quality of questions, and as I recall, they even set up incentive programs to reward people for asking as many questions as possible.

The site was inundated with repetitive low-effort questions, often with false premises that seemed intentionally crafted to provoke people. The crappy questions drowned out the interesting ones that had previously made me a regular visitor.

Scrum is the thing that has tainted "agile" in my opinion, because Scrum is so widespread that many people think they're the same thing.

Leaving aside the "agile is a philosophy, not a methodology" argument, there are well-defined agile methodologies other than Scrum. I've worked at a couple Kanban shops and, while our dev processes were far from perfect, most of the things people routinely hate about "agile" just didn't come up at all because they're actually Scrum features.

If the thing you don't like involves the words "sprint" or "standup," you are complaining about Scrum, not agile.

That last one is an interesting example. If I needed to do that, I would write something like this (in Kotlin, my daily-driver language):

    fun foo(list: List<Bar>) =
        list.filter { condition(it) }.associateWith { transform(it) }

which would take me less time to write than the prompt would.

However, if I didn't know Kotlin very well, I might have had to go look in the docs to find the associateWith function (or worse, I might not have even thought to look for it) at which point the prompt would have saved me time and taught me that the function exists.

This is useful, thanks. Since you're using this for learning, would it be fair to characterize this as asking the LLM to write code you don't already know how to write on your own?

I've definitely had success using LLMs as a learning tool. They hallucinate, but most often the output will at least point me in a useful direction.

But my day-to-day work usually involves non-exploratory coding where I already know exactly how to do what I need. Those are the tasks where I've struggled to find ways to make LLMs save me any time or effort.

> My prompts are long and complex, with a paragraph or two about the general objective followed by 15 to 20 numbered requirements. Often I'll include existing functions the new code needs to work with, or functions that must be refactored to handle the new requirements.

I guess this is a tough request if you're working on a proprietary code base, but I would love to see some concrete examples of the prompts and the code they produce.

I keep trying this kind of prompting with various LLM tools including GPT-4 (haven't tried Gemini Ultra yet, I admit) and it nearly always takes me longer to explain the detailed requirements and clean up the generated code than it would have taken me to write the code directly.

But plenty of people seem to have an experience more like yours, so I really wonder whether (a) we're just asking it to write very different kinds of code, or (b) I'm bad at writing LLM-friendly requirements.

That childhood native-fluency analogy is insightful! Your experience matches mine.

I started programming at age 7 and it's true that the way code forms in my head feels similar to the way words form when I'm writing or speaking in English. In the same way that I don't stop and consciously figure out whether to use the past or present tense while I'm talking, I usually don't consciously think about, say, what kind of looping construct I'm about to use; it's just the natural-feeling way to express the idea I'm trying to convey. The idea itself is kind of already in the form of mental code in the same way that my thoughts are kind of already in English if I'm speaking.

But... maybe that's how it is for everyone, even people who learned later? I only know how it is in my own head.

I've read that it's common for mystery writers to start with the ending and work their way backwards so the clues all line up.

Isn't that true for all stores, though? If I'm buying something like that, I'll always search for reviews before deciding, whether or not Amazon is involved. Even if it's at a brick-and-mortar store.

The phrase "caveat emptor" was coined long before Amazon existed.

I threw in the towel after about 10 years but not because of deliverability problems. When I first started running an email server for myself and my friends and family, it was a great learning experience. And it kept being a good learning experience for a few years as I rolled out things like Bayesian spam filters and SPF.

But eventually it got stable enough and did its job well enough that I stopped messing with it to learn things. And then it became a job instead of a hobby: friends texting me because my ISP was having an outage and they couldn't read their email, rolling out critical security patches ASAP, coping with the occasional DOS attack, and so on.

At some point, I realized that I'd started to resent running it. It was eating little bits of my time for no additional benefit to me.

I also, as one does with age, started thinking about what happens if I die or become incapacitated: my friends and family all lose their email service the next time there's an outage that requires manual recovery.

So I moved it to a commercial email service and have zero regrets about the move. I make sure I've always prepaid for at least 6 months of service so that if something happens to both me and my wife, my friends and family will at least have half a year to make other arrangements.

The biggest problem I've seen with OKRs as an engineer is that the objectives are business goals the engineering team has little or no ability to influence. Like, an objective of "onboard 5 new large customers" makes sense for the business, and the engineering team could definitely screw it up by, say, building a system that can't scale that high. But when the sales team only closes 3 new deals, the engineering team fails its OKRs no matter how good a job everyone did. I've seen this be quite demoralizing, especially when meeting OKRs is tied to bonuses.

The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.

I keep hearing this explanation (executives want to keep commercial real estate values up) but it has yet to make sense to me. Can someone lay out an example scenario?

"Having investments in commercial real estate" isn't sufficient explanation on its own, IMO. It's certainly true that a lot of executives have commercial real estate investments. It would be weird if they didn't, because real estate is a pretty common thing to have in an investment portfolio. But those investments are going to be diversified across a bunch of commercial real estate, little or none of which has any relationship to the executive's company (because otherwise it wouldn't be very well diversified).

Another unfortunate thing in this context is that coursework is almost always greenfield development of small projects.

Coming up to speed on a large existing code base of inconsistent quality and style is another enormously important job skill, as is writing code that can be maintained by the person who has to come up to speed on your code a year later, but you'll never get those skills from writing small precisely-specified programs from scratch.

That's one aspect of reliability, but the one I was more curious about was determinism. If I repeatedly run the same test suite on the same code base and the same data and configuration, am I guaranteed to get the same test results every time, or is it possible for ai() to change its mind about what actions to take?

I think "most of what I learned is inapplicable to my job" is kind of inevitable in any CS program that tries to expose students to a breadth of topics before they graduate and get hired into specialized jobs. The trick is that the "most" will vary from person to person.

As a fellow 1980s CS person, I too got a lot of DSA coverage, but I ended up using a respectable amount of it when I was working at low-level systems programming jobs. I have never used what I learned in my computer graphics class. But I had classmates who went into animation and used that stuff every day.

Agreed about the lack of any education about the "engineering" side of the work, though. One challenge is that engineering is mostly a group activity but education is focused on individual learning. With some exceptions, you don't get a group grades in classes, and usually, collaborating with other students on your homework or your tests is considered "cheating" rather than "teamwork." Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished, but dealing well with unpredictably shifting requirements is a huge part of the job.

2 deploys isn't enough for robustness. It depends on what the change is, but the full sequence is often more like

* Add the new schema

* Write to both the new and old schemas, keep reading from the old one (can be combined with the previous step if you're using something like Flyway)

* Backfill the new schema; if there are conflicts, prefer the data from the old schema

* Keep writing to both schemas, but switch to reading from the new one (can often be combined with the previous step)

* Stop writing to the old schema

* Remove the old schema

Leave out any one of those steps and you can hit situations where it's possible to lose data that's written while the new code is rolling out. Though again, it depends on the change; if you're, say, dropping a column that no client ever reads or writes, obviously it gets simpler.

And a tricky part of this, for certain kinds of nonprofits, is that you'll be penalized for it because your efforts to raise more money will be classed as overhead and will lower your efficiency rating on various charity-rating lists.

A nonprofit that spends 1% of its funding on fundraising and barely scrapes by each year will be rated as more cost-effective than a nonprofit that spends 10% of its funding on fundraising and grows its donations by 15% a year, even though the latter is ultimately going to be able to devote far more resources to its programs.

I don’t doubt at all that this has happened to you, but as a counterpoint, in 35 years in the industry, I don’t remember ever having been lied to by an interviewer at a company that ended up hiring me. Of course I have no way of knowing for sure about companies that didn’t hire me.

Framing things in a positive light? Sure, but that doesn’t require lying.

I’ve also never once lied to a candidate as an interviewer, nor have I ever been asked to lie. More the opposite: when my employers have addressed this question at all over the years, it has always been to tell people to be truthful with candidates.

Even leaving aside the ethical question, it would be a bad move: if I deceive someone into joining my team, I’m the one who will have to suffer through a working relationship with someone who knows I lied to them from the first moment they met me.

Edit to add: I’ve definitely been lied to by recruiters. Just never by peers or managers.

> I think Kotlin is at risk, though, of having the JVM force them to support two competing models to accomplish the same thing - coroutines and virtual threads is a good example

I don't think it's that good an example, though there's some merit to it. Kotlin coroutines, to me, target three main use cases:

1. An abstraction over an underlying threading model. Get threaded execution without having to explicitly deal with thread pools and such. I'd consider structured concurrency to be part of this use case.

2. A way to write non-blocking code that is structured as if it were blocking. (Incidentally: I love Kotlin's decision to make "await" opt-out instead of opt-in.)

3. A way to write code that generates sequences of values without having to either write an explicit class that maintains state across calls or use callbacks/CPS. Or in other words, a way to use the "yield" function.

Use case 1 still makes sense with virtual threads. Run your coroutines on an executor that uses a virtual thread pool instead of a platform thread pool. If you prefer the coroutines API, you can still use it for structured concurrency and such.

Use case 2 is much less interesting in the presence of virtual threads; you can just write blocking code directly, no need for the language to turn it into async code for you.

Use case 3 has nothing to do with threads to begin with, so it remains exactly as valuable as before and there's no reason to change any existing code at all.

Do coroutines get less useful in the presence of virtual threads? Absolutely. But they aren't competing with virtual threads; there are substantial non-overlapping use cases that make them a worthwhile language feature.

Glad I'm not the only one who was irked by this, and I do need to know a lot about Unicode for my job!

I believe there actually are topics that every software developer ought to know something about, but this isn't one of them. My list would be things more like, the difference between a constant-time algorithm and a quadratic-time one.

> with a bit of back and forth you can get pretty good results that work with only a bit of revision

The problem for me is that the "back and forth" and "a bit of revision" steps very often end up taking more time than writing the code myself would have.

My theory has always been that it's purely an artifact of the spoken language.

When we're saying a date out loud, we Americans tend to say, "September 21st, 2023," whereas I've noticed many of the Brits I've worked with have tended to say, "21st September, 2023," sometimes with an "of" after the day. Those spoken word orders were carried over into the written form, is my suspicion.

Kagi is my default search engine and I'm happy with it except for one category of search: location-sensitive.

I live in San Francisco, and if I type "sf weather" into Google, I get a weather forecast for San Francisco. If I type "sf weather" into Kagi, I get a weather forecast for Santa Fe, which, while technically a valid result for those search terms, is useless to me. Similarly, it's easy to search for restaurants and get search results for other restaurants of the same name in different cities.

But most of my searches aren't location-sensitive, and Kagi does a great job the rest of the time.

What would "quality control" look like for self-published books?

I have a Miele dishwasher and it does a great job of washing ceramic and glass dishes. But reusable plastic food containers (Gladware, etc.) always come out sopping wet and I have to hand-dry them.

The Miele is nice and quiet, but sometimes I miss my old loud energy-hogging dishwasher that had a real "dry" cycle with a fan.