Dax Raad from anoma.ly might be the only CEO speaking honestly about AI right now. His most recent take:

“everyone's talking about their teams like they were at the peak of efficiency and bottlenecked by ability to produce code

here's what things actually look like

- your org rarely has good ideas. ideas being expensive to implement was actually helping

- majority of workers have no reason to be super motivated, they want to do their 9-5 and get back to their life

- they're not using AI to be 10x more effective they're using it to churn out their tasks with less energy spend

- the 2 people on your team that actually tried are now flattened by the slop code everyone is producing, they will quit soon

- even when you produce work faster you're still bottlenecked by bureaucracy and the dozen other realities of shipping something real

- your CFO is like what do you mean each engineer now costs $2000 extra per month in LLM bills”

I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.

• The best way I've advanced my career is by changing companies.

• Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.

• There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.

• I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.

• I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.

• If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

• pour another glass

• Qualities of a good manager share a lot of qualities of a good engineer.

• When I first started, I was enamored with technology and programming and computer science. I'm over it.

• Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.

• The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)

• Related to above, writing good proposals for changes is a great skill.

• Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.

• The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.

• If I ever find myself thinking I'm the smartest person in the room, it's time to leave.

• I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

• We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

• sip

• Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

• Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

• The greatest programming language ever is lisp. I should learn lisp.

• For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.

• Tests are important but TDD is a damn cult.

• Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.

• Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.

• Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.

• Work from home is the tits. But lack of whiteboarding sucks.

• I've never worked at FAANG so I don't know what I'm missing. But I've hired (and not hired) engineers from FAANGs and they don't know what they're doing either.

• My self worth is not a function of or correlated with my total compensation. Capitalism is a poor way to determine self-worth.

• Managers have less power than you think. Way less power. If you ever thing, why doesn't Manager XYZ fire somebody, it's because they can't.

• Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.

• Speaking of titles: early in your career, title changes up are nice. Junior to Mid. Mid to Senior. Senior to Lead. Later in your career, title changes down are nice. That way, you can get the same compensation but then get an increase when you're promoted. In other words, early in your career (<10 years), title changes UP are good because it lets you grow your skills and responsibilities. Later, title changes down are nice because it lets you grow your salary.

• Max out our 401ks.

• Be kind to everyone. Not because it'll help your career (it will), but because being kind is rewarding by itself.

• If I didn't learn something from the junior engineer or intern this past month, I wasn't paying attention.

• Oops I'm out of wine.

• Paying for classes, books, conferences is worth it. I've done a few conferences, a few 1.5k courses, many books, and a subscription. Worth it. This way, I can better pretend what I'm doing.

• Seriously, why aren't webdevs paid more? They know everything!!!

• Carpal tunnel and back problems are no joke. Spend the 1k now on good equipment.

• The smartest man I've every worked for was a Math PhD. I've learned so much from that guy. I hope he's doing well.

• Once, in high school, there was thing girl who was a great friend of mine. I mean we talked and hung out and shared a lot of personal stuff over a few years. Then there was a rumor that I liked her or that we were going out or whatever. She didn't take that too well so she started to ignore me. That didn't feel too good. I guess this would be the modern equivalent to "ghosting". I don't wish her any ill will though, and I hope she's doing great. I'm sorry I didn't handle that better.

• I had a girlfriend in 8th grade that I didn't want to break up with even though I didn't like her anymore so I just started to ignore her. That was so fucked up. I'm sorry, Lena.

• You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That's pretty cool.

• There's not enough women in technology. What a fucked up industry. That needs to change. I've been trying to be more encouraging and helpful to the women engineers in our org, but I don't know what else to do.

• Same with black engineers. What the hell?

• I've never really started hating a language or technology until I started becoming intimately familiar with it. Also, I think a piece of tech is good if I hate it but I simultaneously would recommend it to a client. Fuck Jenkins but man I don't think I would be commuting software malpractice by recommending it to a new client.

• That being said, git is awful and I have choice but to use it. Also, GUI git tools can go to hell, give me the command line any day. There's like 7 command lines to memorize, everything else can be googled.

• Since I work in data, I'm going to give a data-specific lessons learned. Fuck pandas.

• My job is easier because I have semi-technical analysts on my team. Semi-technical because they know programming but not software engineering. This is a blessing because if something doesn't make sense to them, it means that it was probably badly designed. I love the analysts on the team; they've helped me grow so much more than the most brilliant engineers.

• Dark mode is great until you're forced to use light mode (webpage or an unsupported app). That's why I use light mode.

• I know enough about security to know that I don't know shit about security.

• Crap I'm out of wine.

• Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.

• If people are trying to assign blame to a bug or outage, it's time to move on.

• A lot of progressive companies, especially startups, talk about bringing your "authentic self". Well what if your authentic self is all about watching porn? Yeah, it's healthy to keep a barrier between your work and personal life.

• I love drinking with my co-workers during happy hour. I'd rather spend time with kids, family, or friends.

