I (7 YOE) joined a company as a senior developer 2 months ago, since then I've already had the opportunity to develop dozens of features and push multiple bug fixes. However my MRs required quite a few changes for features since sometimes I had no idea the impacts that some things caused in the codebase as there weren't tests for those cases (which I ended up adding together with the features). Because of this, my team lead has been complaining during our 1on1s that I should do better and should work towards not needing many change requests. The only thing I answered was that I'm very new to the codebase and that I'm still getting to know everything.

During my interview he told me that the expectations of being fully ramped up are around 3 to 6 months, however he was already complaining after the 1 month mark.

As a solution I've been discussing as much as possible with my teammates (which are all senior and principal) on possible solutions for my tasks to try and get to know everything and catch errors.

Does anyone have any suggestions on how to improve this on my side? I am also considering the possibility of leaving for another job as I find the team lead's demands unreasonable.

Hello :) Just very curious about it! Besides the 3000 meetings, onboarding, etc, what do you usually try to prioritise on your first two months?

For me is understanding the team dynamic (from how a feature becomes a feature to how PRs are being handled), understanding the actual product (the lows, the highs, the improvements, the logic). I obviously also go through the code I’ll be working on the project, so I make sure I understand the structure, etc.

What strategy or tools do you use to pick up work on your projects when bouncing from one machine to another?

Git, or any version control system, is great if you remember to push your changes.

Remote development virtual machines is an option, but require being tied to the internet.

Dropbox, or similar file syncing applications, is smooth until its not.

I'd love to hear how everyone else tackles this problem, especially if you're like me and switch between multiple machines and operating systems.

There’s so many tools out there, and oftentimes I can get by with good fundamentals.

I started spending an hour a day digging into tools or processes, and I’ve found more than a few ways to improve our code base and make everyone’s lives easier simply by reading docs and tinkering in areas that need work

How much do you spend working on tickets versus digging into processes and tools? How do you choose what to look into?

I’m a SE w/ ~12 YOE working at a fortune 100 company with a huge tech branch. Started the year off great, I got to spin up a new team, we picked our tech stack, didn’t have any directors since we were brand new and needed to hire leadership. Our project is a company top priority. The business side took some time to spin up our product team. It was a lot of fun to move fast, have autonomy, and I was able to be in my strengths as a mentor and writing code.

I’m ending the year in a horrible malaise though…once product and management was in place, my new director hired a ton of contractors to fill out head count and secure our budget as big as possible, and I ended up in meetings all day, am having to do paperwork and fill out tickets and deal with all the red tape I’ve never had to before (in the past, I led our tech teams while a staff eng did all the meetings and paperwork). It’s not hard work, but it’s really frustrating; tons of compliance nits, tickets, run arounds, teams I’ve never heard of telling me we aren’t in compliance for random things but no support on how to do what they want us to do, fragile proprietary deployment systems etc., and while I love mentoring I even find that the new engineers come to me for very basic common sense stuff. I find myself asking them the same questions: “is this requirement in the ticket? Did you talk to the other engineer who is working in this?” Etc. I’m not coding anymore, or rarely.

In short, I’ve had to deal with all the corporate BS at once, and I just can’t bring myself to care any more. I thought our product was going to solve a real problem, but it turns out to be a compliance tool and we don’t have any real users, but a lot of eyes from leadership. Requirements are convoluted. I’ve lost touch with the code base and don’t want to jump in any more, I just review PRs. I just don’t give a rip about what we’re doing any more. It’s excruciating because as tech lead I need to have opinions. Can’t have opinions if couldn’t give a flying flip about the stupid thing we’re doing.

It’s bleeding over into personal life too; I don’t want to go to work any more, blah blah. I’ll be the first to say that I think a job should be a means to provide for yourself or family first and fulfilling second, but this is getting crazy. I feel guilty because it’s a great company, I’m paid well, benefits are great, I work 40-50 hours a week etc.

Is this just the way and I need to buckle up and be a big boy? Would a change of team help? Transition to management? Change companies? Curious how others deal with this. Thanks for reading!

