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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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 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 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.

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.

"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

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

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

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/

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 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.

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

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.