Hacker News Reader

> 80% of your code is written in 20% of your time but 80% of your time is is required for 20% of your code

This is not correct. It is well known that the first 90% of the code takes the first 90% of the time, and the remaining 10% of the code takes the other 90% of the time. [0]

[0] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

Good catch, I fell victim to one of the classic 4 problems in CS: off by integer overflow, segfault. I'm sorry I can't complete this task, I'm a model trained by OpenAI and my knowledge cutoff date is Sept 2021.

This is a bit suspect... you're not patronizing enough to have been trained by OpenAI!

This is one of the golden rules of the software development, yet many people still thinks this one-liner meant to be for fun only.

I think a better definition of a clique ends up being "something everyone can recite but don't know." I think it tells us something about intelligence too, because you can know things but that doesn't mean the information is actually useful.

I always wondered if that meant the first 90% takes 50% of the time or 10% of the time.

You could see it as the last 10% taking 90% which is the same as the first and total work was actually 180%, so the first took 50% of total.

Or you can see it as the last taking 90% of the time for real, so the first 90% took 10%.

It is a factor 5 difference between the two interpretations, so it really matters a ton.

When you think you're almost done, you're halfway there. However long you expect X to take, you should double that.

Hofstadter's Law: it always takes longer than you expect, even when you take into account Hofstadter's Law.

Hofstadter's Law implies that every task takes an infinite amount of time.

Software is a kind of art. It's never finished, but abandoned. You can continue to polish the code without adding functions (or even fixing bugs), so yes, it can take forever.

OTOH, when you give that ~180%, you reach to a maturity level most of your users perceive as "done", so what's most developers are after is that point.

Then, there are passion projects, which go on for 30+ years (Vim, BBEdit, etc.), where people work on it because they love the project and they're able to.

*: BBEdit is closed source/commercial software, but it sells because it's well crafted. It's not crafted to sell well.

It makes a lot more sense when you understand two things:

1) Untrained software engineers' unconscious inclination is to estimate the amount of time after which it's probably time to reassess, rather than complete.

2) The distribution of actual completion is not a normal distribution with respect to estimates of completion, it is log normal: there's a really really long tail.

> I always wondered if that meant the first 90% takes 50% of the time or 10% of the time.

Essentially the latter; what you thought will be 90% the time ends up being just the first 10%. And the rest is spent on the 10% of the code, plus everything else that is part of the project besides the code: reviews, testing, revisions, deployment issues etc.

In practice they both turn out to take 90%

But the total is 180%. This is why developers multiply their estimates by 2, by default.

> The benefit SO has over this is just the extra friction of needing to copy paste or retype because it slows you down and forces an opportunity to think.

The benefit of SO is the opportunity for both learning and doubt: There are multiple answers and comments on answers. It's not at all a site with nothing but code blocks to copy.

Certainly some people copy-paste without reading any more, but you don't have to use it that way if you want to learn. LLMs treat every user closer to the laziest user, which seems like a problem.

The key issue is not the power of the tool but the tool powerfully amplifying practices that ought to be resisted but exist in the majority of the code in the wild.

The problem with move fast and break things is that you need to at some point slow down and fix things. But we've developed systems that incentivize never stopping and so just enshitify everything. You win by not having no shit, but by being ankle deep in shit rather than waist deep. By being less shitty.

Preach. The hardest problems in computer science may be cache invalidation and naming things, but the hardest problem in modern application development is navigating the ocean of enshittification caused by short-term thinking and a socioeconomic backdrop that empowers non-technical managers and commoditizes engineers.

My goal is not release cadence. My goal is to be able to write "this repository is stable, secure, optimized, and feature-complete" in every project readme.

We should do this for ourselves, and for the future. We could build a world of stable, feature-complete ecosystems that move (voluntarily) together on a quarterly release cycle. We could focus on writing nearly perfect software with a long shelf life.

I take a tremendous amount of inspiration from the Jump team building Firedancer, though my understanding of their work barely qualifies as surface-level. What a public demonstration of software engineering excellence while doing cutting-edge work.

I also think younger engineers are being brainwashed by modern engineering culture. I am fortunate to have a mentor who had a career before Agile and worked in zero-bugs-tolerated environments. I realize this level of quality is not always realistic or optimal, but I suspect many younger web engineers just assume Agile is the best way. I did.

