181–190 of 354 posts
Starts with a rant that appeals to hardcore programmers and then tells them to adapt. Of course he is an AI consultant among other things.
OP here. You're absolutely right, I just want to add that "other things" include being a programmer since the nineties :) Edit to add: instead of "adapt" (which would imply "embrace AI", which I didn't say), my intent was more along the lines of "be adaptable."
Claude, is that you? :)
Earlier quoted context omitted.
Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.
“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter. coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job. you ever see a leet-code-for-understanding-requirements? yea, me either…
But really, any interview is really about giving you a requirement, and seeing _how_ you understand it, how you clarify it with your stakeholders (interviewers), and then how you address them.
I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers. Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incred…
Earlier quoted context omitted.
Sorry, but we aren't talking about me here. You were the one who made the claim that AI pretty much makes making software trivial nowadays. Specifically, you wrote: > Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef. You did acknowledge that "some" skill was required: > There's still some skill involved, but the skill is mostly in manual testi…
Oh. So, because I said I work in software you assumed I worked in safety critical systems? Interesting. A little unhinged, but interesting. Anyways, as I said elsewhere, I don't code for fun, and my employer would be unhappy if I sent you their proprietary code. You can decide to do some experiments yourself, or you can decide that you don't want to hear it. No skin off my back either way.
No, I didn't. I asked you to provide me an example of code that you had generated via AI that might survive in such an environment. But if you re-read my original post, I also gave you an escape hatch: just code that was correct. Not even formally.
I'd say your refusal to provide any examples of your original claim is pretty telling, and your reasoning is pretty convenient for you, now isn't it?
Edit: also, I'd like to point out that it was you who used the word "software" as a general claim. You never specified what kind of software. Since you continue to expect me to derive the proof for you instead of you providing the evidence, I don't see any need to continue this discussion since nobody is obviously going to learn anything. I'm sure many of us here would love to learn what secret sauce your using that makes software engineering so trivial, but you don't seem willing to actually provide that.
In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code.
This has been around since the days of batch programming and evolved through domain driven design principles.
The reality is the business can’t see that so they don’t invest in it and have no patience for it.
Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster.
Planning and modeling are the levers of complexity.
LLMs are the invention of the loom. Code is being industrialized. Yes, there always will be artisanal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else. Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up wit…
Earlier quoted context omitted.
Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.
“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter. coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job. you ever see a leet-code-for-understanding-requirements? yea, me either…
Earlier quoted context omitted.
“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter. coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job. you ever see a leet-code-for-understanding-requirements? yea, me either…
You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these t…