• The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would've walked over fire for her.

• On the same token, the best leaders I've been privileged to work under did their best to both advocate for my opinions and also explain to me other opinions 'that conflict with mine. I'm working hard to be like them.

• Fuck side projects. If you love doing them, great! Even if I had the time to do side-projects, I'm too damn busy writing drunken posts on reddit

• Algorithms and data strictures are important--to a point. I don't see pharmacist interviews test trivia about organic chemistry. There's something fucked with our industry's interview process.

• Damn, those devops guys and gals are f'ing smart. At least those mofos get paid though.

• It's not important to do what I like. It's more important to do what I don't hate.

• The closer I am to the product, the closer I am to driving revnue, the more I feel valued regardless of how technical my work is. This has been true for even the most progressive companies.

• Linux is important even when I was working in all Windows. Why? Because I eventually worked in Linux. So happy for those weekend where I screwed around installing Arch.

• I've learned to be wary for ambiguous buzz words like big data. WTF is "big" data? I've dealt with 10k rows streaming every 10 minutes in Spark and Kafka and dealt with 1B rows batched up hourly in Python and MySQL. Those labels can go fuck themselves.

• Not all great jobs are in Silicon Valley. But a lot are.

Finally, if you really want to hurt me, don't downvote I don't care about that. Just ignore this post. Nothing makes me sadder than when I wrote a long post and then nobody responds. So if you hate this post, just ignore.

Jokes aside, GitHub/Microsoft recently announced the public preview for their GitHub Copilot agent.

The agent has recently been deployed to open PRs on the .NET runtime repo and it’s…not great. It’s not my best trait, but I can't help enjoying some good schadenfreude. Here are some examples:

• https://github.com/dotnet/runtime/pull/115762

• https://github.com/dotnet/runtime/pull/115743

• https://github.com/dotnet/runtime/pull/115733

• https://github.com/dotnet/runtime/pull/115732

I actually feel bad for the employees being assigned to review these PRs. But, if this is the future of our field, I think I want off the ride.

EDIT:

This blew up. I've found everyone's replies to be hilarious. I did want to double down on the "feeling bad for the employees" part. There is probably a big mandate from above to use Copilot everywhere and the devs are probably dealing with it the best they can. I don't think they should be harassed over any of this nor should folks be commenting/memeing all over the PRs. And my "schadenfreude" is directed at the Microsoft leaders pushing the AI hype. Please try to remain respectful towards the devs.

I’m a freelance software engineer with about 8 years of experience mainly in early stage startups. At this point, I have a pretty steady flow of referrals. I don’t take every project on and not every one works out, but enough do that I can do it more than full time.

Lately, though, I have noticed a large increase in projects where they paid a ton of money for an internal software and it does not work well at all. Tons of errors, unreasonably slow, inefficient and taking up a lot of resources, and large security flaws. At first, I thought maybe people just hired bad developers. The bar is pretty low to call yourself a developer or even a software engineer anyways, but I’m seeing the same problems now on multiple projects.

When I take on a project on, I always sign an NDA and look at their codebase to look at some upfront issues that I can bring up because, most of the time, the people hiring me aren’t technical and don’t understand what the problem is. This is probably the 5th time now that a lot of the code was obviously AI generated. Comments in the code that were obviously written by AI, algorithms that are inefficient and make no sense, cluttered data structures, inconsistent coding patterns, etc. The overall thing is that, yes it mostly works, but does so terribly to the point where it needs to be fixed.

It might be a few years before we start to see this on an enterprise scale, but I’m noticing this becoming a serious problem for small businesses and startups, especially when the founders / people are in charge aren’t technical enough to identify this ahead of time.

My job recently introduced Copilot subscription for every dev, and of course devs started using it. We write embedded/desktop apps using C++ and Python, and from my experience Copilot is not really good in that domain (especially in very niche domains like ex. implementing COM interfaces on Windows, or using OS APIs).

It's becoming frustrating when I am looking into the PR or talking live with my colleagues about their code, because something is not working and they seek help, and when I ask why they wrote something I hear "because Copilot suggested that". Of course, the suggested code is garbage.

It sometimes even more ridiculous - I send someone a link to the documentation and point the relevant sections with code examples about how to do something. You need to write/do exactly what is in the documentation. Later I get the message on Slack that "it is not working, can you look?" and of course the code written is just the garbage Copilot hallucinations...

And it's not even juniors, it's people with 10-15 YOE...

I was not expecting that LLMs will make my life miserable so quickly, and not because of me being laid of, but because my colleagues thinks they are much more useful than they are in practice.

Many of you have already read the news that Amazon is planning to let go 14,000 management people. Many of my friends and myself work(ed) in companies where the culture was destroyed after brining in Amazon management people. Usually what happens is that once you hire one manager/director from Amazon, they will bring one after another into your company and then completely transform your culture toward the toxic direction.

Be aware at any cost, folks!

