7 ms·

Writing code is easy, reading it isn't

117 points by jnord 1y ago

HuwFulcher 1y ago
This is a challenge which I don't think AI tools like Cursor have cracked yet. They're great for laying "fresh pavement" but it's akin to being a project manager contracting the work out. Even if I use Cursor (or some other equivalent) and review the code I find my mental model of the system is much more lacking. It actually had a net negative on my productivity as it gave me anxiety at going back to the codebase. If an AI tool could help a user interactively learn the mental model I think that would be a great step in the right direction.
- catigula 1y ago
  An AI tool can both navigate a legacy codebase and help explain it to you successfully currently, right now, if you're doing it correctly. I've contracted some of this understanding of pieces/intellectual work out to Claude code many, many times successfully.
  - HuwFulcher 1y ago
    Yes it’s definitely possible now. My point was that people need to move past “vibe coding” to using the AI as what it should be, an assistant
    - lukaslalinsky 1y ago
      I don't think people are realistically "vibe coding" production apps. You see a lot of hype, and I'm sure there is growing number of people without software development skills using Claude Code, but those are not the people writing important software. Even the people from Anthropic encourage programmers to first use CC as analytics/research tool, not for writing code. Once you get a feel what it can do, you will feel comfortable feeding it chunks of work you want to delegate, but realistically never more than you can review. Yes, you can ask it to build the next Instagram, but you will very quickly find out it's not going to work.
- ivape 1y ago
  but it's akin to being a project manager contracting the work out. And that's probably the difference between those who are okay with vibe coding and those who aren't. A leader of a company that doesn't care about code quality (elegant code, good tradeoffs, etc) would never have cared if 10 monkeys outputted the code pre-AI or if 10 robot monkeys outputted the code with AI. It's only a developer, of a certain type, that would care to say "pause" in either of those situations. Out of principal I would not share or build coding tools for these people. They literally did not care all these years about code quality, and the last thing I want to do is enable them on any level.
  - marcosdumay 1y ago
    Well, now they can have their way without a pesky developer second-guessing every decision of them. I don't want to participate on it either, but I'm glad they'll have the chance to make things their way with all the consequences it brings unfiltered.
  - woah 1y ago
    Or maybe if you are good at delegating and reviewing code and stepping in to do a deep dive by hand when needed to maintain understanding, then you can use LLMs to greatly increase your speed.
vivzkestrel 1y ago
I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps?
- Night_Thastus 1y ago
  Practice, context and domain-specific knowledge. #1 is easy, #2 requires some investigation, #3 requires studying. If you're looking at say, banking code - but you know nothing about finance - you may struggle to understand what it's doing. You may want to gain some domain expertise. Being an SME makes reading the related code a heck of a lot easier. Context comes down to learning the code base. What code calls the part you're looking at? What user actions trigger it? Look at the comments and commit messages - what was the intention? This just takes time and a lot of trawling around, looking for patterns and common elements. User manuals and documentation can also help. This part can't be rushed - it just comes to passing over it again and again and again. If you have access to people very familiar with the code - ask them! They may be able to kick start your intro. #1 will come naturally with time.
  - rramadass 1y ago
    Very good advice! To add to the above; IME, #3 comes first. Study the domain to understand the concepts and their relationships. Read some books/Articles, Watch some Videos, Read Documentation etc. to come up to speed on the terminology/jargon and the general concepts/ideas. Then, in order to understand their mapping to the specific application at hand, sit with the local "guru" (there is always at least one in every group) and pick his/her brain for a few sessions (getting them brown bag lunches works great for this) on the overall architecture of the System. Next sit with testing and use the app as an end-user to understand use-case scenarios which brings all of the above together. During all the above stages, take copious notes, draw diagrams/graphs/etc. use source code analysis/documentation/browsing/etc. tools eg. doxygen/cscope/opengrok/etc. tools to navigate the codebase and cement understanding. Note also that the above stages are to be done both iteratively and parallelly until you are somewhat comfortable and not necessarily know/understand everything. With the above in hand, pick one use-case scenario, preferably the most complicated, critical and important one and walk through the code from beginning to end for that path. Remember that you are trying to get the overall picture and hence treat all irrelevant details as blackbox abstractions during initial phases. Over time as you iterate and review the code again and again you can slowly add in the details for a more comprehensive understanding. Finally, there is no shortcut to the above; it takes time and self-effort. We Humans are natural-born, trial-and-error, continuous-learning problem solvers and so trust to your intelligence and commonsense to find a path to move ahead when stuck at something.