I'm 56, with 20+yoe. I started as a web guy - mostly PHP/MySQL until recent years when I got into Typescript/Node/NestJS and some Python, MongoDB. I've always kept up with modern stacks on side projects, and feel at home in modern SWE teams. I was fortunate to get into this field early in the millennium when not having a formal CS education wasn't a barrier. But I've always stayed clear of prestigious companies where Leetcode and formal CS training mattered.

Until recently, I had never been able to manage the Leetcode interview style, but something odd has happened. Since working at my last few jobs, which were pretty demanding, I'm feeling very confident with LC problems. Most of the Leetcode 75 list easy levels are solvable for me without referencing any other solutions, and areas I've had less exposure to such as medium graphs/DFS/BFS, binary trees are being picked up quickly. They actually make sense to me, which as a self-taught engineer, is kind of exciting.

I also find that the system design walkthroughs I'm watching make sense with the kind of architectures I would propose. Most of that comes from having earned some AWS certifications, hands-on cloud infrastructure work and designing some systems in my previous job. I'm supplementing that now with some of the traditional study resources, and I feel like I could succeed in more advanced sys design interviews.

So, I'm wondering now if I would be capable of succeeding through interview rounds at more prestigious companies where I wouldn't have tried to apply before. Maybe even FAANG. My knowledge has been more earned though actual work experience, but that appears to now have caught up with the more traditionally schooled approaches.

My question is hard to easily summarize, but I guess it's coming down to: Is a career move like this feasible? Do older engineers with more hand-on experience in smaller/mid size companies have a chance succeeding at FAANG or FAANG-adjacent companies?

As AI is able to generate more and more code and covers more domains each and every day (frontend, backend, mobile, etc), what should I be learning?

I am an avid learner and with AI it just seems whatever I learn next is going to be slopped away by some random LLM model?

Is it a race to the bottom?

I don’t want to learn AI and ML itself, I find it quite uninteresting and boring.

How is everyone coping with this? The joy and reward of learning and deeply understanding something is going away slowly.

Some time ago I joined a company that was already one year into building an internal tool that was going to replace an off-the-shelf one. As soon as I joined, I could already smell something was wrong, and as the months passed, my feelings were right...

Of course this is going to be my point of view as an IC first, and tech leader later, I didn't have the opportunity to get into all the politics "up there".

Our product development process looked like this:

1. The Product Department managed all the stakeholders expectations, who were all internal, and they drove the features to be built and helped with the roadmap.

2. Once product and stakeholders agreed on the feature to develop, the ball passed to ux/ui designers, who would create mockups on Figma

3. Us devs got a nice, clean Jira board with all our tasks coming from the PM. We had 2 weeks sprints, a grooming session, a retro.

4. Once our job was done, we opened PRs, argued a lot, merged to prod and waited for QA to test them out.

Among all this, what really smelled was that we devs didn't talk much to each other. It was pure async, so we worked all independently and only met during PRs, grooming sessions or retros. But worst of all, there was no communication (hence, collaboration), among different departments. I never spoke with a designer, and not much with our PM (poor guy, was always overwhelmed with meetings)

It was a classic fake agile process, product-led to... failure. And that's exactly what happened: after 2 years of dev, the project was stopped. In other words, It was taking the piss.

That really pissed me off. I never saw the impact of my work, or of my team if anything. It was disempowering. Ok, ok, I was still paid and I should move on blablabla, but maybe I'm too romantic, I want to see my work being helpful, somehow.

The next project was not internal, and I was a tech lead there. The situation was slightly better, but the process looked similar. I tried to improve something, but unfortunately all my team was laid off after only 6 months. Predictable.

Anyhow, why I'm I telling you this story?

Well, I really think that if developers were involved from the beginning, we would have avoided a lot of waste, rework, and complexity that delayed completing the project.

And that's not the only time I met this situation. And fellow devs told me similar stories.

You must be thinking, yeah sure, nothing new... We need cross-functional teams, all roles working together, and collaborating like ants.

That's great, but I still think that's not optimal.