Disclaimer: I am only referring to the management people such as managers/directors/heads from Amazon. I don’t have any issues with current and former Amazon engineers. Engineers are the ones that actually created some of the most amazing products such as AWS. I despise those management people bragging they “built” XYZ in Amazon on LinkedIn and during the interviews.

Edit: I was really open-minded and genuinely welcome the EM from Amazon at first in my previous company. I thought he got to have something, so that he was able to work in Amazon. Or even if he wasn’t particularly smart, his working experience in Amazon must have taught him some valuable software development strategies. Few weeks later, I realized none was the case, he wasn’t smart, he didn’t care about any software engineering concepts or requirements such as unit testing… etc. All he did in the next few months was playing politics and bringing in more people from Amazon.

June edit: It wasn't worth making an entirely new post just for this, but someone followed up asking what my experience has been like after 6 months. You can see my reply here: https://www.reddit.com/r/ExperiencedDevs/comments/1gz9ksj/my_senior_engineer_interview_experiences/mueldum/

I recently wrapped up a ~3 month gauntlet of studying and interviews and came away with 3 L5 offers, and a lot of people on Blind found my tips (in the OP and DMs) to be useful, so I wanted to write a similar post here.

The SWE market is much different now than 2020-early 2022, and I've noticed that these kinds of posts have consequently appeared much less often now compared to that period of time. Since I have the benefit of typing this on my computer instead of the Blind app, I'll try and be more thorough to make this more than a "TC or GTFO" post.

As a disclaimer, I only have 6 YoE, and I was hesitant about even sharing this here, since many people here have been doing this since before I was born. It's kinda like the people asking "how do I start saving money" on /r/fatFIRE . But then, I figured I can't do much worse than Yet Another Leetcode Complaining Post. So, take it with a grain of salt as you would anything else that a barely-thirty-year-old would say, but I hope someone out there finds it useful!

Background:

• 6 YOE

• Previous FAANG experience

• Currently employed

• All of my experience has been in the SF Bay Area

The Job Search / How I Got Interviews in the First Place:

• I was only interested in companies able to pay $350k and higher in total comp (signing bonus not included)

• I preferred public companies, as I've already done the "hope and pray for an IPO" thing, and wasn't a fan. Of course, if e.g. OpenAI or Databricks came knocking (they didn't), that "requirement" would go out the window ;)

• I was not limiting myself to full remote jobs, but it did need to be local to the bay area otherwise.

I applied to around 20 companies via LinkedIn and directly on their website. Given my previous requirements, the list of companies that I could apply to was pretty small. It was pretty much the usual suspects: FAANG, Uber, Airbnb, etc. Notably, I did not hear back positively from a single company that I applied to via a job portal. I either got a rejection email or ghosted. This was in stark contrast to my last job search, where I was inundated with recruiter messages from the same companies. What remained were the few companies that actually reached out on their own accord, or with whom I had a direct recruiter contact: LinkedIn, Meta, Google, Doordash, and some practice companies to get the nerves out.

Preparation:

I knew I would need to be prepared for system design interviews, and historically those are my weakest ones (again, 6 YOE...), so naturally I focused the most on that.

First, I'll just get Leetcode out of the way:

• No, it has nothing to do with the job, but everything to do with "do you actually want the job". So, coming to terms with it is my recommendation.

• It is IMO easier to pass these interviews than the non-LC ones, because there's only so many different types of questions, and no company besides Google is coming up with their own original LC questions.

• For Meta specifically, just know the top 100 or so tagged questions, don't overthink it.

• I didn't waste time trying to figure things out on my own for 30 minutes first, unless it was a very easy problem. I just learned the solutions through spaced repetition. I'm convinced that this is the most time efficient way to pass LC interviews, but it sucks if you want to be a competitive programmer, or if you just really want to learn Leetcode for whatever reason. Personally, I only do Leetcode to pass interviews, not for fun or the love of algorithms.

• You're far more likely to fail or be downleveled because of SD or behavioral.

System Design

I was asked the typical kinds of problems at every company except Google: Design xyz popular service/infrastructure functionality. For those types of companies, I'd say that all you need is HelloInterview (free at the time of writing, no affiliation) and Alex Xu's 2nd book, provided you have the necessary background to comprehend those resources already. Doordash's questions are small in number and available on the Leetcode Discuss forums.

For Google, their SD interviews are not so formulaic or predictable, and it's the only company that having knowledge of OS and Systems fundamentals was in any way useful throughout the interview process. Here are some more resources that I used - mostly because I just love reading this kind of stuff, not because it's exactly necessary:

• Onsites.fyi $40 annual payment was worth it

• codemia.io - Decent

• DDIA - Honestly just wait for the 2nd edition next December if you're not in a rush. Otherwise, read the first 2 parts. Controversially, this is not very helpful for a 45 minute interview (which it was not designed for), but invaluable if you want an amazing reference for actually learning distributed systems topics and database internals.

• One of the only good things to come out of Blind

• https://cpu.land/

• https://blog.acolyer.org/

• Systems design for advanced beginners

• Scaling Geospatial Queries w/ Redis

• Redis pubsub internals(this actually came in handy)

• The words of a very good programmer who thinks even more highly of himself

• Zero copy data transfer - used by Kafka and this was the best written resource I found on it. Everything else was just a bunch of medium blogs rehashing the same surface level crap. Thanks IBM!

• False Sharing - believe it or not, this was critical for Google

• The Architecture of Open Source Applications

• Raft Protocol Visualisation

• Codecrafters is cracked, seriously. I learned more about the internals of Redis, SQLite, etc. from this than any other resource.

• Any of Tim Berglund's content. The guy is in a class of his own when it comes to explaining highly technical concepts.

• Think Fast Talk Smart - his similarly named audiobook is golden too.

• Code 2nd edition by Charles Petzold

• Inside The Machine by Jon Stokes

Okay, I'll admit that the last two are useless for SD interviews, but they're so well written that I had to shill for them.

What's more important than reading any of this stuff is getting real life practice, whether that's through mock interviews, HelloInterview's practice tool, or by badgering your wife with explanations of the Byzantine Generals problem. I went with the latter two, but I've read good things about HI's mocks. It's very easy to convince yourself after reading some prep material that you've "got it", only to bomb the actual interview by blankly staring at Excalidraw. Ask me how I know!

One interviewer at Meta made it clear via his questions that he himself had studied HelloInterview, and was asking questions that are specifically brought up in their content lol. Knowing what your interviewers are looking for is 90% of the SD interview.

During some of my interviews, I actually had to diagram a system that I'd designed myself at work, rather than being given a hypothetical system to design. Expect every architectural decision to be questioned and drilled into. And if you aren't prepared to speak at length and deeply about a cross-team, highly impactful project you personally led, good luck.

Behavioral

These are the easiest types of interviews for me. I'm a strong speaker and have never had a problem disambiguating any topic that I am familiar with, and my own work certainly falls into that category. With that being said, I did practice answering common "tell me about a time..." questions out loud to my (outstandingly patient if you haven't already noticed) wife, and asked her to try poking as many holes into my stories as possible until I reached a breaking point. Regardless of your resume or experience, prepare to be challenged on everything you say. Was the impact you demonstrated really because of you, or were you simply along for the ride? The interviewer needs to believe without a doubt that you're capable of bringing a high-impact, xfn project from inception through to post-launch care with minimal hand-holding. This probably goes doubly so for those of you with much more experience than I, aiming for L6+ roles. There are other posts on this sub with advice for those more senior positions.