jameskilton 1y ago
Software's job is to tell other people what the computer is doing.
- ivanjermakov 1y ago
  Great saying. When I got into the industry I was surprised how programmers is just a small fraction of a company's head count.
mintaka5 1y ago
[dead]
tptacek 1y ago
This article makes points that are valid in general but not apposite to code generation with agents. It is indeed difficult to verify a piece of code that is either going to ship as-is, or with the specific modifications your verification identifies. In cryptography engineering the rule of thumb (never followed in practice) is 10x verification cost to x implementation cost. Verification is hard and expensive. But qualifying agent-generated code isn't the verification problem, in the same way that validating an eBPF program in the kernel isn't solving the halting problem. That's because the agentic scenario gives us an additional outcome: we can allow the code as-is, we can make modifications to the code, or we can throw out the code and re-prompt --- discarding (many) probably-valid programs in a search for the subset of programs that are easy to validate. In practice, most of what people generate is boring and easy to validate: you know within a couple minutes whether it's the right shape, whether anything sticks out the wrong way, the way a veteran chess player can quickly pattern-match a whole chessboard. When it isn't boring, you read carefully (and expensively), or you just say "no, try again, give me something more boring", or you break your LLM generation into smaller steps that are easier to pattern match and recurse. What professionals generally don't (I think) do with LLMs is generate large gnarly PRs, all at once, and then do a close-reading of those gnarly PRs. They read PRs that are easy (not gnarly). They reject the gnarly ones, and compensate for gnarliness by approaching the problem at a smaller level of granularity. Or, you know, just write those bits by hand!
- kiitos 1y ago
  > In practice, most of what people generate is boring and easy to validate: you know within a couple minutes whether it's the right shape, whether anything sticks out the wrong way, the way a veteran chess player can quickly pattern-match a whole chessboard. When it isn't boring, you read carefully (and expensively), or you just say "no, try again, give me something more boring", or you break your LLM generation into smaller steps that are easier to pattern match and recurse. nope! https://sketch.dev/blog/our-first-outage-from-llm-written-code https://sketch.dev/blog/our-first-outage-from-llm-written-co...
  - tptacek 1y ago
    What do you think your "nope" here is about? (You and I are probably the only 2 people reading this long-dead thread now, and I'm very familiar with the post you just shared --- I've been using Sketch for several months and following along with their Github repo. Sketch is great.)
ppeetteerr 1y ago
This is not unique to the age of LLMs. PR reviews are often shallow because the reviewer is not giving the contribution the amount of attention and understanding it deserves. With LLMs, the volume of code has only gotten larger but those same LLMs can help review the code being written. The current code review agents are surprisingly good at catching errors. Better than most reviewers. We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way.
- foxfired 1y ago
  One thing to take into account is that PR reviews aren't there for just catching errors in the code. They also ensure that the business logic is correct. For example, you can have code that pass all tests, and look good, but they don't align with the business logic.
- gyomu 1y ago
  > We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way. The real breakthrough would be finding a way to not even do things that don’t need to be done in the first place. 90% of what management thinks it wants gets discarded/completely upended a few days/weeks/months later anyway, so we should have AI agents that just say “nah, actually you won’t need that” to 90% of our requests.
  - deleted 1y ago
    [deleted]
- prybeng 1y ago
  I wonder if the paradigm shift is the adoption of a higher level language. Akin to what python did to blackboxing C libraries.
