Your First Day

September 05, 2019

Joshua and Kel talk about your first day as a developer in this podcast episode. What to expect, what not to expect, plus tips for making your first days a bit smoother!

Be sure to check out our new Slack community to meet others who are facing the same things you are and share your journeys!

• 00:00 Joshua

  Hey folks, welcome to Getting Apps Done. A mostly non-technical podcast about building software.

• 00:10 Joshua

  Today we want to talk about.... We quite often talk about all the stages before you get a job, how to build up your CV, how to build your profile, what to do in an interview, things like that... but we don't actually talk about what to do on day one when you do get that job.

• 00:25 Joshua

  So we wanted to go through some of that today and discuss, you know, what you should expect, what you shouldn't expect and just generally how your first day is going to go.

• 00:34 Joshua

  Now before we do that though, it has been pointed out to us that we have made over 40 episodes now and we never actually tell anybody who we are. So we're going to try and figure that out today. I am Joshua. I am a technical consultant. I've been developing software for 20 years.

• 00:50 Kel

  And I'm Kel. I am also technically a consultant. Um,

• 00:55 Joshua

  Technically a consultant!

• 00:55 Kel

  I have been.... I am technically a consultant. I technically consult on software development and processes and all of the fun stuff, similar to Joshua. Um, I have been programming for about 25 years now is what I figured out this summer. Um, though professionally as a developer, only 10, 15 ish. So anyway, yeah, we will try to introduce ourselves so people at least know who is speaking on each episode. Uh, but otherwise, yeah, continue like normal.

• 01:23 Joshua

  Alright. Um, so on your first day... We'll get back to the actual topic here. Um, so there are a lot of things that people seem to expect or not expect on the first day that are kind of surprising. I think it's probably good just to start to go through a couple of those things.

• 01:40 Joshua

  So the first one for me, and this is kind of one that I ran into very quickly, even if you think you know what you're doing, you're going to get in and have no clue what you're doing. It's guaranteed. Even as a senior developer, when I walk into a new project, there's a bunch of stuff in there. I've never seen it before. And yeah, I can probably figure it out, but there's just so much that I have no clue what's going on. And it's like walking in and being completely fresh. So no matter how much experience you have or don't have, it's perfectly normal to walk in and have no clue what's going on.

• 02:15 Kel

  Yeah, that's.... I can't actually think of an analogy for this. You know, if you, if you're, I don't know, a mechanic, most engines are kind of similar, but when it comes to software, the.. Like the way the complexity can emerge is without prediction. Like it's impossible to guess what that software will look like or what architecture patterns, like people design stuff differently everywhere you go. And it's the larger the product, the more interesting constraints that formed you know, formed the architecture and those all these things you have to learn and memorize. And how does the database set up and where is this and why is this here, what does this even do? Like that's just a normal aspect of developing on a giant project.

• 02:58 Joshua

  Absolutely. And most of these projects have grown organically over time. So whether there was a single pattern or not, there may well have been 12 different patterns over time. So there's just going to be tons and tons of stuff to try to figure out on day one and it's just not going to happen. It's going to take you time to ramp up.

• 03:15 Kel

  Maybe biology is a better analogy.

• 03:18 Joshua

  Yes. All the bodies are kind of the same but completely different.

• 03:23 Kel

  Exactly. So I mean part of the, what kind of spawned this topic was someone was mentioning of uh, they were talking to me about our preference on version control systems as a junior developer. And my first thought was, "you think you're going to get a pick that?"

• 03:39 Joshua

  You don't get a preference.

• 03:41 Kel

  Exactly. And that's, that's kind of the reality is when you're starting a new job as a developer as junior or senior, when you walk into that job, you're not going to get to pick the tech stack unless it's a brand new project. You're not going to get to pick anything. Those things will be done for you when you get there. You're going to be walking into an existing project that has a lot of decisions that have been made, that have been ran with, that had been built upon. And those are the things you have to learn in order to be able to contribute.

