331–340 of 512 posts
Earlier quoted context omitted.
indeed, being on-call cleanses many developers of slopulist habits
That depends on how quick the feedback loop is for your decisions. If it takes weeks or months to find the impact of your changes, or worse, if you're insulated somehow from those changes, you may not be pushed toward improving the quality of your code.
Earlier quoted context omitted.
Have you seen large consumer products’ codebases?… Companies like Google are tiniest exceptions when it comes to code gatekeeping and quality.
Funny how the biggest, most profitable software companies emphasize code quality.
Earlier quoted context omitted.
> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work qu…
And yet somehow the shittiest buggiest software ends up being the most popular. Look through the list of top apps in mobile app stores, most used desktop apps, websites, SaaS, and all other popular/profitable software in general and tell me where you see users rewarding quality over features and speed of execution.
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work qu…
Have you taken a look at the world in the past… I dunno, at least several decades. That ceased to be true somewhere around the time I was in high school, maybe before.
Earlier quoted context omitted.
> At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. Ah yes, if you aren't shitting code out the door as fast as possible, you're probably not shipping anything at all.
That isn't a fair reading.
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
This is very much a "it's not the fall that kills you, it's the sudden stop at the end" sort of thing. (Same with the other variant I've heard, which is something like "no company has gone out of business because of tech debt".)
Code is as much a tool for developing and expressing conceptual models as it is for making computers do things. So not only does code quality have proximate impacts on engineering productivity and reliability, but, done well, it also improves the holistic design of the system you're building. You get better tools, faster, by putting some thought and care into your codebase and, especially, your core abstractions. Teams with good code move faster even in the short term and produce better tools and products.
Of course, it's not just a matter of code; you also need a culture that gives engineers the agency to make real, long-term decisions about what you're building (not just how) which, unfortunately, is rare to find in the modern tech industry :/ The dominant "high-output management" paradigm where code is seen as a virtually fungible "output" to be "delivered" loses the higher-order advantages of good code and good conceptual design, and leaves us with something much closer to the trade-off you describe. But there are other ways of approaching technical work that don't make this trade-off at all!
I'm optimistic that AI will actually increase the proportion of good code in the future. 1. IME AI tends to produce good code "in the small." That is, within a function or a file, I've encountered very little sloppy code from AI. Design and architecture is (still) where it quickly tends to go off the rails and needs a heavy hand. However, the bulk of the actual code will tend to be higher quality. 2. Code is now very…
Put simply LLMs perform better on better code.
Earlier quoted context omitted.
> You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work. Exactly, thank you for putting it like that. So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy whi…
I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most sof…
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Earlier quoted context omitted.
I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most sof…
The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in…