We have a service at work which categorizes internal documents and logs, then triggers some automation depending on the category. It processes maybe 100 per day. Previously we only used some combination of metadata, regex, and NLP to categorize. Now a call to a LLM is part of that service. We save a lot of manual time where we used to have to resolve unknown documents. The LLM can help fill out missing data, too. It's all stored as annotations so it's clear who/what edited the data.
Granted this is a pretty simple task and a low stakes scenario, but I don't think we should limit ourselves to assuming AI will always only be dev tooling.
I used Btrfs for a few years but switched away a couple years ago. I also had one or two incidents with Btrfs where some weirdness happened, but I was able to recover everything in the end. Overall I liked the flexibility of Btrfs, but mostly I found it too slow.
I use ZFS on Arch Linux and overall have had no problems with it so far. There's more customization and methods to optimize performance. My one suggestion is to do a lot of research and testing with ZFS. There is a bit of a learning curve, but it's been worth the switch for me.
Kudos for one of the most relatable descriptions of C++ I've read.
I did a couple years writing C/C++ professionally, and I hope to not go back to that. Too many hours debugging other people's code, suffering vague integration issues, and just trying to get the build system spaghetti to run.
I have fond memories of reading this book as a teenager. I was watching an introduction to computer science course online. I think maybe from Yale or MIT, and the professor recommended Hacker's Delight. It was a beginner class teaching C, and I mostly only had experience with BASIC.
Back then I barely understood binary, and pointers completely confused me. I remember most of the book feeling like a collection of magic tricks. Sometimes I pull it out to rekindle that sense of wonder.
I think it is completely worth it to learn the Vim editing commands. You can get a lot of the benefits from just turning on Vim-mode in VSCode or IntelliJ. Emacs with Evil mode is an improvement in my opinion as well. The quick line editing, moving around the file, etc etc smooth out your programming experience a lot.
If you're working a lot with text, Vim macros are great. I'll regularly go into Vim as kind of a text workbench.
If you want to try an auto-updating Vim suite, check out LazyVim [0]. The defaults are great, and there's a lot of features with absolutely zero configuration.
Yes unfortunately. There are TikTok "challenges" go slap your teacher for example. Similar to the "challenges" where you should eat a spoon of cinnamon, eat a Tide pod, etc. There's an air of do this and film it for clout. Most kids roll their eyes as well of course, but there are people who follow along.
The side-by-side view in that article is the key user experience reason to leave. The Fandom wiki sites tend to be slow and covered in ads. I avoid them if possible. I'm glad to see more and more groups take their wikis back.
The Runescape wikis left Fandom a few years ago. The improvement to quality and features has been massive. I'm not sure how much traffic the Minecraft wiki gets, but the Runescape wikis got over a billion page views in 2021 [1]. These are not insignificant losses for Fandom.
I agree with this method. In high school I tracked what I did every hour for 3 months. Probably over the top, but seeing the hours add up of watching TV--or just killing time--was what I needed. All these years later that exercise stays with me.
The trick for me was to only be able to see one day at a time until the end of the month. I would record a day and think "I'll do better tomorrow." Only to realize that today is always yesterday's tomorrow.
When I was working at Ford a few years ago, many Ford engineers worked very closely with Argo engineers. Sharing code or data was common, they used our internal tools, and sometimes we would go in-person to troubleshoot with them. A lot of their employees had come from Ford, and so they knew who to call and even already had our numbers.
All that to say I'm not surprised to see they hired back many of those people. Ford is a large company and Argo felt just like any other team within the company at times.
I've been using Lisp for hobby projects for a few years. Yes the syntax takes some time, but
> I feel like if I used it, it would atrophy my skills in other more traditional languages.
was not the case for me at all. If you go into a text editor and remove all the parentheses, I find that's how Lisp programmers tend to see Lisp, (function argument) isn't that far from function(argument).
Learning Lisp has only improved my skills as a programmer, after getting ideas like code as data, macros, let over lambda, CLOS and the metaobject protocol. It's a simple model that to me shows how other languages have picked an abstraction and stuck with it, but Lisp has all the tools to implement those abstractions and more.
More mainstream languages are great at focusing the developer, and that makes them very practical. It is amusing though to watch many of the "new features" in languages come out even though Lisp had them years ago.
I'm also interested in something like this. I've been considering writing one because I already start most projects with djangobuilder.io, which generates a project, models, and test skeleton. I've found that very useful when I have a lot of models.
I can second this one. Not necessarily your personal time but at least once your assigned work is on track or completed. Not rare to hear people say "this past weekend I was playing around..." though.
If you have a good idea for a feature, product, or a new system to improve your team, it's unlikely there will be time in the schedule for it. In my experience you spend your extra time playing around, show it off, and wait for a decision maker to take interest.
Like the original comment said, I've personally never seen someone be assigned time to innovate from scratch. Once a POC already exists folks jump on the bandwagon though.
My usual first steps are to read the title, the abstract, and the figures/tables, in that order. Pause there and mentally summarize what I just read. If there are terms I didn't know or I'm not familiar with the topic, then I go through the introduction parts of the paper. After that I read the discussion sections and conclusions. I usually skip the methods sections and read those last only if needed.
All during that I try to keep track of questions I have or claims the authors are making. Once I've gone through a lot of the paper, I go back and look for answers to my questions. Interrogate the paper until you are convinced.
I remember being younger and getting stressed about reading papers. So I want to add that not all paper are well written. Don't worry if you're struggling. It's not easy in the beginning and the papers themselves aren't perfect. Keep working at it because it does get easier!
End to end tests mostly. Those were kept static throughout the process as a baseline and for benchmarking. That let us have simple metrics like "test 1 had a 100x speed up" and "test 3 took a way too long to finish before the rewrite."
Any unit tests got rewritten along with the test's relevant code. Now that we are sticking with this Go based solution, adding more unit and regression feels more reasonable now.
I have embraced this workflow completely. I used to be more concerned about which language, but now I find I much more useful to just start immediately in Python. I spend most of the time working out the kinks and edge cases, instead of memory management or other logistics. Maybe ~75% of the time, that's it, no need for further improvement.
Recently I chose to rewrite several thousands of lines of Python in Go, because we needed more speed and improved concurrency. Already having a working program and tests in Python was great. After figuring out a few Go-isms, it was a quick couple of days to port it all for big improvements.
A group of researchers published a paper on this topic, "Energy Efficiency across Programming Languages" [0]. They have tables listing the relative energy usage and memory consumption.
It's just one paper of course, but the energy results weren't too surprising. C was the baseline. C++, Rust, and Java close behind. Languages like C# and Go near the middle, and then Python, Ruby, and Perl at the bottom for most energy used.
Granted this is a pretty simple task and a low stakes scenario, but I don't think we should limit ourselves to assuming AI will always only be dev tooling.