• 04:08 Joshua

  Absolutely. And even if it is exactly the same stack that you would have chosen, they will have made different decisions and how they've implemented it and you are going to have to live with them. You might absolutely be able to make changes over time, but certainly on day one just assume that whatever they've got is what you got.

• 04:25 Kel

  Exactly. Like you're, you're going to be coming into a situation where you do not know all the history and you're going to have to learn it first before they're going to allow you to make unilateral decisions unless you were hired as the boss, which is unlikely if you're a brand new developer.

• 04:40 Joshua

  Yeah. And even if you weren't, you shouldn't be making those decisions on day one. You should figure out the stock before you start to make random decisions to get rid of it.

• 04:49 Kel

  Yeah. It's important to build up trust before you start, you know, using that trust and power to make unilateral decisions like work your way into those kinds of things.

• 04:58 Joshua

  Yup. Also on day one you don't get to pick your team or who's going to be your teacher or any of those things. So you're gonna have to work with what you dealt. It's kind of one of those situations where you may be given a of a mentor or it might even have a couple of different mentors. You may have nothing. You might just get, in fact the first development job I got I was given a link to download some source code and told good luck and that was it. They may well be set up for training, they may will have books and libraries that you can use. They might even have courses that they send you on and things like that. But they may well not have any of those things at all.

• 05:36 Kel

  I'd almost say probably not probably. I like how this is immediately starting off as you don't get to pick any of this stuff and what you walk into could be anything. Like great way of setting expectations there but...

• 05:49 Joshua

  It's very true.

• 05:51 Kel

  So, I mean, common ways that I've seen people actually go through like training, you know, new person joins on, usually paired with somebody. They walk you through, you know, this is the source code, this is the project we're working on. Hopefully they set you up the, you know, they don't just give you a download link to the source code but actually help you set up those things. Um, especially as developers, it's really common to set expectations really early that you will figure it out on your own.

• 06:16 Kel

  A lot of developers, especially the ones who've been in this industry as like, as long as Joshua and I have been started off with loads of technical experience and not just development. We learned, as you know, we supported software or desktop stuff or Linux or servers and did like varied experience. And so it's a really common thing for development departments that have this expectation that you'll have all of these other skills as well. And if you don't, well that just gets to be another thing you get to learn is how does this database server work anyway? How do you install this thing?

• 06:47 Joshua

  Yeah. And that is going to be a lot of your first days is just learning all the tools and the pieces that fit into the puzzle. It's not just about languages, not just about frameworks. There's a whole infrastructure around everything that says huge set of tooling, which again, you don't get to pick any of, so you have to learn and make due with, and that's part of the fun of it I think is going out and figuring out all these things and learning about it. But certainly you cannot expect that somebody is going to sit there and hold your hand and teach you every single one of these things. Some of it is going to be stuff that you're gonna have to learn.

• 07:24 Kel

  yeah. Unfortunately the kind of the, the other side of these things evolving out of decisions is no one actually knows like can work backwards. Not many people actually know that the path of the decision, so you'll run into things that make absolutely no sense until you learn all the history and so you just kind of got accept that it's there and that's what I got to work with and that's fine.

• 07:46 Joshua

  Yup. And that's okay. Yeah.

• 07:53 Kel

  I'm going to go along with the not just the software, not just the development, not just the architecture but also the processes. We talk about agile pretty often on the podcast and that's a pretty common methodology and everybody does it completely differently.

• 08:07 Joshua

  Yeah. I'll... Even if you were talking about a very specific version of it, like scrum people will pick and choose the parts of it that they like. Very few software development houses that I've seen follow it to the letter. And even then there are different interpretations, different versions. So what you are used to, what you learned in school, what you learned in bootcamp may not be what they're doing. They're not necessarily doing it wrong, they're just doing it their way.

• 08:31 Kel

  This is a lot of the reason why we talk in really like general and abstract terms as part of the podcast too is because these are kind of the overall patterns that we've seen in multiple development environments. And we want you to have that kind of like root understanding of why do you do agile? Because that'll help you interpret when you go into these new jobs and you see their process and they don't do stand ups. They do, you know, they check in in another way. You know that stand up isn't just an arbitrary thing, but it's to get everybody on the same page. And so that's why we talk about these things.

