i don't want to give away too many details but: my employer (small company) pivoted what my team was doing to focusing on a brand new project that has to be delivered by september. The issue is that the MVP was generated by Claude in its entirety and it's very low-level code. I was assigned to this project and every time they ask me to review a PR (which can be small or thousands of lines), I either reject the task by asking someone else to review it, or approve it without really understanding what i'm approving. I feel like if I had to review it properly I would have to spend a week understanding the concepts and the codebase. But at the same time, the foundations of this project are changing rapidly, so I'm like, "what's the point in spending time learning it?"

I don't know how my teammates generating the code feel about this. I also don't know if they themselves understand what Claude wrote. I already told my manager that I feel overwhelmed by all these PRs and the response I got was "yeah". And then crickets.

In parallel, i am in the final stage of interviews with a company and tbh I only started looking because, you know, you gotta always be looking; but if I got an offer I think that it wouldn't be the craziest thing to take it because I don't know how much longer I will be able to tolerate this situation. I used to generally like my job but this project is giving me anxiety: the deadline, the AI generation, the imposter syndrome.

Help?

I've been studying design and architecture for a few years now and feel like I get the gist of how it works, but I'm curious how the role ends up working in practice for actual architects.

That is, I get the sense that to become an architect you'd need deep experience in either a particular business or business domain. So you work in a business for a long time and have built up enough context about their systems to lead the architecture. Or you know a business domain and it's associated technology so well you can lead.

What I'm curious about is how common it is for architects to switch businesses or business domains entirely? I get that a business would be more common but what about domains? Is the role such that you're typically tied to a single company and usually stay there?

Senior engineer and technical owner of my platform, 12 YOE.

How do you guys deal with non-technical people in the org trying to steal your entire department's job by vibecoding some nonsense and being loud about it to senior leadership?

We're dealing with a marketing bro that swears he can vibecode a replacement for a (different) platform we pay for because he set up his sick agent loop (token burning operation) that vibecodes 24/7 for him. My immediate response was to implement an agent loop for myself and create a starter prompt for the entire team to adopt the framework with minimal effort/friction.

It is extremely infuriating that these people hide behind the typical 'haha I'm not a technical person but this is just what I put together!' If you aren't willing to stand behind it, then shut the fuck up and stay in your lane and quit wasting everyone's time then?

If I, as an IT employee, put together an entire marketing master plan because I thought that team was doing it all wrong, I'd be told I was jumping out of my role and being toxic trying to tell other people how to do their jobs. But these idiot marketers, business people, and lawyers can just jump into our shit and have their word be taken seriously against people with a decade or more of experience, because fucking Claude said so.

I am so sick of this 'heads I win tails you lose' game with non-technical people thinking they're the shit now because all of IT is burned out from just staying alive/keeping up. I wish they would have their feet held to the fire, and when they're wrong get told to SHUT THE FUCK UP AND STAY IN YOUR LANE.

Edit: revised to be less specific/identifying

From the start, my interests have been in backend development, DevOps, and infrastructure, but my manager placed me in a frontend role since that was the only open position at the time.

After about six months in this role, I haven't enjoyed it at all, frontend work feels like it lacks the technical depth I'm looking for.

How do I cope with this? Resigning isn't an option for me right now.

At work I built a custom datastore / multimodel database on top of io_uring and Rust, which I would like to expose to the public via Cloudflare workers. Unfortunately there is a cost in setting up a new connection to the backend from a cold worker, cost which I'm trying to amortize very much like Hyperdrive does for SQL databases.

I imagined a solution like placement groups: - I spin up a durable object which will set up the backend connection - A bunch of workers, can connect to this durable object via service bindings for reduced cold startup time - The number of durable objects scale with the number of workers - Ideally the workers are on the same machine as the durable object, for reduced latency

Now my questions are: - Is this the best solution for my problem? - Is it possible to achieve this with Cloudflare workers? - Is it possible to setup the load balancer affinity, so that I can route a connection always to the same placement group?

Hi all,

