Companies need to set the bar and uphold it. Saying people are "quiet quitting" is synonymous with saying, "we don't know how to set and uphold standards". Putting the blame on the employee instead of having clear guidelines (i.e. making it a performance problem) is an unfortunate scapegoat used to shift the blame and accountability. A job is a contract. Ain't just one sided.
Edit: Amending to mention that there are companies that do quite well at upholding standards. To those, thank you for trying.
'We're going to force workers into the office and hope they do some work out of boredom' is taken as a serious strategy because the average manager is mind-bogglingly incompetent. If you know how productive people are (i.e. your managers aren't morons), and you have incentives set-up (e.g. pay, promotions and hiring/firing is dictated by productivity), then there's no problem to solve. Workers who are more productive in the office will be forced into the office to meet standards, you don't need blanket rules.
Oh and the penny pinchers have consistently under-leased space and forced the worst setting imaginable on most of us - open floorpans. So RTO is disruptive, distracting and pointless.
My small team of 3-4 will occasionally go to the office when someone is in town, ask for a room/office get denied and assigned random open floorpan seats.
Usually sat next to the interns or the Helpdesk or some other noisy group we don't interact with at all.
Often they can't even find contiguous seating so we are sat hodgepodge amongst people we don't work with.
Of course after this post, no joke I go into the office last week and the reservable open desks were in the supply closet with broken chairs and monitors. Amazing.
The other day my manager straight up told me he doesn't understand what I am spending time with issue X for and why I even put it in my scrum meeting ( he assigned it me; he really should know what it actually entails, but clearly doesm't know ). I will be honest, I got pissy and simply removed it from my todo list, will let it fail and I will let it be assigned to me again. I am now George Constanza and embrace the sheer corporate managery.
I think there may be a set of people that have figured out, 1) how to interact with LLMs; and 2) what in their lives is improved when interacting with LLMs. I am in the group that has not found the best use case for my own life, and have never needed it for improving anything I need to get done. Always looking for suggestions, though!
I enjoy brewing some loose leaf* green tea with varying ratios (leaf, water, temperature, time). Others might enjoy it! I think it's a fantastic replacement beverage that helped me cut soda.
I like doing 4g of Japanese sencha leaves, 80-100mL of water, at 60-70C for 30s to a minute. Second steep 10 seconds, and third 30-40 seconds. But honestly the fun is in experimenting! (plus at lower temperatures you can drink it right away!)
Congrats on your feat of strength! To others looking to quit, I've read[1] that it's dangerous to quit cold turkey. Ease yourself out, and save yourself from possible complications.
Thanks, I was also a chain smoker and for me quitting smoking is much more difficult. You get to experience hallucinations, depressions and severe withdrawals. Alcohol is just more about losing your social activities, and being weird around your drinking buddies, but eventually time will make them understand.
The ideas shared in the post replies are great. My approach has been more hands-on and puzzled together recently. I've been digging into harder problems on sites like leetcode to learn more math, and solidify some algorithm and data structure concepts. It has really helped me feel more confident and erase some of the lingering imposter syndrome around the algorithm-side of programming. A great guide that got me started on this was the tech interview handbook[1], which helped me dig into specific concepts instead of just randomly targeting. I've found my ability to review code has also improved through this, as I am picking up different libraries and concepts that I wouldn't have otherwise.
I currently have three large components that handle state between them, and a bunch of control components that don't care about state (they receive values as attributes, and trigger "change" events if changed by the user).
The larger components contain their own state, and communicate by events (so component Foo emits a change event when its state changes, and component Bar listens for that event and fetches the new state by checking event.target.data).
It's working reasonably well with this relatively small set of interactions. But I can see a point where I'll have to create a Flux/Vuex-style state store and use actions to mutate it.
I use something similar to React class components. Under the hood my set function calls Object.assign and I debounce the render function callback. You could implement it yourself in <80 lines of JavaScript[0]. I'm not sure what other people use but I've been using this style of state management for ~4 years and it's been fine so far.
There are so many factors. Compounding knowledge, ability to focus, and environment are crucial components to learning. That plus motivation and interest, diet, sleep, and knowing how your brain learns best.
It's interesting to look back in time at things you did that maybe didn't add much to your schema/knowledge bank. Also interesting to look around at what others focused on.
For take home reviews, I wonder what the impact of generative AI would be. I can see a lot of people feeding the code segment into an AI and using it's comments instead of generating their own. Of course, people will do that with programming questions as well, so I suppose it's up to the hiring manager to decide on the best method to handle this situation.
What strategies do people leverage to avoid purely AI answers?
A good take-home interview process usually involves a review phase where the candidate talks about their solution and how it works.
This is remarkably effective at filtering out people who had a little too much help in solving it, either from friends, Googling it, or now using an LLM.
It doesn’t happen often, but from time to time someone will come in with a solution they supposedly wrote in the past week but they are unable to discuss it. “I don’t remember exactly what I did here…” and other excuses. It doesn’t take much discussion to reveal someone who never actually understood their own submission.
Of course, I always continue the technical interview to cover the odd possibility that maybe they were too nervous or something. So far I haven’t had anyone who is unable to discuss their own take-home yet shows well in the rest of the interview process.
Time will tell, but there optimists are already predicting that in just a few years great programmers will feed requirements into AI and then review the code it produces, not write code themselves. I'm not sure I believe it, but given that someone who can make AI produce good results is worth a lot more than a great programmer without an AI.
With a take home, and honestly any kind of interview, the key is not in the deliverable it's in the discussion about it. To be totally honest as a hiring manager I don't care if a take home was fully written by AI so long as when we discuss the solution the candidate can clearly explain how the code works and why it was written that way. Of course in the case of an AI the why might be flimsy but if it isn't then who cares. The goal is to hire someone who's capable of solving problems and in turn explaining their solutions I don't care who wrote the code.
I appreciate your opinion and although I disagree, I'm curious about how you handle talking to reports about their careers, the work they've been doing, progress on their goals, problems they are encountering, etc.?
Annually? You think the right cadence to see if one of your direct reports is progressing toward their goals or having difficulties is once per calendar year?
That's how most companies work, if that frequently, with difficulties handled by exception. Only in big tech is that the focus of the "work" and do you have managers who spend their time on it, leading to the "professional meeting attenders" mentioned elsewhere.
My experience with 1:1s is that they uncover things that wouldn't be uncovered... well, without 1:1s.
Most of us are "trained" not to "bother" our managers so allocating some dedicated time is valuable in my experience.
I'm honestly baffled at the pushback against 1:1s I'm reading. Assuming you have a relatively normal number of direct reports for software engineering (5-10) that adds up to not a lot of hours.
At companies without regular 1:1s, I often had no idea if my manager thought I was doing a good job or not. You can say that this is bad management or bad communication, and you're right but management and communication tend to be rather poor in our industry! 1:1s are more often than not a part of the solution.
yes, at a company, which has been running for several decades, each of my manager’s made sure to ask what I wanted to do with my career. To not ask, one may infer that there isn’t much career advancement available.
It's not just the tech industry. For better or worse, frequent 1:1 meetings with direct reports are a common management practice in most large US companies.
Edit: Amending to mention that there are companies that do quite well at upholding standards. To those, thank you for trying.