HackerTrans
TopNewTrendsCommentsPastAskShowJobs

madmax108

no profile record

Submissions

64,000 Lines of Nothing

lifeofnav.in
4 points·by madmax108·22 dagen geleden·0 comments

Terragrunt is dead: Multi-state transactions killed run-all

stategraph.com
2 points·by madmax108·2 maanden geleden·0 comments

Dome Systems – A system of control for AI agents

domesystems.ai
1 points·by madmax108·3 maanden geleden·0 comments

Gen AI Video – Building a Scalable Validation Framework

blog.hotstar.com
1 points·by madmax108·5 maanden geleden·0 comments

Online RL for Cursor Tab

cursor.com
1 points·by madmax108·10 maanden geleden·0 comments

comments

madmax108
·3 jaar geleden·discuss
The solution is quite evident is it not? Regulatory bodies to set response latency and limits with over-life degradation as an additional parameter.

Only reason "they’re just being asked to turn lead into gold and often get silver." happens is because automakers know they can get past all regulatory approval with lead/silver or whatever metal you prefer.
madmax108
·4 jaar geleden·discuss
https://m.imdb.com/title/tt0479879 <- This is the one.

"Chasing Ghosts: Beyond the Arcade

1982's Video Game World Champions share their philosophies on joysticks, groupies and life."
madmax108
·4 jaar geleden·discuss
"My opinion is that Jira reflects the organisation that manages it."

Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).

Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!

On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.

Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
madmax108
·5 jaar geleden·discuss
LOL, this reminds of an episode of Mythic Quest where the lead engineer (Poppy) imagines "real-time, persistent, globally-reflected environment changes" for the MMO they built, gets told that it's unfeasible by the entire dev team, mows ahead anyway and ends up with a disastrous demo at the end when the system basically collapses on itself.

Funny how reel-life and real-life collide into each other! :D

---

As an aside, after Ted Lasso (which gets all the well-deserved hype), Mythic Quest is a great trope-filled show esp. for anyone who's worked in tech in general (and game dev specifically).
madmax108
·5 jaar geleden·discuss
Some of these are great tips and I agree wholeheartedly.

However, in personal experience, I've found that this works much better with more experienced developers rather than with junior engineers. Why? Because for some reason, a lot of junior engineers have been pavlov-ed into thinking every interview is for something at Google/Facebook scale (no matter where they are interviewing) and they start describing extremely convoluted designs using tech that they are also not completely familiar with just because they want to come across as knowledgeable.

Something that I struggle with in these cases is reining in the dev back to the "what" rather than the "how", because I've seen even good engineers go into this "let's add a system-bus for everything" way of thinking. Constraining problems explicitly tends to devolve into the "Interviewer-Interviewee information asymmetry" which is the same with most DSA problems (At least with DSA, most constraints are known by both parties).

On the other hand, almost every time I've picked an actual problem we have with a system, be it a bug or a new product or something else, as an interview question with an experienced interviewee, I feel like I've come out understanding the problem space AND solution space better just through the process of discussion and in multiple cases, actually ended up using a lot of ideas from these discussions, so interviewing feels much more "natural" and a "dominant strategy" in game theoretic sense.