A lot of time product development is just... waiting. We wait for people to finish their tasks, so someone else can continue from there. Product => Design => Engineering => QA. So much waste in between. A cross functional team would probably shorten those delays, but they'd still be there, and we'd end up trying to find something to do to not stay idle. We would improve communication, but not the implementation part.

I've been thinking, maybe, just maybe, we should try to minimise those delays to the minimum, even removing them at all?

One of the articles that most inspired me and shaped my career is "The Product Minded Software Engineer" article from The Pragmatic Engineer newsletter.

A Product Minded Software Engineer is one that doesn't stop at the tech stuff, but goes beyond that. They are very interested in the product side, they love to think about the product - technical tradeoffs, they think about edge cases, they really care about the user experience and want to have an impact with their work.

And I'm so happy that a bunch of companies have started to hire roles that follow that mindset: UX Engineers, Product Engineers, Design Engineers.

Some companies being:

• PostHog
• Linear
• Ashby
• incident.io
• epilot GmbH  
• Typefully
• Speechify

The common denominator is: engineers are not code monkeys, they can actually be an active part in shaping the product, way beyond just technology.

In PostHog for example, product engineers can actually build a case to develop a feature, talk with customers, gather data, put together a UI, implement it and launch it. E2E. Product managers are there to hold the big picture. Designers are there to help with complex interactions if needed.

You may be thinking, that's fucking crazy man, jack of all trades, master of none blabla.

But being a product engineer myself, I can say that it's not about being a generalist that does everything bad. It's about becoming specialised in the product development process, and learning to ask for help to experts when needed (which happens less times that you think).

Could this be the future?

Engineers overseeing the development of features e2e, starting from a customer problems and not tickets, relying heavily on automation, and I have to say this, AI to help with the work at the intersections.

Recently I found this blog https://www.theeuropeanengineer.com and he maintain some list of high-paid job board for remote workers in Europe, I was interested in that, so bought a subscription, and what is the result? That's just links to linkedin jobs, a lot of them outdated, and salary that he posted is "estimate", that a super innacurate, so think twice before purchasing it. Why I ever need this, if I could go to linkedin and filter it manually?

https://i.redd.it/fa4b9jqbulae1.gif

Hey everyone, i need to solve a problem and i have a green field options here. I'm an EM for not the most experienced team that have built a solution that has all sort of flaws and now we have the opportunity to rebuild something. I'm still hands on with team occasionally and support them sometimes with RFC or mediating architectural discussions + the general EM work.

I have 3 streams of data coming at different intervals. After i receive at least once one of these, i will have the final and ready "object" for the clients.

I will receive around 20 updates per second for these parts.
I will need to provide an API for clients that on peak will need to handle 2000 req / sec.

So in a nutshell:
peak of 50-100 writes / second
peak of 2000 reads / second

These 3 pieces of the object are relational, however they can be orphan. I need to provide an API for consumers to read and write to this data, streams are also an option and i need to export a full batch of the newest built object to other systems, so i have Object 1 fully built and it has an update of his first part, and the same happens for other objects and i need to batch these updates and export them.

I want to define mainly which DB i will use for storing it and the BE tech stack i'm not that worried. I did some stress test with Postgres and Mongo. They both performed well. The team is more familiar with Postgres and we will need to generate different type of reports as needed to validated against the origin systems.

I think looking at this data as relational data sets make it easier to join them together as needed. As the consumers get the data at an API level, the Backend can deliver just the valid data or errors if they are not valid.

So my current inclination would be to:

* Go with Postgres for the DB, i can not enforce a FK relational and have the joins handle that while still having indexes
* I can add a read replica to improve the performance for read requests, i have a few prod systems with Postgres handling 400 req / sec with P99 of 30ms and works well with a read replica
* I can add a cache layer if needed such as Redis or something to improve read performance and reduce DB load
* The team has Postgres familiarity
* BE i'm not sure it matters but would be either JVM based (spring boot) or NodeJS, the team is probably more inclined to work with the JS world
* For the batch exports i'm considering creating a Kafka topic to post Object's ID's that have been updated and then later having a consumer every 30 minutes batch those updates to other systems

