I really can not believe this, that I finally got an opportunity yesterday to work as a backend developer and the first 90 days will determine whether I am going to continue working in that company or not. And suddenly I saw your video. your advice to me has always been a life-changing advice. THANK YOU
@IAmTimCorey9 ай бұрын
Awesome! Best wishes.
@michaelday69879 ай бұрын
Great list. What a great foundation for a new employee. Here somethings I would like to add: 1. Be honest with timeline estimates. Expect delays, issues and questions. Just because you may think the project is "Two days of work", doesn't mean you won't run into permission issues, or have to wait on an email reply, or have 15 meetings this week. Build in a buffer, and be ready to explain to your boss why you feel it should take that long. 2. Learn the full process of the projects you work on, not just the small task you are completing. (Especially if this is a long term project) 3. Be open to projects other people hesitate on. A developer who is not afraid to take on a tough or unpopular projects is worth their weight in gold.
@IAmTimCorey9 ай бұрын
Thanks for sharing!
@anonb09 ай бұрын
Starting my new job in a few days, so this is perfect timing! 😊
@IAmTimCorey9 ай бұрын
Excellent!
@domizianoatticciati57189 ай бұрын
I would like to integrate the valid advices that Tim has given. Changing job can be a great period of stress, the risk of trying to be "the perfect employee" is to lose sight of yourself and your needs trying to please your boss. “Work as hard as you can” can be a double-edged sword. What I mean is therefore yes, commit yourself and follow Tim's advices, they're good advices, but remember that you too are a person with needs and that, if it is true that you are in this job to allow your boss to - in Tim's example - building software that needs to be sold, without you there is no software, the relationship is equal and not a "one way".
@IAmTimCorey9 ай бұрын
There's a balance here. In life, yes, you are equal. In the job, no, you aren't equal. Your boss is in charge. You've agreed to do something in exchange for your salary. That means doing it well. Now if your boss asks you to do something outside of what your job entails, you have the opportunity to choose not to (and walk away from your job). But if you want to remain inside the job, you have to put yourself under the authority of your boss.
@DeepWorksStudios9 ай бұрын
Sadly i lost my job after successfully 4 months sadly my mental health come into my way...
@IAmTimCorey9 ай бұрын
I'm sorry.
@Sysshad9 ай бұрын
I feel this is very American biased. It's good advices but in some countries most people already does this out of respect to the employer, colleagues and workplace. And in regards of on board documentation, we as devs must make the lead and product owner understand how important it is to keep it updated all the time. I've been in teams where practically all who knew anything quitted so those left had a really hard time.
@IAmTimCorey9 ай бұрын
Well, I am American so that's definitely my primary point of view, yes. However, I think you should be careful not going too far the other way, though. Yes, there are countries where people already do this. That doesn't mean that most countries do. I've worked with companies from other countries and I can tell you that it isn't just an American thing to not do this by default. I also agree with the sentiment of keeping documentation up to date, but in this video, I was talking to people in their first 90 days. They shouldn't be trying to "make the lead and product owner understand". I pointed out that you should figure out how the business runs and why it does things certain ways before suggesting changes. So while I agree that up to date documentation is important, it isn't the role of the new hire to force that to happen. They can document what they learn and they can update the information they were given as a help to their boss, but that should be as far as they take it unless they are asked to do more. At most, they could ask to be assigned to keeping it up to date.
@Sysshad9 ай бұрын
@@IAmTimCorey I agree, but what I meant about documentation is that it ideally always should be there and work 99% so the newcomer won't leave because he finds it all to messy (has happend in my experience) it's a sign that the team actually has time to do this work which most often is neglected due to stressful schedule. Sometimes there ain't even time to take care of the newcomers :(
@MfundoTenza9 ай бұрын
Thank you for the advice 🙏🏾
@IAmTimCorey9 ай бұрын
You are welcome.
@codefoxtrot9 ай бұрын
I took notes!
@IAmTimCorey9 ай бұрын
Excellent!
@dand44859 ай бұрын
I would disagree with some of the info. The part of "ask questions... even be annoying..." Granted their is probably a bit of info stepping into a new job you will need to get from others, no argument there. Would assert most places will have a new hire on-boarding doc, ask for that and read it. And many places i worked they didn't have one, then volunteer to create one. Then about asking the questions, first thing would be to ask your boss "Who should i ask questions...?" But a big factor that will turm me off on a new hire, the person simply doesn't put any effort in to learn it or find it out on their own. Also Tim's suggestion to write down and save information you get from others to refer to later, would suggest write down your questions as you go along and save them, ask the person mentoring you "Hey generally to make the on-boarding easier for you, would you mind if i ping you say every two or three hours? I prefer to struggle a bit and save up my questions along the way, then i can ask you all at once so i'm not a huge burden on you....?" Most mentors i have had in the past will agree and/or speak up and say "Ah don't worry just ask when you have the question, i'll be sitting very close... But this give them the freedom... Best of all it shows you are organized and thoughtful towards others, ie. "A good team player..." While my general rule is I'll put in as much effort helping others as they put in to helping themselves as well. But even still do exactly at Tim said, write the answer down to remember it or a link to the reference to find it... Would suggest it should be electronic such that you may easily organize, search and find it later. While can agree more with Tim's comment talk to you manager and ask what his needs are, and even talk in terms of building up a channel to talk about stuff. Find out what are the short term and longer goals and issues that are or will be the most prominent. Along with that should ask what will be the immediate tasks you should concentrate on. Also talking about learning the company's style for doing stuff, ask for the coding standard and design/convention document for the example Tim gave for the sql and naming it "tblCustomer", might be me i started working before SQL was a thing, or might say before $icroMoft bought it, have to admit strange reading through the sources for M$ $QL and seeing "Sybase " the originator for M$ $QL. Many think the Hungarian notation is bad, but really does help in my opinion... Which of these are tables or views? Customer, Sales, Employee? Now the same tblCustomer, vwSales, spEmployee or prefixing with tbl_, vw_, sp_. The only choice might be to use the underscore or not. Get into a database with 400 tables, 1000+ views and oodles and oodles of sprocs will guarantee everyone will start loving Hungarian and the debate is ended 😋 Class and variable names in source, might be more lax in the most stuff id object oriented and we are dealing with classes, Gone are the daZe when it was straight up Win32, and it relaly did matter, say for a pointer, was the memory was malloc(), HeapAlloc() or GlobalAlloc(). Unless you've lived and worked back when there were hieroglyphs in my office (some may call it a cave) the reason for using lpszcSomeString or pzcszCustomerFirst, needing to know the details are gone now... Thus as software development evolved some things dropped off. Would assert a lot of this wasn't done to be a pain, and may seems senseless now, you simply couldn't or wouldn't be able to develop anything sizeable by not doing it...
@IAmTimCorey9 ай бұрын
I think you are probably reading into what I said a bit too deeply. I never advocated for asking questions instead of thinking for yourself. I even said to try not to bother people. However, a rookie mistake is to struggle for hours on something that you didn't have all of the info on and that someone could have helped you with in two minutes. That's wasting company time. One quick note on your love for Hungarian notation (not my cup of tea, but I'm fine with it) - Don't do "sp_" That's a problem. You can do "sp" but not with the underscore too. If you use "sp_" then SQL has to look in the master database as well for your stored procedure, since that indicates a global stored procedure. That slows SQL down and it can step on toes.
@dand44859 ай бұрын
@@IAmTimCorey Not sure i said i love Hungarian notation, but there was a time and place it was needed. People didn't simply do it for fun. Might assert in the mid to late 90's the need for it kind of went away. Doesn't sound like you had to deal with multiple heaps, or why it mattered. It is a good thing, we no longer need to do it. Would assert your comment about SQL needing to look up from a global seems off. At least from how sql worked when i worked on it, bldg 35 was a nice building.
@AzDev-CommV4 ай бұрын
This are some good tips! 😀
@IAmTimCorey4 ай бұрын
Thanks!
@gilbertigwegbe94819 ай бұрын
About creating onboarding documentation, is there a general template for doing that or do i just wing it?