Loads right for me.
1,663 karma · joined September 1, 2010
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
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.
And you can contact hn@ycombinator.com if you're serious. But I'm not sure they do actually accept contributions. And anyway a dark mode is something that has been talked about for years and there doesn't seem to be much interest in adding it to the site. You may try other -external- options to add a dark mode through a browser extension.
It's a site with live camera feeds from around the world to see the sunset.
---
But... now let's think for a moment about what you're doing there. Not the technical bits, but what the user sees.
You have decided that the average male lives to 71-72 and female to around 74. You have then decided that this average should be taken as a hard, fixed limit. And that people will die at that age no matter what.
These two assumptions are somewhat tricky. I mean, the first one is fairly random without a context. For, say, India, this is about right, but for other countries of the world -or as an average for the whole world- it can be quite different. And you don't mention any particular country.
But anyway, it's the second assumption that is more problematic. Because the number is just an average and using it as a hard limit is clearly wrong. First of all because death is not linear. Take a look at this sample table for the US [0]. Life expectancy increases with age. That means that initial life expectancy can be 80 years, but if you make it to 60, your total life expectancy goes up to 84. And if you make it to those 80 your life expectancy still gives you -on average- another 9.5 years to live.
Why is this relevant? Well, because such a calculator would assume the user, the person that goes there to see how much time they have left with their parents... well, still has their parents alive. It would be stupid otherwise if they know their parents are already dead. So this is 2026. The user states that their dad was born in, say, 1956. That's 70 years. Is the 71.5 average life expectancy right? Not at all. Even as an average, even as a hard limit, it is wrong. For a person at 70, that life expectancy would be something like 80+ and the remaining time should be calculated according to that. Sure, this means you need to write code that is a bit more complicated than what you've done here. Because you don't just have one average life expectancy, you need a whole table or function to calculate it. But, hey, this is learning! It's a coding exercise. So it is an opportunity to learn more and go beyond the simple tutorial into an exercise that is just a little bit more advanced.
---
But then again, let's ignore even this. Let's go back and keep the simple exercise. Let's assume just one fixed life expectancy. Then, as I mentioned above, we have a problem that's worse, more... stupid. Because as I said such a calculator has to assume the parents are still alive. Otherwise is simply makes no sense. And yet, you're giving the user the option to choose birth years as far back as 1940, while directly assuming that anyone born before 1952 for men or 1955 for women is already dead.
When you offer that option, you're saying it is a valid option. But when the user chooses it, you're saying they are stupid for doing so.
What you're doing is like this conversation:
- Hi, I visit my dad every Friday afternoon.
- That's nice. But from this other perspective that may not be a lot of time. How old is he?
- Oh, my dad is 78.
- Bad news: your dad's already dead.
- What? No, he's fine, I saw him just yesterday.
- Your dad's been dead for years.
- You're an asshole.
So... again, congratulations on your coding exercise. You did it. The coding is solved [perhaps]. Well done.
But take this as an additional learning point: The problems you solve will sometimes involve writing code, but they will always require you to think about the details and nuances of the problem itself. It's all about the decisions and assumptions you make.
Discussing this seems useless.