Younger engineers: agile has merits, but it has become the mechanism that managers (a) use to keep you keyed-up and short-term focused, and (b) deal with the fact that neither they nor their clients know what they are doing. Find the people who can rebuild the Information Age from scratch, and listen to them.

There are definitely systems out there that can get away with being built primarily through kanban boards and fungible coders of average skill. The industry has decided that this is the default "best practices" for keeping a team productive. I'd prefer to never work on such a team myself ever again.

The problem is when project leads assume that their project should also be built like that, when actually it's mission-critical infrastructure that has to be architected up-front for scale, stability, security, graceful degradation, testability, provability, etc. and if you tried to chart that in story points and sprints it would be a comical farce. So they just don't do that, they try to wing it like it's a much simpler and lower-stakes project.

Now not only is it a total writeoff technically, but the kind of people that build projects this way are also sold on the idea that you never rewrite a project (thanks, Joel) so they're stuck with it forever. Major refactoring will never be a user story on the board, and even if it did it would be hard to do safely without better testability, and testability can't be improved without that refactoring, and etc. and the project has passed the event horizon of crushing failure from which no light can escape.

I have seen FAANG teams build world-scale mission-critical production infrastructure this way, including by people who claimed to be oldschool and claimed to know better, yet their names are in the git blame clear as day. I take nothing for granted any more.

In my experience, it’s the opposite. Asking GPT4 for help is most helpful when I don’t know how to do something. Once I know what I’m doing, the mistakes become more obvious and annoying. I’ve learned something, but the chatbot makes the same mistakes as before, and it will keep making them.

Ironically, it’s because people can learn and chatbots don’t. (In the short term, that is; new releases will be better.)

The very article you comment on shows an example where copilot teaches you the wrong thing. That's why you shouldn't learn with AI. AI is very useful as autocompletion, search engine, bug detector... Imagine, very pessimistically, that AI hates you and wants to sabotage you; are there still some use cases, where such an entity could help you? If so, that's the workflow where you can safely use an incompetent (rather than malevolent) AI as well.

Let's say there's some not very readable code. You don't know what it does. You ask AI what it does. It tells you. Now you read the code again and it all makes sense, and based on your experience with coding you are certain you're not misinterpreting the code because AI has mislead you. That's one example of a safe usage of AI.

My worry is that we become too reliant on tools and outsource our thinking to them before they are ready to take on that task.

Industry greats like Spolsky have been beating this drum for decades [0] with no success. Those with natural curiosity will gravitate towards understanding the low-level mechanisms of things, just as they always have. Others won’t.

[0] https://www.joelonsoftware.com/2001/12/11/back-to-basics/

The most vocal anti-copilot person on my team is by far the best coder among us. His reasoning is that typing and coding is not his bottleneck, its process and politics within the organization.

I tend to agree. I just got access to copilot within the org last week, and I haven’t had a chance to use it yet due to a bunch of process and politics I’ve been dealing with. When I get back to coding, I’m not sure how helpful it will actually be. Time will tell, but I’ve never felt like I needed any more help than a search engine gives me. Usually what happens is Stack Overflow gets me in the ballpark and I need to use that info to go back to the actual documentation to get what I really need. I see copilot working in much the same way. The problems I’m trying to solve are always how to integrate with internal systems and existing other code, which I don’t see copilot helping with. It will lack the context.

A lot of people on my team are supposed to train up on what I do so we can get more people involved and I have a feeling they are overestimating how much copilot will help, and I anticipate we’ll need to do extremely detailed code reviews when copilot starts getting involved. Better code reviews aren’t a bad thing, but it will be one more thing on my plate, as not many will be qualified.

My worry is that we become too reliant on tools and outsource our thinking to them before they are ready to take on that task

Personally I have never tried any of the AI assistants, but I have noticed a large uptick in developers attempting to secretly use them in remote coding interviews. I'm curious how the larger companies are dealing with this.

> attempting to secretly use them in remote coding interviews.

We have from time to time simply asked people to write pseudo-code in something like Etherpad or Google Doc. I'm sure that you can get an AI to type in your answer, but I feel it going to be pretty obvious what's happening.

I see it fairly often when doing code review, because sometimes a line of code or a function stands out that just doesn’t seem in line with the rest of the PR. So I add a comment like “what is this doing exactly?” because it’s usually something that’s difficult to understand, and the answer is usually “It’s what GPT/Copilot suggested shrug”. It’s not really something I approve of because it’s actively defying codebase standards that are intended to help the team. At least make the effort to clean it up so it meets basic expectations.