• 09:01 Joshua

  Yep. And that is an important thing when you are on your day one, we're talking about what is going to be like, but some things that you can do to make it better. And the number one thing is talk to people. We said in the podcast episode the other week, use more words. If you are struggling, tell somebody, explain to them what you're struggling with, why it's a problem. You can even tell them a little bit about what you've done in previous companies, but don't ram it down their throats. "We used to do this and it was much better."

• 09:30 Kel

  Yeah, that's now going to make you a popular person around your office.

• 09:33 Joshua

  No and I've seen it so many, so many times. In fact I know I was guilty of it many, many times when I was a younger man. I might still do periodically, but if you explain it in a way that is respectful and explains or puts them in this context that you are in, it makes it clear that this is why you're struggling with this is not because you're an idiot, it's not because you don't understand what they're talking about at all. It's just because you come from a different point of view and you're trying to understand theirs.And I think most people aren't going to be respectful of that in general. They're going to be happy that you are trying to understand their point of view so that you can do a better job.

• 10:11 Kel

  Absolutely. And it is kind of important to differentiate between the, I don't like this, you should be doing it this way, kind of point of view. Like contrasting that against, I don't understand why you're doing it this way. Like those are kind of different points of view. Like once you understand why something is the way it is, then you can start forming opinions about accomplishing that same goal in different ways. Kind of the difference between a user story and an implementation. Um, but until you actually understand it, you really shouldn't be trying to make any suggestions. So starting with understanding is a, as an important thing and if that's how you're approaching the, your coworkers and asking them, I don't understand why we do these things and then, you know, explaining why, where you're coming from and using more words to get that understanding. Um, like you said, most people go along with that.

• 10:59 Joshua

  Yeah. And that actually leads into then the best approach that you can take to any new job is to be curious, be inquisitive, explore, ask them. There a going to be people there. I would assume there's going to be people there who have learned all these things before and they have a better understanding of that environment. They know what the architecture is, they know what the infrastructure is, and there'll be able to guide you and tell you, okay, actually it would be really good if you researched this. It would be great if you knew these patterns and that will help you decide what your homework is.

• 11:30 Joshua

  I don't generally encourage people to go home and do work after work, but at the same time I understand that certainly when you're new, sometimes that makes you more comfortable and I would much rather you be comfortable than work your hours and absolutely nothing else. Yeah.

• 11:47 Kel

  That's kind of part of I guess the, the company itself, setting expectations and how fast you should be learning and picking these things up and hopefully those expectations are reasonable. Um, but in, you know, if preferably they would have this expectation that you'd be learning these things during business hours, but that's not always the case. Yeah. They might have expectations that you will hit the ground running, right into a wall.

• 12:12 Joshua

  Yeah, you're going to run into it one way or the other. Some people or organizations will absolutely allow you to do those things on work time and that's great if you get that, but if not, if your only option is to do it in your own time, then absolutely ask as many questions as you can so you're not wasting your own time learning things that aren't going to benefit you.

• 12:33 Kel

  Yeah. I feel like there's some other expectation setting we should do on the negative side of things of you're going to walk into this job shiny and new and excited about all of these new things to learn and do and they're going to be so jaded... Of, oh yeah, that was this one catastrophe with that one customer and Oh, just, just don't even just forget about that. Yeah, like any other job. It's not all that's all. Not all shiny and new and positive, but development jobs do have more opportunity for curiosity, which is why we're here.

• 13:11 Joshua

  Absolutely. And if you can start your first job with that in mind and continue that with every single job you move into it will keep things going. I, that's the main reason I'm still interested in development because I get to try all kinds of new stuff and even within the constraints of... When I'm stuck with a particular stack, I still get to explore new things, try new things, make small changes and that's a great way to move forward to also bond well with your team because if you're improving things for them, they're going to be happy. And that is another good thing that you can do is start early on communicating with them and asking how you can provide value to them because that's your team. The more you work with them, the better you work with them, the better they're going to help you.

