t-writescode

6,246 karmajoined 7 лет назад

comments

2 часа назадdiscuss

And Fahrenheit 451 is a book.

2 часа назадdiscuss

To add to this, for all the claims of 100x, can anyone cite an example of someone actually pushing 100x in a domain that isn’t “translate or port tool/library/whatever from language A to language B”? Because that’s literally what LLMs were invented for and that’s not a normal part of work.

I will fully admit we have examples of people converting Postgres to Rust, HL2 to wasm, etc. but that’s all porting. The code was there, we’re just translating it, warts and original-languagisms and all.

But even if you’re making a bunch of tiny tools and chaining them together, I can’t see more than a 2-3x sustained increase.

We also have artists that can make games now, and that 0-1 transition sure feels like 100x and maybe it is; but the problem of “starting feels impossible and the barrier is too high” to “I can now actually do something” is not where the 100x developer idea comes from either.

And that 0-1 change asymptotes really quickly to, again, maybe a sustained 2-3x once the artist understands the domain.

So, does the 100x person, who isn’t a novice and who isn’t literally translating existing code from A to B, exist? What are some real world examples?

Edit: I will concede one area: the investigation stage. E.g. “Does this code have an exploit?” I would argue that’s not generating new output (yet), but it is a great deal of work that is simplified and sped up. It’s also where most of my own use of AI speeds me up considerably as a developer.

20 часов назадdiscuss

Oh definitely not. Many of us work in tech. Many of us are the people that wrote the code that other people on this website complain about as anti-patterns, dark patterns, etc.

23 часа назадdiscuss

God I hope not. That’s terrifying.

23 часа назадdiscuss

Citation Needed.

The specifics of an implementation of this are objectively absurd. Power requirements alone make this a non-starter. If that weren’t enough, it would be a declaration of war.

вчераdiscuss

I have been impressed with them as a “on this line” or “the next couple lines” autocomplete, though.

My first real use with them as that was during an interview with Jetbrains’ assistant enabled and I repeatedly went “oh! Huh!”, so … in that form, it seems very good but that’s first impressions and everything feels like magic at first

вчераdiscuss

You’d be surprised how often this doesn’t end up happening, especially in languages that are supportive of this style:

Kotlin, Python and Typescript, to name a few. A lot of functions you write are helper functions, wrapper functions, system functions, etc and all 3 languages support making things modules of interconnected concepts, extension functions, etc.

You can make code very readable this way - arguably more readable.

Have you ever had so many tests for a single class that you’ve broken the test class into a package and have a whole file / test class for each big method? Same idea! :)

вчераdiscuss

Similarly, I try to follow an “around 400 lines per MR” (violations can exist for test code if something is particularly gnarly).

I’ll build whole features and then break them apart into several MRs that chain off each other.

Everyone who has seen this style has been really grateful for it and finds my code much more readable. I encourage and embody the pattern everywhere I go.

Exception: For mass find/replace or auto-linter changes, that’s all one MR, and is usually pair programmed so the other person can confirm that’s all I did, still easing cognitive load.

вчераdiscuss

What do you think of traditional AST-based static analyzers (like SonarQube, Rubocop, etc.) that catch cyclomatic complexity and code duplication deterministically?

You can even put them on the build pipeline, even. No tokens spent at all!

вчераdiscuss

TDD like this is a very good system for a lot of things, especially brownfield development - gotta make sure you understand the error space before you know you’ve fixed the error. :D

вчераdiscuss

Oh, ok. When I posted that I genuinely thought they wanted people to call Ubers, etc.

This is less terrifying, thank you for clarifying!

позавчераdiscuss

> or cabulance

I'm sorry, are insurance companies now demanding that people use Ubers to get to the hospital?

... do they reimburse those charges? Because wtf.

позавчераdiscuss

What do you do to keep the cognitive load of reviewers at a minimum?

позавчераdiscuss

