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.

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?

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.

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....

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.

Second time posting (was not aware of the flair rule)

Human man here, I have gotten off of the ai hype train a while ago.

I stopped paying real attention after sonnet 4.6. While I won’t say I have an unlimited budget but I get enough to use whatever. I once again went back to 4.6 from sonnet 5 and the opus ones.

So just in case my question is not clear. Am I really missing out? Am I promoting wrong (slight sarcasm).

Or am I boiling less water? The results have not blown me away, sonnet 5 aggravates me with its push back over thinking for meh results. Opus just burns tokens.

No I did not use AI at all, but ask me again I know the rules.

I'm having this discussion at work right now, but when I tried to research I found remarkably little discourse on it online.

So, say you have a main/master branch, a develop branch, and possibly one or two release branches. Normally commits go from dev -> release -> main, no dramas.

Now suddenly you need to hotfix main, how do you get that commit to all the branches? I maintain it's best to merge into main, merge main into release 3.1, merge 3.1 into 3.2, merge 3.2 into dev (assuming 3.1 and 3.2 are active releases being QA'd right now).

The other school of thought is to merge the hotfix branch into all 4 branches independently.

My argument is that a cascading backmerge ensures no conflicts when it comes time to merge develop into main (as with independent merges, it could do the change differently on the different branches)

Would love to know what others think, am I the weird one here or is cascading backmerge something others do too?

We've started a new practice at work where every 'entity' that's owned by a service gets defined in a certain repo/library as a protobuf file, so that other services can use them, regardless of the service's language

The library also defines the GET/POST endpoints used with the entities

On paper this makes sense, global contracts, don't break them, multiple services can just use the library for getting the endpoints/contracts and trust that it's correct

I am, however, somewhat skeptical. I feel like this isn't solving any actual issue, and that the added cost of having to open a PR to a shared library in order to add some endpoint is just extra busywork that will ultimately slow everything down for very minimal rewards

Would love some thoughts/experiences with such a work flow

​

Hello guys,

The title basically says it all - how should I deal with oncalls that were NOT discussed with the people (eg., me) who shall be on the calls?

I have been at this company for around a year, and last quater I got onto this team that has a very unstable, yet very important product. There were multiple outages at monthly/weekly basis, and our teamlead solved most of them. He got this idea, (and I actually get it) that we shall have oncalls, and he discussed it with the higher ups and got what he wanted.

My problems are basically twofold:

1) Even when I get why we are having them, not discussing it with us is a major red flag for me, and there is no "opt out". I have a stable second job for a friend on the weekends, and this totally removes any possibility for me to work for him anymore (because guess who took all the weekday oncalls).

2) The team has this very weird policy "simplicity over anythig", which has lead to me clashing with my teamlead on multiple ocassions - we are rather producing invalid domain models and move the complexity onto the cognitive load rather than write 10 more LoC ... I find it impossible to improve the product in this environment to the point we remove the oncalls.

I would also like to disclose that I don't have too much spare money as now I am focussing on family - got a mortgage, going to buy a new car etc.

I've passed two interview loops of system design interviews up until this point in my career for mid level engineering roles. I'm a senior engineer now going through recruiting again and am curious if the system design interview rounds will be roughly evaluating the same things for senior vs mid level or if they're expecting me to be substantially more technical in how I answer the question.

For IC4 mid level eng, knowing the components and their attributes and math was enough. What's the throughput, CAP theorem, how do you load balance, what type of load balance strategy, what type of storage, what type of cache. This is stuff you can study on any guide.

So will the system design interview for senior eng be harder? That aforementioned sys design study guide will have a LOT of content and I'm wondering if senior system design interviews are gonna really hammer these concepts home, and you'll fail if you don't know all of them.

I'm gonna be interviewing for some big tech companies soon with the traditional 5 round onsite interview process. I've heard that how well I do in the system design interview will determine my leveling. Problem is, I'd like to believe I'm effective as a senior eng but I was a product eng in big tech, meaning the low level storage and infra problems have largely been abstracted from me.

I'd like to hope that the system design interview will be similar to the mid level interview expectations.

Thanks for reading folks! Curious your experiences as an interviewer in big tech and as an interviewee.

Hey everyone.

My background is ~9 years of experience. Right now I am NodeJS Senior SWE and basically acting Team Lead.