_feus 1y ago
I have the opposite experience. After years in appsec and pentesting, I can read any codebase and quickly understand its parts, but I wouldn’t be able to write anything of production quality. LLMs speed the comprehension process up for me even further. I guess it comes down to practice, if you practice reading code, you get good at reading code.
- dingnuts 1y ago
  reading production code that is known to work can be done with faith and skimming. You don't have to understand every function call because they've each been tested and battle hardened, so it's easy to get an overview of what is happening. LLM code is NOT like this at all, but it's like a skilled liar writing something that LOOKS plausible, that's what they're trained to do. People like you do not have the ability to evaluate the LLM output; it's not the same as reading code that was carefully written at ALL. If you think it's the same, that is only evidence that you can't tell the difference between working code and misleading buggy code. What you've learned to do is read the intent of code. That's fine when it's been written and tested by a person. It's useless when it comes to evaluating LLM slop. You're being gaslit.
  - danielmarkbruce 1y ago
    You are being gaslit if you think "production code that is known to work" covers any reasonable proportion of code in production.
    - dingnuts 1y ago
      well played, but of course inevitably whatever it's doing in production (whether to spec or not) is "working" for somebody. Obligatory XKCD https://xkcd.com/1172/ https://xkcd.com/1172/ "Workflow" reference
  - _feus 1y ago
    Code is code, it's not a piece of art where we all can have different perspective about what it means or does, so from appsec perspective it doesn't matter who wrote it, just what it does. Also you seem to be interpreting "reading" as one would read a novel, but here "reading" is about finding and exploiting security flaws. So yeah, dunno what you are on about.
s_Hogg 1y ago
You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it Just write simple code
- EGreg 1y ago
  what exactly is "the smartest code you can" :)
  - brudgers 1y ago
    Actual quote: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
    - OnionBlender 1y ago
      Known as Kernighan's Law.
  - havefunbesafe 1y ago
    In this case, it sounds like "The code that will most impress your parents"
  - flykespice 1y ago
    I guess this https://www.ioccc.org/ https://www.ioccc.org/
- lukan 1y ago
  Thank you, I will be using this. Not sure if there is actually data for the assumption to be twice as smart to debug than to write code, but it sounds about right. And also, if you write the smartest code you can, while you are at your peak, you also won't be able to read it, when you are just a bit tired. So yes, yes, yes. Just write simple code. (I also was also initially messed up a bit by teachers filling me up with the idea to aim for clever code)
- 1y ago
m3kw9 1y ago
With LLMs you need to read well, they can introduce “later bugs”
- flykespice 1y ago
  "ChatGPT write me some unit tests for this piece of code you just generated"
  - yoyohello13 1y ago
    "Proceeds to write tests that pass, but don't actually test the underlying functionality."