• 13:57 Kel

  Yeah, definitely. I mean that's not so much about setting expectations about, but things that you can actually do intentionally, mindfully when you're at a new job at an any job is you know, mindfully forming these communication bonds with your, your teammates, you know, open and honest communication, use more words, all the good things.

• 14:17 Joshua

  There's a reason why these subjects keep coming up because they are extremely important. We're all just people and we all do great things and stupid things and wonderful things and terrible things. And the best way we can deal with that is to talk to each other. Just communicate, be open to what other people have to say, what their opinions are, what they think and learn from it. And if you can do that on day one, that's going to set you up for a pretty good run.

• 14:43 Kel

  And on the topic of everybody just being, people do keep in mind that your, your senior engineers, your senior developers, the folks that are over are still just people. They will make mistakes, they will under misunderstand things. What they have is a like experience. They have experience and a skill built around that experience and that's what you should be like kinda depending on, but they are still people. They are not magical. They're not magical. You've mentioned imposter syndrome before of like the gurus being, I don't even know how to describe them.

• 15:16 Joshua

  Absolutely. I just assumed, you know, when I got out of high school I thought, okay, I'm going to get into college and there'll be all these gurus. They know all these wonderful things. So I got to college, no, they weren't there. And I thought, okay, well no, I'm going to go to work and they'll be there and I got there and Nope, they weren't there. I have met some very, very intelligent people. I've met some really creative and talented people, a lot of people who were much better at particular things than I am. But there are no just gurus out there. There are people who have different knowledge than I have.

• 15:43 Kel

  Yup. They're all still just people. And so yeah, going in with that expectation. It's also kind of a helpful thing because it, it sets up these relationships in a like an equal and equal back and forth where they're both equally valid. Both equally is you know, important like there's no odd ranking system that you get if you approach your, your approach these relationships that way.

• 16:06 Joshua

  Yeah, absolutely and that was another thing that I noticed early on is that quite often I was afraid to talk to the more senior developers because I thought I was wasting their time and that I wasn't as valuable or relevant as they were and that's just absolutely not true and they don't want that either. They want you to communicate with them because you're a part of the team and the sooner they can get you up to speed and doing the things they need to be doing, the better that is for them. You are a partner in this to them.

• 16:34 Kel

  Exactly. The sooner that they can trust you to accomplish things without them having to do everything for you, like the more that they can trust you with, the more that the more value they're getting out of you. As a teammate and so as much of that workload you can take on and accomplish, the better you will be as a teammate for them.

• 16:53 Joshua

  Yeah, that is definitely something I have seen. That is a misconception that a lot of people have, myself included originally, that everybody's going to want them to just pull their own white, do their own thing, learn everything on their own, figure everything out on their own. But actually most of the time I want you to give it a good try and then come to me if you're banging your head against the wall, because I don't want you to go spend two days trying to figure something out when I could've spent two minutes just telling you this is it, and then you'd know it forever.

• 17:22 Joshua

  I want you to put it a little bit of initiative into it so you can learn things because there's absolutely a ton of value in figuring things out for yourself, but at the same time, you're part of a team. Take advantage of that.

• 17:34 Kel

  Absolutely. And that's kind of a kind of a directed learning of when you, like if I tried to teach you things, I'm not always going to guess what you don't what you know and don't know and what order things you need to learn in and so you are attempting it on your own is a very important part of that process of Oh these are the questions you have. I totally guessed wrong what you were confused around.

• 17:55 Joshua

  Yeah.

• 17:55 Kel

  At the bootcamp I taught at, they had a 15 minute rule of hack at it and if you were completely stuck after 15 minutes on one silly problem, go ask somebody. Anybody TA, another person, just ask like don't waste anymore time. And while that's probably not quite appropriate amount of time for outside of this learning environment, like a job environment, but if you hack at something for an hour, you should probably go ask somebody if you're completely stuck.

• 18:22 Joshua

  Yeah. I generally say about an hour because if somebody comes and bugs me every hour, that's eight times a day. I'm not going to get too wound up about that.

• 18:30 Kel

  For sure, especially when they're new.

