You joke, but this was more or less the default behavior we expected from average new hires on remote teams before COVID. I referred to it as the "college schedule" because a lot of new grads just continued their college procrastination habits right into remote work. People treated it like a group project where they know someone else will care enough about their grade to make sure the project succeeds.

It doesn't take long before the high performers on those teams get sick of picking up the slack. The high performers move on to companies that care, while the team's output continues to decline as everyone pushes the boundaries of how little work they can get away with. Eventually management wonders why certain teams have so many people but so little output, "restructuring" occurs to trim the slackers, and the hiring cycle starts again to build the teams back up.

Performance management is more important than ever when leading remote teams.

> The high performers move on to companies that care, while the team's output continues to decline as everyone pushes the boundaries of how little work they can get away with.

That's where a good compensation structure comes into play

Wow this really explains why it seemed like people who were at a company for ~7 years seemed like such trash.

The 30 year seniors were pretty good despite their ignorance of the world outside their company.

The newbies have something to prove.

And it takes about 10 years to have a recession... To cut the fat.

Is there any disadvantage to being a "forever newbie" at companies? I learn sooo much when I change jobs. I can't imagine 7 years in 1 position is good for your career outside a chance at management.

> Is there any disadvantage to being a "forever newbie" at companies? I learn sooo much when I change jobs.

Always being in situations where you're learning is a great idea. You should be able to find learning situations as you move up in your career.

Always being in situations where you're a total newbie/beginner is not so great. You should ideally be able to build upon previous experience in some way with each new job. The problem is that your performance will be evaluated relative to some baseline, and constantly being too far on the "total noob" side of that baseline will start to send the wrong impression as you get older.

That's not to say you shouldn't avoid opportunities where you'll need to learn a lot to begin, but you should be evaluating new opportunities with an eye toward career progression at each step. It's easy to hit the reset button multiple times when you're young, but people will have different expectations about baseline competency when you've had a decade of career experience under your belt.

Companies that promote from within will look within (first) for the senior engineers. To get to the really high pay you need experience in something in depth. Knowing a little about a lot of the same things everyone else knows gets you the mid grade positions, but if you really want to move up you need to grok the details that matter to your company. Very few get to (or want!) these high level positions where you know the complex details of something useful nly to your company, but they go to those who have been around long enough to have experience.

Of course you risk tying yourself to a dead horse that will never go anywhere and now you need to start over from the below the rest: you have experience that nobody needs and none of the general experience everyone else wants for an okay position. Good luck recognizing when/where you need to be to get the good position in 10 years vs a dead end that they don't care about...

Your question about "forever newbie" is really interesting to me, and I'd love input from people with more experience in software development (15+ years).

Personally, I love the idea of jumping around every 18 months or so to experience new domains, new technologies and learn from new people, but I also worry a lot that this will severely limit my career potential after I've done it for 10-15 years.

Basically it boils down to responsibility. You can’t see the effects of your code if you jump around every year. Everyone thinks that they are good at writing code, until they have to maintain their own mess after a couple of years (not a month in production). Cowboy slinging is something we do for fun but as an adult we need to eat our veggies (writing documentation, choosing the language with a stable tooling, proper time estimation and everything else that seem unglamorous and easily dismissed).

>Your question about "forever newbie" is really interesting to me, and I'd love input from people with more experience in software development (15+ years).

I'm 20+ years in and HATE changing jobs. The initial period where I'm Jon Snow (I know nothing) is always annoying and makes me feel like I'm not contributing at a level that supports my role and compensation. I find that it takes 3 months to start to understand conversations, 6 months to contribute to them, and 9-12 months to really be a consistent and effective leader of things.

I didn't change jobs but I changed from integrating graphics on the backend to the web team (using Rust).

And the difference is stark. While I could coast and still outperform everyone I now have so much to learn and the progress seems so slow. I'm slowly getting my hunger back and as someone who loves to learn I wonder when did I lose it?

Wouldn't work at my company, as I'm often enough stalled by trivialities (who has password to this third party service? why does this test does not pass today? deployment to k8s seems broken? need to order access to database X etc. etc.) that it's impossible to make much progress in a short timeframe (much less during an all-nighther, when all people who could help are unavailable) so I need to spread my work evenly across the week. A lot of it can be just waiting on a Teams reply, though.

We deliberately work 2 or 3 major tasks in parallel in anticipation of always being blocked by 1 or 2 goofy things like what you suggested.

On one hand, you're shipping stuff which is what you're paid to do. On the other, why not avoid the all-nighter and work 2-3 hours per day? At least then you won't have to lie.

It's hard to find the motivation without the adrenaline rush for many people

Every team that I worked on had a lot of visibility into daily commits. Someone doing this would stick out like a sore thumb.

Not sure if this is satire, but if not, how do you manage code reviews when pulling the all-nighter in order to merge features?

Not every company does code reviews.

How in the world does that work :)

I ask myself this every time I deploy to prod. Then I see all the regressions reported. Then I realize it doesn't work...

On a more serious note, since no one is reviewing my code, I resorted to automated testing. It doesn't catch all the bugs, but at least it's something.

I used to work at web agency that did stuff from APIs to SPAs, no tests and reviews. And honestly it worked decently enough. It works decently the fewer developers are on a single project.

Sometimes I had 5 different projects at once though.

Try Focusmate.com - It's really helpful to keep accountable. If you find yourself procrastinating, share your screen.

Very useful for me now that I WFH and not a coworking space.

So basically revert to college behavior?

ADHD?

hell yeah