deleted 1y ago
[deleted]
jongjong 1y ago
Makes sense. Once you become really good at writing code, it becomes increasingly obvious that the real challenge of software development is the social problem of pointing out subtle contradictions in requirements and suggesting resolutions/trade-offs in a way which earns you respect instead of hatred. With some stakeholders, this is an almost impossible problem; sometimes this is because they lack vision and so their requirements are littered with impossible contradictions; other times, their ego is too big to accommodate any kind of push-back; even if you try to drip-feed the suggestions as gently as possible, they begin to resent you because they start to associate you with negative feelings such as self-doubt. Schopenhauer explained this phenomena succinctly: "A man must be still a greenhorn in the ways of the world, if he imagines that he can make himself popular in society by exhibiting intelligence and discernment. With the immense majority of people, such qualities excite hatred and resentment, which are rendered all the harder to bear by the fact that people are obliged to suppress — even from themselves — the real reason of their anger. What actually takes place is this. A man feels and perceives that the person with whom he is conversing is intellectually very much his superior. He thereupon secretly and half unconsciously concludes that his interlocutor must form a proportionately low and limited estimate of his abilities. That is a method of reasoning — an enthymeme — which rouses the bitterest feelings of sullen and rancorous hatred." This is a really big problem because people who attain management positions are often very good at understanding and then manipulating what other people think about them; this is how they were able to rise to their current ranks. They are exactly the kinds of people who build these reflective mental maps/models of who thinks what about them; and they are good at plotting against those people who they believe may harbor negative thoughts about them.
vjvjvjvjghv 1y ago
I find reading code mentally much more draining than writing it. I admire open source maintainers who mostly handle pull requests from others. This must be very hard. Linux cones to mind here. I assume Thorvalds and the other maintainers don’t get to write much code themselves.
bcrosby95 1y ago
Basically when you read code you're mentally doing the same thing as when you write code. But your mental model is more likely to be wrong when you're reading rather than producing the code.
ottaborra 1y ago
I think the same could be said of anything resembling technical writing. As an example aside from code writing, I think more than half of the machine learning papers out there are horribly written in the sense they rush a point or give no rhyme or reason for certain parts And the best part, most people shallow read all of them and decide the details are needless till they are forced to deal with the details and then their understanding falls apart in front of them
jmsfltchruk 1y ago
Struggling with making an algorithm in a big architecture once I felt the same way - just couldn't keep the current state of the code in my head and also imagine the new solution at the same time. Ever since, have been working on http://etchpad.dev http://etchpad.dev to solve this pain (shameless plug). We're trying to make an interface that works with an engineering brain, so we can think in terms of blueprints and wiring, idk just something more tangible than hallucinating wildly in a multidimensional space like we have to right now. Really agree with the article, ultimately the typing and thinking speed issues can be solved with AI, but trusting it and auditing what it does seems like a job for humans for the foreseeable, you know, so maybe we avert a classic sci-fi AI apocalypse and whatnot
larntz 1y ago
Has anyone read The Programmer's Brain and have an opinion about it? I'd like to improve my ability to read and understand code and was thinking about reading it. https://www.manning.com/books/the-programmers-brain https://www.manning.com/books/the-programmers-brain
Krei-se 1y ago
This is the same dissonance as the post about "never write bugs". The premise is wrong to think of code as something you can fit in your brain like you remember the shape of a new building you frequent or a persons face. You need to both remember the processing done in the code and the structure. The structure will need your working memory in the language center as its n-dimensional and not representable with a closed surface 3D model - at maximum you can do graphs which well dont look like much you will be able to draw from memory. Remembering state and data needs your whole brain to debug what will happen when you run the code. All people here telling you they can train this train either an abstract concept like functional programming or work with software in their field which will have a similar scope - you will NOT be able to easily comprehend code written in another style or purpose. Don't be mistaken doing 10 years of mobile apps, ERP or whatever would allow you to follow any C-written code for systems or sth. Fitting code as an abstraction in your mind is literally neurons growing new pathways - its expensive, no one likes doing it and if you are not in the same field you will try to bend it into your domain or not engage much. Trying to find general assumptions here will not work - if you could condense n-dim rulesets to some general principles - you would simply do so and refactor the code. Thinking theres no way to debug abstracted, proveable code you can not fit fully in your working memory is wrong, because you only need to test each function / morphism to be correct, not the whole thing. Its certainly doable to write systems that interconnect 30-40 entities you need NOT remember all at once and still end up with bugfree code because each part is constrained to strict interfaces and types. That's how rulesets with bigger scopes work - no one designs the aircraft carrier all alone - there's restrictions and interfaces everywhere, not a single engineer knows the whole thing down to the molecules and electrons. Still it works.
kazinator 1y ago
This is positively false. In my anecdotal experience, I have produced code that was brutal to write, but then it was easy to read afterward. Just like a piece of music being easy to listen to after sweating out the composition. Sone coding is like solving the puzzle. Once it is written and debugged, you're looking at the solution. The code will readily spoon-feed you the solution again when you revisit it months or years after forgetting everything, possibly even its existence. Wen code is easy to write but hard to read, you must be writing fluff. Maybe try to steer your career a bit away from that. But do improve your ability to make fluff readable.
duckydude20 1y ago
KISS yet they want to test leetcode bs. the irony in this industry...