• 18:32 Joshua

  If you came to me every 15 minutes, then we might start to have a problem.

• 18:37 Kel

  And you might find out that that's not an achievable like timeline either. In which case that's sounds like they don't have a lot of extra capacity to be training a new person and they may not have hired correctly, but you can still work around that limitation of that's when you start getting into having to do things in your own time or just documenting your questions throughout the day, like rotating through different projects so you can, if you get stuck on one you can move to the next and those kind of clump them all at the end to ask the poor person over, you know, hey, can I have a meeting with you every day for an hour and we can go over all the things I'm still lost and confused about and I have them in a nice documented and a bullet pointed list.

• 19:13 Kel

  You know, there are, there are ways that you can kind of streamline the process for this other probably overworked developer, but yeah, trade offs. Preferably somebody can actually work with you next to you. I'm a big fan of pair programming when you're first learning, especially just because it's kind of a constant back and forth. Even if it's two newbies.

• 19:31 Joshua

  Yeah, absolutely. And that then the gates, all the 15 minute rules and one hour rules and things like that because you're right, there are working together. You can learn and ask questions openly and it works really well. Not all the time, but absolutely. There should be some time dedicated to that.

• 19:47 Kel

  Yeah. Unfortunately we can't set that as an expectation cause that's probably the least popular programming practice I'm aware of.

• 19:53 Joshua

  Yeah, and I can see the point of view. A lot of companies see it as paying two developers to do the same thing and they don't necessarily see the value. Whether they're right or wrong is completely irrelevant. That's what a lot of companies have decided, so you can't expect that, but some companies will allow for that and if they do take advantage of it.

• 20:13 Kel

  A lot of it too. That takes a lot of practice to be a good pair of programmer and especially for folks who learned like me and you, you know, we learned on our own pair programming is kind of a different skill and it's not something I'm particularly good at. I usually code on my own and most people can barely follow along, so...

• 20:28 Joshua

  Yeah. Other things to expect on your first day... Don't assume that you're going to go straight into code. It may well be that particularly in large organizations, they're going to have you just vetting tickets at first or they might have you doing tests or building unit tests. If you are writing any code at all, it might just be building a bunch of unit tests. Take advantage of those as well. Those are really great ways to start to learn your way around the product that you're building.

• 20:55 Joshua

  In fact, I keep saying this to people. I think the best way possible to become a really great developer is to spend some time in support as if it gives you a different viewpoints on a lot of subjects.

• 21:07 Kel

  Absolutely maintainability and usability.

• 21:09 Joshua

  I am absolutely convinced that, maybe not necessarily shoving developers on a help desk, but having them vet tickets... Just go through the tickets, make sure that the problem exists. Talk to the end user about what exactly happened and start to get a grasp of the sorts problems they face, how they manifest, who the people that are building this product for are. That will make you a better developer in long run. In fact not even in the long run. In the short term it will make you a better developer straightaway.

• 21:36 Kel

  Absolutely like it. It shows you where the real problem like problem are, where the actual issues are, what users are trying to do and not do. Where maintainability problems are popping up. Like going through tickets is probably the most important thing you can do as a like a product manager is probably met. The main focus of this is you know, what are, what are their priorities is usually whatever is popping up in the support and by reading those as a developer, it gives you a much better idea of what the product does and is being used for that sort of thing. If nothing else. It will also give you a high level tour of the product as you start digging into every single ticket.

• 22:10 Joshua

  Yeah, absolutely. So the point is, don't be offended if on day one you aren't fixing bugs or creating new features or anything like that. It's a very practical exercise. It's a very good way to onboard new people. So if the company immediately puts you on tickets, don't just assume that first off they're relegating you to ticket duty and that's all you're ever gonna do. But second, don't look down on it. It's a really great thing to start out with. It's a really good way to get dug in and it will not be very long at all before you're fixing some of those bugs that you are seeing before and you are starting to submit ideas for how to fix it. At the very least and that's a very valuable way to start integrating yourself with the team to start to get better with the product, to get better with the customers and to get better. As a developer.

