We are retiring our bug bounty program
turso.tech354 points by tjek a day ago
354 points by tjek a day ago
Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.
We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code.
The net effect of such a "productive" engineer always was that instead of increasing the team velocity, team would come to a crawling pace because either his PR had to be reviewed in detail eating up all the time and/or if you just did cursory LGTM then they blew up in production meanwhile forcing everyone back to the drawing board but project architecture would have shifted so rapidly due to his "productivity" that no one had a clear picture of the codebase such as what's where except that one "super smart talented productive loyal to the company goals" guy.
Sounds a like a tactical tornado, made me think of this paragraph:
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” - John Ousterhout, A Philosophy of Software Design
I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else, sometimes for higher pay. The slower folks end up getting the worse code and no raises in exchange for comradery.
But also I have no idea how that situation arises unless the slower folks are just auto-approving PRs. You kind of did that to yourself if you let the new person get away with it.
My experience is exactly the opposite. The TT ends up being the last engineer standing a lot of the time. The people who want to have better refactoring and more maintainable code are usually the ones who move on. The TT often stays in the same place for 25 years. Often correcting mistakes they themselves made in the past.
I knew one engineer who came in every Sunday night to process missed orders from an e-com system they wrote. They were unable to actually fix the problems with their code, so they just fixed the problems by hand. Every week...for years on end. Management thought he was a star who worked hard. The devs knew he was the worst engineer they have ever worked with. He still works at that same company 25 years later.
The correlation between what management thinks and reality can be pretty large at times.
The profile you describe is not a Tactical Tornado to me.
A tornado is something big and temporary.
Someone who makes a mess but stays to fix it cannot be described as a tornado.
I worked with actual TT and with people fitting the profile of your guy.
To me they are quite different and have a different impact on the teams they work "with".
I would say your guy is more a Sisyphus.
The ones I met where thought as hard working by management, because they actually were.
If your guy works extra on Sunday for free, they're working hard in my books.
They were not thought as stars, but they were more liked than average 9-5ers. "I know he's not great, but at least he's compensating by working harder".
In the end, if they make something not great, but the work expected from what they do is actually achieved, that's more than most.
And I honestly prefer the Sisyphus to the TT. At least I know they'll own what they do. Not drop it on everyone else to go chase their next "miracle".
> If your guy works extra on Sunday for free, they're working hard in my books.
Working hard on the wrong thing: endlessly manually processing things the software should be taking care of. Investing that time in fixing the code would be better. Working hard only matters when the effort is well spent.
> I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else
In my case, it's worse than that. They usually get promotions, raises and move up the ladder. The business only cares about thing: making cash. This means pumping out feature as soon as possible because the sales team closed a million dollar contract, which includes features we don't have.
The engineers who deliver the features are noticed by managers and win big. No one cares about code quality and half the time, the code is rewritten or thrown away anyway..
I'm sure there exists organization where code is treated as art, but I sure as heck haven't worked in one. Over the years, I've given up trying to cleanup crap code, now I just get the work done as best as I can and call it a day.
I can tell you how that situation comes about.
You start by rejecting those PRs, saying "write more maintainable code, not quick hacks".
Management starts pressuring the original developer "why is it not merged yet, I thought you had it working".
That developer hits back with "well, it failed code review, they want me to refactor it".
Management goes back to the reviewer, "why did you fail this? It meets coding standards right? Pipeline is green".
Reviewer says "Well, yes it technically meets coding standards but it's full of hacks and is not future proof, it will bite us."
Management says "If we coded for tomorrow we'd never get anything done. Don't be so awkward". And then code gets merged.
Then you learn to just let these people go wild. If it hurts in the future you have a nice little "I told you so". But in my experience, management doesn't actually care if it hurts us in the future, it's not their problem. They just say "Well give me bigger estimates if you need to refactor". Fair enough, it's not a big deal but it is a pointless slog of picking up the pieces.
The other way it comes about is when the original developer just isn't really that good of a developer. So you end up in such an endless feedback loop trying to get the code in a good state that you piss everyone off and it's just easier to merge it.
Some hills just aren't worth dying on. And these guys can be exploited for your own advantage if you want to get code merged quickly ;)
>You start by rejecting those PRs, saying "write more maintainable code, not quick hacks".
How do you go about that when for example, my previous employer just allowed any software developer to commit to any branch, and there was never any code review happening?
Set rules on the repo. For example, no one on my project is allowed to check in code unless it's on a PR that's been reviewed and approved by at least two people. Attempting to push to /main will just fail otherwise.
> I have no idea how that situation arises unless the slower folks are just auto-approving PRs.
Restricting changes to PR's is nowhere near universal.
Sometimes the issues emerge later. The code doesn't scale well, it has subtle bugs that crop-up later, it doesn't handle edge cases well. Basically, it answers the immediate issue well, but it is poorly engineered and hence, why it causes problems for others down the line.
They'll often exploit a power dynamic. If you're less senior than them, in some organizations it can be very difficult to stand up to that behavior. I experienced that at my previous employer as a relatively senior engineer, even. Top down organizations look unfavorably on feedback that runs upwards. Your pushback will be seen as standing in the way of progress.
In objective terms, these tactical tornadoes are among the most valuable headcount at a big company to the extent that they can rapidly patch production issues and restore service, by any means possible.
The problem is allowing this kind of frantic tactical development even in "peace time".
You fix the environment so that proper code reviews are explicitly part of the process regardless of priorities, unless management sign off on taking on responsibility of the shitstorm if things break in production
> You kind of did that to yourself if you let the new person get away with it.
In theory, sure, but in practice, to echo the others, you often don't have a choice, because of power dynamics/politics.
Its easy to say "its management's fault", but the principle is the same - these guys are spammers and quacks (and deserve nothing less than to be confined to the level of hell reserved for spammers), they just have to spam long enough and something will get through (volume over quality). And after their "success" i.e. fraud, they can ditch the company and move onto the next. I've seen multiple "seniors" like this, not actually very good at the work, but great at pushing half-baked slop.
AI can be the ultimate tactical tornado.
Yup, this was my first thought. Tell an LLM that there's a bug, and it will _happily_ add 200 lines to the project, usually wrapped in if statements so that it all interleaves with existing code. Then it will write twice as many lines in tests, run it all, and be done. Your bug is fixed. All the tests run, and test coverage went up. Now do that a couple dozen more times. :shudder:
But it really doesn't have to be like this.
For their bug bounty program, the company can just charge 5-10$ per submission to guarantee everything you send gets thoroughly reviewed by a human, and so it completely eliminates bot slop DDoS submissions overnight. If your bug and PR was actually good, then you get 10 + 1000$ back, and if it wasn't good, then you need to do better due diligence next time, and the skilled human feedback you received on why it wasn't good, was a valuable lesson for your engineering career, and it only cost you the price of a Starbucks latte, and it also cut out all the scammers polluting the system. This way everyone wins.
I said it before and I'll say it again, for opportunities open to the entire world on the internet, adding monetary friction is THE ONLY (anonymous) WAY to filter out serious people from bad actors doing spray-and-pray hoping they'll make some money, or get that job, by weaponizing AI bots. You can't rely on honor systems and a high trust society on the anonymous open internet, you need to financially gatekeep to save yourself and your sanity, and make sure the honest serious people you want to engage with don't end up drowning in the noise of the scammers and unscrupulous opportunists.
But we can't shut ourselves down just because we refuse to apply solutions to AI slop DDoS.
> monetary friction is THE ONLY (anonymous) WAY to filter out serious people from bad actors
This is a great strategy idea, I like it. I'm not good at thinking out the curse of the monkey's paw, so I'm curious if folks can think of any downsides.
I said it before and I'll say it again, for opportunities open to the entire world on the internet, adding monetary friction is the only way to filter out serious people from bad actors doing spray-and-pray hoping they make some money or get that job through weaponizing AI bots and sucking all the air in the room.
So many problems can be solved that way, including customer support. Instead of having to post a sob story on Twitter and HN when the AI at BigCo bans my account for no reason, why not charge me $100 for access to human support that is empowered to triage and escalate genuine issues? Then, issue a refund if the problem is on their end.
I don't understand why this isn't a thing.
$100 for someone in SV isn’t much. $100 USD for someone in Africa, India, some parts of Asia could be a week or even months salary.
You could probably adjust the cost per region, but then you open yourself up to spam bots again because it’s trivial to spoof one’s location.
>$100 for someone in SV isn’t much. $100 USD for someone in Africa, India, some parts of Asia could be a week or even months salary.
That's kinda irrelevant. A Macbook Pro is still around $2k USD whether you're in US, EU, LATAM, Africa or India. They don't sell it cheaper to people in developing nations just because they earn less money.
My guess is there is no easy way to deal with chargebacks and they would probably be bad.
It would almost need to be analog. Fill out this form and drop it in the mail with 10 bucks inside.
My guess is there is no easy way to deal with chargebacks and they would probably be bad.
Sure there is. That would be casus belli for a real ban.
It’s hard to forecast this. Support calls occur chaotically. So staffing to support them is difficult to do in a way that keeps a steady margin.
Then who arbitrates the inevitable dispute over whose end the problem was?
For the times when it actually saves the company from going through arbitration, $100 is cheap.
When I was being trained in Team Software Process (https://en.wikipedia.org/wiki/Team_software_process) our TSP coach mentioned someone on an adjacent team that Management loved because he stayed late, worked weekends and was generally seen as a hero by them.
The problem, as the coach pointed out, was that that kind of behavior was pathological and showed poor planning and bad project management. Cheering on someone, even someone with the best of intentions, who was working like that was sending exactly the wrong message and reinforcing the wrong behavior.
But we already knew that!
This is profound and beautiful description. Thank you for sharing. Totally can relate to that. Been there, seen that.
Do people like that exist?
Totally.
But seriously, I guarantee you the opposite is more common- the incompetent devs which can't manage shipping anything, keep trying to do "surgical and small edits" after 1 week of thinking about them and then have them blow up in prod for someone else to fix quickly because if it's up to them, it'll take 2-3 sprints
10 years ago I was a lot closer to what y'all talking about. After having more and more colleagues I can no longer agree and suspect this is mostly the opinion of incompetents which try to discredit regular devs.
Another thing they always lack is the ability to see when a large change is necessary because that's just what is necessary to achieve the feature in a stable manner. Sorry to say this, but starting of this discussion while trying to discredit large change sets in the age of ai is incredibly inept.
When you wrote your software well, large changes are possible and increase stability when you actually need to add a fundamental change of behavior. Which can come from a miniscule requirement.
But to close off on the topic of this article: they made the right call. In the open source context you cannot have this kind of incentive anymore with openclaw continuously shitting out one PR after another
From the excerpt it sounds like the author is just describing one specific archetype from within a list of others included in the book and doesn't make any claims about it being a uniquely common type within every org, or the most common type of bad engineer in general.
In fact it gives the opposite impression by specifying "at least one", which implies the category is supposed to be distributed widely enough to be recognizable in an org of sufficient size, but not dominating the ranks of software developers in droves. That seems more like a strawman you're arguing against.
"[...] bottleneck isn't in writing the code. It is in reading and understanding the code". 100% agreed! Furthermore, the more code is generated by AI, the fewer people will actually understand it!
Generally, software engineers already have little to no understanding of the code that's actually being executed. We're so used to high- and higher-level abstractions like C, Go, Python, and JavaScript that we forget that we're already working with mostly-deterministic symbolism in a process that more closely resembles invoking magic spells than writing machine code. One more level of abstraction is not the end of software engineering.
Consider a plumber who doesn't understand mettalurgy or electronics but relies on some foundational trade principles that they learned from a mentor and who can understand manufacturer guides for clever new fittings and pumps.
That's the level that most competent software engineers should be working at.
Delegating understanding to LLM's is totally different thing. It's not plumbing at all. It's more like hiring a unlicensed, generalist but well-reputed handyman from Craigslist and then going out to a movie while they do the work. It could turn out fine, or not, and if it does work out, it could even save time and money if they're rate is low enough.
But it's not plumbing anymore, and you should be wary about billing plumber's rates for their work or taking on liability for it if you haven't even made sure that work meets your own standards of trade and quality.
You can argue that it's "one more level of abstraction" but it's a qualitatively different kind of abstraction. And in the economy of skilled labor, and the legal landscape of accountability and liability, that difference is enormously relevant.
This argument comes up a lot. The point is that with unreviewed AI nobody understood the code at any time (including the AI). This is completely different to a C compiler wherein the writers and maintainers deeply understand the code. This means that even though I don't understand it, I can use it with some confidence.
Your point about AI being another abstraction similar to the "mostly deterministic" C compiler also comes up often but there are many arguments against it. If you think the determinism of a compiler and an AI are similar then I'm not sure whether you know anything about how either of them work or have even compared examples of what they produce.
That's a you problem. If you feel this way, its the universe saying that you aren't very good at writing software. Good engineers don't have this problem.
PS We have way too many levels of abstraction now, that doesn't mean the right answer is to add another. Even worse unlike the others, LLMs aren't deterministic.
There’s a large difference between understanding precisely what some code does and understanding what code intends to do. It’s why “what happens when you begin typing into your web browsers address bar?” is such a powerful question for weeding out low quality interview candidates. I’ve never worked at Google, but I can talk about how they probably handle the incoming requests. I’ve never worked on Windows OS-level software, but I can start talking about input buffers. Kind of reminds me of WIRED’s “5 Levels” series…
Anyway, my point is prompts are non deterministic and there’s no way of inferring what code output by an LLM is intended to do because that’s not how LLMs work
> because that’s not how LLMs work
It's almost impossible to have a rational discussion about the effects of this technology because this point is so easily lost. Even super smart, credentialed, expert people easily (and often!) fall into the trap of anthropomorphizing the bot because it makes human noises. It's really important to remember the mechanical principles underlying its function. No different from any other computer program in that respect, the difference is the psychological hold it gets on the user. There is no intention behind its actions, but it's very easy to hallucinate one because with every other thing that speaks human language there is some intention behind the words and actions.
Precisely they are deterministic, so extrem cases apart, we could expect that given the documentation and a peace of code, engineers would most of the time be able to translate properly to assembly and explain what the assembly actually trigger in mechanical terms.
LLMs, as pushed currently, are not deterministic.
Moreover, I yet have to see a compiler whose output try to convince me I'm completely right and bring very smart interesting point on the table. Quite the contrary actually, though generally errors messages are not explicitly telling users how stupid the proposed code is as it doesn't even pass mere syntax and fundamental logic requirements.
To the extent that's true, it's already a problem plaguing the profession.
I wouldn't advocate for using different tools, but everyone should be able to reason about the machine instructions underlying their code. Both in the immediate sense of the assembly a simple function turns into, and the tricks language runtimes use to enable their neat features.
The attitude that things are magic is poison. There is a difference between feeling confident something is comprehensible and not yet needing to go learn it, vs resigning to a position of powerlessness.
The thing is that C is formal by itself. Opcodes, Assembly, C, Python, Common Lisp,… are all equivalent to each other, meanings there’s no statement and no algorithm that you can’t map to each other. That’s what it means to be Turing Complete.
The main issue is that not everyone cares about the semantic of what they’re writing. You don’t need to know assembly to talk about C’s semantic or know C to talk about Python semantics. It does not require going up and down some abstraction tower.
I was (almost) just that guy for one PR. Removed something like 20% or more of the codebase by leveraging the libraries and external tools we already had in use better, but it meant almost every single thing we were doing had to use the library function instead of the one we wrote. But assuming you have good regression tests and linters, so you know the code works and it's not terrible, the review should be more about overall high level quality instead of poring over every character to check correctness. It was still a pain to review, though
Admirable effort. But why did you have to do it in one PR?
> almost every single thing we were doing had to use the library function instead of the one we wrote
As per the other person's comment, yeah basically I could have broken it up but it would've been an arbitrary demarcation. I just deleted our functions and fixed everything that yelled. Admittedly that could've been one and then leveraging the libraries better could've been another, but they would've been 2 PRs that changed almost every line. So done as one to mitigate review time.
Arbitrary demarcations can still be valuable! Just because something is arbitrary doesn't mean that it's not helpful. Working in chunks will let you take more time to review each callsite individually, and increase your confidence in the changes
In the future, I would definitely encourage you to explore a more iterative solution—fix the first 50 occurrences first, or maybe all the occurrences of a handful of functions. For example, if you have utility functions A, B, C and D, maybe fix functions A and B first, and then C and D second.
Ultimately, at the end of the day it's going to depend on how much code you're touching. If you're only touching 100 library calls, then it's probably easy to do them in one PR. But if you're updating 1000 library calls, you'll need to take a more iterative approach. Building those skills now will serve you well in the future when working on bigger codebases and harder refactors.
Well another problem is that there was a developer also working on those functions at the same time. So just like the recent post on a 25 million LoC reformat done in a weekend, it seemed better to do it in one fell swoop. If it's good enough at 25 million, I'm sure it's good enough at a few thousand
Autoformatters are deterministic tools that are tested regularly, with extensive test suites and went through a very long process of production usage and review before the reformat:
> We also built a tool to diff ripper trees across formatted files, accounting for things like rubyfmt converting single quotes to double quotes. Combined with our extensive test suite, we built confidence slowly and deliberately.
They also didn't do the entire thing in one weekend—that was just the article title clickbait. they did it file by file, incrementally, over the course of months:
> Rolling out a novel autoformatter to 25 million lines of code has two big risks: merge conflicts and correctness. A bug affecting just 0.01% of lines would still touch tens of thousands of files. To manage both, we built in a per-file opt-in so rubyfmt would only format files that explicitly asked for it. Following the Developer Productivity org’s typical pattern, we started with systems we owned and could observe closely, then expanded coverage gradually as our confidence grew.
Why not leave your functions but have them invoke the libraries instead?
It depends a bit. But it would now mean that there are multiple ways of doing the same. Call your internal function or call the library directly. You need to put up some linting around it that people only use your function or the library function.
Otherwise you may get that you have your function, you think everywhere is using it, you make it fix a bug. And poof, you introduced bugs at the other call sites.
My whole career I yearned for green field projects but somehow predominantly worked on existing grown code bases and legacy projects.
That naturally meant reading and understanding more code than writing. Sometimes my LOC count was even negative, and I was proud of that accomplishment.
Now with AI I write even less and I've given up on the dream to gain fulfillment that way. The ability to quickly understand large amounts of code from questionable sources, be them machine or human, should hopefully stay valuable until my retirement, especially when supported by AI? What do you think?
Personally, and this is just my wild guess; I think almost no one is _really_ going to learn to code again. That's not a slight on the next generation or anything; I wouldn't know how to code right now if LLMs existed 25 years ago. I love coding, but it's the _result_ that's the real accomplishment. The journey a bit... but having the result always just sitting there, ready to grab with no effort, is too much temptation to resist.
And as this goes on, folks who can run an LLM _and_ understand/criticize/rework/re-prompt are just going to get more and more scarce. Even using an LLM in my preferred style, where you guide the model through a long series of small steps, will fade away.
> And as this goes on, folks who can run an LLM _and_ understand/criticize/rework/re-prompt are just going to get more and more scarce.
As long as LLMs keep constantly making mistakes and introducing bugs and humans keep having to verify their output and clean up after them it should mean plenty of work for the few humans alive who can actually understand the code. Future AI models being trained on an increasingly large body of vibe coded bug-filled slop will only make the problem worse.
A small number of people with skills that are in demand will tend to make good money, and jobs that make good money will attract more people into learning how to code.
Statistically speaking, most codebases are brownfield. Without joining a startup, working on a greenfield project is actually a pretty rare treat. And deleting code is wonderful. I'd go as far as to say lines removed is more often than not more valuable than lines added; every line that's no longer in the codebase is code you no longer have to understand or care about. So long as functionality remains intact, of course.
The problem, as I see it, with prolific use of AI to generate code is that it goes in the exact opposite direction. More and more code is bolted on top of existing code, more and more edge-cases, patch-ups, workarounds, etc. accumulate, the codebase grows and grows. In the end, no matter how good you are at understanding "code from questionable sources", you're still a human being. The AI can generate new code at rates several orders of magnitude faster than you can injest and understand it, and when your meat brain becomes exhausted, the machine does not tire. From a business perspective, your employer will weigh their options: they can wait for you to interpret the code and generate good code (whether by hand or by machine + human review).. Or they can just keep pulling the lever on the slot machine until it works well enough to sell. And for the business exec just looking for the fastest path to paydirt, I'm afraid the latter option is going to look way more appealing.
> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.
The people AI evangelists often say "typing" instead of "writing code", because they don't really understand -- or it's not lucrative for them to acknowledge -- what makes writing code hard.
We don't just write code to be executed by machines, we also write it to be read by humans. Code reviews, debugging, future changes -- all of these things involve reading and understanding the code someone wrote. And until we have an AI that we can actually hold responsible for its actions, we can't delegate the understanding to it.
> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.
No, it's that quite literally the PR submissions are SPAMmed. Whoever made them is acting like a SPAMmer, sending out lots of garbage and hoping it sticks. IE, they're not doing their part in reviewing what the AI found and generated.
So you agree. Unless you're using some definition of "reviewing" which somehow doesn't involve "reading and understanding".
No, reading and understanding is not the bottleneck.
Whoever is running the AI is spamming instead of doing the actual work. IE, they are just pushing their work onto the people who would review legitimate submissions.
I don't understand why one wouldn't just auto reject big PRs and tell them to make smaller ones. Sounds like it's a communication and social problem, not a technological one.
Even with AI, just tell it to make smaller self contained PRs. I do this with Claude or GPT models and they do just fine.
Power dynamics. Usually the person making the giant PRs is the one with all the sway. An earlier-career engineer is unlikely to push back against that level of influence.
It can be a company wide policy rather than trying to target a single individual even if the outcome is that they are targeted. This is something that should be addressed to them through a manager etc or if not, it's time to leave while they ruin the product over time.
This "you should leave" thing is a very boring and tired take and it should be said regularly that almost no engineer can afford it nowadays.
Beautiful theory, but only that.
What's the alternative? You push back or you don't, leaving you likelier to leave in the future. For non-junior devs, the market is still humming along.
I don't see how the market is humming along for anyone.
Then again, I have zero network. Maybe you can just call someone on the phone and jump ship next week? I can't. Many other people cannot as well.
My idea right now is to find ways to do things mostly my way and introduce a near-perfect meritocracy in my team. No seniors or juniors; I am technically "the most senior" but we all have differing and unique experiences. I share my experiences and when I feel stronger about something I make it clear why but I don't go sad in the corner if the other engineers overrule me.
Regardless of how the market is, I like getting along with people. Of course sometimes (actually: often) it's not possible in which case either a team restructuring should be done, or one should indeed leave (which is the nuclear option; not just "oh well, things did not work out").
> I don't see how the market is humming along for anyone. Then again, I have zero network
I mean, yeah, that's the issue. Even without a network my LinkedIn is full of recruiter spam because my profile is optimized, which is a skill anyone can learn and do, same concept as SEO.
> I like getting along with people.
Sure, who doesn't? The issue is when one becomes a doormat, just as in other social situations; in this case, it'd be being nice to others when in reality you'd need to be firm but fair that their writing huge PRs is negatively affecting everyone else. It's the paradox of tolerance applied to the engineering world.
> it should be said regularly that almost no engineer can afford it nowadays.
Everybody is not you.
The market is bleak - but don’t mistake everyone’s leverage - or understanding their leverage - for your own.
> Everybody is not you
Perfect example of a non-sequitur. Irrespective of whether or not the statement is true, it has no bearing on the veracity of the original claim: that in the current market, the majority of workers simply do not have this leverage.
The original claim wasn’t “the majority of workers”, though.
I likely would have avoided commenting, if it was.
The original claim was “almost no engineer”.
Anyway, the point is, if you take little interest in the “full stack” of whatever you’re working on (the technical stack, BizDev, whatever),
you will obviously be easier to replace with an automaton - AI or human.
Same can be said back to you. Obviously mine and 50+ acquaintances experience is not the entire world but geographical clusters and/or work-area clusters do apply.
Can you pick up the phone and be in the next job the next week?
Coming off of a health sabbatical, yes, I have more contracted work around than I can commit to.
I can’t even imagine having 50 acquaintances I see in a year, currently, so I don’t know I’ll be able to offer advice specifically…
but generally?, I think I’d be pretty upset if I knew 50 people and none of them would bring me on their team, or start something up with me.
Well, I am upset. But -- bubbles. My health has been in decline for years and I am very slowly making some strides. Missed on a million networking opportunities by being unable to go to conferences and... yeah, I'll not turn this into a sob story.
LLMs really accentuated the importance of networking, did they not?