Oftentimes feedback is useful to address a complaint. “Lots of people are frustrated with X” is great signal. The solution might not be (but certainly sometimes is) the fixes they recommend; but the pain they’re expressing is real.

позавчераdiscuss

I think a useful question here is “what is a good commit?”, specifically at the MR stage. I don’t care what commits look like on your local machine.

I tend to like to treat commits at that stage as complete, atomic thoughts.

  “This commit is a refactor of this function name”
  “This commit defines all the data classes we’ll use”
  “This commit writes the new function and all its tests”
  “This commit injects the new code into the old path with a feature flag”
  “This commit fixes the tests that broke from that change”

Some of these would be better served as separate MRs entirely; but I imagine my idea stands.

позавчераdiscuss

Can’t wait to get in trouble for having curse words in my chat with AI get flagged by the company’s anti-swearing-in-code automation.

4 дня назадdiscuss

I mean, not really? The urge to throw all the code out and start over is what ever mid-level software engineer has always wanted to do, and it’s almost never the right choice. The old code worked well enough most of the time, it just didn’t have good or safe practices and those can be retrofit.

In fact, doing and directing such things are kinda senior, principal and management jobs, in general.

4 дня назадdiscuss

If you have done or are doing all of that, why not just use the code you’ve made inside your docs?

Like, are you using languages where data structures are hard to write and/or work with? Typescript, Kotlin, Python and Ruby (via Sorbet or DryStruct) are all really easy to write all those data structures and code.

5 дней назадdiscuss

"wire up an agent to do":

  * pull a metrics API every morning
  * reshape JSON
  * drop results into a table

This means they:

  * know there's an API that they need to call,
    likely a specific endpoint
  * know there's a database
  * know the schema of the database
  * know where the data should go into the database

--

Or perhaps they re-derive this every single day.

Every day, they search for an enpdoint and call it. Every day, they check all the databases that the agent knows about. Every day, they read the full schema of those databases to guess where the data should go. Every day, they invent the SQL to insert this new data into the database in a format the database is expecting.

There are two possibilities:

  * this person exists and is common
  * this person does not exist or is very uncommon.

If you're this person, hey! Welcome to beginning to program and learn about the deeper work that goes into making things fast and easy. It's gonna be really weird, but you might find it rewarding! And, you can mostly keep to being a vibe coder, genuinely; but you're gonna wanna change "hey go do this" to "write me a program that can do this". It may be a higher starting cost; but it'll pay dividends as the weeks go by. Like, dollars a day to pennies a day in server or power costs.

--

But I tend to believe that this person isn't very common (if you're the person that does this, no big deal. You're new to programming. There's a whole lot to learn and you've already started. That's awesome!)

Instead, though, we've got a person that:

  * knows what endpoint they need to talk to
  * knows what the schema looks like
  * probably knows how to write SQL (or doesn't, in which case,
    oh god, they're letting the bot write and execute
    brand new SQL everry daOh god oh god.)

But they still let a bot do it? Every single day? Do they work for a company that subscribes to and/or do they subscribe to a token-maxing philosophy? Because they must know this much agent interaction is going to be not only expensive but also really slow. 10s of seconds vs, what, 3ms of parsing and maybe 100ms of waiting for API and DB communication on the high end?

Maybe you're forced into doing it due to internal office politics and prioritization - this article is going to be great for explaining to your boss why it's a bad idea to keep doing what you're doing. Otherwise, none of this should be changing very often, and this codepath should be, all in all, quite cheap to write - with one exception.

The only situation I could see where this approach the article suggests "lots of people are doing" makes sense and is a reasonable thing an engineer would have done is if the DB and the API endpoints are constantly changing, so they need to rederive over and over again.

But is that really where we're going as an industry? Random, dynamically changing API endpoints? I sure hope not.

7 дней назадdiscuss

It's spirituality. Religions tend to have creeds.

You wouldn't call every animist belief the same religion's name. That's a loooot of religions that believe those things - the vast, vast majority of them, in fact.