• 22:55 Kel

  That's a pretty great progression of starting with you know, starting with those basic tickets, reading them, understanding them, then starting to actually fix the bugs yourself and then from there Lou recognizing larger patterns that would do well with a feature of this problem comes up a lot. We should probably build a feature around this use case so it stops coming up entirely and that's a a very common progression and you know both you know as a product, you know, building a product and also as the developer implementing the product.

• 23:25 Joshua

  Yeah.

• 23:25 Kel

  So is there anything important we're missing?

• 23:29 Joshua

  There are a few different skills that we've talked about in the past that are probably worth mentioning. Things that you may not necessarily have learned in a boot camp or at university but may actually be really beneficial for you to pick up very quickly.

• 23:43 Joshua

  One of them that I can think of right off the of my head is estimation. Being able to understand how long it's going to take you to do a piece of work because that's going to very quickly happen. Somebody is going to ask you how long do you think it will take you to do that?

• 23:55 Kel

  Maybe on day one!

• 23:56 Joshua

  Maybe on day one! It could very well be the case. In fact, I have asked people things like this on day one usually not anything technical, just more about them and their ability to pick something up and read something, but very quickly they're going to want to start to gauge you and start to understand you. Particularly if there's a project manager involved, one of their first jobs is going to be to understand you and figure out how long it takes you to do things so they can start to plan around that so you being able to estimate your workload and how quickly you can get through pieces of work is extremely important. We should probably do episode recapping on that one because we've talked about that quite a while ago. It might be a good one to bring back.

• 24:32 Kel

  It has been a while... And I mean my methods of estimation or, yeah, like preferably you, you're going to aim high because you would rather deliver early than deliver late because at least people can plan for a long period of time. Like, oh, that's going to take me a month, and then it takes you two weeks and it's like, well that's, you know, that's better. If you said two weeks and it took you a month, well then everybody's schedule is messed up so you usually end up overestimating and then as you get more accurate that risk level goes down like you can. You can pick.. You need less buffer over time as you actually learn your own speeds, you'll learn the products, you learn how fast things go on, but yeah, I definitely agreed that estimation is one of those things that's going to come up very quickly.

• 25:17 Joshua

  Yeah. We already mentioned communication, obviously with everything. Communication is key, but one thing I would say is setting expectations as a part of communication is extremely critical. Learning how to, again, just make it clear to people what position you're in and how things are going to go. Because the worst thing that you can possibly do, much like the estimates, is tell them one thing or have them here something that you didn't necessarily intend and then deliver for them because that's going to set a negative impression very quickly. So being able to appropriately set expectations, make it clear how long something's going to take, make it clear what's involved with something, make it clear what your context is with something that helps everybody involved. Plan around it, understand what they need to do, what you need to do and where everybody is.

• 26:05 Kel

  A lot of this stuff is like formalized in agile processes and things, you know, these are your deliverables, these are my acceptance, these are my user stories. Like these are all concepts that can be applied to any kind of basic communication. But the, the biggest part is, you know, making sure everyone understands what's happening when it's going to happen and then everyone agrees that this is an okay thing or you know, can show that understanding. Like keep asking questions, make sure that people understand what you're providing. If you're not sure, that can be a little annoying at first but people will get used to it. You may find that after listening to the podcast you are better at this than they are.

• 26:41 Joshua

  It could be! Listen, the podcast more often! You mentioned agile and that's actually another really good point. Learn the processes, start figuring out what the processes are from day one because those are going to be really important. Most organizations have some kind of process, but it's going to be different from one to the next. So even if this isn't your first role, if it's the second, third, fourth, even 10th role, learn the process first thing as almost as important as communication and estimation and setting expectations, learning that process, knowing what's going to happen when it's going to happen, why it's gonna happen and how you can proactively plan for those things is gonna save you a lot of grief.

• 27:22 Kel

  Yes, absolutely. And processes are a lot like software. They are a, like scrum is an app and you run your organization on top of it. And so people make their own modifications and changes and you have different priorities and different use cases. And so like a process is different at every company. And honestly I think that's delightful. There's a reason why my little tagline is developers, software processes and people. Um, I think developing processes or processes, whatever are, is just about as entertaining as developing software.