In current organization I work for last 6 years. I am starting to look for new opportunities both to grow my income and my expertise. Also I am fully remote and regardless of how funny it may sound - I deeply miss social aspect of showing up in office every once in a while.

So I started looking for new Senior positions in my local market (Central EU) and so far overwhelming majority of positions are ASP.NET. NodeJS market is dry AF, if you discard web-agency sweatshops. So I became curious with actually hopping to ASP.NET considering that I had some brief non-production experience with it in form of couple of small learning pet projects and I really liked the ecosystem compared to NodeJS.

In last week I started heavily learning ASP.NET by translating core architectural concepts from NestJS and building production-grade demo project using idiomatically correct approaches by inspecting open source repos and consulting with LLMs. So far I am close to be finished and I believe I covered ~90% of concepts to the point where I have a really solid idea how to approach challenges related to backend API architecture , their deployment, configuration, security, etc. I still lack good knowledge about important inner workings of CLR but I believe it’s mostly theoretical “good to know” that I can read through in a week or so. Final “finishing touches” of stack understanding I am planning to get from actually working in new org on their own flavor of “production grade codebase”.

In my opinion overall majority of expertise that senior and above levels bring is autonomy and understanding of strategic concepts like architecture of software, infrastructure, scaling, observability, etc. All of those concepts are quite loosely dependent on actual language stack that is used to implement actual business logic.

The biggest challenge that I see is that I have no”real” ASP.NET experience so there is close to none chances for me to even get to technical interview because I am 100% getting filtered out by recruiters or ATS. I also don’t really consider reducing salary expectations to work for some time at middle level and then fighting for raise.

So, I would like to ask from fellow hoppers or people who have strong (or any) opinions about these topics:
- Do you think it’s sane to consider such hop without salary hit? Am I missing some kind of larger picture that stack change really affects?
- What do you think about the take that in modern business-logic-heavy web APIs importance of language stack comes second to actual architecture of the application?
- Have you done similar hop at around the same level? Maybe different stacks? How was experience?
- Did you lie in your CV and phone screenings about experience with required stack?
- Did you lie during your technical interview about having production experience? How did it play out?
- Did you had a chance to work with employees who did such hop? What was experience with them?

i just saw someone share a story that they opened 2 AI engineer roles this week. In a bit more than a day, 600+ applications came in. That's generally at least 4x more than they get for the other Engineering roles. On top of that, 30+ pitches on LinkedIn, 5 via work email, 3 via personal and 4 agencies reached out to them, and they're not even the hiring manager

there are so many obvious Ai written posts on the linkedin frontpage everyday where it is announcing a new project they made, some platitude or lecture, or "advice". the amount of Ai noise makes me want to punch sam altman

i just finished having 2 silent weeks in a row, meaning i have zero replies after applying to jobs and reaching out to people for various reasons. most linkedin jobs are just reposts for the appearance of keeping up growth

where do you usually go now to apply and build a steady pipeline. i dont want to rely plainly on cold dms from staffing agencies

For the last few years I’ve been struggling with finding enjoyment from software development, as I have found myself falling into the mindset that an LLM can carry out the implementation of a complex feature better than I can, so why should I bother even attempting to write the code myself. (Note: this is specifically regarding implementing a solution after the requirements have been identified and refined but maybe there are still some hidden edge cases due to the complexity).

However, as I’m sure many others here have experienced, this often results in a cycle of:
- oh it missed these edge cases or didn’t consider these scenarios (that I also hadn’t considered before reading through its output)
- now I need to let it know what it missed based on this new information and repeat the prompting cycle a dozen more times

I don’t know about others, but personally I grew to find this process absolutely soul crushing, as it felt like the job had become babysitting a machine through this discovery process, which I used to gain so much enjoyment from. And often the end result felt like it took just as much time as if I had done it myself.

So recently I have started doing something different. I still use AI for the more mundane and boilerplatey tasks (CRUD endpoints, CI/CD workflow files, unit tests, etc), but when it comes to implementing a complex feature I will sit down and do a first pass of it myself, and then ask the AI to review my work. This process has brought back the old feelings of excitement that I used to get from writing software, and when all is said and done I understand the system much better and have a much more stable implementation that covers more edge cases. And more often than not it doesn’t end up taking much longer than if I’d gone down the vicious prompting cycle from the get-go.

