I have spent months adjusting my resume, applying for all
jobs where my skill set may be of use, building
proof-of-concepts using Claude, and doing cold outreach to
anyone who may be interested in my potential products or my
services. The well has gone dry.
A major quandary companies are finding themselves in is "resume fraud", which can be defined here as being inundated with applicants only to find 99%+ have used GenAI to produce a bogus work history tuned to satisfy the job posting. To the point where many companies simply give up trying to identify "real" applicants via online submissions.
It is analogous to email spam in the 90's, before anti-spam technology was mature.
I've been thinking this for a while now, but I feel like especially with the rise of crazy salaries in AI research, it's time for software development to have its agency moment. Just like athletes and actors, I think the industry might be better off if there were reputable agents with a portfolio of people they represent, and something the equivalent of a casting director at companies instead of the current "cram leetcode" mode of evaluation.
I’ve seen a setup like this in software for some specific high-demand SAP (ERP) consultancy roles. The nature of SAP migrations are per-project in nature (you wouldn’t want to migrate your company’s ERP all the time). The person had such a skillset that they had what is effectively an “agent” who would negotiate their next job assignment. The agent was even baked into the contract with the client as a party, I don’t recall how much of the hourly this agent would get, but they were invoicing the company separately.
At least this is what I recall.
Meta: this is probably the first time this year where I use the word agent to refer to a human. Feels odd even.
> Just like athletes and actors, I think the industry might be better off if there were reputable agents with a portfolio of people they represent ...
This is what recruiters in quality staffing firms do. Granted, there are many staffing firms which are worthless body-shops. But those are not reputable. :-)
> ... and something the equivalent of a casting director at companies instead of the current "cram leetcode" mode of evaluation.
The equivalent has traditionally been hiring managers who work with approved staffing companies, both to ensure those companies provide value as well as to foster an understanding of the people/skills needed by the organizations.
Wise organizations use multiple staffing firms and perform internal audits in order to minimize complacency/corruption.
All else being equal, the return of high-touch recruiting work is of course a reduction in industrial productivity and a negative contribution to economic growth. But it does generate more jobs! Put that in your predictions of AI’s economic impact and smoke it …
> All else being equal, the return of high-touch recruiting work is of course a reduction in industrial productivity and a negative contribution to economic growth. But it does generate more jobs!
When the problem definition is "companies want applicants who are known to be humans having a minimally vetted work history", Occam's Razor[0] implies people can do so efficiently. If for no other reason than it being trivial for one person to converse with another.
How would the above result in:
... of course a reduction in industrial productivity and a
negative contribution to economic growth.
If someone who contributed to the Linux kernel has their resume on par with a spammer who lied about it how do we know who is correct unless there is a verification system?
I think you have misunderstood what I was saying. I didn't compare total productivity with high-touch manual work from a recruiting agency in the actually-existing 2026 to total productivity without that same manual work in the actually-existing 2026. I agree (or certainly find it plausible) that in our actually-existing 2026 total productivity is likely higher with the extra manual work from recruiters than without it. What I compared was total productivity with high-touch manual work from a recruiting agency in the actually-existing 2026 to total productivity, without that same extra manual work, in a hypothetical 2026 where modern (GPT-4-or-better) LLMs don't exist (or at least don't exist yet). That's the relevant comparison when it comes to asking the question "what impact have LLMs had on productivity?" The actually-having-existed 2019 or 2022 are probably a decent proxy for the hypothetical 2026 here.
Put simply, organizations needing skilled personnel can delegate post-application screening to their set of approved staffing firms. Said organizations can employ initial screening techniques to filter out obvious fraud, such as requiring online applicants prove they possess the email/cell phone provided via industry standard mechanisms (while employing deny-lists as applicable). Given the remuneration commitment each hire represents year-over-year and the ability to hold staffing firms accountable, their fees are typically quite reasonable.
Why you introduced the question "what impact have LLMs had on productivity?" in this context escapes me.
> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature.
This reminds me of one of my software engineering axioms:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...
Relevant: Programming as Theory Building (1985) by Peter Naur. The actual text is rather stuffy, but basically the code+docs cannot replace the richer in-human-heads ideas for what the real-world problem is and how computers should (or shouldn't) be used to face the problem.
>> a snapshot of your understanding of the problem
> Relevant: Programming as Theory Building (1985) by Peter Naur.
Great reference and I agree. From the abstract in the PDF I have of same:
Peter Naur’s classic 1985 essay “Programming as Theory
Building” argues that a program is not its source code. A
program is a shared mental construct (he uses the word
theory) that lives in the minds of the people who work on
it. If you lose the people, you lose the program. The code
is merely a written representation of the program, and it’s
lossy, so you can’t reconstruct a program from its code.
Programming is a fascinating combination of mathematical determinism and pure expression of consciousness. Both are entirely abstract, whose worth is only quantified indirectly.
Entire organizations are built upon these intangible work products. Careers are made, promotions given, "free valence problem solvers" allowed to soar, stock options issued to birth millionaires.
But Valhalla is only reached if a cadre of engineers can "see" the system, both for what it is now as well as what it must become.
I'm truly amazed by what is happening right now. Software is a knowledge business. Teams and orgs compete on their capacity to learn, express and operationalize knowledge.
Yet everyone is buying into the discourse of a handful of vendors that they need to lock into their ecosystems and trade in their knowledge for short term speed gains.
It's brilliant from the standpoint of the vendors, and absolutely crazy that people are arguing vehemently that walking into that trap is a competitive necessity.
> But knowing your pre-conditions an post-conditions for your isolated parts of your code is important.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
> Even more fun is pointers, especially when windows / macos were switching from 32-bits to 64-bits (in different ways).
And yet even more of a fun time with porting pointer code was going from the various x86 memory models[0] to 32-bit. Depending on the program, the pain was either near, far, or huge... :-D
> This is a phenomena I have yet to experience in the wild.
I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
> I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
Is that communicating though?
Or are those meetings examples of people occupying the same space while audibly moving air with their lungs in order to feel better about themselves?
Maybe this is just my interpretation but OP effectively argued "too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
The commenter above argued that the problem was slightly different, it's not too many meetings for communication but too many that are not achieving effective communication. A meeting in itself does not create communication (of information and exchange of opinions etc.) and the commenter wanted to increase the number of meaningful meetings instead of/in addition to just cutting down meetings by numbers. The criticism of not enough time spent on communication is in the same vein, both agree on the issue of "too many unnecessary meetings".
Y'all are saying the same thing over and over with slightly different words proposing that the different way of saying it has a meaningful impact on the message. It doesn't.
>"too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
>it's not too many meetings for communication but too many that are not achieving effective communication
^^ there's no meaningful distinction between those two, discussions that devolve into such things suck all potential value out of a thread.
The distinction is explicit in the statements you quoted. One is advocating for lessening the number of meetings. One is saying that won't help, and instead advocating for increasing the quality of meetings.
* Acknowledging that too many meetings are ineffective
* Suggesting reducing the number of inneffective meetings
* Saying there needs to be clearer, independent direction
The second is:
* Stating that there are not too many meetings in general (the first says nothing about this)
* Acknowledging that too many meetings are ineffective (same as bullet 1 of the first sentence)
* Not suggesting how to address either problem
I agree with GP. There is no meaningful distinction between the 2, but the first suggests 2 ways to solve the problem of ineffective meetings whereas the second simply acknowledges the existing of problems.
> Too much time is spent attempting to communicate and as such, communication isn't actually happening.
This is where I think we have a different definition of communication.
> (i.e. we all spend way too much time in useless meetings where nothing happens and few people are any more informed than they were before)
Hence my clarification of:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.
Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
Listening is a skill, one which is can be perfected if practiced.
That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
>> Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
> That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
Good point.
I should have made the example more germane by saying "(always|only) using stand-ups for status updates." My apologies for the ambiguous exemplar.
EDIT:
Speaking of daily stand-ups...
IMHO, there are only two questions which need be asked of each team member in a stand-up:
1 - Is there anything you need from anyone in
order to be successful *today*?
2 - Is there anything you want to share with
the rest of the team?
Any other questions/concerns need to be addressed separately.
> Standard philosophical problem, you're disagreeing about the definition of a word instead of the content of the message.
Perhaps I should have said we have a different understanding or expectation of communication, instead of "definition." For this confusion I introduced, I apologize.
> Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
I do not.
Again, as I previously self-quoted:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
OP postulated:
Or maybe we're spending too much time on communicating.
To which I disagreed. OP then opined:
If too much time is allocated then its hard to stay focused
and there's always the next time that can be used to
clarify.
Which is an indirect reference to meetings, not communication.
Finally, OP concluded with:
Cut all the unnecessary meetings and only allocate the
minimum viable time to communicate. Then everyone will be
listening.
Which erroneously correlates meetings with listening. Your original response included:
... we all spend way too much time in useless meetings where
nothing happens ...
Thus reinforcing said erroneous correlation. I blame myself for insufficiently expressing my thoughts on the difference between listening, which is implicit in communication and the topic of the article, and meetings, which are an assembly of people requiring only physical presence.
You're still doing it. Now with "definition" vs. "a different understanding or expectation of"
You are not understanding, perhaps willfully, what people are writing and muddying the waters by trying to make unimportant distinctions about words instead of engaging with the meaning as intended by the author.
Every one of your clarifications has just been a pedantic restatement of what someone else clearly meant using different words trying to make a distinction which is not at all necessary to make.
Clearly I am not understanding your perspective on this topic.
> ... perhaps willfully, ...
Not at all and something I had hoped to communicate by a detailed analysis of the thread thus far.
> ... what people are writing and muddying the waters by trying to make unimportant distinctions about words instead of engaging with the meaning as intended by the author.
Words have meaning and I chose mine carefully. There is no such thing as "unimportant distinctions about words" if the words used have differing meanings and can reasonably be interpreted as conveying different thoughts.
> Every one of your clarifications has just been a pedantic restatement ...
This is one way to categorize my communication in this thread. Another way would be to say we disagree and perhaps have talked past each other.
I guess I still need to improve my listening skills. Perhaps you need to as well.
I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.
For the typical "agile" process for software:
- standup: this fits, attempting to communicate status and request help with blockers
- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.
- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.
- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things
I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.
But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...
>> Tonnes of frameworks around this concept, so I won't repeat what others have done ...
> Totally understand, but I would love if the author included links to these other things for articles/etc they thought did a good enough job not to repeat them!
I believe the author identified the primary remedy in the article:
The problem isn't that you need a better system. The
problem is you're avoiding doing the work.
It is analogous to email spam in the 90's, before anti-spam technology was mature.
reply