771–780 of 897 posts
Earlier quoted context omitted.
Agile yes, it's micromanagement at scale. But writing tests and doing code reviews is good practice.
Everywhere I’ve worked I’ve found that the entire organization pays lip service to unit tests and code reviews, but then sets timelines so short and workloads so high that make real tests and reviews genuinely impossible.
Earlier quoted context omitted.
> Devs are cost center, not a profit center. They are "value enablers" not "value adders". I don’t understand this and I think it would require breaking my brain in order to. A person pays the company to provide a service. The developers create and maintain (part of) that service.
A business tends to break its components down into different units or departments, and then (from a financial perspective) largely boils down those units into "how much money do you spend" and "how much money did you bring in as income." Software being a cost center means that the expected income of the unit is $0, and thus it shouldn't be judged on its operating profit. It doesn't mean that software doesn't have val…
Audit, Security, IT (internal infra people), cleaning personnel, SPEND money.
Sales, Product Development, MAKE money.
Once the "developers" can charge per-hour to the clients, then we love them because they BRING money. But those 'losers' that slow down the 'sales of new features' with their 'stupid' checks and controls and code-security-this and xss-that, are slowing down the sales, so they SPEND money and slow down the MAKING of money.
Now, in our minds, it is clear that those 'losers' who do the code check 'stuff' are making sure that whoever buys today, will come and buy again tomorrow. But as it has been discussed here, the CEOs need to show results THIS quarter, so fire 20% of the security 'losers' to reduce HR costs, hire 5 prompt engineers to pump out new features, and pray to your favourite god that things don't go boom :)
Meanwhile most CEOs have a golder parachute, so it is definitely worth the risk!
Earlier quoted context omitted.
Exactly that. Software development isn't about writing code, never was, it's about what code to write. Doesn't matter if I type in the code or tell an AI what code it should type. I'll admit that assuming it's correct, an AI can type faster than me. But time spent typing represents only a fraction of the software development cycle. But, it'll take another year or two on the hype cycle for the gullible managers being…
I've been telling friends and family - and kids interested in going entering this field - this for years (decades actually, at this point), that I don't spend much of my time typing out code. I've found that it's very hard for people to conceptualize what else it would be that we're spending our time doing.
But the truth is that the way the computer works is alien and anything useful becomes very complex. So we've come up with all those abstractions, embed them in programming languages with which we create more abstractions trying to satisfy real world constraints. It's an imaginary world which is very hard to depict to other people. It's not purely abstract like mathematics, nor it's fully physical like mechanics.
The issue with LLMs is whatever they produce have a great chance of being distorted. At first glance, it looks like it's being correct, but the more you add to it, the more visible the flaws are until you're left with a Frankenstein monster.
Earlier quoted context omitted.
Everywhere I’ve worked I’ve found that the entire organization pays lip service to unit tests and code reviews, but then sets timelines so short and workloads so high that make real tests and reviews genuinely impossible.
Not in my experience. Maybe I've been lucky. Try working for bigger, established firms for better chances.
Earlier quoted context omitted.
What's wrong with writing tests? I sleep well at night when we push to production because of our robust test suite.
Writing good tests is an art. Its hard. It takes a deep understanding of _how_ the system is implemented, what should be tested and what should be left alone. Coverage results don't mean much. Takes some experience to know how easy it is to introduce a major bug with 100% test coverage. Tests are supposed to tell you if a piece of code works as it should. But I have found no good way of judging how well a test suite…
Earlier quoted context omitted.
>> Yeah the consistent "reporting" of "status" on "stand-ups" where you say some filler to get someone incapable of understanding what it is that you're doing off your back In my experience it is human nature to think you are doing something that people around you can't or don't understand. The graveyard is full of irreplaceable people is an old saying. Sometimes the people you report to are morons, but if you consis…
> graveyard is full of irreplaceable people I am not special and make no claims of it; I am entirely replaceable and I'd make no claims to the contrary. This has nothing to do with me or anyone like me, and everything to do with the "adult daycare" style of project managers. I'm tired of re-iterating to non-technical project managers that status of tickets, why things are "blocked" or why the ask isn't feasible given…
Earlier quoted context omitted.
The submitter should also have thoroughly reviewed their own MR/PR. Even before LLMs, coders not having reviewed their own code would be completely discourteous and disrespectful to the reviewer. It's an embarrassing faux pas that makes the submitter and the team all look and feel bad when there are obvious problems that need to be called out and fixed. Submitting LLM barf for review and not reviewing it should be gr…
> The submitter should also have thoroughly reviewed their own MR/PR What does it mean to have to review your own code as a separate activity? Do many people contribute code that they wrote but… never read? > Submitting LLM barf Oh right…
The concept and design were by that point iterated on, so it doesn’t happen that I need to rewrite a significant amount of code.
Earlier quoted context omitted.
I've been telling friends and family - and kids interested in going entering this field - this for years (decades actually, at this point), that I don't spend much of my time typing out code. I've found that it's very hard for people to conceptualize what else it would be that we're spending our time doing.
I think that's a good part of the issue. You have the computer that is doing stuff. And you have the software engineer that was hired to make it do the stuff. And the connection between them is the code. That's pretty much the simplistic picture that everyone has. But the truth is that the way the computer works is alien and anything useful becomes very complex. So we've come up with all those abstractions, embed the…
But to your last part, this is why I think the worst fears I see from programmers (here and in real life) are unlikely to be a lasting problem. If you're right - and I think you are - that the direction things may be headed as-is, with increasingly less sophisticated people relying increasingly more on AIs to build an increasingly large portion of software, is going to result in big messes of unworkable software. But if so, people are going to get wise to that, and stop doing it. It won't be tenable for companies to go to market with "Frankenstein monsters", in the long term.
The key is to look through the tumultuous phase and figure out what it's gonna look like after that. Of course this is a very hard thing to predict! But here are the outcomes I personally put the most weight on:
1. AIs might really get good enough that none of us write code anymore, in the same way that it's quite rare to write assembly code now.
In this case, I think entrepreneurship or research will be the way to go. We'll be able to do so much more if software is truly easy to create!
2. We're still writing, editing, and debugging code artifacts, but with much better tools.
In this case, I think actually understanding how software works will be a very valuable skill, as knocking out subtly broken software will be a dime a dozen, while getting things working well will be a differentiator.
Honestly I don't put much weight on the version of this where nobody is doing anything because AI is running everything. I recognize that lots of smart people disagree with me about this, but I remain skeptical.
Earlier quoted context omitted.
Agile yes, it's micromanagement at scale. But writing tests and doing code reviews is good practice.
Code review is another sacred process that seems too good not to have, but many teams use it as a "we care about quality" stamp when in fact they do not. Used for just nitpicking code style (important but not the whole reason to have CR, and there are tools for this), issue comments like "LGTM" and approve whatever arrives at the pull request anyway.