My main concern is scalability here, retries and fail proof is something i'm not too worried. Any thoughts on that?

Thanks

I work as a contractor, and thus often need to juggle multiple logins for say azure, outlook, gcp, etc.

Now a while back, I found the solution to all my problems with Arc that let me easily switch between seperate profiles and be logged into multiple accounts on the same sites. However Arc is dying, and I need to find a new solution.

Chrome is okay with it's profiles, but it opens each profile in a new window, and I would like to have tabs/bookmarks in a sidepanel. Firefox has a very clunky handling of different profiles imo.

Vivaldi, Opera etc also doesnt let me switch very easily between profiles.

So my question to you is, how do you handle this? Are there some plugins that solve my issues? Alternativ browsers I haven't tried? Anything else you want to add?

Hey all,

Looking for any advice or ideas on how to manage tenant configurations in an existing distributed system. Currently in a multi tenant environment where several different applications would need to create/modify/access/delete a tenant's configuration. Different teams have their own configurations so the model would need to be quite flexible. Different teams may also only want to access a subset of the tenants total configuration.

Right now different applications are all storing their own configurations and it's a mess. We have duplicate configs, services grabbing configs in a 'distributed monolith' approach, a mess of api calls to grab each others configs, it's bad. A centralized place for config management would help clean things significantly and make debugging a lot easier.

I Was thinking of a a basic API that would allow a tenant to be on-boarded. Once on-boarded, it could allow for key/value pairs to be set on the tenant. Things get tricky when you want to avoid one team accidentally overwriting another team's configurations on the tenant. It may also become tricky to store nested configurations.

Anyone have experience with this? Are there any tools / cloud services people have had luck with?

Edit: is my post too poorly worded? I see that it's getting downvoted heavily. I don't think I broke any rules with this post either? Please let me know if I need to clarify!

Edit2: all team leads have agreed that this is a problem and are willing to work together on migrating to the new config management system. Many in the comments brought up that this could be a blocker. But I'm really just looking for technical advice here

I have 15yoe and hard-reset my domain, now planning to carve out knowledge in this new field (manufactoring to backend - very little commonality - not even REST). I also dropped seniority from lead to mid with the change.

My question is, at what point would a hiring manager be suspicious about how long I stayed as a mid-level engineer, whereby it could damage my employability. Must I push for senior as hard as possible in the next 2 years? At this current position I am basically bottom of the pyramid again, with little responsibility and wondering if its going to look bad during an interview

I would welcome any suggestions regarding podcasts that cover topics such as seniority, big tech, leadership.

My suggestion: Soft Skills Engineering

I’ve been working on a relatively successful iOS app for the past two years (top 50 on the App Store). Since its successful launch, management has been consistently adding new features to the app, which has kept the UI/UX team fully occupied with creating mocks for new feature pages.

Over time, I’ve noticed a lot of inconsistent UI components across our app, especially between iPad devices. I recently tallied up the inconsistencies over the past six months, and there were more than 20 issues. These include:

Misuse of text sizes.

Navigation drawers that work on some pages but not on others.

Overflowing components on smaller devices.

I’ve compiled lists of these inconsistencies and brought them up to my manager multiple times. Each time, I’ve been told, “We’ll conduct a design audit,” but nothing has been done so far.

The QA team isn’t very proactive, so they rarely catch issues like this on their own.

Most of these issues are caused by other two teams that occasionally commit into our codebase.

Maybe it’s my ADHD making me hyper-aware of these details, but the design differences are glaringly obvious to me. Should I even care this much about these inconsistencies as a developer, or am I overthinking it?

I've been programming for many years, and during my early days being online "all over the place" was so helpful for me. I was exposed to so many things that I was not aware of, and this made me develop a very broad knowledge about many things, specially computers. Operating systems, network, compilers, web development, low level programming, databases, and so on.

But I'm older now, married, have a kid, another one is on the way. Time is scarce, and I feel that the constant loop of information seeking is becoming more and more stressful. There is also the fact that most of the news/tech are things that will be irrelevant in no time. Maybe this is just my FOMO?

