This is such a strange take. Your words remind me of past crypto hype cycles, where people pushed web3.0 and NFT FOMO hysteria.
Engineering is
the practical application of science and mathematics to solve problems. It sounds like you're maybe describing construction management instead. I'm not denying that there's value here, but what you're espousing seems divorced from reality. Good luck vibecoding a nontrivial actuarial model, then having it to pass the laundry list of reviews and having large firms actually pick it up.
> This is such a strange take. Your words remind me of past crypto hype cycles, where people pushed web3.0 and NFT FOMO hysteria.
Thats a little harsh. I think most everyone would agree we're in a transformative time for engineering. Sure theres hype, but the adoption in our profession (assuming you're an engineer) isn't waning.
I wonder if we'll reach a breaking point with public forges, where they'll simply reject hosting a repo if it isn't from someone with a vetted background or if it detects hallmarks of LLM slop (e.g., many commits over a short period of time or other LLM tells).
GitHub recently added new repository settings to turn off pull requests or limit them to approved contributors. The announcement doesn't mention AI agents, but that's certain relevant.
GH also needs to find a way to stop AI scraping of IP.
(Or not. It might be lucrative to host some novel algorithm on GH under a license permitting its use in generative LLM results, at a reasonable per-impression fee.)
I think there'll be space for curated forges at some point but they're going to live on the margins like most self-hosted repos do.
You could solve it with tech by using ideas from radicle and tangled but the slop is ultimately a social problem, so you just have invite-only forges where the source of the invite is also held accountable (lobsters style).
If you want a high quality internet experience these days you have to step out of the mainstream.
I think that AI will do the vetting of repos - just as humans do that now. Perhaps AI will do a better job. The only way we're gonna fight AI slop is with AI.
I've been a software engineer for over 15 years, working on everything from APIs and financial models to data pipelines and firmware. Beyond the technical stuff, I’ve led small, tightly-knit teams, managed projects, mentored and advocated for colleagues, and spent a lot of time communicating technical concepts to folks who aren't as tech-savvy.
Now that I'm authorized to work for any U.S. employer, I'm hoping to pivot to a smaller company where I can make a stronger impact. I'm open to any field, but particularly drawn to life sciences. It's been an area of interest for me ever since going through a bioinformatics algorithms textbook cover-to-cover, and the hope is that I can continue learning about the life sciences space while providing value with my existing skill set. Like many on HN, I have a heartfelt drive for learning, whether through books, courses, shadowing experts in the field, or jumping head-first into unfamiliar situations.
If you're doing anything in biopharma, computational biology, medical devices, synthetic biology, or anything along those lines, by all means please drop me an email. If you're working in some other unrelated field, still don't hesitate to reach out — I'm always interested to know what folks are working on and if I'd be able to help move things along in any way.
I program in modern C++ as well (C++23). I disagree with both "very safe" and "fun". Even with 23 there are an innumerable number of footguns throughout both the language and the standard library. Debugging code is also a mess. Good luck getting anything done without paying for an IDE, and even then it can be a struggle.
Of all the languages I use C/C++ have the least need for paid tools.
I use emacs(and vim), make and Boost's b2 build system for most of my programming. Although on Windows, Visual Studio is a joy to use. On Linux I use gdb. Works fine. I also use static analysers and valgrind. But I come from a tradition of Unix and living on the command line.
I've tried CLion, because I pay for IntelliJ IDEA for other programming (I also have to write Javascript, and Python) But while its nice, there is nothing there that I couldn't do without.
If you stick to C++ standard libraries, Boost, and turn on all warnings, and are reasonably competent, you won't encounter any bugs that are so serious that your program crashes inexplicably.
I took a crack at explaining the Viterbi algorithm after learning about HMMs from a bioinformatics book I was reading. You may find it helpful, but that's assuming my interpretation of it is correct.
I thought about this and we have a backup problems in place if they don't feel comfortable sharing. The context will be the same, both the candidate and the team member will be working as equals to address the problem. Although, in this case, the team member is already familiar with the problem.
I would love to see data comparing reluctance to go (back) to the office versus things like commuting mode of transportation (walking, cycling, transit, commuter rail, driving) and/or commute time.
> Car commuters miss commuting the least: 55% of this group do not miss it at all. Commuters by (e-)bicycle are the group who miss commuting the most, with 91% missing at least some aspects of commuting. As might be expected, the feeling of missing commuting also decreases with increasing commute duration (Fig. 5).
> The connection between work and commuting is evident in the relationship between missing commuting and the intention to work from home in the future (Fig. 7). Among those who do not miss the commute at all, 72% express desire to work more from home in the future. Among those who miss commuting a lot, 69% would like to go back to their previous work routine.
This matches the numbers that have been reported in Norway as well, where the percentage that miss their commute are roughly 80% for pedestrians/cyclists, 50% for public transport and 30% for driving (https://www.nrk.no/norge/blir-palagt-hjemmekontor-_-mange-sa... in Norwegian)
Never thought about it this way, but my bicycle commute has always been 30-45 minutes and that's why I'm leaning 60-70% towards "I don't miss it". If it was only 20mins door to door I guess that would be different.
Just personal anecdotal data. The main factors for me are just general flexibility and commute. I used to commute 30m-1hr one way. So that's anywhere from 1-2h a day I'm getting back right at the start. Then flexibility: being able to get chores done, run an errand, take a walk, etc. This actually ends up giving me even more time back. I can work when I'm productive. Output is the same, but I'm not forced to pretend to work for 8 hours. It just makes so much more sense. If my office was 5 minutes away and I could still do all of these things without the social pressures, I might consider it.
I structure my notes on a topic as if it were a book.
- There's a table of contents.
- There are prerequisites for each section (links to other sections within the notes).
- There's a terminology section at the bottom has short definitions for all the new terms I should remember (software automatically links each usage of a term to its entry in the terminology section).
Engineering is the practical application of science and mathematics to solve problems. It sounds like you're maybe describing construction management instead. I'm not denying that there's value here, but what you're espousing seems divorced from reality. Good luck vibecoding a nontrivial actuarial model, then having it to pass the laundry list of reviews and having large firms actually pick it up.
reply