HN user

avilay

117 karma
Posts15
Comments46
View on HN
Making 3 hours ago

I have been grappling with a similar sentiment for a while now. I hate to think of myself as a Luddite, but I love the act of writing code. A blank VS Code in front of me is a beautiful sight full of wonder and possibilities :-) Here is how I rationalize the two - the pride and satisfaction I get from my work depends on how much effort I put in applying some previously acquired specialist knowledge, which itself took some decent amount of effort to acquire. This is why a beginner programmer is just as proud of their temperature convertor as a professional distributed systems engineer of their new 2PC module.

A quote that I read somewhere, possibly by Naval Ravikant, strikes at the heart of this - "a creation without a (human) creator is meaningless".

Neither the Github nor the HF repos have anything on the XiaomiRobotics-1 model or datasets :-( They have a bunch of assets (datasets, code, model, etc.) for XiaomiRobotics-0 however, but I don't know much about that family of models.

Sad to learn that future generations of programmers won’t benefit from learning from him directly. I took his SICP course a couple of years ago after numerous failed attempts at reading the book and even watching the MIT videos. David’s course was the first time the concepts really clicked.

For sure, any task or activity that is hard enough and just outside our reach, can get us into flow state. The trick is in ensuring that it is the right kind of hard, it is not too hard, and we time box the activity/task. If you think of how to beat the boss fight in a video game even when you are not playing it, it is the "right kind of hard". For me, beating the boss fights in Elden Ring were too hard, never got into flow state in that game :-)

Debugging can be super fun as we eliminate possibilities and it feels like we are converging to a solution. There have been instances where Claude (Opus family) was not able to effectively debug and I had to step in and do it. But debugging an over-engineered library for example, can become very wearisome. This is when I am really thankful for having Claude Code, it is able to figure out the bug and its fix/workaround pretty fast. I can then get back to doing my main task instead of spending an indefinite amount of time stepping through sloppily written code.

Ok here are the flow related links. This was about 1.5 years ago when I was trying to figure out burnout and it turned out flow (or lack thereof) was closely related.

  * https://youtu.be/VbUFMYs0kXQ?si=xiNw4ZFlla8k-p7w  The person who gives this talk (Rian Doris) has a good newsletter that I still read. I just checked their website and it has gone in full commercial mode, so YMMV.

  * https://www.ted.com/talks/elizabeth_gilbert_your_elusive_creative_genius

  * https://www.amazon.com/dp/0465074871

  * https://www.betterup.com/blog/meaning-of-personal-values

Not being able to enter flow state is a very interesting observation. I've felt it too to the extent that I went down a whole new rabbit hole of what it means to be in flow state. Let me know if anybody here wants to know more, happy to post some links.

To answer your question - I discuss the approach with Claude Code (e.g., should I implement my own ACT model in JAX or PyTorch, Python or Rust or Julia, etc.). Then write the initial part of the code myself. Opening up a blank vscode is a simple joy of life I refuse to give up :-) I'll ask Claude for advice if I get stuck, it will helpfully offer to write that code for me, I obstinately decline. Eventually, I'll get bored of some minutiae or other, at which point I'll ask Claude to complete just that part of it.

Om 26 days ago

Reminds of this couplet by Kabir (https://en.wikipedia.org/wiki/Kabir):

जब हम पैदा हुये तो जग हँसे हम रोये,

ऐसी करनी कर चलो, हम हँसे, जग रोये।

Translation: When you were born, you cried while the world rejoiced;

Live such a life that when you depart, you smile while the world weeps.

The author does explain his reasons for not using LeRobot in the post - although "I also use LeRobot for training and running baseline policies, and the vendor SDKs for the hardware.")

Ah! That is exactly what I use it for as well :-)

I am liking the SO101 - teleop and robot both work great. For sure, it is very easy to get started with. I was able to collect around 50 demos with them and train my first ACT policy within days of setting up the robots. Happy to share more detailed learnings from this if/when you get started with it. https://github.com/avilay/learn-robotics

Two things semi-parallelly:

  * Robotics Hello World: Objective is to implement ACT model to train my arm robot on simple pick-and-place tasks. Leaning heavily on HuggingFace's LeRobot library, but stopping short of using their model implementation and training loop. https://github.com/avilay/learn-robotics

  * Designing a new programming language: This is when I want to escape the annoyances of coding in Python and start daydreaming about a new language :-) https://github.com/avilay/kulfi