117 points by jnord 1y ago

This is a challenge which I don't think AI tools like Cursor have cracked yet. They're great for laying "fresh pavement" but it's akin to being a project manager contracting the work out. Even if I use Cursor (or some other equivalent) and review the code I find my mental model of the system is much more lacking. It actually had a net negative on my productivity as it gave me anxiety at going back to the codebase. If an AI tool could help a user interactively learn the mental model I think that would be a great step in the right direction.

catigula 1y ago
An AI tool can both navigate a legacy codebase and help explain it to you successfully currently, right now, if you're doing it correctly. I've contracted some of this understanding of pieces/intellectual work out to Claude code many, many times successfully.
- HuwFulcher 1y ago
  Yes it’s definitely possible now. My point was that people need to move past “vibe coding” to using the AI as what it should be, an assistant
  - lukaslalinsky 1y ago
    I don't think people are realistically "vibe coding" production apps. You see a lot of hype, and I'm sure there is growing number of people without software development skills using Claude Code, but those are not the people writing important software. Even the people from Anthropic encourage programmers to first use CC as analytics/research tool, not for writing code. Once you get a feel what it can do, you will feel comfortable feeding it chunks of work you want to delegate, but realistically never more than you can review. Yes, you can ask it to build the next Instagram, but you will very quickly find out it's not going to work.
ivape 1y ago
but it's akin to being a project manager contracting the work out. And that's probably the difference between those who are okay with vibe coding and those who aren't. A leader of a company that doesn't care about code quality (elegant code, good tradeoffs, etc) would never have cared if 10 monkeys outputted the code pre-AI or if 10 robot monkeys outputted the code with AI. It's only a developer, of a certain type, that would care to say "pause" in either of those situations. Out of principal I would not share or build coding tools for these people. They literally did not care all these years about code quality, and the last thing I want to do is enable them on any level.
- marcosdumay 1y ago
  Well, now they can have their way without a pesky developer second-guessing every decision of them. I don't want to participate on it either, but I'm glad they'll have the chance to make things their way with all the consequences it brings unfiltered.
- woah 1y ago
  Or maybe if you are good at delegating and reviewing code and stepping in to do a deep dive by hand when needed to maintain understanding, then you can use LLMs to greatly increase your speed.

vivzkestrel 1y ago

I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps?

Night_Thastus 1y ago
Practice, context and domain-specific knowledge. #1 is easy, #2 requires some investigation, #3 requires studying. If you're looking at say, banking code - but you know nothing about finance - you may struggle to understand what it's doing. You may want to gain some domain expertise. Being an SME makes reading the related code a heck of a lot easier. Context comes down to learning the code base. What code calls the part you're looking at? What user actions trigger it? Look at the comments and commit messages - what was the intention? This just takes time and a lot of trawling around, looking for patterns and common elements. User manuals and documentation can also help. This part can't be rushed - it just comes to passing over it again and again and again. If you have access to people very familiar with the code - ask them! They may be able to kick start your intro. #1 will come naturally with time.
- rramadass 1y ago
  Very good advice! To add to the above; IME, #3 comes first. Study the domain to understand the concepts and their relationships. Read some books/Articles, Watch some Videos, Read Documentation etc. to come up to speed on the terminology/jargon and the general concepts/ideas. Then, in order to understand their mapping to the specific application at hand, sit with the local "guru" (there is always at least one in every group) and pick his/her brain for a few sessions (getting them brown bag lunches works great for this) on the overall architecture of the System. Next sit with testing and use the app as an end-user to understand use-case scenarios which brings all of the above together. During all the above stages, take copious notes, draw diagrams/graphs/etc. use source code analysis/documentation/browsing/etc. tools eg. doxygen/cscope/opengrok/etc. tools to navigate the codebase and cement understanding. Note also that the above stages are to be done both iteratively and parallelly until you are somewhat comfortable and not necessarily know/understand everything. With the above in hand, pick one use-case scenario, preferably the most complicated, critical and important one and walk through the code from beginning to end for that path. Remember that you are trying to get the overall picture and hence treat all irrelevant details as blackbox abstractions during initial phases. Over time as you iterate and review the code again and again you can slowly add in the details for a more comprehensive understanding. Finally, there is no shortcut to the above; it takes time and self-effort. We Humans are natural-born, trial-and-error, continuous-learning problem solvers and so trust to your intelligence and commonsense to find a path to move ahead when stuck at something.

