[dazeandconfuse]

Thanks. I definitely will take that into consideration in the future. I'm not sure if it would have helped in this specific case but I can definitely think of other situations at work where taking your advice would have helped me.

[sdenton4]

Pushing back on changing requirements is also a good skill to pick up. Part of it is getting a really clear agreement on what you're actually doing - what's the real scope of work - and actively changing the agreed plan when requirements change. I also find it helpful to highlight that changing requirements will have a cost in time, etc.

There's also a an art to getting together a good MVP efficiently. You can treat lots of added requirements as shiny feature requests, and prioritize them below getting the MVP working. Having an MVP that people can try out and see it working at all goes a long way towards building belief in your work. At the same time, you want to build flexibly enough that the MVP can expand rationally to take on those added feature requests... without writing in SO MUCH generality that nothing ever gets done. Doing this well is a skill learned on the back of many failures and tedious refactors... But efficiently getting a demo+MVP is golden, even if you build up some tech debt to get it.

[btown]

I'll add here that there's a ton of nuance to "pushing back on changing requirements." My rule of thumb is this: program managers should understand the expected and worst-case consequences (including baseline time, switching costs, stepping on other team members' toes, etc.) of any proposals to expand scope, and as an individual contributor it is vitally important to be vocal to ensure they understand the full dynamics.

But if and once they do understand and acknowledge the consequences, and still say a scope increase is justified, it's highly highly likely that they have more business context than you. Document the decision, of course, but fundamentally trust your team.

[s17n]

It really is the solution to everything. A shitty coder who communicates well will do better in a corporate setting than a good coder who doesn't communicate.

My advice to you: 1. Put serious effort into Slack (or whatever your company uses). It is just as much a part of the job as writing code 2. "You don't get a second chance to make a first impression." I'm not saying you should definitely change companies, but you should seriously consider it, as you are now going to have to put in a ton of effort to regain trust. There is a good chance that you'll have a better ROI just putting in that effort at a new job instead - if you kick ass in your first 6 months to a year, you will enter into a flywheel of being well regarded which makes you more effective, which makes you more well regarded.

[DrNuke]

I’m afraid the boss’ boss was talking with the wrong part of your team, in that his criticism really seems made for your boss, not you? That said, you were not treated like a novice at all, being given a fair share of high-level feedback. Take it as a nudge to improve and do better, without thinking too much: it will be your manager’s job to assess your output fairly.

[r00fus]

The 'bother the professor' part is key. With new teammates, I want them to reach out if they're on a project I'm leading. If things look like they're going well - then it's great to get positive feedback. If not, better to change direction early (lost work due to changing requirements).

Do you have a weekly 1:1 with your manager?

[dazeandconfuse]

No, I don't, is this something you think it'd make sense for me to request?

[NortySpock]

Yes, or just schedule the one-on-one yourself. You have Outlook, same as them.

[kuhewa]

While changing requirements are outside of your control, clearly the consequences affect you, however unfairly. It's a skill to predict what might change and which parts of the project could end up being wasted time, and you will develop it with experience. I think being in continuing regular communication with your manager and team members as others are suggesting is also a good idea and partially for indirect reasons, because you might pick up on some clues of what these things outside your control may end up affecting how your performance is perceived.