On 1point3acres

Out of the 80+ dms that I've responded to on Blind, this was the most frequently discussed topic:

"Is 1p3a worth it?"
"How do you properly translate it?"

So, this topic gets its own section. If you don't know, 1point3acres is a Chinese interview cheating advice website, wherein the users share internal question banks, and try to get themselves assigned to interview specific people so they can pass them along in their interviews. The issue (among others) is that the site is in Chinese, and the users use a certain type of slang system to ensure that Google doesn't properly translate the true meaning of what they're saying.

So what do you do about it? You use ChatGPT to translate it instead. It figured out how the code words are determined - they basically use Chinese characters that translate phonetically to the intended English words, but make no sense when translated verbatim. I found this to be an invaluable resource, because they share questions for Meta, Doordash, and Google that don't make their way to Leetcode/Blind/Onsites.fyi nearly as quickly. There are WeChat groups where people do the aforementioned interview rigging, but as a regular-ass American I'm not able to speak first hand about that.

The Offers

I passed Meta, LinkedIn, and Google, failed Doordash, and bombed a couple other random interviews. The Blind post has the Meta/Google offers: https://www.teamblind.com/post/zc2bRCUO (486k+100k signing bonus for meta, $442k+50k signing bonus for Google). I didn't bother continuing team matching with LinkedIn despite having great things to say about the interviewers and company, because they simply can't come within $200k of my Meta/Google offers without being upleveled to Staff. Meta's offer represents a ~3x increase in total comp compared to my current company, in the same city.

The Meta, Google and LinkedIn recruiters were amazing to work with.

Timing these offers was a nightmare. Meta's team matching took 2 weeks, and that's pretty expeditious! Meanwhile, I had to stall the Google offer as long as possible, and then some more, because Meta is not giving anyone a max E5 offer without a strong competing offer from a "peer" company like Google, Tiktok, OpenAI, etc.

Conclusion

I started writing this in notepad, just to share with some of my colleagues that have been laid off from my company earlier this year and are still looking for jobs in a tough market, but I hope that it is also useful to a wider audience, and future Google searchers too. Feel free to dm any questions. I use old Reddit, so I might not see the new dm request things that New Reddit does.

Preface: 8 YoE, Big company (where I work) acquired a small but very successful product last year. I recently moved over to this product to help integrate it into our suite of software.