jameskilton 1y ago

Software's job is to tell other people what the computer is doing.

ivanjermakov 1y ago
Great saying. When I got into the industry I was surprised how programmers is just a small fraction of a company's head count.

mintaka5 1y ago

[dead]

tptacek 1y ago

This article makes points that are valid in general but not apposite to code generation with agents. It is indeed difficult to verify a piece of code that is either going to ship as-is, or with the specific modifications your verification identifies. In cryptography engineering the rule of thumb (never followed in practice) is 10x verification cost to x implementation cost. Verification is hard and expensive. But qualifying agent-generated code isn't the verification problem, in the same way that validating an eBPF program in the kernel isn't solving the halting problem. That's because the agentic scenario gives us an additional outcome: we can allow the code as-is, we can make modifications to the code, or we can throw out the code and re-prompt --- discarding (many) probably-valid programs in a search for the subset of programs that are easy to validate. In practice, most of what people generate is boring and easy to validate: you know within a couple minutes whether it's the right shape, whether anything sticks out the wrong way, the way a veteran chess player can quickly pattern-match a whole chessboard. When it isn't boring, you read carefully (and expensively), or you just say "no, try again, give me something more boring", or you break your LLM generation into smaller steps that are easier to pattern match and recurse. What professionals generally don't (I think) do with LLMs is generate large gnarly PRs, all at once, and then do a close-reading of those gnarly PRs. They read PRs that are easy (not gnarly). They reject the gnarly ones, and compensate for gnarliness by approaching the problem at a smaller level of granularity. Or, you know, just write those bits by hand!

kiitos 1y ago
> In practice, most of what people generate is boring and easy to validate: you know within a couple minutes whether it's the right shape, whether anything sticks out the wrong way, the way a veteran chess player can quickly pattern-match a whole chessboard. When it isn't boring, you read carefully (and expensively), or you just say "no, try again, give me something more boring", or you break your LLM generation into smaller steps that are easier to pattern match and recurse. nope! https://sketch.dev/blog/our-first-outage-from-llm-written-code https://sketch.dev/blog/our-first-outage-from-llm-written-co...
- tptacek 1y ago
  What do you think your "nope" here is about? (You and I are probably the only 2 people reading this long-dead thread now, and I'm very familiar with the post you just shared --- I've been using Sketch for several months and following along with their Github repo. Sketch is great.)

ppeetteerr 1y ago

This is not unique to the age of LLMs. PR reviews are often shallow because the reviewer is not giving the contribution the amount of attention and understanding it deserves. With LLMs, the volume of code has only gotten larger but those same LLMs can help review the code being written. The current code review agents are surprisingly good at catching errors. Better than most reviewers. We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way.

foxfired 1y ago
One thing to take into account is that PR reviews aren't there for just catching errors in the code. They also ensure that the business logic is correct. For example, you can have code that pass all tests, and look good, but they don't align with the business logic.
gyomu 1y ago
> We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way. The real breakthrough would be finding a way to not even do things that don’t need to be done in the first place. 90% of what management thinks it wants gets discarded/completely upended a few days/weeks/months later anyway, so we should have AI agents that just say “nah, actually you won’t need that” to 90% of our requests.
- deleted 1y ago
  [deleted]
prybeng 1y ago
I wonder if the paradigm shift is the adoption of a higher level language. Akin to what python did to blackboxing C libraries.

_feus 1y ago

