Hacker Newsnew | past | comments | ask | show | jobs | submit | fdsf111's commentslogin

I dual boot windows with linux, but I haven't used windows in over a year.

The thing that stuck me about windows (windows 11) was how slow the right mouse button click feels. On the main screen, between right clicking and seeing the modal pop up, there is a ~150-200 ms delay that wasn't there on Windows XP and Windows 7. Those were the last major version of Windows I used as my daily drivers.

In windows 11, I was also annoyed by all the bloat on my home screen that I had to turn off manually, like the news feed or the weather or the stock market tracker. Oh -- and here is a good one -- my system clock resets every time I restart. I easily spent 2-3 hours trying to figure out why, and I eventually I gave up. Yes, there is a setting for "synchronize time automatically", but it doesn't work for me. Every time I log into windows, I have to go into the clock settings and manually force a resync with the correct time zone. To me this is just wild.

I transitioned to using Linux full time around 2018-ish, when I stopped playing MMOs. I still keep a version of Windows on my PC, but single-player gaming is a first-class citizen on Linux now, so I haven't logged into windows for some time.


The clock problem is actually a Linux issue. Linux sets the hardware system clock to UTC and only applies time zones when displaying the time.

Windows sets the hardware clock to local time.

Every time one or the other updates the clock, it's now in the wrong format for the other OS. The fix is to tell Linux to use local time. There are no side effects as far as I can tell


I wouldn't call that a Linux issue or a Windows issue. It's kind of like driving on the left or right side of the road: either way is fine, you just need to have everyone agree on which way they are going to use.


There in an advantage to using UTC: when legislatures change the rules about which time zone is which, or you move your computer while it's off, the time remains correct.

Using local time for the RTC theoretically makes it simpler to schedule wakeups at user friendly times, but that seems less impactful.


The better solution is allow config instead of trying to agree, and the best is auto defect and apply the correct config are the OS level


How do you autodetect the timezone, when the RTC clock doesn’t have one?

On Linux with one command you can switch between UTC or local RTC time to match Windows. On Windows you need to change a bit in the registry if you want it to adapt to the Linux way - i.e. the correct one.


I'd say that's a Windows issue and Linux has a solution to make it compatible with Windows. Why would you want the system clock to be in local time instead of UTC? For example you switch off your laptop in one timezone, fly to another timezone, switch it back on, the time has been ticking the same whether you moved to a different timezone or not, you only need to change the timezone for display, why would you need to save back to RTC a different value based on the timezone? I never tested it but I'd like to see what happens on a Windows desktop if you change the timezone and unplug the computer without giving a chance to save to RTC. On next boot the local time read from RTC will be wrong.


you can also just tell windows to use UTC for the hardware clock


I recently tried a 7-day trial version of Claude Code. I had 3 distinct experiences with it: one obviously positive, one bad, and one neutral-but-trending-positive.

The bad experience was asking it to produce a relatively non-trivial feature in an existing Python module.

I have a bunch of classes for writing PDF files. Each class corresponds to a page template in a document (TitlePage, StatisticsPage, etc). Under the hood these classes use functions like `draw_title(x, y, title)` or `draw_table(x, y, data)`. One of these tables needed to be split across multiple pages if the number of rows exceeded the page space. So I needed Claude Code to do some sort of recursive top-level driver that would add new pages to a document until it exhausted the input data.

I spent about an hour coaching Claude through the feature, and in the end it produced something that looked superficially correct, but didn't compile. After spending some time debugging, I moved on and wrote the thing by hand. This feature was not trivial even for me to implement, and it took about 2 days. It broke the existing pattern in the module. The module was designed with the idea that `one data container = one page`, so splitting data across multiple pages was a new pattern the rest of the module needed to be adapted to. I think that's why Claud did not do well.

+++

The obviously good experience with Claude was getting it to add new tests to a well-structured suite of integration tests. Adding tests to this module is a boring chore, because most of the effort goes into setting up the input data. The pattern in the test suite is something like this: IntegrationTestParent class that contains all the test logic, and a bunch of IntegrationTestA/B/C/D that do data set up, and then call the parent's test method.

Claude knocked this one out of the park. There was a clear pattern to follow, and it produced code that was perfect. It saved me 1 or 2 hours, but the cool part was that it was doing this in its own terminal window, while I worked on something else. This is a type of simple task I'd give to new engineers to expose them to existing patterns.

+++

The last experience was asking it to write a small CLI tool from scratch in a language I don't know. The tool worked like this: you point it at a directory, and it then checks that there are 5 or 6 files in that directory, and that the files are named a certain way, and are formatted a certain way. If the files are missing or not formatted correctly, throw an error.

The tool was for another team to use, so they could check these files, before they tried forwarding these files to me. So I needed an executable binary that I could throw up onto Dropbox or something, that the other team could just download and use. I primarily code in Python/JavaScript, and making a shareable tool like that with an interpreted language is a pain.