Story: Unfortunately, this product lacked any sort of staff tooling, so support requests were more often than not accomplished by running SQL directly on the production database (💀).

One of the most standard requests was updating product codes that were specific to a user's account, i.e. a given product code for one user would not work for another user. The SQL boiled down to:

UPDATE "users"
SET "product_access_codes" = "..."
WHERE "users"."id" = '289571032';

Last week, while on-call, I wake up to an "urgent" request to enable a user's product codes in time for a demo "very soon". Having done this countless times, I whip up and run the following:

UPDATE "users"
SET "product_access_codes" = "...";
WHERE "users"."id" = '289571032';

Notice anything? Well I didn't until I saw the dreaded "12857294 rows affected" result. There is truly no stronger stimulant than the realizing that you just bricked the production database by overwriting the user table with bad data.

After coming to terms with the reality of my situation over the next 10 seconds (felt like 10 hours) I hit up our SRE team and give them the bad news.

Outcome: Luckily for me, our SRE team had backups configured such that we were able to restore the database to the state ~2 minutes before my mishap. Total downtime ended up being ~20 minutes while we ran the restore.

After the dust settled I'm glad to report I did not in fact lose my job. I did feel incredibly embarrassed, but equally thankful for my coworkers being empathetic and understanding that mistakes can happen. My EM blamed the situation more on our lack of tooling, so we sliced up some time last week to write our first version of staff tools.

Takeaway: Doesn't matter how many times you've done something or how long you've been in the game, fuck-ups do happen and often when you feel the most complacent. This was a query I'd written many times over; the early morning request plus the urgency led me to get complacent and cut corners.

More importantly though, in retrospect, always turn off autocommit in your production DB sessions. I could have avoided the entire situation had my SQL instead been

\set AUTOCOMMIT off
BEGIN;
UPDATE "users"
SET "product_access_codes" = "...";
WHERE "users"."id" = '289571032';

Upon seeing the syntax error and rows affected output I could have just ran ROLLBACK and avoided the whole situation. I honestly wanted to write this post mainly just to call out the fact that anytime you run SQL in production it should be wrapped in an explicit transaction.

I am a mid-level dev on a team and we recently hired another mid-level dev. He is really nice, but is constantly working. I am seeing him commit code at 2 am, 7am, 3pm, 10pm etc. And he is taking most the tickets in the backlog. He completed an entire epic in 3 days working overnight. It's starting to make what was once a great team environment feel hyper competitive and stressful, as I have to scramble just to get work before he gobbles up several more tickets. And now I'm spending more time just reviewing his work than doing my own. In standup he is getting praised as a 'superstar', but in my view he is making the work environment a bit toxic.

I want to bring this up to my lead at my next 1:1, but I'm not really sure how to phrase it as I dont want to be viewed as petty or lazy. Any advice?

I've been freelancing on the side for more than couple years now, mostly helping startups and smaller teams fix bugs, add features, the usual stuff.

Used to be maybe 1 or 2 projects a month. Now I'm turning people away because there's too much work coming in. And I'm pretty sure I know why.

About 70% of the requests I get now are basically "we built this with AI and it doesn't work, can you fix it?"

tbh I'm not mad about it. The money's good and the issues are usually pretty straightforward once you dig in. Last few weeks alone I've seen zero input validation, hallucinated libraries that don't exist, payment logic that does the opposite of what the comments say. The security stuff is wild. Apparently 45% of AI-generated code has vulnerabilities and I believe it.

Don't get me wrong, people hired me to clean up messy code before AI too. But it used to be like 1 in 10 projects. Now it's most of them. And the pattern is always the same, looks clean, runs fine once and then falls apart when complexity hits.

My income's up like 40% from last year and I barely market myself anymore. People just find me when their vibe-coded MVP starts breaking under real use.

So yeah, thanks AI. Best thing that happened to my side hustle. Hope this keeps up:)

As someone has seen a lot of tech trends come and go over my 20+ years in the field, I feel inspired to weigh in on my take on this trending question, and hopefully ground the discussion with actual hindsight, avoiding panic as well as dismissing it entirely.

There are lots of things that used to be hand-coded that aren't anymore. CRUD queries? ORM and scaffolding tools came in. Simple blog site? Wordpress cornered the market. Even on the hardware side, you need a server? AWS got you covered.

But somehow, we didn't end up working any less after these innovations. The needed expertise then just transferred from:

* People who handcoded queries -> people who write ORM code

* People who handcoded blog sites -> people who write Wordpress themes and plugins

* People who physically setup servers -> people who handle AWS

* People who washed clothes in a basin by hand -> people who can operate washing machines

Every company needs a way to stand out from their competitors. They can't do it by simply using the same tools their competition does. Since their competition will have a budget to innovate, they'll need that budget, too. So, even if Company A can continue on their current track with AI tools, Company B is going to add engineers to go beyond what Company A is doing. And since the nature of technology is to innovate, and the nature of all business is to compete, there can never be a scenario where everyone just adopts the same tools and rests on their laurels.