I know that this is kinda of an open ended question, but I'm just trying to understand how you all are dealing with these things. I would like to spend less time on screens, but I don't want this decision to impact my career.

I started my career in the mid-90s, working for an ISP while studying computer science. For the next 15 years, I spent my time at small consultancies as a software developer and tech lead on content management and e-commerce projects. I then worked 6 years at an ad-tech company as a data engineer before joining big-tech (with thousands of developers) as a backend developer.

Throughout my career, I've primarily used Java (starting with Java 1.2). Early on, I worked extensively with Perl, TCL, and other scripting languages, and more recently with Go. I briefly ventured into leadership (3 years as an Engineering Manager) but quickly realized it wasn't the right fit. I genuinely enjoy being hands-on and working alongside people who are directly involved in development, rather than spending my days in meetings. I've used AWS for the past 10 years and am comfortable with both CLI and modern Java IDEs and tools. I've worked on large distributed systems and managed on-call responsibilities for critical services serving millions of users.

I'm approaching 50 and estimate I have about 15 good years left (knocking on wood). While I'm content at my current employer, layoffs are always possible. At my age, job-hopping seems increasingly risky. I likely wouldn't earn significantly more elsewhere, and I value working with people I like and on projects that keep my skills current—both of which I have in my current role.

I'm still uncertain about how to position myself in this market to maintain employability. Should I continue as a senior backend developer? I've done some SRE work, mainly because no one else on the team wanted to, and I'm comfortable with it. Many dev teams struggle to find people willing to handle SRE tasks, so I'm considering investing more time in this area to potentially market myself as an SRE if development work becomes scarce. However, I don't want to focus solely on SRE as I still greatly enjoy development.

Alternatively, should I pursue a principal engineer role? I worry I'll face the same challenges I encountered as an Engineering Manager—missing hands-on work. These positions are also very rare, and at my large company, reaching this level would likely take 10 years, I reckon.

What would you do in my position, and what's your plan when you reach 50? (I know some will suggest retirement, but that's not currently an option for me.)

For SaaS like software products that deal with a lot of critical propitiatory data, large companies typically want to run that as a managed service on their own VPSs (on AWS, Azure, GCP, etc). It seems like there's no appetite to trust a dinky little startup with all of the critical (potentially PII) data.

Throughout my career, I've only worked on cloud based SaaS, and never had to deal with this until now.

Say, you've built a SaaS product already, and you've integrated with the likes of SendGrid for communications and something like Ory or Clerk for enterprise auth. How do you actually package up, deploy, and manage the software on all of your customers' VPSs? Specially when there are dependencies like a databases, and 3rd party services like I mentioned above.

Are there places where I can connect with other staff engineers to practice sustem design interviews? I know there are paid coach sites but looking for peer to peer practice more or less.

Hi, Happy new year to you all. Need some insight and help with peer review. I find is non productive to call the PR owner to meeting and explain changes instead of reviewing changes and making it async via comments and slack. Of course I agree with point on having one to one meeting for any difficult concepts or mis interepreted business logic. For every change or PR seems like blocking time and dev effort. Can the team not have one meeting and agree on common checks to be made on any changes prep a checklist so anyone and every one can do the review async and get in touch with PR owner only if they require explanation on logic handling parts when is complex. Would like to learn and improve myself in these areas. Am I wrong?

Hey fellow devs 👋

I've been thinking about something that's been bothering me throughout my career - the way we handle business logic in our codebases. You know, that thing we're supposed to protect "at all costs" with fancy patterns and principles?

Let's be real: when was the last time you saw business logic being treated with the respect it deserves? Instead, what I usually see is:

• Services/controllers that are absolute units 🫃
• ORM models polluted with business behavior
• Massive scripts moving data between DB and UI with zero regard for separation
• The loud silence of non-existent test coverage

Why did we let this happen? I think there are a few reasons:

1. Our hiring practices are broken: Job posts be like "must know 17 JavaScript frameworks" but zero mention of problem-solving or domain knowledge

