Maybe your product is great, maybe even fantastic, but the presentation does not convince me to sign up at all.

Sorry if this sounds harsh; nothing personal.

Do you think this is the correct way to achieve whatever it is you want to achieve?

Have you read the HN guidelines?

You get the results and they do have direct URLs. But then, if you do some things with the link, e.g. right click to open it in a new tab, it swaps the URL to the indirect one. The idea is that initially you see a normal link, with a normal URL which will be displayed correctly when you hover the mouse over it, but right before you click it, it's swapped for the indirect one.

So, they have been doing stuff like this for a while and it has been somewhat fluid, because the swapping can occur on different events and I have also seen it load with all the links pre-swapped to the indirect ones, sometimes.

So, yes, what you see may be different and you may get the indirect URLs swapped at different stages.

I would suggest just leaving as soon as possible. I know it's hard and I know the current market is difficult, but do make a firm decision to, if not immediately, leave in a fixed time frame, say in two months or before the new year or something else but put a limit on it. Not only will that push you into doing it, but seeing a clear exit will probably help with your peace of mind.

In fact, the team needs to lead the modernisation effort. It needs updating before the rest of the system can be.

From your explanation it sounds like you expected to find a modern and skilled team maintaining a legacy project. That is not at all so frequent. If the project is legacy, most often is because the team also is outdated.

So, obviously you can just switch jobs. And if you're getting sick from it, then you should by all means leave this job.

But then again, if what you actually want is to make this job work, then my suggestion is to:

1. Get the whole team together and evaluate their situation. Make a list of the skills the team is lacking and the knowledge updates needed. Make them participate in this so that, at the same time, you can evaluate their attitude towards the whole thing.

1.a. If the team does not want to update, then there's no successful path and I would suggest leaving.

1.b. If the team is receptive, then go ahead.

2. Meet with whoever needs to authorise it and get them to commit to providing both time and resources for re-training the team. You will need a plan, a timeline, and achievable goals.

3. Start as soon as you can. Focus first on basic infrastructure. Any tools, processes, skills, that are generic and widely applicable. Then go for more specific ones directly related to the project's technologies.

The team may need some rearranging too, but try to keep this at minimum so that they can be confident that all of this is strictly related to a technology and skill update, and will not imply any sort of job insecurity or competition.

You may have noticed that all of this is mostly people management. If this is not something you'd like to do, then the only option is leaving. The job you're in right now is clearly one of people managing and not so much a technological one -though is still requires knowing and choosing the technological goals to seek, obviously-.

If you do follow, then who knows what will happen. But if things go well, you might expect to see some results in around 6 months or so, depending on how large/small the team and project are.

> Can I delete my account?

> We try not to delete entire account histories because that would gut the threads the account had participated in. However, we care about protecting individual users and take care of privacy requests every day, so if we can help, please email hn@ycombinator.com. We don't want anyone to get in trouble from anything they posted to HN. More here.

The TIME_CURVES array is filled (js/app.js:763) with objects in the shape of {time_ut, coords}. Then, the crossings array, which is built from TIME_CURVES (js/app.js:364-380), is filled with objects in the shape of {tUT, p} but, and here is the problem, you try to set the tUT property from a nonexistent tUT property in the TIME_CURVES element -it should be tc.time_ut or something derived from it- (js/app.js:377).

What happens then is that positionAt (js/app.js:382) goes through all the elements in crossings comparing the tUT argument passed into the function to undefined because the items in crossings all have their tUT property as undefined. This results in positionAt always returning crossings[crossings.length - 1].

And so, no matter what tMinutes argument you pass to updateLive (js/app.js:404), it will always get the same position into pos and it will always set the umbraCircle and the penumbraCircle at the same latitude and longitude. And so, nothing gets animated in the map. Or, to be more precise, it does get animated but is always painted at the same position.

Next time, you might want to consider skipping the insults.

So, what I don't understand is what is the play button supposed to do? Also why submit this two days early if people cannot see anything until tomorrow? Come tomorrow, people will already have dismissed this as useless and forgotten about it.

You press the play button and the timeline gets animated but nothing happens on the map at all.

> #opensource #infosec #cybersecurity #ethicalhacking #news #privacy

You can stop doing this.

You want to link https://8bit.gioorgi.com/ or https://8bit.gioorgi.com

[0] https://www.magnetic-press.com/frontier/

After a few clear fabrications, in the hallucinations it suggests I might be "a private individual" about who there's not much information.

I mean, I guess oh my gosh that's me but...

If I had to highlight the one thing all those conversations had in common it would be precisely this:

  I thought that having this knowledge would set me apart

The following is only a perspective on the argument of "the product works" and what "code elegance" means. I don't really care much about LLMs but the following is not necessarily tied to them.

Also, I'm retired from professional programming so feel free to ignore all of it as antiquated and irrelevant.

---

Code is not really "a means to an end". Code is better described as a liability.

People you write code may have different perspectives on code but those with more experience generally end up with this idea engrained in their minds. Code is a cost.

Thus, you'd want to have less of it, and you'd want to have code which:

- you at least have some grade of confidence that you can understand as deeply as possible, because that means you can maintain it better and more efficiently. It means that you can, when if fails, quickly/easily find where it failed, sometimes even why it did.

- you can manage in its entirety, which becomes exponentially more difficult when there's more of it and you didn't write it yourself. Not only that, it becomes more difficult to manage it when it has been incorporated in very large chunks that reach all over the codebase, and it becomes a lot more difficult when it lacks consistency, coherence and a certain uniform style.

What you call "the elegance of code" is not an aesthetical quality but a practical one. A developer obviously wants to have something that works, but that it does so well, reliably well. And they want code that is manageable enough that when shit happens -and it always does-, the fix will be hopefully easier and will hopefully make the resulting code more reliable, not less.

And, sure, in some circumstances development speed does matter. The problem is that the circumstances in which it does are frequently "unwanted" ones, usually external pressures, which we already disliked. Usually, you need to develop faster because someone else is pressuring you into putting that speed above reliability, not because it is intrinsically better to do it faster.

The one acknowledged situation in which development speed is tolerated above these other qualities is when doing a prototype. But then again, experienced developers know that prototypes can very easily turn into traps. When doing a prototype, quality is relegated because it is understood that this will not be the final product. It is understood that a prototype's code is disposable. But too often prototypes then become either the product directly or the basis for it. And again this happens because of external pressures. Most of the time because someone says "hey, it's working" without realising that it is barely so, that it's fragile, that it relies on constant tweaking and manual adjustment. But as it appears to be working, it gives the impression of being good enough to make financial sense to build on it.

And when you "ship version 2.0 at an incredible pace" what you're usually doing is shipping prototype 2.0, an unreliable system that requires more constant tweaking and manual adjustment. A system that entraps the developers into more maintenance on each iteration, when they'd want the opposite.

---

All in all, using LLMs to produce code may have its place. But if you focus on the idea of producing vast quantities of it faster, then that may not be the best use.