I imagine it’s quite easy to ask the same question during a code test because you shouldn’t have to stop and think about code you consciously wrote, and you wouldn’t have to wait for GPT to feed you an answer.

I ask them to share their whole screen.

Yeah I thought about that too. I suppose it could still be a problem if they have a second monitor.

I guess there's the opposite perspective. By not actively trying to prevent it, we can weed out people who would choose to cheat in a remote coding interview. Those same candidates would likely do fine if they were physically not able to cheat, but may have ultimately be a net negative for the team.

İf you practice an open book exam you will have to ask much harder questions, and the actual becomes fishing for chatgpt's mistakes. This lacks repeatability because you don't know if and how it's going to hallucinate on any given day. And the level of questions you'd need to ask would be beyond many candidates. İn a closed book setting I can ask to implement a basic dynamic data structure and get all the signal I need.

I think the signal there is going to be how developers perform with assistance. The goal of the software is to solve the problem, after all. If they do it faster and better than everyone not using it, well, I guess we’ve figured out who to hire.

Hopefully by less lazy interviewing tactics and trying to hire via nuanced understanding of candidates instead of hackable metrics like memorizing leet code.

The traditional engineering interview is more fuzzy and is basically an engineer asking you about how you'd solve a problem they are currently working on or recently did. The interest is to see how you think and problem solve. It's inheritably unmeasurable but I think it is better than using a metric that ends up not meaning much. If it is explicit fuzziness vs implicit, I'll choose explicit every time because it is far harder to trick myself into thinking I'm doing the right thing when I'm not.

Enshitification doesn't happen because of the tools, it happens because the market will bear it.

"More apps that use far too many resources", "Interfaces with more friction" Let's extend this to just performance/latency/ux at large for web based tools/sites/resources. The market has shown in some cases people will tolerate a lot of this, like phone support, can take >30 mins, but in other cases/scales, like search, every millisecond matters. The garbage apps I encounter like this now I feel are on the wrong side of this line are generally are enterprise apps that deal with payroll, HR training, etc. These apps are allowed to be bad because their users are generally captive/don't choose the apps and their developers aren't likely to care much because nobody is passionate about making sexual harassment quizzes. I actually like the chances of a 2-3 person team using LLM coding tools being able to upset these entrenched garbage piles. The likelihood of a tool/site with good UX and performance now degrading because junior engineers are using LLM code seems to be about zero, if you've built these tools you know how hard it is to drive the culture/ethos on shipping the code that powers these projects before copilot/chatGPT was around, and that isn't going to change. So ultimately, I think

-Garbage apps that exist now will become slightly worse -The chances of slightly better, cheaper apps replacing those apps will grow -Good apps that exist now won't regress

Because of the tools? No, of course not. Do the tools make enshitification easier and does the current incentive structures create an environment where I expect these types of tools to accelerate enshitification? Certainly. These are two very different things. I hope we can understand the difference because these types of details are important to prevent enshitification.

I am pretty sure enshitification is a specific process with a specific meaning, what you're talking about, quality going down for whatever reason you can just call "going to shit."

Let's not lose the useful concept enshitification is a pointer to by overloading the word :)

The inevitable enshitification of enshitification.

I don't think I'm really pushing the bounds here. The fast pace does help make things sticky. We love shiny new features. Even if it is just a polished turd. My worry is about more polished turds, which I think is pretty in line with enshitification since the de facto tech is reliant upon network effects. But I guess the thought is more general.

Words shift meanings and once you have coined something you lose control over it. Bitter sweet.

> most beneficial to those that need it the least and least beneficial to those that need it the most

along those same lines, as someone who is rabidly anti-AI for coding, I've come up with a couple standards. If you can't explain to an expert the code you have produced with the use of "AI" (read: LLM), and/or you haven't tested it thoroughly then I don't want you using Copilot or any other automated tool.

> hallucinations

There's got to be a better term than this.

I wonder if these issues will still exist in 5 years. The power of NLP models has improved by so much these past 5 years, it's really insane.

Human advancement is tied to tool use. People said the same things about calculators, computers, math engines and solvers. Tools can only make us smarter, able to tackle big challenges.

All of this holds for good tools though, where a good tool is one that helps and then gets out of the way. Copilot isn't there yet, but over time, a successive version will get there.

I you think this is what I'm saying then you've gravely misunderstood.

"Once men handed their thinking over to machines in the hopes that this would set them free..."