Good point - it works well in a group setting to look around and make eye contact as you speak. It makes others feel included in the conversation.
1,391 karma · joined August 29, 2013
As others have mentioned: tone, pacing, modulation, content ... these could all contribute, but I don't think you'd be able to know unless you really analysed a video or audio recording with someone.
Here's a few things that may help:
1) Get a voice coach and do a few lessons
2) Join an acting class
3) Take a clip from a movie and re-enact it. Record yourself and play it back to see the difference, you might pick up a few things.
Then you get people together to agree what consistent looks like.
I find the easiest way to do this is to borrow someone else's publicly documented coding conventions e.g. Company ABC.
Then anyone disagreeing isn't disagreeing with you, they're disagreeing with Company ABC, and they (and you) just have to suck it up.
From there on in, you add linting tools, PR checks etc for any new code that comes in.
Some years ago I gave a task to some of my younger (but intelligent) coworkers.
They spent about 50 minutes searching in google and came back to me saying they couldn't find what they were looking for.
I then typed in a query, clicked one of the first search results and BAM! - there was the information they were unable to find.
What was the difference? It was the keywords / phrases we were using.
Yes, and to provide enough context.
There's probably a lot that experience is contributing to the interaction as well, for example - knowing when the LLM has gone too far, focusing on what's important vs irrelevant to the task, modularising and refactoring code, testing etc
Also testing for physical security and social engineering. Old folks could make pretty good pentesters.
Except, you get what you pay for.
If someone is good then they are able to compete for more highly paid positions and therefore aren't working for 20% of the salary.
So in the end you shoot yourself in the foot, especially in startups where crappy code leads your team to work at a snails pace as your code becomes a spaghetti tangled mess. Then, once it does you end up hiring the expensive guys to come in as consultants to try to get back to what you could have avoided in the first place. Then you have to hope that in the meantime you haven't had any major security issues...
In particular, the Nikola Tesla Museum, free walking city tour, massages, and some cool bars.
Everything was really inexpensive compared to say Germany, and the women over there... they are stunning!
Of course it'd be different to live over there, but it really wouldn't be the worst place to end up if you were earning a decent salary.
Only obvious downside for me was smoking in restaurants (I can't remember but probably bars as well). Not sure if it's still the same now.
To be fair though the only online application that went through was Atlassian.
I have a CS degree and over a decade of experience as a full stack dev.
Maybe I just got lucky, but there have always been people out there that seem to apply for hundreds of companies and land nothing. I've also helped some of those people land a job.
IMO it mostly comes down to understanding and preparing for the interview process, and tailoring yourself for the position you're applying for. Sometimes people also need help with blind spots - little things like correctly referring to technologies in their CV, small talk and being personable etc.
In a social setting you can just tune out or move on, but in a work setting... It's extremely tiring because you're trying to catch what's important and distinguish from the unnecessary fluff.
For example, "can you pass me the X" is straightforward in English, but requires a bit more thinking / planning in German where you have to consider "what gender is X, and what case is it in?".
Of course for a native speaker this is for the most part automatic. For someone learning though, it emphasises objects in a way that you didn't have to before. All of a sudden every item is distinct, has an additional attribute and must be used in a specific way.
One thing is that when you begin a sentence, to get the grammar correct sometimes you need to know what comes at the end of the sentence, along with understanding the context in which nouns are used.
For example "the blue dog". In German if you said "I pat the blue dog" it would actually change to something like "I pat then bluen dog", whereas "I am the blue dog" wouldn't have the "-n" endings on the word "the" and "blue".
Once you change the word "dog" for "cat" then the endings on the words "the" and "blue" change, because every noun in German has a different gender (masculine, feminine, neuter), and the words endings in a sentence can change based on the particular gender and context they're used in.
Anyway, this is a long way of saying - you need to know what you're talking about BEFORE you begin!
In English we have the luxury of kind of making it up as we go. If we decide last minute that we're not patting a blue dog, but are patting a blue cat then that's simple, we just change the noun at the end once we get to it. In German you need to have that noun info upfront, otherwise you might not get the grammar correct!
For example, on a server I'm working on there are helper functions that generate different types of responses. Responding in certain ways will produce a 200, but will also log a warning or error.
On the client side, you can create request helpers that all requests go through and that can resolve requests appropriately, rendering error messages to the user etc.
The main thing is to have a well defined, consistent approach.
200 OK {status: "failed", errors: ["field X is required"]}
How you deal with this on the application side, what JSON statuses you have etc is up to you.
I use http status codes to encode how the _request_ was handled, not necessarily the data within the request.
A 400 if you send mangled JSON, but a 200 if the request was valid but does not pass business validation rules.
Inside the 200 response is structured JSON that also has a status that is relevant at the application level.
Otherwise how can for example you tell if a 404 response is because the endpoint doesn't exist, or because the item requested at the endpoint doesn't exist?
I believe it's important to have a separation between what is happening at the API level vs Application, and this approach caters for both.
Pay the $20 for Claude, copy the table DDL's in along with a query you'd like to tune.
Copy in any similar tuned queries you have and tell it you'd like to tune your query in a similar manner.
Once you've explained what you'd like it to do and provided context hit enter.
I'd be very surprised if having done this you can't find value in what it generates.
But what you'll probably find is that people that are skilled communicators are currently getting a decent productivity boost from LLMs, and I suspect that the difference between many that are bullish vs bearish is quite likely coming down to ability to structure and communicate thoughts effectively.
Personally, I've found AI to be a large productivity boost - especially once I've put certain patterns and structure into code. It's then like hitting the N2O button on the keyboard.
Sure, there are people making toy apps using LLMs that are going to quickly become a unmaintainable mess, but don't be too quick to assume that LLMs aren't already making an impact within production systems. I know from experience that they are.
People that actually enjoy writing software / solving problems are the ones that get ahead.
If you are skilled, can talk to people and aren't afraid to put in the yards to prepare for interviews you'll do just fine.
From the first link you provided:
> Firstly, increased risk for onset of mental disorders between mid-adolescence and early middle age could be a consequence of serious and enduring difficulties within families, rather than being a direct result of residential mobility. Relocation occurs more commonly amongst single parent and step families and those from lower socioeconomic background
Correlation != Causation. People are different and respond differently to various situations.
For me personally, having been in lots of places means I always have people to visit and in many cases a place to stay.
That being said, the one thing that you can't really replicate is getting honest feedback about what you're doing at work.
For example, you can learn all the design patterns, write the best code etc, but are you even working on the right problem? What are the assumptions that you've made that are incorrect? Is there a much simpler approach that'll get you there in one tenth of the time?
These are thing things that experience may provide which no course or single book is going to give you.
You basically need senior people to talk to.
The most straightforward way to do this is to get a job which has this structure set up for you already. Otherwise make friends, go to meetups, do some networking and find some experienced people you can get some feedback from.
People definitely latch on to the negatives, and that is in itself a big part of the problem of social media type platforms today.
Sure there's misinformation etc, but I'd much rather what we have today - it's not perfect, but it is so much easier to learn topics, so many more resources, and no not everything is free, but a lot of it is, and at least the paid resources exist!
I'm also glad that we do have people raging and seeing the negatives too. We need these people as a way of finding balance, and I'm sure as a system we'll regress to a mean and everything will be ok.