711–720 of 785 posts
Earlier quoted context omitted.
What did the software engineers hope to learn from this tour?
The scale of a cloud datacenter is pretty awesome to witness. I had the opportunity to visit a large cloud company’s data center years ago, it was immense in scale and (mostly) very well thought out.
> bad engineers were always a liability So. AI Makes good engineers better, more productive and able to deliver well designed systems. But it makes the bad engineers 10x worse. Before, they had negative productivity in a team environment. Now, its 10x negative productivity. The mess they create as one person might need 10 people (and their AI's) to clean up. I would also put people who don't know how to code in that…
Earlier quoted context omitted.
I kind of think the whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry. Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job. The problem is our industry mostly doesn't have any sort of reasonable mentorship or apprenticeship culture, so we've always left it to the engineers to teach themselves. Sink or swim. The problem is th…
Learn to code wasn't just about careers though. It was also about individual empowerment. Everything goes through computers, and having the power to understand that domain increases agency. For a lot of people, they have no need to ship production grade software that scales to babel. But a custom script that solves an immediate business need is a common thing. I think that aim is more important than the harm learn to…
One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet.
This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written for humans and from unit tests. Code is cheaper than it used to be, but so is formalism.
This may be a way to put firewalls around AI slop.
There's a more general problem. We need to figure out how to use LLMs and still have decent code quality. One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet. This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written fo…
Earlier quoted context omitted.
> I'm rarely given the time or resources to do any engineering. Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary'? Failure in (most) software isn't going to harm anyone, so there isn't much technical need for engineering in software. As I am sure you can attest, artisans are fully capable of delivering great software. Some of the best software out there…
> Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary' I'm not certain of much these days, but I'm pretty sure of this. Any time I have tried to properly "engineer" something with documentation and specs and planning I've been told to just deliver it instead
However, it seems like both you and your employer both want artisans anyway, so it sounds like you have found a good fit. The software industry is putting more and more emphasis on engineers, but that is far from being universal yet (and will likely never be 100%).
Earlier quoted context omitted.
> For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did. "Professionalize" is an interesting way to frame this. As Milton Friedman argued, occupational licensure is almost always pursued by the practitioners rather than consumers. The licensing boards are mostly run by practicing lawyers and CPAs, so you have practicing lawyers and CPAs determining who ca…
Milton Friedman was a libertarian crank. I'm a consumer and I'm quite happy that doctors and lawyers are licensed.
Earlier quoted context omitted.
> I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now. What's the current delivery rates? From my past experience, any feature can take several weeks from idea to be in a somewhat usable shape for production. While the actual coding is often less than a few days. A lot of time is spent on gathering requirements and resolving confli…
> I believe most current improvement in speed is just moving from idea to demo in a few days This is an outdated view. Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say th…
My issue with these kind of numbers is that they never contrasted them with a NO_LLM practice while keeping everything the same. It's always perfectly fine to YOLO generated code straight into prod, but if you handwrite it, you need to fill several forms in triplicate to even make it to the review phase. Then someone claims they are 10X-ing their productivity with AI.
> you can just ship the feature and be experimenting with customers much faster.
That's basically what I said. Instead of shipping something that have some value to the customer/user from the get go, which may takes one or two months, you spend one or two weeks on it, ship it, then frustrate your customers/users when things aren't working or keep shifting around.
For all of AI being touted as the best thing since sliced bread, there's been little to no value for humanity as a whole.
Earlier quoted context omitted.
Doesn't this imply that, had your friend not taken your advice, he would have failed and thus been an "obvious fraud", but a mere 3 weeks transformed him from fraud to competent programmer?
No it means he fooled the interviewers