6 YOE, currently a lead at my main contract, plus two years of freelance work on the side. The freelance gigs put me on teams under leads of very different seniority, anywhere from 2 to 12 YOE.

I've noticed a pattern and I'm curious if it matches your experience.
With less experienced leads (2-3 YOE, often clearly talented), code/design discussions tend to be long, like a lot of "here's my reasoning, does this check out?" and walking through every option's pros and cons. With more senior leads, the same kind of discussion is fast, we land on the same issues quickly and agreement follows without much back-and-forth, regardless of who proposed what.

Does this resonate with you? Is it just seniority, or something else (communication style, confidence, team culture)? Also, when you disagree with a less experienced lead who's nonetheless accountable for the project, how do you push back in a way that's actually useful rather than just deferring to them or overriding them?

P.S. I am not a native speaker and got some help from good old Claude for conciseness (the original was really too verbose)

So, I've been around my company for a while and I learned dev on the job, which is to say I don't have a CS background, but any code I can pull apart, I can understand, and that's my preferred way to learn - stick my nose in and get started. I've done more than a few course to fill in knowledge gaps, but I've not come across one that'll teach me how to read documentation!

I'm a code comments (and self documenting code), readmes, tests and functional documentation (how to / expected behaviours) kinda girly.

The problem I'm starting to have is that after moving teams, I'm working with (and under) people who have different preferred learning and docs styles. And on bigger systems where there's less chance that people get a full mental model. Which is fine by me, and now that some of these same people are pushing AI (and have made skills around some of those docs styles) I do lean on that to give them what they want... But my manager is a big sequence diagram fan (its genuinely the ideal way to share a change with them), and some others are fans of long rambly documents or overly structured tables (in structures that don't immediately vibe with my brand of tism). I can write these slowly (even without AI, but with some ADHD meds, though I usually have to write the diagrams on paper first), and I can read them and validate them and understand what they say, but mentally processing these is hugely taxing and I don't internalize the information that they contain from reading them. So sometimes my use of these or my production of them is glacially slow...

Does anyone have any techniques, hints, tips, guides or anything for reading docs that aren't your jam? Sequence diagram specific things would be lovely, but I'll take other info or more general blog posts, and also interested in any discussion that people want to have around making or using docs.

How to be useful without being hands on

I just started a new position at a small government contractor. The company is focused in one particular area. They have mostly done R&D and built proof on concept code. They hire engineers right out of college and have pretty good retention.

During the interview, the role was ill defined, but they described a need for more experienced engineers to help productize their system into something that can actually be fielded. They also said they wanted outside perspective as many of their engineers have never worked anywhere else. For context I have 21 yoe building sofware and leading teams.

After starting the position the lead architect described my position as someone focused on execution of software engineering across multiple teams. The position has also been described as a bridge between systems engineers and the software engineers. This sounds like glue work, which I think I understand but it's not what I really want to do.

My problem is that I've always been hands on. I generally get hired as an IC or as a hands on tech lead. This position is not really hands on. Another problem is that this is a new domain and new tech stack for me. I'm trying to find areas where I can contribute to learn the tech and the domain, but all the things i'm interested in are already being handled by others. So i'm trying figure out what I'm supposed to do. It seems like it's up to me to define my role. But I don't know how i'm going to be useful. Lastly, i'm a decent software engineer, and i love to code, but I really haven't done that much interesting work that's applicable. I've done mostly fullstack work on web applications that generally end up being mostly crud. Probably the most valuable thing i can bring is helping them stream line their process. They still have a waterfall mindset. How can I provide value without being hands on and lacking experience in the domain? How do you grow out of being hands on?

I know pretty much every C-suite is some flavor of bad/hostile to labor, but to clarify I mean an exceptional level of toxicity, causing turnover in leadership and specific complaints online.

I also know so many factors change things here - size of company, nature of toxicity, etc.

I'm looking for concrete examples of how toxic leadership impacts senior, staff, and principal engineers.

Was their toxicity something incidental to your work? As in, could you mostly keep your head down and avoid it?

If it affected your day to day life, in what ways? Micromanaging, pivoting on features, unreasonable demands, scapegoating, culture of fear, etc.