• 27:56 Joshua

  Yup. Um, this one's a little bit less on target, but I would also say infrastructure learning, the infrastructure that you're working in is important. Infrastructure isn't always focused on in development, but he's actually really important. Understanding the difference between your development environment, your UAT environment, your acceptance or testing environments or demo environments or production environments. You might even have multiple.

• 28:22 Kel

  Staging!

• 28:22 Joshua

  Yeah. There may won't be lots and lots of different physical infrastructure environments that you're working with and understanding which ones are, which could be the difference between deploying something to UAT or accidentally promoting something to production. And you can get a lot of trouble understanding those things and having a reasonable comfort level with them will make everything easier. Once again, just giving you that level of confidence. It will also help with your communication because you can tell people exactly it was on the demo system or it was in the UAT system.

• 28:52 Joshua

  Just simple things like that can make a huge difference because getting it wrong can make a huge difference as well.

• 28:59 Kel

  I'm going to call you out on using more words. What is a UAT system?

• 29:02 Joshua

  Ahh! Absolutely right. I used an acronym. UAT is user acceptance testing. Uh, it's kind of like a demo system but it's, it tends to sit between a development system and a demo system so people can go in and make sure that the features you're working on, or the bug fixes that you put in actually work before you start deploying it to thousands and thousands of machines.

• 29:23 Kel

  Which you'll see is a lot of... There's a lot of overlap between infrastructure and process of the infrastructure supports the process and it supports what you're doing and depending on the scale of company infrastructure, could be that one server over there that hosts our version control system and that's it. Or or infrastructure be, you know, all of AWS like Netflix is running.

• 29:44 Kel

  There's pretty wide range and especially lately the expectation in development world is to be a little bit more infrastructure aware, um, than we used to be because of the serverless platforms because of, you know, virtual machines and docker and containers and all of these infrastructure technologies are kind of bleeding their way into just, you know, pure development, you know, writing code. And so there is a lot more expectation lately to have at least a little bit of awareness of those things. And you know, back in the days when, like when we first started, everything was a server or it was a desktop and that was about as good as it got. And actually when we started, that might have been dumb terminals technically.

• 30:23 Joshua

  Yeah. I worked on quite a few of those.

• 30:26 Kel

  Yeah, we did. But I don't, I don't, I think that was just because of the industry we're in. I don't think it was because of our age... They just didn't go away.

• 30:35 Joshua

  We had tons of those at Boeing because yeah, they worked. Why mess with something that works.

• 30:40 Kel

  They're fine. They're green. Um, but yeah, dumb terminal in this case. You know, machine connects to a server or a mainframe. Um, anyway, so yeah, having an understanding of infrastructure is very important both for the process and for what you're going to be doing. That's another one of those things you just Kinda have to learn. Um, I kinda like wandering around what I like to use to do would just be kind of bouncing around and ask people what's the most important thing they can think of and just kind of collecting that as a list. Um, and then you can kind of look at for overlaps, highlights, you know, it gives you a starting point of what do I need to learn next?

• 31:14 Joshua

  I really liked that because every environment is going to be different. What's important to one company's not necessarily going to be important to the next. I walked into companies where the number one thing that they mentioned was change control because their change control process was so wildly difficult that figuring it out was one of the first things they tasked you with cause it can take you a month.

• 31:33 Kel

  Absolutely. And talk to more than one person to, cause it might be that one person is in charge of the change of control system and is the only one who actually cares. Unfortunately.

• 31:43 Joshua

  Absolutely. And it's different with every company. Other companies that I've been with, the first priority was always understanding the customers. So the first thing they would want you to do is start to talk to some of their customers, get involved in meetings with other customers and start to understand what their needs are, what their pain points are, things like that.

• 31:59 Kel

  I feel like that won't be your first day as a junior developer though.

• 32:02 Joshua

  No, probably not. But it's very difficult to know what a company is going to think is important and not particularly when you're talking about smaller companies, what they think is important may be very, very different than what a large corporation is going to think is important. So ask around.