I have the opposite experience. After years in appsec and pentesting, I can read any codebase and quickly understand its parts, but I wouldn’t be able to write anything of production quality. LLMs speed the comprehension process up for me even further. I guess it comes down to practice, if you practice reading code, you get good at reading code.

dingnuts 1y ago
reading production code that is known to work can be done with faith and skimming. You don't have to understand every function call because they've each been tested and battle hardened, so it's easy to get an overview of what is happening. LLM code is NOT like this at all, but it's like a skilled liar writing something that LOOKS plausible, that's what they're trained to do. People like you do not have the ability to evaluate the LLM output; it's not the same as reading code that was carefully written at ALL. If you think it's the same, that is only evidence that you can't tell the difference between working code and misleading buggy code. What you've learned to do is read the intent of code. That's fine when it's been written and tested by a person. It's useless when it comes to evaluating LLM slop. You're being gaslit.
- danielmarkbruce 1y ago
  You are being gaslit if you think "production code that is known to work" covers any reasonable proportion of code in production.
  - dingnuts 1y ago
    well played, but of course inevitably whatever it's doing in production (whether to spec or not) is "working" for somebody. Obligatory XKCD https://xkcd.com/1172/ https://xkcd.com/1172/ "Workflow" reference
- _feus 1y ago
  Code is code, it's not a piece of art where we all can have different perspective about what it means or does, so from appsec perspective it doesn't matter who wrote it, just what it does. Also you seem to be interpreting "reading" as one would read a novel, but here "reading" is about finding and exploiting security flaws. So yeah, dunno what you are on about.

s_Hogg 1y ago

You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it Just write simple code

EGreg 1y ago
what exactly is "the smartest code you can" :)
- brudgers 1y ago
  Actual quote: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
  - OnionBlender 1y ago
    Known as Kernighan's Law.
- havefunbesafe 1y ago
  In this case, it sounds like "The code that will most impress your parents"
- flykespice 1y ago
  I guess this https://www.ioccc.org/ https://www.ioccc.org/
lukan 1y ago
Thank you, I will be using this. Not sure if there is actually data for the assumption to be twice as smart to debug than to write code, but it sounds about right. And also, if you write the smartest code you can, while you are at your peak, you also won't be able to read it, when you are just a bit tired. So yes, yes, yes. Just write simple code. (I also was also initially messed up a bit by teachers filling me up with the idea to aim for clever code)
1y ago

m3kw9 1y ago

With LLMs you need to read well, they can introduce “later bugs”

flykespice 1y ago
"ChatGPT write me some unit tests for this piece of code you just generated"
- yoyohello13 1y ago
  "Proceeds to write tests that pass, but don't actually test the underlying functionality."

deleted 1y ago

[deleted]

jongjong 1y ago

Makes sense. Once you become really good at writing code, it becomes increasingly obvious that the real challenge of software development is the social problem of pointing out subtle contradictions in requirements and suggesting resolutions/trade-offs in a way which earns you respect instead of hatred. With some stakeholders, this is an almost impossible problem; sometimes this is because they lack vision and so their requirements are littered with impossible contradictions; other times, their ego is too big to accommodate any kind of push-back; even if you try to drip-feed the suggestions as gently as possible, they begin to resent you because they start to associate you with negative feelings such as self-doubt. Schopenhauer explained this phenomena succinctly: "A man must be still a greenhorn in the ways of the world, if he imagines that he can make himself popular in society by exhibiting intelligence and discernment. With the immense majority of people, such qualities excite hatred and resentment, which are rendered all the harder to bear by the fact that people are obliged to suppress — even from themselves — the real reason of their anger. What actually takes place is this. A man feels and perceives that the person with whom he is conversing is intellectually very much his superior. He thereupon secretly and half unconsciously concludes that his interlocutor must form a proportionately low and limited estimate of his abilities. That is a method of reasoning — an enthymeme — which rouses the bitterest feelings of sullen and rancorous hatred." This is a really big problem because people who attain management positions are often very good at understanding and then manipulating what other people think about them; this is how they were able to rise to their current ranks. They are exactly the kinds of people who build these reflective mental maps/models of who thinks what about them; and they are good at plotting against those people who they believe may harbor negative thoughts about them.

