51–60 of 76 posts
As a former CTO, nothing is less likely to make me believe a claim than prefixing it with "CTOs agree..."
I hear the dentist that doesn’t agree with the other nine is more interesting at parties.
Earlier quoted context omitted.
It has been my experience that nobody wants to hear the software engineer's opinion as to what will improve the product however.
Nobody wants to hear anyone's opinion but their own, we have a poverty of effective communications. Nobody wants to communicate because it is pointless to communicate: what you say will be misunderstood, it will be repeated incorrectly and attributed to you, people will play games with your messaging and with you for trying to communicate. The management bully game activates, and they all participate in keeping the e…
There were some good insights in there. I like the idea of changing the hiring interview process to focus on testing code review ability. I feel like this would have been useful even before AI. A candidate who can identify tradeoffs present in some code and make insightful comments is likely good at systems thinking. It's a highly effective way to test someone's knowledge, intelligence and taste. It's actually brilli…
Counterpoint: you're doing a 15k line concrete implementation of a spec, or a module with fixed integration points. There could still be a lot subtly wrong, but there are going to be stress points and high leverage validation methods you can use to avoid reading the whole 15k.
But in most situations when I see a PR over a few thousand lines to an existing codebase that's highly depended upon, my stress levels tend to spike. On particularly complex projects and critical component, I'd read every single line.
Some modules I worked on, I would barely trust myself adding 100 lines to it because of how many other developers' code is depending on it. Sometimes they may be using it in ways which were not officially supported but I don't want to break backwards compatibility anyway.
So on such module, I would panic if I saw even a 1k line commit from somebody else.
15k lines is a lot. Each line comes with a probability that it introduces a bug. For a junior dev, the probability may be that 1% of lines introduce a bug... For a senior, it might be 0.1% per line and for the world's best coder, it might be 0.01%... But with 15k lines, and whatever the exact bug probabilities are, it's highly probable that the code contains at least one bug no matter who or what wrote the code.
Earlier quoted context omitted.
CTOs were told that the companies shares will be sold off if they can't produce AI results, and that the CEO will be deposed for "not having an AI strategy", so they should kindly shut up and go along with the flow.
Sounds like they’re followers and not leaders. So what are they getting paid for?
> Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed.
I keep seeing this claim, and it's incoherent. Programming languages are the languages we use to express system design, and just like Sapir–Whorf in natural languages they admit, emphasize, or force consideration of different concerns in the design process. If we did get to the point where those languages ‘don't matter any more’ it would just be because modern tooling allows us to express ourselves at a higher level than these languages were designed for — but then whatever higher-level language you're using to express yourself matters instead (and matters more than ever: the higher-level you go the more inaccuracies compound).
Programming languages are designed for humans, not for computers.
Classic Software Engineering stages of Specification and Verification (both Formal and Informal) take center stage with the software unit being treated as a blackbox. Developers are now "Systems Engineers" responsible for end-to-end systems delivery.
See also my previous comment chain here - https://news.ycombinator.com/item?id=48431591
Earlier quoted context omitted.
When it comes to AI, it really does seem so.
No it doesn't. Time still flows linearly. It's just bad writing.
What CTOs did not notice yet is that cheap code exposes inefficiencies elsewhere. Migrating Spring Boot apps from 3.x t 4.x is now easy given all the tooling available. But the administrative load can't be reduced by faster code delivery and that's the new bottleneck.
They should think about what happens when expectations are so high that a single dev must deliver and maintain multiple products. What stops that single dev from leaving and offering the same product on his own.
The engineer might not be good at sales or at raising money or at doing taxes or doesn’t have the appetite for risk.
But now it takes 3 months with AI, making a business and charging money has never been easier. Legal is a problem, but AI is a big help there as well.