• 32:16 Kel

  Yeah.

• 32:17 Joshua

  Kel's absolutely right, that's a great way to find out what people there think is important.

• 32:21 Kel

  And you may or may not find, like in some places I've been direction for junior developers is very specific. You know you're going to work on these bug tickets and you're not even going to get to pick the bug ticket. And then in other places it's more here's your computer and a couple of links. Good luck. Talk to me if you have any questions on what you should be doing, in which case that's another opportunity to go kind of talk around, find out people's pain points and find out if there's a way you can support what they're doing. Not necessarily like offload stuff they don't want to be doing because they're working on something more important. That's one of the more useful things you can do as a junior developer is act as that support. It could be, oh I need somebody to sort through these tickets cause I need to go do something else. Well then sure you can do that and that's like an approach you can use to kind of make yourself helpful. If it's that terrible change control system that only one person knows how to use and that person also has a lot of other things they need to do, it's a great time to learn about the change control system.

• 33:18 Joshua

  Yeah, absolutely. I just asked somebody the other day because they asked, oh, I'm out of stuff to do. What do you want me to do? Oh, I have this form that's really tedious and I don't want to do it. And actually he was a really great learning experience for them and it meant that I didn't have to do that. So they're my new best friend right now.

• 33:35 Kel

  I think we've mentioned this on a podcast before, but I'm a big proponent of like switching the leadership and support roles regularly. Um, but when you're first starting out and you know absolutely nothing, then support's pretty much the only thing you're capable of doing until somebody can be like, alright, here's your feature, how will be helping you on this? But you get to pick the path and that's like a later thing. It takes a while to build up to that stage. And also requires somebody who's capable of supporting a junior person who is leading. Cause you know, it's kind of like guiding a child when they're first learning something, you don't want them to run off a cliff, that sort of thing.

• 34:06 Joshua

  Yeah. And that is probably another valid point. Don't just assume that the senior people actually know at all how to help you with anything because they may well be so far removed from your context that they aren't just not capable or they're not in a position to teach you because that's not what they've been doing.

• 34:25 Kel

  And unfortunately that is a different skillset.

• 34:27 Joshua

  Yeah. Some people are very, very good teachers. Some are not. Uh, most of the time just because they haven't had any practice with it. They've been tasked with sit down at your desk, write code for the past five years and they do a really good job of that. So why mess with that?

• 34:40 Kel

  Yep.

• 34:42 Joshua

  I've certainly been in that position quite often as well. They doing a good job, so we'll have somebody else train all the new people because we need Josh doing the work. So certainly don't assume that they're just fobbing you off because they are, they may well just not have any idea how to help you,

• 34:59 Kel

  And it's pretty common for the newbies to train the newbies, which isn't actually a bad thing. They tend to know where all the highlights are pretty quick. Unfortunately, they also have kind of like generational knowledge gaps of lessons learned in the previous generation that are lost and the next, but yeah, so... that's uhh..

• 35:17 Joshua

  I think that covers most of day one at least, and then a few more probably.

• 35:22 Kel

  Yeah, a little bit of a different format than our normal podcast. I don't want something different this time just to talking of setting expectations.

• 35:29 Joshua

  There you go. All right. I'll put some transcripts up at gettingappsdone.com Please be sure to check out my website at joshuagraham.info and Kel's website at piffner.com. If you have just recently started at a new company and you think some of these concepts resonate with you or you have some different things that we didn't mention because I have a lot of different things that happen on the first few days of a new job, shoot them over our way. Let us know what you're running into in tech. Why don't you join us at gettingappsdone.com/slack where you can talk to our community directly and just share your experiences. Because there are a lot of new developers in there. Some of them have just recently started their first jobs. Some haven't gotten that far yet and would love to hear from you about your experiences. So you are more than welcome to come and share that with us.

• 36:16 Kel

  Definitely.

• 36:17 Joshua

  Alright, in the meantime, we post every Thursday, so, uh, we'll see you next week. Thanks for listening.

• 36:23 Kel

  Cheers.