5
points
goostavos
Joined 5,472 karma
Software engineer and overall pretty swell guy.
Checkout my book! https://www.manning.com/books/data-oriented-programming-in-java
chriskiehl.com
- goostavos parentIf the only reason you write is as a means to and end, sure. Inevitable. If you pursue it as a craft then the struggle and imperfections are part of the process. LLM usage would sand away those wonderful flaws.
- Oh, hey -- you're that guy. I learned a lot of what I know about TLA from your writings ^_^
Consider my behavior changed. I thought the "high school math" was an encouraging way to sell it (i.e. "if you can get past the syntax and new way of thinking, the 'math' is ultimately straight forward"), but I can see your point, and how the perception would be poor when they hit that initial wall.
- I find the same. Even those who are interested in it in theory hit a pretty unforgiving wall when they try to put it in practice. Learning TLA+ is way harder than leaning another programming language. I failed repeatedly while trying to "program" via PlusCal. To use TLA you have to (re)learn some high-school math and you have to learn to use that math to think abstractly. It takes time and a lot (a lot!) of effort.
Now is a great time to dive in, though. LLMs take a lot of the syntactical pain out of the learning experience. Hallucinations are annoying, but you can formally prove they're wrong with the model checker ^_^
I think it's going to be a learn these tools or fall behind thing in the age of AI.
- Fictional, but it captures something about work and life in that unique way that art is supposed to.
One of my favorite scenes:
Peggy: "You never say thank you!" Don: "That's what the money is for!"
It captures a lot of the mismatch in perspective between employer/employee boss/subordinate. You're there to do something for someone who is paying you to do it. That's as far as it goes (despite the constant human pull to perceive it as more).
- FWIW, even with the "simple explanation," I'll echo OP's statement that the README doesn't really explain what it is or what it's solving. "Generates new versions of the structures" might mean something really clear to you, but even the phrase "data modeling" is enough to trigger lots of conflicting baggage in my head. Also: it took awhile it realize it's for Scala. I initially assumed this was a Smithy-like competitor.
It looks neat (once I found your docs)! Show what it is and what it solves in your README! The structural inheritance is slick.
- It destroys the value of code review and wastes the reviewers time.
Code review is one of the places where experience is transferred. It is disheartening to leave thoughtful comments and have them met with "I duno. I just had [AI] do it."
If all you do is 'review' the output of your prompting before cutting a CR, I'd prefer you just send the prompt.
- One of the surprising things about working inside of $MegaCorp is that if you knock on enough doors, you'll eventually find that each org has, like, one dude* with a spread sheet that powers everything else. Teams will get spun up to try to "automate" this spreadsheet, but, on a long enough time horizon, the spreadsheet wins.
- I don't think you can capture the complexity of the world with a single variable. I'm at Amazon. We all make about the same. Some more than me. Some less. However, while I don't have to worry about changing jobs, or _not_ having a job (for awhile), they do. They're working with an entirely different set of pressures and constraints.
For me, I can hop ship, decide I don't like it, boomerang back or take some time off no worse for the wear. That level of autonomy doesn't exist when you've got 60 days to land a job or uproot the life you've been building. Salary is a minor part of the picture. If changing jobs is a gamble that might end in "leave the country," the employer gets a certain kind of "loyalty" that salary cannot buy.
- I similarly half-joke about the same thing. Being "replaced by AI" would be the kick in the pants to finally make a run of it.
In Seattle, I feel like I could get really far on a dumb, single-issue platform: "I will fix the potholes on 1st ave." I won't talk about anything except that. I'll only try to accomplish that. And then I'll leave.
- I similarly got this lesson early in my career. One of my first jobs. I was young and excited to be at a startup. Learning a ton. I poured hours into that job. Then, one day we were pulled onto a call, told they couldn't afford us any more, and fired on the spot. We were immediately locked out of everything and that was that.
It was shocking at the time. To young me, it was a big "....oh" kind of realization about what kind of relationship you can/should have with any kind of business.
Now, I'm here cause you pay me. I don't keep stuff at my desk or decorate 'my' space. I show up, do the job, and leave. Once I close this laptop, work is dead to me until the next day.
I'd be lying if I said I didn't occasionally work more than 40hr/week, but most of the time my work/life balance is fantastic by choice.
- I think it goes beyond that.
TLA+ requires you to think about problems very differently. It is very much not programming.
It took me a long time (and many false starts) to be able to think in TLA. To quote Lamport, the real challenge of TLA+ is learning to think abstractly.
To that, I think plusCal and the teaching materials around it do a disservice to TLA. The familiar syntax hides the wildly different semantics
- I work at a FANG. Senior SDE. I don't have slack on my phone. I don't read emails (unless someone tells me out of band that one needs a response). Once I close this laptop work is dead to me until the following day.
You pick and choose your own involvement. I'm "passionate" about the job. I consider it a craft and a lifelong pursuit. I'm writing a book on the topic. But the job is just a job. I'm here because they give me money. That's where my obligation ends. I do have to do oncall rotations, and it sucks, but I mark that up to "what the money is for."
My only point being, one of these rants makes it to the front page every few months. "Unionize" gets thrown around. People complain as though it must be done. I've only worked 2 legit 80 weeks in my life. I decided I didn't like it, so I stopped doing it.
That means I cannot compete inside of this place with the people that work non-stop, live on slack, and devote their lives to their job. And that's OK. They can have the Top Tier rating and the salary that comes with it. I prefer to just make my little slice of the world good during the hours that I'm paid to do it. Then I go do something else.
Balance is a choice.
- Sandy Maguire wrote a fantastic book on the topic: https://leanpub.com/algebra-driven-design
You can also checkout the work of Conal Elliott: http://conal.net/
- 8 points
- I think it's something people keep rediscovering. It's a pretty fun programming problem that lets you explore lots of different domains at the same time (video processing, color theory, different coordinate systems for visualizing things) and you get a tangible "cool" piece of art at the end of your effort.
I built one of these back in the day. Part of the fun was seeing how fast I could make the pipeline. Once I realized that FFMPEG could read arbitrary byte ranges directly from S3, I went full ham into throwing machines at the problem. I could crunch through a 4 hour movie in a few seconds by distributing the scene extraction over an army lambdas (while staying in the free tier!). Ditto for color extraction and presentation. Lots of fun was had.
- I'd argue it has less to do with the "capitalist systems" and more to do with how obnoxious "slugging" sounds. Commuting in your own car guarantees (a) you have a ride and (b) you have flexibility. You can change you plans, stop by the store, run errands, anything your heart desires (plus, not deal with strangers everyday. Ugh.)
This isn't a pro-car thing. I've haven't driven a car to work in 8 years (I pay out the ass to live downtown so that I'm close enough to walk / bike). It just seems like "Well, that sounds like a pain in the ass" is a simpler possible explanation to why slugging isn't popular in the US compared to Big Business not wanting it to be.
- Hard disagree. I think a huge part of our job as engineers is to build systems that can outlive us and comfortably change hands (without the next team cursing the former).
Maybe this is born from spending so many years in Amazon (with it's high turn over and near-quarterly re-org shuffling), but what's getting called "replaceable" here I'd call "writing maintainable software."
The goal is to get knowledge out of your head and into the codebase so everyone can reap the benefits. Knowledge hoarding is lame.