I work as an architect for a specialized area within a much larger company. Of the several teams having to implement my designs there are a couple engineers who constantly fight me on my decisions.

Of the two, one in particular is… acidic. He has a strong following among the engineers and is constantly posting trollish questions about why I am involved in any given decision. He’s a good engineer, don’t get me wrong. But I am forever deflecting his pointless questions while also trying to answer them in a non-acidic way. After years of this it is exhausting.

The team (of several who have to follow my designs) would suffer if he was no longer there. My goal is not to get rid of him. I would love to know how to better get along with people like this without eroding trust in either one of us. 30+ yoe and I’m still struggling with this. Any suggestions?

In my previous thread, I asked (and received plenty of great suggestions) on high-quality resources.

This time, however, I'd like to discuss a much less concrete aspect of our jobs. Namely, your favorite productivity habits and personal know-hows when it comes to leading projects, working on complex cross-team features, keeping lots of tricky context in mind.

I often have my own retrospective sessions when I am just trying to assess whether I am good at what I do at all. To clarify, it's not in the "impostor syndrome" sense at all. I know that there are parts of the job I excel at and I think I deserve the title and responsibility scope I have at the moment. That said, there are certain aspects where I am not good enough and therefore am now trying to improve. For example:

* Working on technical writing skills. Mostly by reading the book and blog on https://refactoringenglish.com/

* On a similar note, writing down as much as possible whenever possible. Whether it's a small favor for some other team, a super trivial task, or a large feature, it becomes a Google Docs document. Initially, it's just a very chaotic piece of writing, but then it transforms into a system design or a very detailed Jira ticket at least.

* As in aviation, it's very important to pay attention to near misses when you were on the verge of an incident and just got lucky.

* As I have rediscovered once again, working out is extremely important for productivity and focus. I have yet to get my official ADHD diagnosis, but since I don't want to spend the rest of my life on stimulants, I have added a few supplements (Vitamin D, Omega 3), hydrate well, and work out a few times per week + light cardio. Never felt better.

* Appreciating hammock-driven development. I used to have these awful hyperfocus episodes when there is no external pressure, but I feel intellectually challenged and forget about food and sleep to figure something out. I feel much happier, when I let myself think about a problem while walking my dog in the evening or just having rest and then feeling super fresh and working on it the next day.

What are yours?

The current version of my CV is 2 pages at 11 point but there is a lot that's not included. In the past I have let it be longer but I've heard/read all sorts of opinions on this including:

• Your CV should never be more than 2 pages, it shows discipline and brevity
• It doesn't matter how long your CV is- if they are interested they won't reject you for it
• What even is 'length'? Nobody prints anything
• It doesn't matter - they will just use AI/ATS to search for keywords

Obviously CVs are one of those things that people tend to have 'Opinions' on, and of course there's variation in them - one person's 'well obviously' is another's 'Hell, no!'. Some employers get really excited about tracking every calendar day's employment so there is some pressure to keep with a chronological format, which can mean a lot of boilerplate for company name, dates, titles etc. and then the pressure to put some achievement for each one. Sure you can cut the older positions but what if that removes some of your best achievements and forces meaningless stopgap stuff such as some contract work?

What do we think a 'suitable' length for a CV is at lead/staff engineer level?

I don't necessarily mean people whose main role is as a technical writer (although I'm sure insight from those people would also be valuable). But more along the lines of engineers/devs who have leveled up their technical writing skills, and how that has affected them individually, as well as the surrounding team or org.

Something I notice in my work, which I'm sure is very common, is documentation that just... sucks. It's one thing if something is outdated, or having duplicate pages for similar things. But sometimes I can find the "right" page and it's just bad. It's unclear, it's missing context, etc. And I sit there wondering, "am I dumb? am I missing something that is obvious to others? Or would this be confusing to anyone?"

On the flip side, as an individual I'm very aware that I'm not great at explaining things. It's hard to know how much detail to include, what level of accuracy vs clarity vs completeness is best. I think one way of improving even verbal communication/explanation/teaching is to improve my technical writing skills. Although in my time at this job I haven't heard anyone talk about this, so I'm curious to get some insights from other people who may have spent more time thinking about and/or working on this as a skill.