2. Architecture? What architecture?: Clean/hexagonal/onion architectures get ignored because "we need to ship fast"

3. The eternal time crunch: Always rushing, always cutting corners, always "we'll fix it later"

4. Software engineers being just “ticket machines”: business logic is something that someone else has to define, we just implement it and we don’t need to understand it (depending on company’s culture of course)

What if, in our next project, we took a moment to really understand the "why" behind the features we're building? What if we advocated for separating out business logic in our code, even in small ways?

Perhaps we can share these ideas with our teammates, sparking conversations that lead to gradual shifts in how we work.

What’s been your experience with this?

Recently, my company announced the full acquisition of one of its competitors. I work on one of the three app development teams. The competitor’s app does exactly the same thing as ours, but ours is more popular and consistently ranks in the top 50 on the App Store.

What will happen to the competitor’s app once the acquisition is complete? Will our team be responsible for maintaining it, or will their team continue to operate independently as before? I’ve never been involved in an acquisition process before, so I’m not sure what to expect.

Reflecting on this year, I dug up some feelings that I clearly hadn't fully processed from a job upgrade search that started in 2023. I work in embedded and have 4 years experience.

I began interviewing for Company X, a household name, in the Summer of 2023 for a position in the bay area. They ghosted me a couple times for months throughout the process, so in the meantime I interviewed for Company B, well known in my field but without the cool factor. In any case, I'm not so much concerned about the prestige vanity here (who am I kidding, I am a little) as I am about the upward mobility I might have lost out on, just trying to provide context.

The Company B interview process was a breeze, frankly, easy. Two rounds, talk with manager, offer two weeks later in December of 2023. By this point, I assumed Company X had cold rejected me which seemed to be confirmed since they never replied to my "I have another pending offer" email, so I accepted at Company B and moved on with my life. The role was close to home (not California) so I didn't need to move.

Almost 3 months later, 2024, I got an email from Company X's recruiter with an invite to one last interview. By this point, their process had taken more than 7 months since my first recruiter contact. I had been with Company B now for almost 2 months. I took the interview. They extended an offer a week later and gave me 48 hours to decide. Keep in mind, I knew based on how they re-engaged that I was still their first choice.

I felt a little disrespected, having been dragged along for so long only to be given an exploding offer with no regard to the fact that I had gone with another company. I tried my best to swallow any pride and make a rational decision. The compensation, accounting for COL, would have been about the same. I wasn't thrilled about moving to the bay area, either. But if I had never gotten the job from Company B, I would have absolutely taken the opportunity and made the move.

The actual engineering team at Company X was really nice, very engaging and passionate. That hurts a little, thinking about it now.

I rejected the offer. I was happy where I was, especially having almost doubled my TC, didn't want to resign after only a couple months, and didn't like how Hiring treated me during the process.

Now here I am, almost a year later, the high of getting a huge pay bump has worn out. I wonder if maybe I should have just sucked it up and taken it. Especially since from the levelsfyi data, TC would have really ramped up after a promotion or two. But I also know that I am still in my 20's and have plenty of opportunities left. I can make some mistakes and learn some life lessons. Part of me thinks I'm not good enough to get an opportunity with a company like that again, but the other is proud that I went through the famed interview hell and made it.

Making big life decisions is hard, but it's easy to overthink disproportionately to the level of risk, especially as a young person. Your thinking and decision making process is always partially a product of motivated reasoning, fueled by whatever feelings and desires you have in the moment. If I had a button that could take me back in time to reconsider, I'm still not sure if I would press it! But I would like to at least remind myself that ultimately I would not be working with the bad recruiter had I accepted, and that my material satisfaction after either decision would naturally return to a baseline over time.

I'm posting this in case someone else likewise in their early career ends up in a similar situation as me, but honestly I don't know what the moral of the story is. It's relieving to just write down my thoughts, though.

Thanks for reading, happy new year!

I'm currently employed, but I'm looking at other jobs and applying because things are not going well at my current company. We’ve had a few rounds of layoffs over the last two years. I survived them all, but I don’t feel comfortable or secure anymore. There are a few other minor issues, but if it weren’t for the financial problems and job security concerns, I probably wouldn’t be looking elsewhere.

