5 ms·

I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Mig

I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Might be more about web backend than the whole field, but the challenge always comes from formulating requirements in a rigid form with all edge cases considered. This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.

bayindirh 2mo ago
This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for. Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.
- ivanjermakov 2mo ago
  Yep, LLMs excel here because most of the time analogous solution is already in the codebase. Most of my initial promtps include "look how it's done in X and do the same".
- munksbeer 2mo ago
  > Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules. You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part. I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
  - bayindirh 2mo ago
    > I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules. This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high performance programming in Boundary Element Method space. The knowledge is not novel, but the formulae is. We developed the math, not optimized something already out there. Moreover, we had to optimize to the hardware architecture we had. This means tons of runs, profiles, optimizations, and even more runs. There are some bottlenecks here. You can't make profiling faster since you're already going flat out. Memory bandwidth, processor's internal pipelines, load and store units are completely saturated. Perf returns numbers close to theoretical maximums, the systems are running at TDP limits, you're done. AI can't make it faster. Developing the math, chopping the formula and sprinkling at different levels of the loop to minimize step count to use what you have at hand becomes important. You also check modeling accuracy here, testing around 32 significant digits precision, again takes time. If you're changing processor architectures, load/store widths change; pipelining behavior change, memory bandwidth per core, NUMA structure change. You have to fine tune here and there to get the same efficiency from a different core. So, method is not the bottleneck, but the novelty of the problem and method and runtime is. When testing engineering stuff precision and accuracy both matters, and seeing tradeoffs take time. When there's nothing to draw from, maybe AI can point out blaring issues, but without running the code and seeing it for yourself, you can't reach to the point where you need to go. For the "codification of it" part, humans have something called intuition which is a kind of tacit knowledge which shows us the way based on a wide network of knowledge. It's not easy to surface, define, codify and transfer. That knowledge esp. helps when systems act contrary to guesswork and rules break in myriad of ways. "Having a feeling of the machine" is only possible with experience, and can't be codified and transferred easily. This is why we have master/apprentice model and why it's so important in transferring knowledge.
    - munksbeer 2mo ago
      Thank you for writing that. It's a good example. I think 99.999% of all coding/engineering is not like this example though.
jibal 2mo ago
[dead]
zero_shift 2mo ago
It depends what you mean by enterprise project? If you just mean a large company, I would say they do exist - though it may take some looking for them. You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce) I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding. My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions. That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.
- bramadityaw 2mo ago
  > ...it's better to be a goat than a cow. That's the first time I've heard that idiom. What does it mean?
  - thereforegrin 2mo ago
    I don't know it either, but I read it as: - 'goat' referring to both the 'greatest of all time' as in specialized and at the same time to it being a not-so-common animal, - while 'cow' is simply just a common animal, so in this context it represents a plain worker. I'm not aware of any 'cow' acronym, that would directly relate to work/proficiency as the 'goat' does but it would further enhance the meaning behind the quoted phrase. In fact it's exactly what is missing, for the phrase to be instantly understandable by making it symmetric in both direct and acronymic reading. So is there a 'cow' acronym, that is an antonym to 'goat'? I'm not aware of one.
  - zero_shift 2mo ago
    I made it up on the hoof (pun intended) Cows are the most common animal on the farm, and overall they produce the most value. But they are very replaceable. When times are bad, you slaughter them. Cows are like your rank-and-file application developers: you scale them up and down with the times. Goats are more niche. You don't have many of them on your farm. But they solve important problems (eating weeds), and they look after themselves, so you seldom slaughter goats. Goats are like specialists in your company. People who know how the "real" things operate. You don't need many of them. But they are involved in enough critical things, niches that can't be scaled down, that you seldom lay them off
dsego 2mo ago
[dead]
zabzonk 2mo ago
Trading systems? Most complex things I've worked on.

bayindirh 2mo ago

This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for. Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.

ivanjermakov 2mo ago
Yep, LLMs excel here because most of the time analogous solution is already in the codebase. Most of my initial promtps include "look how it's done in X and do the same".
munksbeer 2mo ago
> Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules. You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part. I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
- bayindirh 2mo ago
  > I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules. This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high performance programming in Boundary Element Method space. The knowledge is not novel, but the formulae is. We developed the math, not optimized something already out there. Moreover, we had to optimize to the hardware architecture we had. This means tons of runs, profiles, optimizations, and even more runs. There are some bottlenecks here. You can't make profiling faster since you're already going flat out. Memory bandwidth, processor's internal pipelines, load and store units are completely saturated. Perf returns numbers close to theoretical maximums, the systems are running at TDP limits, you're done. AI can't make it faster. Developing the math, chopping the formula and sprinkling at different levels of the loop to minimize step count to use what you have at hand becomes important. You also check modeling accuracy here, testing around 32 significant digits precision, again takes time. If you're changing processor architectures, load/store widths change; pipelining behavior change, memory bandwidth per core, NUMA structure change. You have to fine tune here and there to get the same efficiency from a different core. So, method is not the bottleneck, but the novelty of the problem and method and runtime is. When testing engineering stuff precision and accuracy both matters, and seeing tradeoffs take time. When there's nothing to draw from, maybe AI can point out blaring issues, but without running the code and seeing it for yourself, you can't reach to the point where you need to go. For the "codification of it" part, humans have something called intuition which is a kind of tacit knowledge which shows us the way based on a wide network of knowledge. It's not easy to surface, define, codify and transfer. That knowledge esp. helps when systems act contrary to guesswork and rules break in myriad of ways. "Having a feeling of the machine" is only possible with experience, and can't be codified and transferred easily. This is why we have master/apprentice model and why it's so important in transferring knowledge.
  - munksbeer 2mo ago
    Thank you for writing that. It's a good example. I think 99.999% of all coding/engineering is not like this example though.

jibal 2mo ago

[dead]

zero_shift 2mo ago

It depends what you mean by enterprise project? If you just mean a large company, I would say they do exist - though it may take some looking for them. You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce) I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding. My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions. That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.

bramadityaw 2mo ago
> ...it's better to be a goat than a cow. That's the first time I've heard that idiom. What does it mean?
- thereforegrin 2mo ago
  I don't know it either, but I read it as: - 'goat' referring to both the 'greatest of all time' as in specialized and at the same time to it being a not-so-common animal, - while 'cow' is simply just a common animal, so in this context it represents a plain worker. I'm not aware of any 'cow' acronym, that would directly relate to work/proficiency as the 'goat' does but it would further enhance the meaning behind the quoted phrase. In fact it's exactly what is missing, for the phrase to be instantly understandable by making it symmetric in both direct and acronymic reading. So is there a 'cow' acronym, that is an antonym to 'goat'? I'm not aware of one.
- zero_shift 2mo ago
  I made it up on the hoof (pun intended) Cows are the most common animal on the farm, and overall they produce the most value. But they are very replaceable. When times are bad, you slaughter them. Cows are like your rank-and-file application developers: you scale them up and down with the times. Goats are more niche. You don't have many of them on your farm. But they solve important problems (eating weeds), and they look after themselves, so you seldom slaughter goats. Goats are like specialists in your company. People who know how the "real" things operate. You don't need many of them. But they are involved in enough critical things, niches that can't be scaled down, that you seldom lay them off

dsego 2mo ago

[dead]

zabzonk 2mo ago

Trading systems? Most complex things I've worked on.