AskHN Digest

1. Ask HN: What was your most humbling learning moment?

Top comment by hu3

Learning that some folks can produce so much value with crappy code.

I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control. Some of these projects were so late in their deadlines that had to be cancelled.

And then I've seen one man projects copy pasting spaghetti code around like there's no tomorrow that had a working system within 1/10th of the budget.

Now I admire those who can just produce value without worrying too much about what's under the hood. Very important mindset for most startups. And a very humbling realization.

2. Ask HN: Machine learning engineers, what do you do at work?

Top comment by schmookeeg

Getting my models dunked on by people who can't open MS Outlook more than 3 tries out of 5, however, have a remarkable depth and insight into their chosen domain of expertise. It's rather humbling.

Collaborating with nontechnical people is oddly my favorite part of doing MLE work right now. It wasn't the case when I did basic web/db stuff. They see me as a magician. I see them as voodoo priests and priestesses. When we get something trained up and forecasting that we both like, it's super fulfilling. I think for both sides.

Most of my modeling is healthcare related. I tease insights out of a monstrous data lake of claims, Rx, doctor notes, vital signs, diagnostic imagery, etc. What is also monstrous is how accessible this information is. HIPAA my left foot.

Since you seemed to be asking about the temporal realities, it's about 3 hours of meetings a week, probably another 3 doing task grooming/preparatory stuff, fixing some ETL problem, or doing a one-off query for the business, the rest is swimming around in the data trying to find a slight edge to forecast something that surprised us for a $million or two using our historical snapshots. It's like playing wheres waldo with math. And the waldo scene ends up being about 50TB or so in size. :D

3. Ask HN: How to handle a senior hire turning out to be junior?

Top comment by UseofWeapons1

As you consider the decision to let them go, consider the impact on other people in your work place too. Other developers notice someone like that underperforming and getting overpaid, and it can hurt the good climate you aim for. It may feel bad to fire them, but it may be worse to keep them.

4. Ask HN: 30y After 'On Lisp', PAIP etc., Is Lisp Still "Beating the Averages"?

Top comment by alexdowad

There are lots of interesting ideas to be found in the Lisp/Scheme family. A Lisp can be an excellent choice of primary dev language, especially for a dev shop which puts enough investment into training and tooling.

At the same time, the state of the art in programming languages has advanced since PG wrote those essays. Even many of the languages which he was presumably referring to as "Blub" are much better now than they were.

A bigger issue is: As one gets better and better at computer programming, at some point the specific implementation language starts to matter less and less. (It never completely ceases to matter; but, less and less.) In one of his essays, PG contrasts "applying Bayesian filtering" with "applying if statements", which describes the matter quite aptly. At some point, language constructs such as "if statements" really do melt away.

For this reason, I reject claims that using a certain programming language will make one "1000 times more productive" (or similar) out of hand. The big problems in software are not at the level of the language at all.

This may sound false to newer programmers who have just discovered a fantastic programming language which allows them to work much faster than they could before. To such ones: I've been in your shoes. I've tried many languages, perhaps even the one you are enamoured with now. The benefits don't scale indefinitely. At some point, as you apply your fantastic new language to bigger problems, you will find yourself wrestling with the same issues as you used to with your old language, perhaps in a different form.

5. Ask HN: Going low-level – what to learn next?

Top comment by sshine

If you want to "go low" in the operating system, you could write a Linux kernel module:

https://sysprog21.github.io/lkmpg/

https://blog.sourcerer.io/writing-a-simple-linux-kernel-modu...

If you want to "go low" in the way hardware works, you could try and write an interrupt handler on an embedded device.

If you want to "go low" in how optimizations work in application development, you could try and implement microbenchmarks and look at flamegraphs.

https://github.com/brendangregg/FlameGraph

https://bheisler.github.io/criterion.rs/book/index.html

6. Ask HN: Anyone left their job because of RTO?

Top comment by wavemode

Company wanted me to not only return to office, but also move to the west coast. Leaving was a no-brainer.

But the job market is really shit. In the past I've left jobs and got new offers in a week. This time around I was out of work for almost three months.

7. Ask HN: The Required Fundamentals for Self-Taught Programming

Top comment by aeonik

If you really want to learn programming.

1. Buy SICP and put it on your book shelf.

2. Don't read it, instead read random StackOverflow posts talking about the content.

3. Spend the next 10-50 years trying to understand what people are talking about on various related forums.

4. Add more legendary books to your shelf over these 10 years, like The Art of Computer Programming. Fawn over their greatness. DON'T READ THEM.

5. Go on long walks, take spirit journeys to harsh natural locations, put your life in danger while you meditate on the concepts.

6. Blog profusely about your experiences.

7. Optional: actually write code.

8. Ask HN: How do you personally stay fit?

Top comment by gnulinux996

Fridge is always empty. Want snacks? Too bad, only water available, nothing you can do at 2AM

24/7 gym open so I have no excuses No alcohol, only espressos. No snacks, only lunch + maybe dinner, sometimes meat, if there are sugar cravings only honey on rice cakes.

Lost 22 kilos since October with 7 more to go, everything is so sweet to me at this stage and I have no need for sugar.

Most significant life improvement I have ever had, even better than using vim + tmux

9. Ask HN: Anyone just say "no" to leetcode interviews at this point?

Top comment by dekhn

I'm not opposed to leetcode questions, but if a junior engineer asks me a question literally from leetcode without changing the test details (IE, they just copy/pasted from the site instead of coming up with something slightly different), I exit the interview and email the CEO with an explanation (I'm very senior, so it makes sense to go straight the CEO).

Because of this, I have instead written my own interview questions that I administer. You won't find them in leetcode, and they're not particularly challenging- and it still filters out many terrible candidates.

10. Ask HN: If you are starting in 2024, what is the most productive solo dev stack?

Top comment by yodon

An under-appreciated advantage of single-devs is ease of refactoring.

In the time it takes a big team to schedule a pre-meeting for discussing changing a schema, solo-devs can whip through many huge cross-cutting refactors across their entire architecture without anyone complaining about broken merges.

Building a real, successful thing generally involves more time and more learning about the customer space than you expect at the outset. As a single dev, you have a massive advantage over big teams in your ability to make huge fast change in the architecture of your product.

Here's the controversial part of this: if you want to maximize your ability to make big changes, you want a strongly-typed codebase (for me that's TypeScript on the front-end and C# on the backend because of the quality of the refactoring tooling for it). There's no formal guarantee that strong typing will keep your code working across big refactorings, but in practice it just works. You focus on getting the inner loops right and the compiler and IDE takes care of the rest.

Yes, you can probably write the first iteration faster in a dynamically typed language, but when you start making those big changes that are your unfair competitive advantage against larger teams, the strong typing combined with modern IDE tooling capabilities means a working system remains a working system even as you treat it like completely malleable clay.

I'm also a fan of modular monoliths, again for ease of major refactoring (if you're not familiar with it, check out for example TurboRepo in the node.js space). You can organize an enormous amount of code well using this technique, including having things partitioned to hand off to other devs or multiple teams if you happen to eventually want to scale up from single dev to multi-dev.