So I had Claude whip something up in Golang. It took about 2 hours, and the tool worked as advertised. Claude was very helpful.

On the one hand, this was a clear win for Claude. On the other hand, I didn't learn anything. I want to learn Go, and I can't say that I learned any Go from the experience. Next time I have to code a tool like that, I think I'll just write it from scratch myself, so I learn something.

+++

Eh. I've been using "AI" tools since they came out. I was the first at my company to get the pre-LLM Copilot autocomplete, and when ChatGPT became available I became a heavy user overnight. I have tried out Cursor (hate the VSCode nature of it), and I tried out the re-branded Copilot. Now I have tried Claude Code.

I am not an "AI" skeptic, but I still don't get the foaming hype. I feel like these tools at best make me 1.5X -- which is a lot, so I will always stay on top of new tooling -- but I don't feel like I am about to be replaced.


Your bad experience is because AI can’t really reason in general. It gets some kinda reasoning via a transformer, but that’s nothing like the reasoning that goes into the problem you described.

LLMs are great at translation. Turn this English into code, essentially. But ask it to solve a novel problem like that without a description of the solution, how will it approach it? If there’s an example in its training set maybe it can recall it. Otherwise it has no capability to derive a solution.


However, most problems (novel problems, problems not in the training set) can be decomposed into simpler, known problems. At the moment the AI isn't great at driving this decomposition, so that has to be driven by a meat bag.


> I worked really hard at the practice of interviewing

What did you do?


Not the OP but I tell everyone on the market that one of the highest ROI things you can do is just go through your own past career history with a fine toothed comb and simply remember all the different things you did and be able to tell the story of each concisely and informatively (if possible, recall actual numbers and quantifiable impacts etc.).

When in an interview, when you're asked a question about your past experiences, the larger the library you have to draw on, the more likely you are to find an example that's relevant and persuasive. Even questions of the form "How would you deal with [hypothetical scenario]", I encourage applicants, if possible, to answer it in the form of "Oh yeah, that's interesting, we had to deal with a very similar case at [one of my previous jobs], here was my approach towards it".

After each interview, do a "l'esprit de l'escalier" retro, write down all the questions asked, what your answer was at the time and what you would have ideally answered now given the fullness of time to think about it. If there's a significant delta, that's a sign to go back and prepare more until your "real time" performance approaches your retroactive performance.


As terrible as the Amazon interview process is, they’re very up front in telling candidates exactly this: Here are the LPs, come up with stories for each one and make sure it’s STAR format.


Everything. MIT has open sourced their coursework so I took all of it. I studied, I worked my way through TAOCP, cracking the coding interview (less helpful honestly) and tons of leetcode, I spent 4 years doing this and interviewing to get an idea of the system architecture problems and see how I was progressing.

It worked, after 4 years of studying I landed a SF job and 6 months later I was at Apple, year after that I was at Netflix. You get out of this life what you put into it, and in software it’s all out there for you to get. You don’t need a degree, you don’t have to pass the bar or boards, you just need to prove yourself and be willing to hustle


The number of mentions needs to be normalized by the number of job posts.

Example:

- 2021-01: posts=842, python=194, ratio = 194 / 842 = 0.23 (mentions per post)

- 2025-01: posts=487, python=87, ratio = 87 / 487 = 0.18

And then if you want to see a trend, do a moving 6 months average.

[2021-01] https://news.ycombinator.com/item?id=25632982

[2025-01] https://news.ycombinator.com/item?id=42575537


probably more like number of job posts that include at least one programming language for conditioning. (if you want to look at relative trends). distribution over job class as well as an accurate count of actual jobs per post here also probably makes sense for measures of overall activity and longitudinal analysis. could maybe skip the deep counting if you can show that it's static across the dataset.


Number of job posts itself seems like a better measure of the state of the job market than mentions or mention-density. What aspects might mentions capture that number of postings wouldn’t?


There's also the popularity of HN itself and the popularity of posting jobs on HN that's an important factor.

You could both normalize the figures and include a separate graph for job posting density per month or something like that. Total posts on HN monthly would also be interesting to visualize. Is it trending up or down?


There's also the popularity for HN based upon the particular language.

It's possible there's skew where rust becomes more popular say, and gets the bulk of the new posts, but python or java aren't super interesting anymore. So those people stop showing up to HN.

I'd like to see the popularity of posts by language. I bet we'd see a lot fewer Java and Python posts compared to Rust.


It would capture the shift in need for each language.


Optionally, the novelty factor plays here: C++ created 40 years ago, Python a little bit later, and Rust less than two decades ago. The selection of programming languages should be augmented/benchamrked with the TIOBE index.

[1] https://www.tiobe.com/tiobe-index/


Yeah, I found the percentage of job posts with the keyword in https://www.hntrends.com when I was publishing it, was effective.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: