Good article!
To set the context for my comments, I've been managing developers off and on (mostly on) since 2007, much of that in professional services, so I have gotten to supervise many dozens of people over many dozens of projects and gotten exposed to dozens of clients' development shops.
The one thing I'll criticize here, is that 90 days to show that you are a useful member of the team is 60 days too many. A good manager knows within a few weeks - often sooner - if someone really is the right fit for the job. Everything else in the first few weeks or months is either reinforcing or changing that opinion.
Most development orgs don't onboard enough folks to have a solid, repeatable plan to onboard. You're lucky if you have a computer, the tools installed, and the access you need in the first week at a lot of places! Likewise, they don't have this nice queue of tasks that are perfect for a junior developer, not so high-priority that a more-experienced person needs to address them ASAP, and they can wait for you to take your time on them. In addition, virtually no places have such a surplus of developer bandwidth that they have someone take significant amounts of time to coach and mentor you. And forget about documentation. Maybe 10% of the companies I've engaged with even have the CI/CD or DevOps stuff written down, never mind things like naming conventions.
In such an environment, it's extremely difficult for a new hire, never mind someone without much experience, to show their stuff quickly.
But what they *can* show, that goes a huge way in keeping their paychecks coming (or, at the very least, not classified as "the first person we let go when we are told to make cuts"), is to demonstrate an amazing attitude. Come in with "what can I help you with? Where are you short? How can I best assist without getting in the way?" (that last one is super important!). Get on those things. Ask SMART QUESTIONS ("which repo has the code for X?" is a smart question, "how do I write an INSERT statement?" is not...), show you can search for info... not just in a global search engine, but in the code repos, the intranet, the wiki, the collaboration tools (Teams, Slack, etc.), the ticketing system, and so on BEFORE you ask the question ("I did a search and saw three copies of this code, which is the right one?" is 10x smarter than "which file has this code?" which is 10x smarter than "I'll write a function to do X").
One of the best junior folks I ever worked with would come to me with questions like "I looked at how we do this elsewhere, but I'm thinking that might not be the best approach here because of A, B, and C, so I came up with two alternatives, here are the pros and cons of all three... which do you suggest I use?" which showed that he could figure things out on his own, come up with useful ideas on his own, be able to justify his ideas, identify pros and cons... yet had enough self-awareness to know that when new, it's good to ask someone else.
The final key is to regularly report progress (that's the "bragging" that OP mentions!) which being fast to ask for help getting blockers out of the way. Want to lose a job? Wait until your manager says, "what's the status?" to say "I'm blocked by ABC", or waiting until your regular update to say that. As soon as you know that the blocker will impact the expected timelines or what you can deliver, RAISE YOUR HAND!
That's the stuff that the manager sees (or hears about) in your first week, and then continues to the next 90 days, and beyond, so when your name comes to mind, the immediate reaction is, "they are inexperienced but have unlimited potential, we need to keep them at all costs" as opposed to "gee, this person showed a lot of promise in the hiring process, but they really let us down."
J.Ja
