Redis handles tens of thousands of concurrent connections in a single event loop, while MySQL uses one thread per connection. No matter how I look at it, that seems like a step backward.

Of course, performance isn't everything. And if performance isn't a problem, having everything in one place does make it easier to reason about. But I'm worried that under spike traffic, this approach might actually cause more problems.

I actually think all these industry issues arise because the ultimate role most programmers aspire to is that of the Master. They want to be the ones designing the rules, frameworks, and architectures that mass produce journeymen. In reality, a department head at a major tech company certainly holds a position worthy of being called a Master.

However, I believe being a Journeyman is a thoroughly valuable and respectable end destination in itself. The reason is that once someone becomes a Master, they drift away from the actual field. They start focusing purely on building tools for the journeymen, whereas it is the journeyman who generally remains closest to the actual consumers.

I read your comment carefully. Thank you for taking the time to reply, and have a great day. It's been a weekend full of things to think about.

Software consists of various layers, and everyone has their own specific areas of strength. For instance, because I am an application programmer, I often need to write code that prevents the program from halting—aligning with recent programming trends that involve preserving the computation context using monads. In other words, my strengths lie in the overall architecture and interface design. This fundamentally relates to cohesion and coupling. I excel in this area, particularly when dealing with codebases around the 60,000-line mark. This is a realm where books like Clean Code are quite effective (many people dislike it, but it is actually a well-written book). Put differently, I possess the ability to mass-produce software (regardless of absolute quality). Over the course of 7 years, I have built CRUD applications for 43 companies across 16 different domains (ranging from drones and golf simulators to tax SaaS and supermarket POS systems). Therefore, I believe I have at least an average, solid capability in this regard. The primary area where I actually made money was PLC, so while I may not have deep academic expertise, I certainly do not think I lack capability.

In Korea, the profession known as SI (System Integration) is a field where you enter contracts on a "project" basis. In that environment, I have encountered a wide variety of people. From those experiences, my takeaway is that programming is divided into quite several distinct layers.

To speak of algorithms first: I learned basic algorithms and fundamental data structures in university. However, in the field where I worked, there were many people who struggled to implement those basic algorithms, yet they still built a large number of applications. Why is that? There was even someone who made an amount of money I could never dream of touching in my lifetime. Why did he make so much money when he didn't even know how to implement basic algorithms?

The answer is quite simple. It is because the "implementation model" and the "contract and cost model" are different. The contract and cost model is a self-contained body of knowledge. It is the ability to know exactly where to fit a given piece into the puzzle. Implementation is simply the ability to build that piece from scratch. In fact, mostly due to issues like employee turnover and the organization's future maintenance capabilities, many teams (specifically, organizations with lower implementation capabilities) decide on an open-source library and design their architecture based on its API. In these cases, the primary technical challenge becomes how to connect those components based on the performance of that library.

Yet, people tend to think that only those who can implement from scratch are capable of programming. A person who can take someone else's implementation and piece it together to fulfill their own contract is also a programmer, but people frequently forget this. Depending on which layer you exist in, certain knowledge requires you to implement it yourself, while other knowledge only requires you to understand the contract. I believe this is the core of programming.

Those on the side that must design and build libraries or frameworks naturally have things they must know about implementation, as they are creating the SDKs. However, I have seen quite a few cases where these very people have no idea how their work is actually utilized in the upper layers. And these types of knowledge are highly fragmented.

In my case, I am familiar with quite a few paradigms. On my personal homepage wiki, I can differentiate between OOP, DOD (Data-Oriented Design), and others, and in the context of relational databases, I know exactly where the ORM impedance mismatch occurs. However, this is largely an area intertwined with architecture, and its essence is closely linked to David Parnas's theory of information hiding. In other words: to what extent do we hide the internals, and where do we expose them to minimize the contact surface area and ensure a safe connection?

For example, I can't implement PostgreSQL's B-tree. But I can design a business system using PostgreSQL. I only know the name of TCP congestion control—I don't know how to implement it. But I can build networked applications.

That's what an 'industry' really is. The ability to trust the contracts of other people's implementations and assemble them. The ability to trust others.

In that regard, I agree with many of your points. However, I actually believe the software industry needs more of those "average" people. I think the very definition of an "industry" should premise that average people can maintain their livelihoods simply by dedicating themselves to a single specific field. From that perspective, when building one's expertise within this fragmented landscape of knowledge, it is perfectly natural not to know much outside of your own specific layer.

p.s https://www.makonea.com/en-US/casual/cargo-cult-programming-...

To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.

It's not that code wasn't difficult—it really was.

In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.

Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied.

The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult.

In the end, whether coding was difficult or easy depends entirely on which layer you're working in.

What's certain is that coding was difficult, and it still is.

I agree that the 'overall' video game industry is recession resistant. Over the long term, it will continue to grow.

But I don't think the 'polarization' of video games makes the middle tier recession resistant

So, because the game industry has an escapist quality to some extent, I can understand why people set aside a budget for hobbies. But apart from that, I think game consumption itself is becoming polarized."

There's this concept of 'AA games' or 'Myst games' that sit between AAA and indie titles. From what I hear across most of the industry and genres, as people's disposable income shrinks, the market is polarizing into reliable AAA games on one side and small, niche indie games on the other. Small indies can bet on extreme gameplay that big companies would never attempt.

In other words, when people start cutting back on hobbies, the first thing they reduce is spending on hobbies. And when they start tightening further, the first games to get dropped from their lists are the mid-tier ones.

Whether it's software or any genre market, this middle tier is disappearing because consumer spending itself is becoming extremely polarized.

This is a contradiction in cost structure.

When developing software, reducing the size to a mid tier level doesn't linearly reduce fixed costs. You still need to build server infrastructure, payment systems, security, basic UI/UX, cross platform support, and more, all of which come with enormous upfront costs. AAA companies can amortize these fixed costs by selling to millions of users, but a AA studio with limited capital ends up spending most of its budget just on infrastructure, leaving few resources to polish the core value of the product, graphics, gameplay fun, and design.

Also, when a recession hits, a cognitive tandem effect occurs. Only two things survive: what everyone else is playing, and niche products that match your personal taste. Mid tier products with moderate price and moderate quality require marketing efforts to convince consumers of their ambiguous value, often relying on influencer reviews or other forms of consumer persuasion.

In other words, the ABI we rely on today isn't really part of the C+ standard—it's more like the Itnaium C++ ABI or the MSVC C++ ABI.

In the end, I think the ABI stays stable because of community conventions established by compiler vendors.

Comments URL: https://news.ycombinator.com/item?id=49207422

Points: 2

# Comments: 0

In that sense, I sometimes feel like logical flaws might actually be a signal of humanity