Learn how AI tools can help your velocity, and improve your code's reliability, readability, testability. Even ask it to explain chunks of code that are confusing! Push its limits, and use it to push your own. Because at the end of the day/sprint/PI/quarter or fiscal year, what will matter is how far YOU take it, not how far it goes by itself.

Some of the tickets I see are so badly written and communicated that it's left me thinking that, as an industry, we underestimate how important it is for staff to be able to write clearly and succinctly.

The amount of time we waste seeking clarification when it comes to tickets must be huge.

It makes sense when you think about it - we put people through all sorts of assessments during interview - competency interviews, coding assessments, take home challenges - and yet we don't seem to care whether a new hire can write well.

What makes it even worse is that this skill has become even more important with the rise of working from home and with many of us communicating over Slack/Teams/etc..

I was reviewing PRs from data scientists (python developers) for the web service. The data scientists were using Claude Code to generate changes to the web site (rails/vue) and send PRs to the web developers. I made a decision that I no longer want to review this code, since it's AI generated and people who generate it do not understand it. The reason is that I find it very easy for me to miss issues during such PR reviews, because the AI generated code looks good and plausible, so it will lead to bugs and security issues.

Today we had a company-wide meeting, and during my turn I explained the issue and announced that I no longer be reviewing these PRs. It went surprisingly well. I got massive support from people and the leadership also acknowledged the issues. I can now go back to what I love the most -> writing code :D.

Update: I think I was not clear in my post and the title is misleading -> I apologise. I have no issue with programmers using AI at all (I use it myself all the time). The problem is that the people who used the AI to make those PRs do not understand the code it generated.

Update #2: Thank you all for contributing to this discussion and for support, I learned a lot from your comments, with the two particular insights I want to highlight:

1. The issue is code that nobody truly owns or understands. Review breaks down when the reviewer becomes the only person reasoning about the system.

2. The cost ratio between generation and review has collapsed, and the reviewer absorbs most (all?) of it.

I recently transitioned to an EM role so am observing a lot more peer-to-peer conversations rather than being directly part of them. I'm also getting the one-sided vent from my reports after certain meetings.

I really thought this was more of a Reddit thing but no it's 100% all over the place in my industry and it's really holding some of you back. If a person doesn't understand X concept or hasn't used Y tech or doesn't know about Z feature, just fucking explain it. Don't get exasperated. Don't act frustrated. Just take the 15 seconds to explain it, it really really isn't that hard.

I know of at least 2 IC's at my company that are decent engineers and were only held back from promo because there was someone in the review board that discussed them being rude / disrespectful to people that asked questions / didn't understand something.

Just be nice. Most of us are idiots so that probably includes you too.

My team currently has two junior devs both with 1 year old experience. Unlike all of the juniors I have met and mentored in my career, these two juniors startled me by their lack of interest in software engineering.

The first junior who just joined our company-

• ⁠When I talked with him about clean coding and modularizing the code (he wrote 2000+ lines in one single function), he merely responded, “Clean coding is not a real thing.” • ⁠When I tried to tell him I think AI is a great tool, but it’s not there yet to replace real engineers and AI generated codes need to be reviewed to avoid hallucinations. He responded, “that’s just what you think.” • ⁠His feedback to our daily stand up was, “Sorry, but I really don’t care about what other people are doing.”

The second junior who has been with the company for a year-

• ⁠When I told him that he should prioritize his own growth and take courses to acquire new skills, he just blanked out. I asked him if he knew any learning website such as Coursera or Udemy and he told me he had never heard of them before. • ⁠He constantly complains about the tickets he works on which is our legacy system, but when I offered to talk with our EM to assign him more exciting work which will expand his skill sets, he told me he was not interested in working on the new system which uses modern tech stacks.

I supposed I am just disappointed with these junior devs not only because after all these years, software engineering still gets me excited, but also it’s a joy for me to see juniors grow. And in the past, all of the juniors I had were all so eager to seize the opportunities to learn.

Edit: Both of them can code, but aren’t interested in software engineering.

The biggest problems I see are a culture of thinking we live in a meritocracy when we so obviously don’t, and the fact if engineers went on strike nothing negative would really happen immediately like it would if cashiers went on strike. Does anyone have any ideas on how to pull off something like this?

Companies are starting to cut remote work, making employees lives harder, just to flex or layoff without benefits. Companies are letting wages deflate while everyone else’s wages are increasing. Companies are laying off people and outsourcing. These problems are not happening to software engineers in countries where software engineers unionized.

Juniors are some of the most creative thinkers in this industry because they haven't been conditioned to use tools and techniques that have matured over time. They're more malleable to new tech. Their solutions come from a place of curiousty rather than ego and it just feels nice to help someone else grow in their career.