> If you are a senior, don’t tell juniors to do something that you aren’t certain that is right and that you believe that it is right because another senior told you to do that when you were a junior. Don’t be a parrot.

Excerpt from https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/

I don't think I'm unreasonable to believe that engineering judgment should demand reasoning and evidence. And yet, across five companies, including big tech, I have repeatedly watched engineers choose instinct, convention, and authority. Many barely skim the documentation, much less read books or papers. Yet they confidently repeat “facts” they cannot explain with anything more substantial than:

- “This is how we do it.”

- “I believe I’m right.”

Or, God forbid:

- “Claude said it.”

More recently, I met self-described “AI engineers” who had not seriously studied prompt design or evaluation practices; they just winged it and hoped for the best.

The best engineer I ever worked with frequently said, “I don’t know.” He had a doctorate, more than ten years of experience as a professor, and years of company experience. He spoke less, but when he did, you could trust him.

He also had enough intellectual independence to disagree directly with our manager (sometimes abrasively) and enough humility to change his mind when the evidence demanded it.

I am not defending impostor syndrome; quite the opposite:

> Pride is not the opposite of shame, but its source. True humility is the only antidote to shame.

—Uncle Iroh

“I don’t know” is not the same as “I should have known.”

I am tired of status performance replacing epistemic responsibility and confidence being rewarded more than accuracy.

I want to ask those with more experience: am I being naive about what software engineering truly is in the market? Is it possible to become a senior engineer who values intellectual honesty, evidence, and willingness to say “I don’t know without undermining my career?

Edit: these responses are giving me a lot of hope. Thanks everyone!

TLDR: Does anyone here else take an E2E-only approach to testing? What is your experience with it?

My current team exclusively uses Playwright testing for our test automation for all client side code. In my 13 years as a mostly frontend software engineer I’ve never seen this approach taken, where there are no unit or integration tests (e.g. with React Testing Library).

Unsurprisingly, this is causing incredible flakiness and slow testing times overall. Getting releases out the door recently has required babysitting CI test runs for an entire day to get all tests to pass.

I have made suggestions to introduce RTL and save Playwright for only testing complete workflows, not for testing individual components, but it’s been met with resistance.

Anyone have suggestions for how to set up a tangible example of the benefits of moving certain tests to RTL? My thought was to take one test suite / area of the app, convert appropriate tests to RTL and show performance comparison and code comparison.

At work I maintain a NestJS microservice which is used by many other engineers. One of the features depends on a third party API for which I need to implement rate limit: - The API has a soft limit of 20 req/s - There is no way to programmatically monitor this limit on their end - Surpassing the limit means that when someone looks at the dashboard then they will manually disable us, and we have to start another manual process to unblock us - This API is owned by the government, so we can't ask or hope for changes

How would you implement rate limit for this external dependency? Here's what I thought: - Have a token bucket limiter inside each service instance, but then scaling - Store the above token bucket in a database, like mongo or dynamo, but it would be very inefficient - Use redis, but I would have to spin up and maintain an additional dependency just for this feature

Can you think of a better approach?

I live in a medium cost of living city in the US. I started looking for software dev jobs, but since my major isn't tech related, I kept it to smaller companies for a while, since I didn't think I would be hired by larger/F500 companies. (That hunch turned out to be right after all)

The average pay for a junior level here is $60-70k when I started looking for work after graduation. After a few months I got one offer, $30k a year with no benefits, so I took it.

6 years later, I peaked at around $50k ($25/hr). My jobs lasted an average of 18 months (usually ending in a layoff) and never got promotions. Then I fell into freelancing by accident because I could no longer get full-time offers.

In between all these jobs, I still applied to many jobs that paid more. Locally and in places where salaries and cost of living are higher. Eventually I did start shooting my shot at larger companies. I interviewed and interviewed at a lot of places and with a wide range of salaries but never got a higher paying job.

After all that freelancing, even that fizzled out and now I'm stuck unemployed for a long time. I never earned as much as the average. Was the SWE path just not for me or did I just have a terrible base to start on? And now I'm thinking, where is the thing I can focus without it being overly broad (I get stuck with having too many choices).

Right now I'm just trying to figure out how to make my resume fit for a help desk job.