Comment by kriro | Hacker News Reader

Comment by kriro | Hacker News Reader

Maybe I'm a bit cynical but most of the "software engineering is so much more important than 'coding'" talk I have encountered came from people who could not write code that compiled/ran, let alone find creative solutions or do interesting things. Maybe it's important for them to see the actual programmer as a replaceable commodity, I dunno. Always bothered me. I'd also say that good programmers tend to be good software engineers even if they never draw a UML diagram (because...why). I sometimes get the feeling that certain "architects" assume programmers are just code monkeys that do not think. And then there's anecdotes of issues that came about because the programmer didn't understand the domain and thankfully the godlike architect saved the day etc...conveniently ignoring the myriads of wrongly collected requirements, wrong diagrams, architectures/diagrams that were never updated/are out of sync with the actual code etc.

Once again only from my experience...good programmers are capable of...thinking. Big shocker there but programmers tend to think about why they do and do not do stuff in certain ways (and even if it makes sense to do them).

I'm well aware there are excellent architects/managers but from my experience the good ones were strong programmers before and then "moved up" but they always understood the code level. And that's why I'm not afraid of "AI will take all programming jobs" scenarios...because even if the (en)coding would all be done by AI, to become really good at directing said AI you also hove to be good at programming (at least in my opionion).

But apart from that, I also see programming as an artistic endeavor at times. There's a lot of creativity and self expression that goes into certain kinds of programs. And writing good code that solves interesting problems is actually hard. I'm pretty sure the initial Quake engine was harder to write than getting the requirements right for said engine for example.

> I'm pretty sure the initial Quake engine was harder to write than getting the requirements right for said engine for example.

Gamedev is historically an outlier because the technical requirements are relatively obvious: keep FPS above a minimum, and latency low. Actual game content is highly flexible, but performance cannot be compromised.

By contrast, enterprise and industrial systems have far more specific requirements that must be identified and satisfied, including domain logic, security and safety.

in an ideal world the code is the best, first, and foremost specification of the requirements.

you should be able to parse the abstract syntax tree and just look at top level definitions to get a good overview.

Games have two other elements that make them an oddball:

1. The data integrity mostly doesn't matter. Crashes, corruption, whatever. Just throw playtesting at it until it kind of works. Higher discipline than that is only needed for multiplayer.

2. Most of the engineering exists to support a pipeline to create, load and render specific assets at a specific level of dynamism, ranging from "menu text" to "skeletal animation" to "character creation". It's the definition of what an asset is or can be, and how dynamic it has to be, that can make the difference between "days" and "years" of development. A team that can argue its technical case eloquently can chop out the most expensive kinds of assets, make extremely shoddy tools to help deliver the ones that remain, and still end up with an engaging experience.

When we discuss old engines like Quake, the genius in them is primarily in finding exactly the right specification of assets to hit the target machine of the time while achieving previously unprecedented levels of detail. It's easy to make a game on modern hardware run at 500hz if you stick to rendering Atari 2600-grade scenes - it's the additional detail that turns it into a major project to hit 30hz.

Today the burden in games has shifted away from the runtime performance costs of a scene - since there are a lot of standard methods of getting an acceptable result, including entire engines with level-of-detail systems to help automatically downgrade graphics - and towards the production cost of achieving detailed assets, which is more in the realm of what technical artists now do as a dayjob.

> "software engineering is so much more important than 'coding'" talk I have encountered came from people who could not write code that compiled/ran

Not only - a person who highly proficient in coding can think it the easiest part of development process not thinking that it took many years to arrive to the point when it become easy. It's like a rich person can not understand that getting money can be a hard part when buying something. People tent values less what they have in abundance.

Yes, as a not-great programmer, I have trouble meeting the requirements even when I know exactly what they are. Even if it's like aligning footnotes in a word document or something, it's hard to be exact.

My experience as well. I have never worked with a non-coding business analyst or architect who provided any positive value to projects I worked on. Quite the opposite.

The secret to completing projects, when people like that are involved, is to ignore whatever input/demands they have and instead solve the actual customer problem. If that means deploying unnecessary tech X, demanded by some “authority”, but not actually use it in production that’s fine.

> Once again only from my experience...good programmers are capable of...thinking.

Agreed. Unfortunately most programmers are not good programmers.

Reply on news.ycombinator.com