I miss being a mentor, I miss having study groups for certs, I miss my friends that were laid off this year and last :(

I'm so tired of fighting for good engineering practices. Clean code, high quality tests, pragmatic use of AI, code de-duplication, extensible design, and so on. Yes all these things are good - but they have never once rewarded me.

The only thing I ever see get rewarded are

1. High volume & high quality engagement in meetings

2. Ability to attach metrics to your work and then make those metrics look good

3. Creating brand new features / tools (improving existing stuff is no-value)

It doesn't matter how clean we get the code. It doesn't matter how many defects we prevent. It doesn't matter that spending 20% more now means every quarter for the next 3 years we spend 10% less. It doesn't matter if you convince your tech lead or EM or PM to go a different way. It doesn't matter if you have high quality & actionable metrics, you just need numbers that look good. 200% increase in usage sounds better than "we have 2 new users". None of it ever matters.

99% of doing well in this industry a the senior+ level is treating every day like a sales meeting. You're not an engineer, you're an expensive product that needs to convince your customer to renew their subscription.

I initiated a feature freeze at the start of 2024 as we didn't have the staff to support adding and maintaining any more features to the core of our product. We had turnover and layoffs and could barely support what we had already. Obviously this was unpopular off the tech team, and executives in general wanted to keep pushing new features to keep up and "capture the market with new generative AI features"

Anyways I ignored all of this and simply refused to have the team develop these features until we had more staff.

Since then, our clients feedback on our system has improved tremendously. They say it is faster, more stable and they are loving how it consistent things are working. Also, they are discovering features they never used before and are now actually using them and liking them. I don't know if they realize there was a feature freeze.

Previously they complained things were too unstable and often breaking in ways that were really bad. But the executive team wanted ABC feature done by QN so we had to deliver fast.

Now they are giving great referrals and we are getting more and more sign-ups and sales through the pipeline from good word of mouth.

Execs are now calling me a genius, saying they love how I turned around the product and saw through their true vision (by ignoring, iceboxing all feature requests) and that we've already exceeded our targets for Q2 and Q3 for the year and are set up for a great raise in 2025.

So yeah idk what to takeaway from this but I found it really funny.

Most of the devs at the company (~1000 total employees) use Jetbrains IDEs for development. This morning it was announced that all Jetbrains products were to be removed from workstations and that everyone needs to switch to.... anything else.

We are primarily a Go and Python shop, which means our only real option is VSCode. If anyone has ever gone from a Jetbrains IDE back to VSCode, you likely know that this transition feels pretty bad. Several other teams use Java extensively, so they at least have the option of using Eclipse.

The official reason given was that Jetbrains has Russian ties. No amount of arguing could get leadership to reverse the decision.

Are other companies doing this? It feels absolutely absurd to me. In order to get similar functionality out of VSCode, people on many teams are downloading third-party plugins written by random people on the internet, which I have to imagine is far worse for security than using Jetbrains products ever will be.

I know like me a lot of y’all are coming up on your performance reviews or they just passed and I wanted to talk about a habit that I feel like a lot of people might not know about.

When performance reviews came around I would spend hours searching slack and jira tickets about what I did the last year, it was incredibly frustrating. About two or so years ago I got a new manager that taught me about brag documents, basically you fill it out through out the year to have all your accomplishments in one document. We did monthly summaries, every month I’d fill out what I did for the month and send it to my manager. It helped a lot during last year’s performance review. Unfortunately, I started filling out my monthly summaries a month later or a few weeks after the week ended cause I was so busy. Still helpful but still stressed me out when I’m trying to focus on coding.

I realized doing it weekly is the hack. Choose the same time every week for me it’s Friday at like 3 and I take 5 mins to log the top accomplishments from the week. Made it easier to make a habit of it rather than forcing myself to write a big review later in the month or year.

Feel free to use this template, it’s simple but gets the job done.

• win: shipped X / fixed Y

• before / after: 310ms / 190ms

• metric:

• who benefited:

• evidence: link/screenshot

Ive used notion, google doc and sheet and kudos notes and honestly they all work fine. Use what you feel the most comfortable with and will help you keep the habit up.

if you track wins, what changed for you at review time? any tricks to keep the habit going in month 5–6 and beyond?

TL;DR: track your accomplishments weekly, it makes it easier to remember what you did the last week rather than year.

So last week I was tinkering with how to change up our technical interview round. For the last few years we’ve been doing a small take home followed by a live coding session where we add a new requirement, minimal AI assistance allowed. However, in our company pretty much everyone is writing 100% of code using Claude now, so although we did used to get good signal from that test, it no longer feels representative of the day to day job developers are doing.

I designed a new assessment which I casually showed to my manager and then suddenly got asked to run it with 3 candidates this week. The scenario is they have to review an agent generated PR that has been flagged as high risk due to it changing critical business logic, and there are bugs in there for them to catch at various levels of severity. We then look at how they drive the fixes and what their workflow is like.

These particular roles we’re currently hiring for are billed as “AI Engineer”. There is something weird going on in my company politically where separate from the tech department that I work in a new “AI native” development team is being spun up to work on internal projects.

What shocked me was that the candidates I interviewed this week are already way beyond the point of reading the code they generate in any capacity. They basically treat it like assembly language, while PRDs and ADRs are their new source of truth for system behaviours, and stuffing the AGENTS.md file with best practices plus some form of agentic review pipeline are the quality control. 

Code review is dead for them, they merge their own PRs once the automated checks pass. One person told me that my new interview was still not representative of what the job is now, and another one was pretty much unwilling to even engage in the assignment of reviewing a PR the old fashioned way. These guys were all previously senior and lead full stack engineers btw with a lot of experience prior the LLM revolution.

Don’t get me wrong, I too have adopted AI heavily in my own workflow. Until this week I actually thought I was pretty up to date with things, I use a supervising agent to manage multiple work streams in parallel, have my own local validation pipeline, etc. And to be honest for my personal projects I also don’t bother looking at the code anymore, so I do get the excitement around how fast you can move with this approach. But for serious projects like the large scale, production grade financial software I work on in my day job it still seems insane to me that we’re going to completely move away from human sign off on high risk changes so we can solve the “code review bottleneck”.

Like, I asked one of the candidates if you aren’t looking at your code then how they would approach quality in a safety critical system where there can be no tolerance for serious bugs, and I shit you not he said to me, “well if I was working in healthcare or sending to people into space then I’d definitely be looking closely at the code review skills, maybe I’d even write the skills myself”. That answer sounded utterly ridiculous to me? But then again, I was one of the people that 1 year ago believed the idea we’d stop typing code by hand was ridiculous as well…

I wouldn’t say the way my team does things right now is optimal, we can’t ignore that code review fatigue is a major problem. To try and help I’ve been adding automated risk assessments to PRs in an attempt to highlight where more attention is needed, and review bots do help us catch issues as well. But abandoning the human 4 eyes check just feels like several bridges too far for us at the moment, especially when not everyone is senior engineer, and we still regularly get valuable feedback at this stage. Even if this does mean we’re turning down an order of magnitude increase in short term velocity (does anyone really know yet what happens over multiple years when you have a team of 20 devs spamming PRs all day into a codebase with no one looking at any at it?).

I’m left wondering this weekend, were these guys just cowboys who are only used to working on PoCs and low risk systems, or is my team actually 6-12 months behind the curve and this is the direction everyone is going to move in? I fear that if we don’t embrace this new era of completely surrendering the codebase to the LLMs then this new team of AI devs is going to make us look bad by comparison to the execs and sooner or later we will be forced to adopt their methods as well. And at that point, the leap to having a product person or whoever taking over large parts of my role starts feeling a lot less far fetched…

I am sick and tired of all the posts (usually AI-generated by CEOs/CTOs/"thought leaders") that start with "Code was never the {bottleneck, problem, hard part, ...}." I'm not sure whether this comes from a misunderstanding of what code is or a deliberate misrepresentation meant to promote AI usage.

For starters, two rhetorical questions. If code was never the hard part, why:

• do hundreds of different programming paradigms, languages, libraries, frameworks, design patterns, and system architectures exist? Granted, some of this is just programmers bikeshedding. Still, plenty of it reflects substantial differences and tradeoffs.

• didn't you write it yourselves or hire a bunch of minimum-wage workers to do it for you instead of having to hire a ton of highly skilled (and highly paid) engineers?

A charitable explanation is that these people are genuinely clueless about what "coding" actually is. Perhaps in their mind coding is just typing: like, once the design phase is done, you've worked out a precise, complete specification of what needs to be built down to every detail in your head (or on paper or a markdown file) and all that's left is converting it into letters on a screen and saving it to a file. Something like a businessman in the sixties dictating a letter to his secretary to type up.

That's nothing like how it actually works. The upfront planning/design phase answers some high-level questions: what do we need to build, what are the basic components/services/building blocks, what data needs to be read/processed/written, how data flows through the system, what the non-functional requirements are, etc. That leaves a ton of lower-level details unspecified:

• What packages/modules/classes/methods/functions need to be created or extended?

• How should they be named?

• What should the signature of each function be?

• What errors/exceptions are expected and where/how should they be handled?

• What data can or should be cached and when should it be invalidated?

• How generic/reusable/extensible should each component be to accommodate likely future requirements?

• For systems languages, how and when is memory allocated and freed?

• and many more.

Asking and answering those questions is (part of) coding. At least before AI, nobody I know had all the answers, or had even asked all the questions, upfront. The questions get asked and answered on the fly, inside the editor. Typing is interleaved with thinking, assessing, trying things out, backtracking.

Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Regardless of how the future of coding plays out, "code was never the hard part" is flatly wrong. It is, or at least used to be, a hard part (not the only one of course) and for good reason.