vjvjvjvjghv 1y ago

I find reading code mentally much more draining than writing it. I admire open source maintainers who mostly handle pull requests from others. This must be very hard. Linux cones to mind here. I assume Thorvalds and the other maintainers don’t get to write much code themselves.

bcrosby95 1y ago

Basically when you read code you're mentally doing the same thing as when you write code. But your mental model is more likely to be wrong when you're reading rather than producing the code.

ottaborra 1y ago

I think the same could be said of anything resembling technical writing. As an example aside from code writing, I think more than half of the machine learning papers out there are horribly written in the sense they rush a point or give no rhyme or reason for certain parts And the best part, most people shallow read all of them and decide the details are needless till they are forced to deal with the details and then their understanding falls apart in front of them

jmsfltchruk 1y ago

Struggling with making an algorithm in a big architecture once I felt the same way - just couldn't keep the current state of the code in my head and also imagine the new solution at the same time. Ever since, have been working on http://etchpad.dev http://etchpad.dev to solve this pain (shameless plug). We're trying to make an interface that works with an engineering brain, so we can think in terms of blueprints and wiring, idk just something more tangible than hallucinating wildly in a multidimensional space like we have to right now. Really agree with the article, ultimately the typing and thinking speed issues can be solved with AI, but trusting it and auditing what it does seems like a job for humans for the foreseeable, you know, so maybe we avert a classic sci-fi AI apocalypse and whatnot

larntz 1y ago

Has anyone read The Programmer's Brain and have an opinion about it? I'd like to improve my ability to read and understand code and was thinking about reading it. https://www.manning.com/books/the-programmers-brain https://www.manning.com/books/the-programmers-brain

Krei-se 1y ago

This is the same dissonance as the post about "never write bugs". The premise is wrong to think of code as something you can fit in your brain like you remember the shape of a new building you frequent or a persons face. You need to both remember the processing done in the code and the structure. The structure will need your working memory in the language center as its n-dimensional and not representable with a closed surface 3D model - at maximum you can do graphs which well dont look like much you will be able to draw from memory. Remembering state and data needs your whole brain to debug what will happen when you run the code. All people here telling you they can train this train either an abstract concept like functional programming or work with software in their field which will have a similar scope - you will NOT be able to easily comprehend code written in another style or purpose. Don't be mistaken doing 10 years of mobile apps, ERP or whatever would allow you to follow any C-written code for systems or sth. Fitting code as an abstraction in your mind is literally neurons growing new pathways - its expensive, no one likes doing it and if you are not in the same field you will try to bend it into your domain or not engage much. Trying to find general assumptions here will not work - if you could condense n-dim rulesets to some general principles - you would simply do so and refactor the code. Thinking theres no way to debug abstracted, proveable code you can not fit fully in your working memory is wrong, because you only need to test each function / morphism to be correct, not the whole thing. Its certainly doable to write systems that interconnect 30-40 entities you need NOT remember all at once and still end up with bugfree code because each part is constrained to strict interfaces and types. That's how rulesets with bigger scopes work - no one designs the aircraft carrier all alone - there's restrictions and interfaces everywhere, not a single engineer knows the whole thing down to the molecules and electrons. Still it works.

kazinator 1y ago

This is positively false. In my anecdotal experience, I have produced code that was brutal to write, but then it was easy to read afterward. Just like a piece of music being easy to listen to after sweating out the composition. Sone coding is like solving the puzzle. Once it is written and debugged, you're looking at the solution. The code will readily spoon-feed you the solution again when you revisit it months or years after forgetting everything, possibly even its existence. Wen code is easy to write but hard to read, you must be writing fluff. Maybe try to steer your career a bit away from that. But do improve your ability to make fluff readable.

duckydude20 1y ago

KISS yet they want to test leetcode bs. the irony in this industry...