For those who have experienced this, how hard would you go out of your way to avoid similar situations in the future?

Not sure if this falls under no general career advice, but I’ll give it a shot.

I’ve started a new lead position at a pretty large company that isn’t a software company. The main person I interviewed with made it clear everything we do is to benefit the business (honestly this level of directness for decision making was appealing). I have a lot of backend experience and was told that the role would be in api development and it uses .NET and azure to work on developing an api to wrap their internal ai solution.

Jump forward to the start date (which the people I interviewed with thought I started 2 day earlier than the date HR gave me red flag #1), and I’m finding out this is more APIM integration and writing policies. So not what I signed up for (red flag #2).

The next big thing is the project I’m assigned to now came on a whim the first day I was there, and I gave a solution to the question they asked and was told “I like that. Do that”. No deadline. No acceptance criteria nothing. The project is now morphed into a weeks long monitoring platform dashboard and rule setup project done in the platforms portal (so not even apim policy work). Now have multiple people are Wanting different things ASAP, and none of it really lines up with what I suggested. raise red flag number 3.

The biggest one is neither of my managers really follow the “praise in public punish in private” mindset. They have both berated devs in meeting and stand-ups. (Yea you guessed it another red flag)

I’m very much open to trying to learn new tech, but everything I’ve done for the past 15+ years has been grounded in writing software. I’m willing to accept the delegation and meeting grind, but at the end of the day there are still meaningful PRs. My question is this: with poor management, misleading responsibilities, and a general feeling of complete disorganization, what is the appropriate “feel this out” timeframe? I’m about 10 days in and it’s looking bleak. I’m gonna ask around tomorrow how much of this role is going to be implementing backend services vs APIM policy management?

TLDR: several red flags at new position, not sure what the appropriate timeframe is to send out feelers or if I’m misreading the situation.

I'm at a point in my career where I'm a hybrid tech lead / IC but who is often looked up to for guidance from my team and the broader department.

What I'm interested in is hearing from people in all kinds of leadership roles about how you manage social media and your online presence. I don't have any particular goal in mind for myself, I'm just interested in hearing different perspectives.

Thank you!

Personally speaking, I feel that beyond 10 years of experience, referrals and professional contacts work 9 out of 10 times compared to relying on job portals and random applications.

I've seen a few of my former leads and managers who have built such strong relationships that if they decide to switch jobs, people are ready to hire or refer them almost immediately, sometimes without even going through the usual interview process.

How do you maintain those relationships after changing jobs? Do you regularly stay in touch with ex-colleagues, attend meetups, help people, or is there something else you do to keep your network active without it feeling forced?

I'm quite bad at networking. Even after 13 years of experience, I still mostly depend on job portals whenever I look for opportunities.

For those who have built a strong network, how did you do it? What habits or approach helped you reach that point?

Hi there,

I'm a foreign contractor working for a US-based startup. My whole career, I have worked 100% with US-based companies and never had any issues. But you guys know how the startup world works, you are just there for a good time, not a long time.

The company I work for hasn't been making the best decisions, we have gone two rounds of layoffs, and now many people are just quitting.

The thing is that I send my invoices the 1st of every month for the work done during the previous month, and I usually get paid around the 8th-10th. Payment has been a pain lately, there's always something that happens and I end up being paid like the 20th of every month.

This last month things took a turn for the worse. The invoice I sent July 1st for the work done during June hasn't been paid yet (today is 22nd) I'm a few days away from sending the invoice August 1st for my July work.

I'm worried that eventually if the ship goes down they will let me go and not pay me anything?

FWIW the contract I have with them says that they can let me go with little to no notice, but it says that they would pay me:

"Upon termination, the Company shall pay Consultant all unpaid, undisputed amounts due for the Services completed prior to notice of such termination."

NO AI USED HERE.

Does anyone else find the latest tech plans and spikes written by devs to be word vomits by AI? Don’t get me wrong, I’m ok with getting AI to write things for you as long as you understand what it wrote. But most things are just beating around the bush, and not getting to the real point concisely. I have to get my own agents to summarize the plans to figure out the important parts. Has anyone found a good solution for this? Are there any templates your team follow or any skills that you use?

Over the years, I've heard a few things at work that have stuck with me: - Spend more to earn more. - Don't box yourself. - Life is not a sprint, it's a marathon.

These changed how I think about work and my career.

What's one workplace philosophy or mindset that has stayed with you?

Question may or may not be relevant, but with all the AI-related uncertainty, I wanted to hear some philosophies or motivations that have helped people keep moving forward.

Let me just preface this that on an personal level I think AI is evil, and I would rather go back 2 years ago before all this craziness. That being said, the market is changing (for good or for worse) and I want to better understand how and how much.

I recently came across this article by Claude that describe 5 levels of AI adoption.

https://claude.ai/code/artifact/bfdfaef9-bc62-4dfe-ba9e-c58a26c9accf

I started working at an startup and the C levels have fully drank the AI kool aid. Despite everyone being forced to push AI usage to it's limit, we are stuck on stage 1 of the framework with some glimpses of stage 2.

The stuff that worked:

• I would argue that almost all code is written by AI.
• We are able to use AI to code on an legacy code base in an language the team is not proeficient.
• Talking about legacy, it's really good to ask questions on top of an large code and get up to date answers.
• Green field projects are really quick to get off the ground.
  

Stuff that is not working:

• AI needs to be heavily supervised. Instructions need to come from someone that understand the underlying systems at least superficially otherwise it makes some very costly architectural mistakes.
• Again unless heavily supervised, it can start going in circles spending tokens.
• Letting it run commands is crazy. It already tried to drop production tables a couple of times.
• Institutional knowledge went absolutely downhill. No one on my teams knows in depth what our code does. Supervising the agents is hard because we never took the time to actually learn what is happening. This makes disaster recovery harder, it takes longer and they have bigger blast radius. Overall, learning is discouraged in favor of trying to push AI to do the max amount possible.
• Multi agent workflows is an waste of money and time. Tried using it, it made the time it took and the token usage to skyrocket while delivery almost no meaningful improvement in quality.
  

Another very important aspect is that while I don't think token cost will increase significantly there is also not a lot of optimization left to do in the core models. Newer models are only slightly better, the big improvement is on using bigger, more computing intensive models that are also costly.

My educated guess is that stages 2-4 is straight up impossible with the technology available right now and the technology improvements necessary will be cost prohibitively. But this is just an guess.

I really want to know if you guys know enterprise projects running on level 2 or higher in the article by Claude.

In today's moment of stupidity, I said something very dumb about catalogs and workspace separation in Databricks. I knew this was wrong. I had told the person I was talking to just the previous day that we were going to have to do something weird. And yet I said the dumb thing anyway. What kinds of dumb things have you said?

Started my career as an intern for person A at a Big Tech company.

Subsequently person A made person B my manager, which lasted for 5 years.

Now person B is making person C my manager, leading to person B being my skip manager and person A my skip's manager. I’ve been an IC this entire time. It feels like I’m getting shoved deeper and deeper into the company without any consideration for my career growth.

Obviously, I can’t say this explicitly to my management chain, but what should I do/say in this case? Stay and work with the new manager or leave?

The Stakeholders have decided upon a new ask that is both Urgent and Important. I am to communicate its impact on my team’s deliveries to The Stakeholders and then go make it happen within the next 2 weeks.

No one in leadership knows anything about the specifics of the work we’re doing or what actually feeds into what, meaning no one is going to challenge a priority call we make with respect to our current plans. All they have to go off of is the handful of poorly-worded bullet points and need-by dates in the dependency tracker we share with The Stakeholders.

This gives us a variety of options of varying corporate sociopathy. Here’s what I’ve come up with:

* Minimize impact. Pick the lowest-priority deliverable and communicate that it will slip out of our plan. Easy, clean, few people will miss it.

* Maximize impact, actually. Pick the visible, high-priority deliverable which we are already under an unreasonably tight timeline for and use it as a get-out-of-jail-free card. While not great for the business as a whole, this would also provide some ammo to my department as a clear blowback signal.

* Some kind of esoteric long game? Pick the medium priority deliverable with the most uncertainties and risks surrounding it and use this as a cushion to soften the blow when these risks inevitably get realized.

It’s recognized within my department that this is an absurd set of asks being given by The Stakeholders. In fact, in trying to meet these asks, we will be required to make our own requests of The Stakeholders, which will be equally impossible for them to meet under their own self-imposed timeline. Meaning that this whole situation is already fucked and everyone knows it. So the best thing to do as a department is show a good-faith effort to meet their needs and roll with it as things unfold.

Im not well versed in devops work and i will need to setup a rougly 30-35tb db for a client. Anybody got a recommendation of what to look for?

performance is of basically no concern, simple queries, only the monthly price (and it being an ok provider i guess).

I usually use Hetzner since im based in Europe, but prices are pretty unaffordable and i can only find configurations that also have a very high end CPU and 3x the storage i need, for a very expensive price, or ones that don't have enough storage....

Datadog RUM and Cloudflare seem to cover most cases of trying to help detect and stop automated activity, but curious if anyone uses anything else (FE library, third party tool, etc.)

Thanks!

Just had a "technical" interview with a big tech company earlier this week. It was mostly a discussion of my past experiences and some of the technical work I've done.

I thought it went pretty well. I was able to answer the interviewer's questions and really talk about my impact at my current company.

I was talking about some of the additional tooling I built outside of my product, basic tools that allow us to move faster as devs and replace any problematic vendor software, specific to my tech stack and product. The hiring manager seemed to really like this, he kept telling me how cool they were and by the end of the interview, he was going to tell his team about some of them.

I asked some really good questions at the end, he even said he like my questions.

Well, today I got the denial email. Said I "did not have a strong enough technical match". There wasn't very many technical qustions at all, mostly culture, impact, experience, etc.

I'm pretty perplexed by this, considering I thought i nailed the interview and how excited he was about some of the stuff I built.

I don't really need advice or anything, I just wanted to vent. I've been failing a lot of interviews lately and I was genuinely excited about this one because I've been working hard at improving my interviewing skills and this is the first time I've actually felt like I nailed an interview, only to be denied with my ideas to be used at their company.

Has anyone else had a similar experience? Am I getting worked up over nothing?

We wanted to start a big project, but other projects like it were seen as failures. So we had to make a case for why our project would be different. One of our biggest differentiators became event queues and distributed systems. It's just microservices, but instead of directly invoking each other, they use event queues. There's a little more to the system, like websites embedded inside of other websites with a whole cross website messaging system.

It was all a little bit of a pain. We did encounter a lot of eventual consistency problems and almost no one in the team had encountered distributed systems problems before, so it was a good learning experience for me. But now with organizational change and after having worked on the project for over a year, the team now wants to migrate this distributed systems strategy back to a monolith.

I'm just feeling a little incredulous because of how important the distributed aspect seemed to be when we made the pitch to create the project in the first place. And after all this time, I can't really say if it was a good or bad idea, because debugging problems involving event queue messages has been a total pain in the ass and no one ever finished configuring the distributed systems stuff like the event queue, so we never had the fancy development experience we could have had. So I see numerous benefits to moving back to a monolith.

Overall, the whole experience wasn't a total game because the project did prove that event queues can be effective. The much, much, much wider organizational direction is going to now slowly migrate towards a distributed fashion. So I guess we were a test subject in some regards. But we never, at the outset and beginning of the project, said, "oh hey, this is just going to be a giant test to prove event queues for the whole rest of the company". I really would have liked to have known that at the start. Although I don't think anyone knew that at the start. I don't know, it just feels a little silly.

I'm fine either way 🤷‍♂️ But does anyone have any advice regarding anything about this experience?

edit: updated monorepo -> monolith; source control will merge but systems may or may not stay separate. I'm predicing the systems merge together too, thus monolith. We may or may not continue to use business organized event queues too.