Live data from Hacker News

Writes large correct programs (2008)

johndcook.com

101–110 of 114 posts

Re: Writes large correct programs (2008)

#101
post #96

Earlier quoted context omitted.

Have you ever watched a scam in action? It's in my best interests to convince you (a boss) that I'll bring lots of value, and then not bring it, and continue convincing you that I am bringing it.

If the boss or HR falls for such a scam, I clearly opine that they are not suitable for their job.

I agree, but the incentives are lopsided. The prospective hire has a huge incentive: they get the money. But the hiring manager doesn't have any such incentive: it's not their money they're spending.

Even worse, they may in some way be compensated based on the number of people or teams they manage, in which case the incentives of useless hires and hiring managers are unfortunately all too aligned.

Re: Writes large correct programs (2008)

#102

Earlier quoted context omitted.

> But, there are definitely some folks who we’d be better off paying to not do anything. An even better idea: simply don't hire such people.

They are motivated to be hired (the alternative is no money, possibly no home or good). They aren’t dumber than the folks who really want to do engineering and make neat stuff, just differently motivated. And if those two groups get in an office politics battle, the group that isn’t distracted as much by engineering wins, right?

> And if those two groups get in an office politics battle, the group that isn’t distracted as much by engineering wins, right?

Wiser than the average wisecrack.

Re: Writes large correct programs (2008)

#103

Earlier quoted context omitted.

> those who can program and those who cannot. Everyone in my PhD cohort that couldn't write code worth a shit stayed in academia and everyone the could went into industry because the money was way better. So it's quite natural.

Those who can't do... teach?

Those who can't do... tech?

// See thread above about UBI vs. tech nonsense jobs. Any industry driving seven figures per head has room for a quite a few before people notice.

Re: Writes large correct programs (2008)

#104

It seems to me that in other areas of tech, companies generally hire electrical engineers, mechanical engineers, civil engineers, etc. On the other hand, software companies feel that they don't need to hire computer scientists. Then periodically there is a discussion on Hacker News that boils down to "all of the other engineering disciplines can make reliable predictions and deadlines; why can't software?" or "why is…

> [P]eriodically there is a discussion on Hacker News that boils down to "all of the other engineering disciplines can make reliable predictions and deadlines; why can't software?" or "why is this company's code so shoddy?" or "why are we drowning in technical debt?".

You'd find those also have more trouble with predictions when machinery needed for the goal hasn't been delivered before.

While most software jobs today are a bespoke configuration of a solved problem, the practice of software development is new enough to remember when most software was to solve a physical problem in a new digital way. Discovering/inventing are predicted on the search space being unknown in advance, making discovery and invention unlikely to be estimated accurately.

Note, though, most software today has already been writting, and the lack of predictable delivery is because the process doesn't rigorously enforce a "first, apply known/solved software" approach.

If, in software, materials use was third party inspected and certified as it is in physical or electrical engineering, you'd find software get more predictable.

Re: Writes large correct programs (2008)

#106

Earlier quoted context omitted.

Unrelated to the central point of your comment, but I've also found that a simple entity system is usually perferable to ECS for smaller games. ECS aids performance, but performance usually isn't what you're struggling with in a small indie game. You're mainly just struggling to organize your code, and just need something simple to help manage complexity.

Minecraft is an entity system and it seems to work just fine. (Fun fact: Forge Mod Loader makes Minecraft an entity component system.)

having things called entities and components isn't doing ECS. Minecraft is a traditional OOP class hierarchy of entities, which (with Forge) have a Map whose entities are called components.

In the technically superior Fabric ecosystem, you can add fields directly to the entity class using bytecode modification instead of having HashMap overhead on everything. Accessing them is a bit roundabout, but in a way the JIT compiler can optimize.

Re: Writes large correct programs (2008)

#108
post #30

> how to organize software so that the complexity remains manageable as the size increases So John is missing the role of software architect here. Science, art, and development - 3 roles. Not all visits to the stratosphere are misadventures.

I think TFA is implying that good SWEs are good architects too, the skills go hand in hand. I frankly don't believe in the "software architect" as a separate role. I've worked with "architects" who are clearly just BS artists because they know the jargon but have no skill to back it up and make difficult technical decisions regarding tradeoffs.

Good SWE can do all 3. The three distinct skill sets are orthogonal to individuals' skills.

Re: Writes large correct programs (2008)

#109

Can absolutely relate and understand. I taught myself C++ by writing games with SDL2. The first game -- snake took about a couple of hundred lines and I put everything in one .CPP file. And I felt pretty good. The second game, well, I forgot what it is, not Tetris nor Breakout, but it was complex enough that I realized that I need to put code into header files and source files. The last game of that project was a Ult…

Unrelated to the central point of your comment, but I've also found that a simple entity system is usually perferable to ECS for smaller games. ECS aids performance, but performance usually isn't what you're struggling with in a small indie game. You're mainly just struggling to organize your code, and just need something simple to help manage complexity.

I built an ECS from scratch back in 2019 using C#. It was my first programming project in earnest and I was 19 at the time. Fortunately, I committed to version control and sometimes I still look at it: https://github.com/randyselimi/ECSRogue

I came up with everything on my own and I don’t know how I was so inspired then. Most of the ECS code is in a folder tilted Partis (that was the name of the ECS system I wanted to develop)

Re: Writes large correct programs (2008)

#110

Earlier quoted context omitted.

Unrelated to the central point of your comment, but I've also found that a simple entity system is usually perferable to ECS for smaller games. ECS aids performance, but performance usually isn't what you're struggling with in a small indie game. You're mainly just struggling to organize your code, and just need something simple to help manage complexity.

I built an ECS from scratch back in 2019 using C#. It was my first programming project in earnest and I was 19 at the time. Fortunately, I committed to version control and sometimes I still look at it: https://github.com/randyselimi/ECSRogue I came up with everything on my own and I don’t know how I was so inspired then. Most of the ECS code is in a folder tilted Partis (that was the name of the ECS system I wanted t…

Probably my favorite piece of code is in ECSRogue/Partis/Entities/EntityIndexManager.cs. I’d love if someone with more experience could critique this code and my implementation. Keep in mind, I just transferred from community college and hadn’t even taken a single programming/data structure course
Post reply on HN