I found mixed results given underlying anxiety that hadn't been diagnosed at the point I was trying this. Talking to new people at work, while out pursuing hobbies, and around town, all accrued to more and better conversations.
It was a much bigger struggle with conversations where I was putting extra pressure on myself. Being able to have those other conversations was helpful though. Eventually, I found a therapist and am in a better place with this.
Letting curiosity be the motivator behind starting these conversations and cultivating curiosity more broadly can help -- or at least I have found it to be helpful in making initiating feel less forced. I wonder about people's jobs or the reasons they are visiting a place or what they think about what's happening nearby, or just generally who they are.
One antipattern I've encountered with this approach tho is that sometimes anxious people will exhaust their conversation partners with a battery of questions. Even if thoughtful, this can sometimes have the effect of exhausting your partner, and tends to keep the conversation steered away from actual connection. YMMV, but either way be mindful and make it a point to share yourself
We delegate power already. Is unleashing AI in some place different from unleashing JSOC on an insurgency in a particular place? One is code and other is a bunch of humans.
You expect the humans to follow laws, follow orders, apply ethics, look for opportunities, etc. That said, you very quickly have people circling the wagons and protecting the autonomy of JSOC when there is some problem. In my mind it's similar with AI because the point is serving someone. As soon as that power is undermined, they start to push back. Similarly, they aren't motivated to constrain their power on their own. It needs external forces.
A big part of the problem is being permitted to teach this stuff. As a UK CS grad from the early-2000s, my observation was that academic staff recognized the need for these skills. They weren't permitted to teach it due to time available and the view that it wasn't academic. Thankfully, my university's CS department offered courses in these kinds of topics taught by the support staff (read: sysadmins). These courses existed to help other departments with skills but were open to students.
Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.
I think it's reasonable to distinguish which side drove this. RAM prices are going up but it's not engineered primarily by RAM manufacturers. They are naturally jumping on the bandwagon and responding, but they aren't the drivers. Of course, how they respond matters. They could make other choices. Over time we'll see how this goes because AI could cool and then RAM manufacturers end up in a spot where they choose to manipulate prices to keep them higher.
I don't believe that devs are the audience. They are pushing this to decision makers where they want them to think that the state of the art is further ahead than it is. These folks then think about how helpful it'd be to have 20% of that capability. When there is so much noise in the market, and everyone seems to be overtaking everyone else it, this kind of approach is the only one that gets attention.
Similarly, a lot of the AGI-hype comments exist to expand the scope of the space. It's not real, but it helps to position products and win arguments based on hypotheticals.
Even if you talk to users, you can do it the wrong way. Big companies are incentivized by the stock market to care more about new users than existing ones because their only focus is growth. Growth can't be rooted in your existing users is a common feeling in product management circles. If you try to do things for people other than your existing users, then you end up doing odd stuff that at best is a mild annoyance. More likely you hurt their ability to continue using the app.
It's not just about the language. The good money for these low-code tools is larger organizations which have deployment/hosting/compliance/maintenance concerns that need to be accounted for. You can knock out as many apps in whatever platform you want, but they don't want these at the IT gatekeeper level.
They want a tool that makes this file share talk to this SharePoint site which updates this ERP tool over there. The LLM approach is great for the departmental person (if they can still host shadow IT) but falls down at the organizational level. The nature of this work is fundamentally different, crappier, and less interesting than what any person on HN wants to be doing which is a contributor to misunderstanding of the market.
>> Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team.
There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.
Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.
Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.
I've wondered if people who write detailed specs, are overly detailed, are in a regulated industry, or even work with offshore teams have success more quickly simply they start with that behavior. Maybe they have a tendency to dwell before moving on which may be slightly more iterative than someone who vibecodes straight through.
It was a much bigger struggle with conversations where I was putting extra pressure on myself. Being able to have those other conversations was helpful though. Eventually, I found a therapist and am in a better place with this.
reply