Your workday isn’t a monolith; it is a series of tiny tasks. Try deconstructing your job to identify intrinsic motivation.
Which micro-tasks do you look forward to? Which raise questions you think about and work on in your free time?
Which tasks do you avoid, put off, or find immediately draining?
If you can’t identify interesting tasks, you are likely looking at too high a level of abstraction. Break “working with clients” down until you find the specific unit of work (e.g., “debugging edge cases” vs. “proofreading emails”) that sparks interest.
After sorting tasks into intrinsically motivating or not, look for a role that involves about 20% more time on the interesting micro-tasks and 20% less on the boring ones. If you do this every few years, you drift toward a career you enjoy without needing a radical “reset.”
This approach led me down an unexpected path: law firm attorney -> government attorney -> regulatory consultant -> small-business operator. Now, I am looking at moving to a role that involves at least 20% more time on software development (intrinsically interesting to me) and 20% less time chasing unreliable people (particularly draining to me). I never set out to change my “identity,” but focusing on the micro-tasks I actually enjoy has allowed me to engineer a career I enjoy on a day-to-day basis.
I, for one, don't even know anymore. I used to quite enjoy the art of coding and "big picture thinking", for lack of a better description. But now LLMs do the former and everyone and their brother are clamouring to do the latter as they see it as the only way to remain relevant in the software industry, leaving it to be a competition that is not fun to participate in.
Yes, this is exactly the distinction I was struggling to articulate.
“Online” has collapsed into a single bucket that includes friends-only play, strangers, stores, chat, downloads, etc. What I want (and what you’re describing with running servers) is a way to scope online access: friends-only communication, no discovery, no stores, no strangers.
The frustrating part is that many platforms either (a) force these things to come as a bundle, so saying “yes” to playing with friends implicitly says “yes” to a much larger surface area; or (b) make the unbundling process so complex that well-meaning parents fail and exhausted parents give up.
The etymology I’ve heard isn’t even listed in the article.
One theory traces “Kentucky” to early forms like Cantucky or Cane-tucky, referring to the region’s vast river-cane brakes, Kentucky River cane, North America’s only native bamboo, which early inhabitants associated with fertile, game-rich land.
A weak judgment betrays itself in the indiscriminate use of fine punctuation; for when the em-dash is made universal, it ceases to be distinguished, and becomes merely another form of hyphen.
Let the em-dash remain upon the height of style. Let the hyphen toil in the shade of the valley. And let the en-dash—patient, capable, and unjustly overlooked—at last be admitted to polite society, where it may properly mediate matters of form–function.
I wanted to share a quick piece of feedback from a potential reader's perspective: There are several small inconsistencies in the intro text (e.g., inconsistent capitalization of 'Rust' vs 'rust', grammar typos).
In a domain like OS development where extreme precision is required, these small errors can subconsciously signal to readers that the technical details might also be imprecise. A quick polish of the documentation would go a long way in establishing authority and trust for the rest of the book.
Hi!
I am the developer of this, and I really appreciate the feedback!!
The book is still on development and this is why I didn't even publish it here, I just recently finished the highlighter which was a lot of work, and I probably will require more.
Currently I am trying to make book and OS unique by developing and creating an explanation on AHCI, which I didn't see much on the internet. And then I try to handle all of the grammar, and typos
I couldn’t care less. It always pisses me off when a reviewer of my PR just flags the entire thing because of inconsistent capitalization. It’s the right correction and I always follow through but it’s also pedantic.
It’s technically more correct. But it’s also not a very big deal. Actually it matters more in code for search-ability but for documentation and comments? Give me a fucking break.
No. Why would it be? I hate it when people come up with defense based off of linguistics. Your defense is essentially "technically correct" sounds like "technical documentation" therefore one applies to the other because of the word "technical". That's an incidence of language and NOT of reality. Let me frame if from a rational and logical perspective:
Technical documentation is not a math proof. Its purpose is to transfer a working mental model to a human reader so they can make correct decisions. A document can be locally, pedantically correct and still be globally misleading if it emphasizes edge cases, omits constraints, or frames abstractions in a way that causes readers to generalize incorrectly.
In practice, what matters is not whether every sentence can be defended in isolation, but whether the document reliably produces correct outcomes in the hands of its intended audience. A simplification that is technically incomplete but operationally accurate is often better documentation than a perfectly correct description that obscures the dominant behavior of the system.
Engineers learn this the hard way. If you have ever followed documentation that was “technically correct” yet caused you to design the wrong thing, you already know this distinction matters. Correctness is necessary to an extent (and not to an excessive extent), but it is not sufficient. The goal is truthfulness at the level of use, not just sentence level defensibility.
Sure you do, you see a crime where no crime happened. Read my post carefully. I imposed nothing. A standard was imposed onto me. I didn't in turn impose anything on anyone else.
People may agree with you but don't imply something was done when nothing of the sort was even attempted. I did not impose my sloppiness onto others, what happened was someone tried to impose their pedantic-ness onto me and then you falsely accused me of imposing onto others. Please don't make up shit.
Attention to detail is important for many and is often a first touch with an end user. I agree with OP, if documentation is sloppy or inconsistent (I'm not saying the doc in question is because I haven't read it) it definitely reduces the impression that it's correct or reliable.
I've skipped even trying software because of poor documentation and so the response of:
I highly disagree. You are judging a book by it's cover. Capitalization is no different from handwriting. Substance matters, capitalization and grammar are superficial. If meaning is captured then capitalization does not intrinsically matter.
You are correct that people judge documentation off of grammar and punctuation. But this is not a rational or logical thing people do. But I can't blame you or others, I mean after all the world believes in religion, myths and other fantasmic spiritual things with no solid evidence as backing. It's normal. I just felt HN was above that. Guess I'm wrong.
>...seems shallow / callous.
Seems that way only because you're not thinking deep enough. Think carefully whether it is rational or logical to judge the works of say Einstein because he had a grammar error or bad handwriting. The two are completely orthogonal and that is the rational perspective.
Not to make a point of it either way, but judging a book by its cover can be useful if the credibility of the book's content alone is difficult to evaluate. That's why people care about degrees and other qualifications.
There are plenty of other ways. Book reviews for example. If the cover is the only way than so be it, but this is rarely case. Additionally the cover of a book, like capitalization is one of the most inaccurate metrics to judge a book by.
It doesn’t. I don’t know how something so simple can’t be understood. Does capitalization matter in math or algebra or logic? No. It doesn’t. Why? Because capitalization is a concept exclusive to language, and not just any language, but an arbitrary family of languages similar to English. The concept for example does not exist in Chinese.
Sure, but we program using programming languages, mostly using the Latin alphabet you are referring to. And yes the syntax for many of those programming languages is in fact case sensitive.
Obviously. The topic is about whether case sensitivity + capitalization matters not whether it exists. My claim is it doesn’t matter much. Whether you use I or i in your for loop as an index doesn’t matter.
And it’s completely irrelevant to logic or math. So whether or not you choose to make capitalization matter in your program is a completely arbitrary choice. It’s like snake case and cane case. You choose one style for consistency but in the end even if you use both styles in your program there is zero practical downside. The only downside is people with ocd get all worked up and don’t have the capacity to understand that it doesn’t matter.
All this for writing Rust as rust! Wow!
Tell me you have ADHD without telling me you have ADHD, just get on with the work and let others do their work. Don't flag their entire work. Linguistics is very inclusive. I took a course on it. No need to be a grammar nazi
The U.S. federal government is bad at redactions on purpose.
The offices responsible for redactions are usually in-house legal shops (e.g., an Office of Chief Counsel inside an agency like CBP) and the agency’s FOIA office. They’re often doing redactions manually in Adobe, which is slow, tedious, and error-prone. Because the process is error prone, the federal government gets multiple layers of review, justified (as DOJ lawyers regularly tell courts) by the need to “protect the information of innocent U.S. citizens.”
But the “bad at redactions” part isn’t an accident. It functions as a litigation tactic. Makes production slow, make FOIA responses slow, and then point to that slow, manual process as the reason the timeline has to be slow. The government could easily buy the kind of redaction tools that most law firms have used for decades. Purpose built redaction tools speed the work up and reduce mistakes. But the government doesn't buy those tools because faster, cleaner production benefits the requester.
The downside for the government is that every so often a judge gets fed up and orders a normal timeline. Then agencies go into panic mode and initiate an “all hands on deck.” Then you end up with untrained, non-attorney staff doing rushed redactions by hand in Adobe. Some of them can barely use a mouse. That’s when you see the classic technical failures: someone draws a black rectangle that looks like a redaction, instead of applying a real redaction that actually removes the underlying text.
This is an extremely interesting perspective. I haven't really heard it before, but I once worked for the state in a technical capacity and watched as they spent entire workdays and scheduled multiple meetings with the sole purpose of figuring out ways to slow down or narrow FOIA requests.
I didn't really know how they slept at night, but I don't know how a lot of people sleep at night. I only had to be involved because I had to do the actual trawling through the emails. They spent their time trying to narrow the keywords that I'd have to search, and trying to figure out new definitions of the words "related to."
There’s a great Australian comedy called Utopia about a government department that has a whole episode B-plot of the characters working on the Aussie equivalent of a FOIA request. It’s pretty funny and in the end one of the workers just finds it easier to leak the document to the requesting journalist rather than deal with the official process, even though it was mundane contract details on a carpark that came in ahead of schedule and under budget.
In another episode they’re trying to find out the length of a stealth submarine for construction planning purposes of a port or something, and they have to go through endless layers of security checks with the military that lead nowhere. In the end a reporter filming a documentary episode on the government agency tells them the length because they were allowed to film the submarine on another program.
Definitely recommend the show and my friends in government say it’s scarily accurate.
Imagine if society were a program and laws, policies and procedures were its codebase. The scary thing is that the way it gets patched in reality isn't very different from the way agentic LLMs perform on actual codebases today. Bug in this department? Delete it. People abuse this system? Add more friction for legitimate users. Society has a need? Greenfield a feature that works great but doesn't fit in with existing systems at all. This didn't used to be so on the nose. I can't decide if we should welcome our new robot overlords or even what is a reflection of who anymore.
No, there isn't an enormous cohort of bureaucrats going to work every day, collectively wringing their hands and saying "haha, we're going to be STUPID today!"
I buy the productivity argument, but I’m not convinced “30 minutes reading/tweaking agent output” is equivalent for learning to building it yourself.
If your goal is the feature, then yes: letting the agent do the heavy lifting and reviewing the diff afterward is a huge win.
But if your goal is understanding / skill-building, the hard part usually isn’t seeing a working solution. It’s doing the messy work of (a) making design choices, (b) getting stuck, (c) debugging, and (d) forming the mental model that lets you reproduce it later. Reviewing a correct implementation can create a feeling of “I get it,” but that feeling often doesn’t survive a blank file.
I’ve noticed this in my own hobby coding: LLMs are great for familiarity and unblocking progress, but the learning “sticks” much more when I’ve had to struggle through the failure modes myself. I’m watching the same dynamic play out with my son using ChatGPT to study for physics/calculus . . . it feels deep for him in the moment with the LLM, but exam-style transfer exposes the gaps.
If I had four hours to dedicate to this particular learning project I would still use LLMs to help me along the way, with the expectation that I'd learn more from those four hours than I would if I'd spent the same amount of time deliberately not using LLMs to help me.
We've been given a tool that lets us ask questions in human language and get back answers that are correct 90% of the time! And that remaining 10% means we have to engage critically with those answers, which is a useful learning trick in its own right.
Learn more if you tried to figure it out yourself for 3 hours then used the LLM for the last hour to unblock/check your work? Or learn more by utilizing LLM for help the whole four hours?
My own experience is what I learn from an LLM sticks better if I take the former approach.
Depends on the task and my goals. If it was something new to me that I wanted to learn really deeply - and I had the four hours to spend - I might try the LLM-free route for the first three hours like you suggest.
If I found myself needing to do anything unrelated to the learning task, like knock out a quick Bash script, I'd still call on the LLM to get me out of that and help me stay focused on the new skill though.
Your workday isn’t a monolith; it is a series of tiny tasks. Try deconstructing your job to identify intrinsic motivation.
Which micro-tasks do you look forward to? Which raise questions you think about and work on in your free time?
Which tasks do you avoid, put off, or find immediately draining?
If you can’t identify interesting tasks, you are likely looking at too high a level of abstraction. Break “working with clients” down until you find the specific unit of work (e.g., “debugging edge cases” vs. “proofreading emails”) that sparks interest.
After sorting tasks into intrinsically motivating or not, look for a role that involves about 20% more time on the interesting micro-tasks and 20% less on the boring ones. If you do this every few years, you drift toward a career you enjoy without needing a radical “reset.”
This approach led me down an unexpected path: law firm attorney -> government attorney -> regulatory consultant -> small-business operator. Now, I am looking at moving to a role that involves at least 20% more time on software development (intrinsically interesting to me) and 20% less time chasing unreliable people (particularly draining to me). I never set out to change my “identity,” but focusing on the micro-tasks I actually enjoy has allowed me to engineer a career I enjoy on a day-to-day basis.
reply