| ▲ | JumpCrisscross 2 days ago |
| > We're in for a really dire future where the worst engineers you can imagine are not only shoveling out more garbage code but the ability to assess it for problems or issues is much more difficult It will probably still be more productive. IDEs, Stack Exchange...each of these prompted the same fears and realised some of them. But the benefits of having more code quicker and cheaper, even if more flawed, outweighed those of quality. The same way the benefits of having more clothes and kitchenware and even medicine quicker and cheaper outweighed the high-quality bespoke wares that preceded them. (Where it doesn't, and where someone can pay, we have artisans.) In the mean time, there should be an obsolescence premium [1] that materialises for coders who can clean up the gloop. (Provided, of course, that young and cheap coders of the DOGE variety stop being produced.) [1] https://www.sciencedirect.com/science/article/abs/pii/S01651... |
|
| ▲ | xigoi a day ago | parent | next [-] |
| You say “more code” as if it was a good thing. On the contrary, I want my codebases to have as little code as possible to achieve the given task. |
|
| ▲ | fzeroracer 2 days ago | parent | prev [-] |
| The problem with 'more code, quicker and cheaper' is that when you fall behind a baseline of quality it actually ends up costing you and your business, significantly. Companies learned this the hard way during the outsourcing booms, and the usage of AI amplifies this problem 10 fold much like it's doing with spam. |
| |
| ▲ | JumpCrisscross 2 days ago | parent | next [-] | | > Companies learned this the hard way during the outsourcing booms Sure. Then we learned how to do it and in which contexts. Since WFH trained executives state-side how to communicate asynchronously and over Zoom, I've seen engineering offshoring done quite productively, possibly for the first time in my career. | | |
| ▲ | fzeroracer 2 days ago | parent [-] | | I've seen attempts at engineering offshoring again and it causes problems because the core part of software engineering isn't the actual coding part, it's communication, design and understanding. If you offshore your coding, how do you know they're not using AI as well? How do you verify code quality? And what do you do when you're left cleaning up a mess? This isn't really a problem of the quality of engineers, but the inherent relationship between a company and contracted firms. | | |
| ▲ | JumpCrisscross 2 days ago | parent [-] | | > If you offshore your coding, how do you know they're not using AI as well? How do you verify code quality? All of these apply to remote-only teams. We know they work. (Note: I'm commenting more on offshoring than outsourcing. Outsourcing is fraught with issues. Offshoring once was, but is increasingly becoming viable, particularly with WFH and AI.) | | |
| ▲ | xyzzy123 a day ago | parent [-] | | IMHO the primary problem with offshoring vs using employees was always principal / agent problem and incentives. There was never a strong incentive for your "partner" to actually finish the job, they got more money from overruns, fixing defects, sunk costs, requirements churn, overstaffing, giving you juniors and billing for seniors, etc etc etc. There were also issues with cultural differences, communication and lack of understanding of the "customer" - but they are minor and resolvable compared to the core problem. |
|
|
| |
| ▲ | slothtrop 2 days ago | parent | prev [-] | | Growing pains. Reviewing carefully is still less work. |
|
