It might be role-specific. I'm a solutions engineer. A large portion of my time is spent making demos for customers. LLMs have been a game-changer for me, because not only can I spit out _more_ demos, but I can handle more edge cases in demos that people run into. E.g. for example, someone wrote in asking how to use our REST API with Python.
I KNOW a common issue people run into is they forget to handle rate limits, but I also know more JavaScript than Python and have limited time, so before I'd
write:
```
# NOTE: Make sure to handle the rate limit! This is just an example. See example.com/docs/javascript/rate-limit-example for a js example doing this.
```
Unsurprisingly, more than half of customers would just ignore the comment, forget to handle the rate limit, and then write in a few months later. With Claude, I just write "Create a customer demo in Python that handles rate limits. Use example.com/docs/javascript/rate-limit-example as a reference," and it gets me 95% of the way there.
There are probably 100 other small examples like this where I had the "vibe" to know where the customer might trip over, but not the time to plug up all the little documentation example holes myself. Ideally, yes, hiring a full-time person to handle plugging up these holes would be great, but if you're resource constrained paying Anthropic for tokens is a much faster/cheaper solution in the short term.
Yup, LLMs are rocking for smaller more greenfield stuff like this. As long as you can get your results in 5-10 interactions with the bot then it works really well.
They seem to fall apart (for me, at least) when the projects get larger or have multiple people working on them.
They're also super helpful for analytics projects (I'm a data person) as generally the needed context is much smaller (and because I know exactly how to approach these problems, it's that typing the code/handling API changes takes a bunch of time).
1000%. When the sale doesn't go through, it's the salesperson's fault. When the product doesn't work, it's the "real" engineer's fault. When everything works, the client gives you a high five.
If you don't know the answer, you can ask one of the "real" engineers.
As long as you show up with a smile on your face and the demo kinda works during the call, you're 10/10.
At FAANG companies, you generally get paid at a level above your technical role; for example, if you have a mid-level engineer's coding ability but can also talk to customers, you'll generally be paid a senior engineer's salary.
Some days, I don't understand why everyone doesn't want this job. But then I'll talk to the product engineers on my team, and they'll thank me for talking to the customers so they can focus on coding. I think it's really a personality/preference thing.
Yup, it is. It's my bread and butter too. So much so I decided to just do it for myself and start my own consulting company.
Being a solutions engineer at the right companies means you get to be one of the few people with full end-to-end visibility of the entire lifecycle of both a client and the technology adoption, deployment, optimization, maintenance, etc. process. And you'll get to see it dozens or hundreds of times for a variety of clients across industries. Again though, totally depends on the company.
@cootsnuck, if I didn't really love working with the people/company I'm at now, I'd also start my own consulting company.
Once I realized you really only need 3-5 consistent customers (well, you only REALLY NEED one customer), and you can generally keep customers and employees happy by responding quickly and doing what you say you'll do (aka not taking on work you can't handle) I'm confident I could branch out on my own if I ever wanted to.
This is one of the few hills I will die on. After working on a team that used Phabricator for a few years and going back to GitHub when I joined a new company, it really does make life so much nicer to just rebase -> squash -> commit a single PR to `main`
What was stopping you from squash -> merge -> push two new changesets to `main`? Isn't your objection actually to the specifics of the workflow that was mandated by your employer as opposed to anything inherent to merge itself?
I agree with you for many use cases, but for the use case I'm focused on (Voice AI) speed is absolutely everything. Every millisecond counts for voice, and most voice use cases don't require anything close to "deep thinking. E.g., for inbound customer support use cases, we really just want the voice agent to be fast and follow the SOP.
If you have a SOP, most of the decision logic can be encoded and strictly enforced. There is zero intelligence involved in this process, it’s just if/else. The key part is understanding the customer request and mapping it to the cases encoded in the SOP - and for that part, intelligence is absolutely required or your customers will not feel „supported“ at all, but be better off with a simple form.
What do you mean by "such a system"? One that uses AI to funnel your natural language request into their system of SOP? Or one that uses SOPs to handle cases in general? SOP are great, they drastically reduce errors, since the total error is the square root of the sum of squares of random error and bias – while bias still occurs, the random error can and should be reduced by SOPs, whenever possible. The problem is that SOPs can be really bad: "Wait, I will speak to my manager" -> probably bad SOP. "Wait, I will get my manager so that you can speak to them" -> might be a better SOP, depending on the circumstances.
It never works. You always just get the digital equivalent of a runaround and there simply isn't a human in the loop to take over when the AI botches it (again). So I gave up trying, this crap should not be deployed unless it works at least as good as a person. You can't force people to put up with junk implementations of otherwise good ideas in the hope that one day you'll get it right, customer service should be a service because on the other end of the line is someone with a very high probability of being already dissatisfied with your company and/or your product. For me this is not negotiable, if my time is less valuable to you, the company, than it is to actually put someone on to help then my money will go somewhere else.
right and keep piling slop over slop, software will collapse with this mentality. And more importantly the more the code is convoluted the more even the llm will bail out and won't be able to make further adjustments because of bad code and context rot
Referrals are the key to non-FAANG jobs. I also have over 10 years of experience, with six of those years spent working under the same supervisor across two different jobs. Four of those years were two different jobs, thanks to strong referrals from my previous boss and the one I worked with for 6 years before that.
I fumbled a bit early in my career and burned some bridges, but luckily, I smartened up after the first 2ish years.
I figured if I have 10+ years of experience and do not have at least 5-10 people I can call up to ask for a job who've worked with me in the past, I've screwed up. Investing in relationships has been the key job security hack for me (also a completely average React dev who happens to know an above-average amount about video and webrtc).
> Investing in relationships has been the key job security hack for me
This is a thing I failed to learn early on and I think a lot of people don't realize.
Connections frequently take precedence over skill! It's hard to determine skill through a piece of paper and some coding exercises under pressure. But a connection give a good signal on that and truth is almost no job requires maximizing skills (exception is at the bleeding edge and even there not always). It's also a signal about soft skills, trusting the connection isn't going to suggest someone that's difficult to work with.
I think it's easy to miss because we're often so data focused and because we want meritocracy. But the truth is you can't measure everything and not everything that's measurable is easy to measure. It takes more work to determine if some junior from a no name school is better than someone from a prestigious school. By connections make that easier to determine just like the prestige of the school serves as a signal, even if noisy. I think it's important to remember how this compounds too. Like your first year undergrad at Stanford is probably at a very similar experience level to a first year at a community college. But that gap widens and the gap isn't only due to coursework and lecturers.
Your logic works out fine if you don't mind a dash of risk (e.g. from a job loss). But when I ran the numbers from my perspective it didn't seem worth it. (I might be doing my math wrong).
Let's say I get a car that costs $30k, I put $10k down, and I take a loan out using the numbers above rounded up just for napkin math (1% APR, 4% savings account).
After one year:
```
$30,000 x 0.04 = $1,200 from savings account interest
$1,200 x 0.33 = $396 in TAXES from the interest (assuming you earn over $145k/year in California)
$30,000 x 0.01 = $300 in loan interest
Total earned = $1,200 - $396 - $300 = $696
```
Don't get me wrong, $696 isn't _nothing_ but I personally would rather have the feeling of not owing people money then an extra $696 at the end of the year. Add in depreciation from getting a new car and it's almost a wash.
>> I could pay off my car tomorrow. But I'll have more money in the end keeping that cash in the bank. Why would I pay it off early?
> Your logic works out fine if you don't mind a dash of risk (e.g. from a job loss).
I notice that no part of your comment actually describes this risk. What is it? Assuming you have the cash in hand, and it's earning more interest than the interest on your car financing, how would losing your job affect the situation?
The only effect I see is that it will dramatically increase the amount of that extra interest you actually collect, by lowering your tax rate.
I don't live in California, taxes are less. There is no risk from a job loss, I could pay it off tomorrow. You're also only looking at one year of a several year loan.
Sure, more expensive buying a new car. But I was going to get a new car anyways, the question is loan or no loan.
I don't care too much about depreciation. It'll probably be in my garage for a decade or more so that's just paper losses today, and once again I was going to buy new anyways.
I KNOW a common issue people run into is they forget to handle rate limits, but I also know more JavaScript than Python and have limited time, so before I'd write:
``` # NOTE: Make sure to handle the rate limit! This is just an example. See example.com/docs/javascript/rate-limit-example for a js example doing this. ```
Unsurprisingly, more than half of customers would just ignore the comment, forget to handle the rate limit, and then write in a few months later. With Claude, I just write "Create a customer demo in Python that handles rate limits. Use example.com/docs/javascript/rate-limit-example as a reference," and it gets me 95% of the way there.
There are probably 100 other small examples like this where I had the "vibe" to know where the customer might trip over, but not the time to plug up all the little documentation example holes myself. Ideally, yes, hiring a full-time person to handle plugging up these holes would be great, but if you're resource constrained paying Anthropic for tokens is a much faster/cheaper solution in the short term.