It's death 1 month ago

Can a kind soul write down their interpretation of the story? I didn't quite get it.

[Edit]: Thanks for all the explanations!

The point about papercuts adding up so resonates with me! I loved Zed initially and did find it more responsive than VS Code, loved the Zed Agent autocomplete, etc. However, I eventually and reluctantly went back to VS Code. The papercut that finally did it for me was [this open bug](https://github.com/zed-industries/zed/issues/36516) because of which I was not able to step into a packaged library's code when I was debugging my own code, this was in Python.

The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.

Totally agree with this! Being "kindly honest" is way better than being "brutally honest". Being honest and direct is important of course. I have often found that delivering constructive criticism in the so-called sandwich manner often obfuscates the message, so delivering it directly is much better. However, being kind to the receiver of the feedback by having empathy for them and supporting them as they process that feedback will help land that message far more effectively than being "brutal" about it.

This hit a nerve as I am in the middle of developing a webapp for myself using NiceGUI. I find CSS, especially its layout framework, pretty confusing and sometimes downright intimidating to work with. `inline`, `block`, `flex`, `grid` seem reasonable when you read about them. But when using it, especially within frameworks when flexboxes are nested within grids which are nested within flexboxes and so on, it becomes hard to reason about. And then you throw in media-queries in the mix and it becomes even more dense.

Lots of nostalgia in this thread. However, I recently started playing around with IBM's quantum computer cloud service and it has been by far the best experience compared to other players. Who knows, that might be their come back story!

Cool, thanks for the response. Yes, I do find that the PyTorch tutorials on distributed training are a work-in-progress.

I was thinking of starting with a basic implementation of the original paper by Jeff Dean, et. al. on synchronized data parallelism, implement basic model parallelism, explain why async parallelism works, do a simple implementation of HOGWILD!, and finally do "hello world" training using existing distributed training systems like Horovod, Distributed PyTorch, RayLib, Microsoft DeepSpeed, etc.

Does anybody else think this is in response to Apple's privacy crackdown on third party tracking data? If you buy on Buy, then you are still first party for Google and they can still get your signals.

And given that a majority of "Ex-Google" engineers are males, where does that leave a woman (or any under-represented group) founder?

She is not asking for money "just because" she is a woman. She is asking for a fair chance. And we need to give folks from under-represented communities a more than fair chance to combat inherent selection bias.

Even if her business idea was bad, or her app didn't have traction, or her LI profile was not impressive enough, she deserved, at the very least, the following:

  * Access to VCs, she had to use her husband's email to get access.
  * Some constructive and personalized feedback. This does not have to be very detailed, a couple of no-BS sentences will do the trick.
I get that VCs are too busy to respond to each and every email they get, but they, and every one of us in the tech sector who is in a position to do so, needs to walk the extra mile to pull in people from under-represented communities who are trying to get in.

What do folks here think of Panda3D (https://www.panda3d.org)?

Its just a game engine without any IDE. So the typical workflow would be to build your assets and scene in Blender (or Maya, etc.) and then code up the game mechanics in Python or C++. I am tinkering with it for non-gaming (Reinforcement Learning) use cases and I was curious what game devs think of it.

That was a pretty cool video! I loved how he used 3D Monte-Carlo and side-stepped all the complicated math. I wonder if he was using a Physics engine like Bullet or ODE to calculate the simulated trajectories. Also, a good intermediate step might've been to build the backboard in something like Unity and shoot some hoops to catch the radius error before actually machining it out.

Spurred by a post on AskHN about a dev who has "fallen out of love" with programming, I wrote down my thoughts on being on the IC path as opposed to the management path. Would love to know your experiences around this issue.

A lot of good advice here, adding my recipe for avoiding burnout (~15yrs into my career):

Delineate between not enjoying your job vs. not enjoying your profession. Sometimes getting a new job in a better work environment and especially with a better manager helps immensely.

Get a new job that is adjacent to software, like technical program management, sales engineer, developer evangelism, etc. Here you can still leverage your extensive programming experience but not have to code. For me - I quickly re-discovered my love for programming.

Treat your employer like your customer. This lets you side-step all the petty office politics, the rat race for the next promotion, etc. which are big contributors to stress-related burnout. Your customer is paying a fair market value for your services - the day that does not hold true, you part ways. No hard feelings.