This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
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.
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.
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.
I think 99.999% of all coding/engineering is not like this example though.
No, it's certainly not. Even for really high-utilty personal projects, what you do, esp. when you compare to the previous example, is extremely simple. Some parsing here, some SQL there, a HTTP POST somewhere else.
Unless you're rendering something, developing a custom, binary file format, talking with the hardware, or doing something extreme like I have given in the example, most programming is very similar. Re-organizations of the very same building blocks.
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.
That's the first time I've heard that idiom. What does it mean?
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.
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
Maybe in Western culture, but a lot of cultures (Middle Eastern and Indian for example) really like goat meat and even raise them specifically for that.
Chickens?