Anyway, I have experience with several languages and technologies that I’ve learned through all my jobs and side projects. However, there are still plenty of job postings for senior developers requiring experience with XYZ technology that I’m not familiar with. In my case, that’s Java. I just never had to learn it for any project or job. I recently sent a few applications for positions that require Java, but I think I’ll be instantly rejected because it’s a core technology for those organizations. Do you think this is true?

I feel that when you’re applying for junior and mid-level positions, companies are a bit more forgiving if you don’t know their “core” language. Obviously, even senior developers won’t be super familiar with all the technologies listed in job postings, and that’s normal. But now, as a senior, it feels like I’m locked into my current knowledge, and it’s harder to get a job if you’re not familiar with the core stuff. This isn’t an excuse for me not to learn Java (and something like Spring) in my spare time. I am planning to learn as much as possible, create some kind of simple but presentable app, deploy it, and share the code on GitHub. I’ll do that, and in fact, I’m confident that with my current knowledge, I can get onboarded much faster than when I was a junior. But will this be enough for senior Java positions?

Additional context about me: I’ve been a full-stack web developer for about 8 years now. I’ve been at my current job for almost 5 years, and this is also the job where I was promoted to senior. I have solid experience with several languages, as well as working on high-traffic/load applications and scaling them, various databases, working effectively with other people, leading and mentoring etc. My reason for wanting to learn Java is primarily to open up more job opportunities in the future because I want to feel more secure even if my company isn’t doing well or if I don't like my current workplace anymore.

P.S. I didn't define "core" language, but from my experience there are companies that only use one backend language, and there are companies that use multiple languages for their backend stuff. For those who only list one language or framework, I call it a "core" language, and it's almost a hard requirement in most cases. On the other hand, my impression is that when a job posting lists multiple languages or frameworks, usually there's no core language that's a hard-requirement to get a job. This is my observation, but I'm sure there are exceptions or more nuances than that.

Title pretty much says it all.

I’ve encountered many non to medium technical people who I have conversations with about a vague feature and they turn around and give me a multi page chat gpt write up of whatever we talked about that’s pure fluff.

I’m then expected to do something with this pdf as from their point of view their job is done and apparently the ai speaks my “technical” language so I should be off to the races.

I’ve been ignoring the ones I can but sometimes they come from above and I have to give them more thought.

The social engineer in me thinks I should get them on a call and read it with me line by line so they can see how useless / fluffy it is.

Anyone else experiencing this?

I usually like to work on the awkward days before Christmas and between Christmas and New Year that we don't get automatically because it's quiet and I can get some focus time in. On those days, I've had no slack messages, no meetings, no priority adjustments. I've just been grinding away at my tasks in silence and when everyone comes back, I'll have a big pile of progress to present.

I'm frontend focused full stack dev. So is this role. Frontend is nextjs and typescript, but backend is graphQL and Ruby on rails. Is the tech too outdated or do I take the job? Referring to ruby and graphQL.

I'm not desperate, I have other interviews, I'm just not sure if these tools are already dated or still relevant. Would I be wasting my time on a ruby backend?

3 years of experience.

I’m in an organization that spans across two locations in different countries. Traditionally the culture has been quite meeting centric, not document centric. I’m trying to get my team to work in a more asynchronous manner, but one of the stumbling blocks seems that a lot of knowledge is held by people, not documented anywhere, and that generally people share knowledge by talking (not chatting).

As a team we document our decisions now. However, personally, I find it really hard to remember everything that was said in a given meeting, because in general it is hard to follow - some members speak in broken English, in many unfinished confusing sentences, and have trouble staying on topic. I try to move the team more towards a text-based form of communication (because it is searchable, doesn’t require everyone to be in the same room at the same time) but so far it doesn’t really pick up yet.

Sometimes I reach out to other engineers who tell me “oh yes, that thing, remember we discussed it in [meeting two weeks ago]” so it definitely seems to not be affecting everyone.