Knowing the difference between a being Jr Dev and a Mid Level Dev

CALEB CRAWLEY:
And thank you all for coming. Today's topic is spotting the difference and closing the gap between junior developers and mid-level developers. So I was motivated to speak about this topic because I used to be a junior developer. And although I had lots of motivation and thought I had all the answers about how to think about certain things, topics and how to behave in the workplace and things like that, after conversations with others who I looked up to, mentors, mid-level senior developers, architects, people like that, having a conversation with them, I realized that while I was on the right track, some of the things in ways that I thought about how to move was incorrect in that, you know, we all have room for improvement, obviously. So the purpose for today's talk is so that if you are mid-level or above and you have juniors or anybody under you, you know, and they have questions and things like that, the helping them move forward or if you're in that position yourself, you know, coming up with that switch about, you know, hitting it and adjusting and being able to move towards the goals that you have for your career personally and professionally.

So as I said, who this talk is for, upper management, you know, you all might be frustrated with your junior developers not advancing quickly enough, you might be the junior developer wondering why you're not advancing or you're just looking to accelerate your process and you want the inside scoop on, you know, what mid-level developers know and how they operate. Or maybe you just value saving time, being efficient, reducing effort strain, increasing your value and making more money eventually. So at the end of this talk, you know, my objectives today, I want you all to leave here with a better sense of how to advance or help others advance their own knowledge and careers. And I also want to cut the average time of lifespan of a junior dev phase in half. So we're going to do that by identifying the major, but often overlooked or misidentified aspects of being a junior developer and what holds them back and also identifying what sets mid-level developers apart from them. And we're also going to use some examples.

So while this topic is important, so the biggest point of any relationship is the value. So just like between a boss and their employee accompanying their client, one of the most overlooked aspects of being a junior developer is understanding the value that you bring to your organization. So you want to be able to know the answers to the questions. You know, why are we doing this? Why does this relationship exist? Why do we need each other? What are we getting out of it? And how does everyone win? So are there any junior developers here today? Can you tell me why you were hired?

SPEAKER:
Why what?

CALEB CRAWLEY:
Why you were hired?

SPEAKER:
Why was I hired? Well, that's a good question.

CALEB CRAWLEY:
If you were to just take one wild guess, would you think that would be?

SPEAKER:
Potential.

CALEB CRAWLEY:
Great answer. That is the answer. So what these three pictures have in common right here, they demonstrate potential energy. So just like a company with a great idea and a good product, but no sales. A quarterback ready to launch that football into the endzone, basketball player at the height of their art, you know, shooting the basketball. Some of you might be needs to release, others might need a push, but converting that potential energy into real energy is the most important value that you have as a junior developer. So from the moment you start your values and the fact that you have that potential energy, you know, you've shown yourself your ability to seem coachable, eager, willing, capable and valuable, it's your job to deliver on that. So far, you haven't proven it yet. Your understanding of the underlying principles is limited and this limits your ability to ask the right questions, find the right answers, get things done on your own, save time and get things done. So how do you turn that potential into real value?

The first thing that I did on my journey is an internship. It lasted three months and I had to compete with other aspiring developers to do the best. I did well. I got hired. And the next thing I had to show was that I could listen and follow directions. So I needed to show I could follow the workflow process, communicate, study, practice, and get things done well and get them done on time. So now let's compare some example personas. So persona one. This junior developer can only be assigned to one project. Most of their questions require stand-up time with other developers because that developer that they're speaking to does not understand anything about the problem and the developer asking the question doesn't understand anything about the problem. They don't communicate their workflow on their tasks which leaves others putting in extra efforts to understand what's going on, trying to figure out what they're working on and how to complete it. They don't complete their task on time and on budget and they're normally too afraid to tell anybody.

This is how they typically spend their day. So 30% is writing code that fails. And this is how it comes about. Most of the time is asking questions. Next, they're waiting. They're doing a little bit of research and then collaborating. And so this ends up being the result of their getting things done, but those things aren't actually done because there's a lot of holes that they're leaving because they're not doing and following the process. So junior developer B, they can be assigned, you know, from 1 to 2 projects. They communicate their goals for the week and for the day, they ask questions which can typically be answered quickly. Some might require some stand-up time. It just depends on the actual concept or problem that they're trying to handle. Sometimes when you're doing things with code or certain JavaScript issues, you might actually have to get on a call to be able to get things explained to you rather than just typing them out. But if they can be handled with a quick response, that developer knows how to ask that question.

They update their tasks with the current status, they communicate their workflow on their tasks consistently and after solving a problem, they document the blocker that they might have had or the fix that they came up with. And at this point, they're starting to notice the patterns and the tasks are working on and they attempt to propose solutions when they see them the next time rather than just being directed about what to do. And every so often, you know, they might volunteer to demo their work for the other developers or for the upper management doing team meetings. This is how that developer spends their day. They do a lot of research and learning and training, they're collaborating with the other developers that are watching other developers, they're asking questions that make sense. They're documenting their thoughts, their blockers, their workflow which results in them being able to spend less time coding and more time getting things done because they're able to debug. When they come across their problems, they're able to write code that works and eventually they're able to solve their problems and be efficient and move on to the next thing.

So here we have a mid-level developer, Berry Books. He can manage two plus projects, he finds solutions to his blockers independently, he's able to do his own research. If he's blocked, he knows how to pose the question to somebody correctly for efficiency. He answers questions and he offers solutions to the team when needed. He is honing his skills to propose a new workflow processes or approaches for new projects and tasks that he's assigned. Management can count on him to take the lead on projects that he's had responsibilities on before from other things that he's worked on. He documents his test. I mean, he documents his thoughts and his processes and he's accountable for his tasks, able to lead junior team members checking up on them and their progress and lending help when it's needed. So if you compare junior developer A and B to this mid-level developer, which one between A and B are closer to Berry Books?

SPEAKER:
B.

CALEB CRAWLEY:
Exactly. This is how mid-level developer Berry Brooks is spending his day. He's planning and prioritizing, he's communicating and collaborating with his team, he's doing research and learning and he's doing a lot of independent coding. Any questions so far? Alright. So if something isn't happening, there's almost always a reason why. So there's a reason why you're blocked and there's a reason why you need to document your thoughts on these tasks. So why do these two junior developers end up being so different? Junior Developer A doesn't communicate, he lacks confidence he doesn't understand how the workflow process works, why it needs to be followed, why it's important and they're not proactive enough to be a self-starter. Junior developer B understands their value and the importance of communicating. They understand the workflow process and they are constantly working on improving their game, which results in higher level of confidence and they produce quicker and better results overall.

So now, I want to introduce myself. I'm Caleb Crawley. This was me before. So coming to the industry, I knew nothing about Drupal. I was terrified of migrations. I ask way too many vague questions without doing enough research. I couldn't learn from my mistakes because I didn't understand the problems that I was having. I couldn't identify what was going on, I couldn't communicate that to somebody for them to help me out and it just led to a lot of, alright. What are you working on? You know, I'm having to answer questions. They're having to ask me questions that I'm having to answer when it should just be me providing enough information in the first place for me to get an answer immediately. So, but I was willing to learn, I was coachable and I had drive. So where am I now? I'm maintaining a full-time project using Acquia Studio plus working on multiple other support clients who are hosted on Pantheon. I'm an Acquia-certified mid-level developer. I've been a part of the community going on four years.

Recently worked with the Drupal Association on Community Events and I made 52 contributions to Drupal on various projects, whether they were contrib modules, themes in 2022 alone. I'm currently working with the Department of Defense, Education activity, doing migrations and site-building and my Brawlhalla if anybody that knows what that is. So I can do this because of repetition. So I prepare monthly reports for the support clients that I work with, I organize their requests into well-documented tasks. I can complete those tasks or I can hand them off to other developers and follow up on the progress that's being made. So we at BrightPlum, we've noticed the patterns in our workflow and we've come up with ways to almost automate them. We create checklists on tasks, we have templates that we use for tasks, communication, daily updates and slack and templates for those monthly reports. So how did I figure it out? Communication through conversations. So I had conversations with my boss and mentors asking them what am I missing?

I had conversations with my colleagues and asked them, how did you do this? Have their merge request available I can look at, had conversations with our clients and ask them, what do you need? And I had a conversation with myself asking myself what do I want and who do I want to be? So you got to communicate. You have to get through the hard conversations that are confusing to get to the ones where everything makes sense. So you've got to put effort into understanding how those around you think and learn what they want so that you can understand how to be valuable to them. You're going to hear things that you don't want to hear. You have to stay out of your feelings and realize that information is meant to help you. You're now in a community of people who want to do well and also want to see you do well. So when you understand that you can move past everything else and focus on the improvements that need to be made. So what did they constantly reinforce? So we're going to go over a couple of different main topics, but what I want you to pay close attention to the themes that are going to be coming up because they're going to be recurring.

So first is attention to detail, then is communication and teamwork, then it's time management, adaptability, repetition and confidence. So first, attention to detail. The difference between good work and great work is attention to detail because it improves efficiency and accuracy. So by carefully reviewing the things that you do, you're able to catch errors and inconsistencies and you can minimize having to go back and redo anything saving time and effort. So it may sometimes be the difference between being blocked and not being blocked. You know, as we say, sometimes the solution is just a matter of clearing the cache. Attention to detail also helps you break issues and tasks down into smaller parts for better understanding. It enhances others trust in you as well as your own credibility. And if you produce quality work that is detailed, others are more likely to rely on you and trust your judgment and it also shows pride in your work. Communication. If communication doesn't exist and it's not clear, nothing's going to get done and nothing can get done.

So no one's going to know what's needed to be done, no one's going to know what to do, no one's going to get promoted and no one's going to get along. So when you communicate effectively, you're able to build relationships and you're able to build trust. You can avoid misunderstandings and conflicts. And active listening, empathy and feedback are major parts of this. So communicate your expectations. Implement daily bot into your slack channels. Daily bot is something that first thing in the morning at a specific time it says, hey, what did you work on yesterday? And you can respond, you can give it a task link or task name. It says, what are you working on today? Are you blocked on anything? It asks you questions just like that, sends it to the team so that everybody can read it and know what's going on. You can hold each other accountable and then that they know anything about the blocker that you have, they They can just reach out and give you an answer, you know. Or they say, hey, do you need to talk about this separately?

How can I help? And then also, you can look at other people's stuff, see what they're working on, see if there's anything that you're interested in learning, getting done or helping out and you can do the same thing for others on your team. So management is going to notice that. So, you know, when you're being proactive and you're communicating everything, you know, not only are you showing yourself to be a self-starter, showing yourself to be efficient and having the drive to get things done on time and on target, they're going to notice it and they're going to appreciate you for it. So whilst communication important because you can make all the changes and improvements in the world. But if no one knows about it or what you've done, it's never going to matter. Next is time management. If you manage your time wisely, you'll learn more, you'll perform better and you'll be more efficient. You'll also have more time to relax because you'll end up being ahead of schedule. So set your schedule blocks for the week on Sunday or Monday morning.

You can do this by implementing Google Calendar or apps like Monday to help you keep track of your schedule. It's helpful for managing multiple tasks or projects because you know what time of your day is dedicated to what So somebody is trying to get you in a meeting and, you know, they're sending out the invite, they'll be notified that, hey, their time is blocked off at this time right now. So then they'll be able to hit you up and say, hey, are you able to move things around or do we need to move this around? And so that way it'll be a more seamless experience for everybody working together as well as you being able to organize what you're working on. So time management also improves your decision-making because you'll be able to give yourself the time and space to weigh options and think thoroughly. If you're always in a rush, you're never going to be able to actually sit down and weigh out the options and make the best decision at the end of the day because you're always going to be stressed out.

So managing your time correctly helps others view you as reliable, efficient and trustworthy. Next we have adaptability. So at any point in time, your coworker might go on vacation, they might be pulled onto another project or they might not be working with you anymore. You need to be prepared for upper management to come to you and say, yeah and you say to them, Yes. I can help. I can handle it. So there's 10 ways to do anything in Drupal and everyone wants to pick a different number. So showing that you're adaptable shows that you have the ability to help out when needed which proves your dependability. So to move up in the world, others have to be able to call on you. But if you're never ready or available or prepared, you won't be able to capitalize on those opportunities. Repetition. Repetition equals reputation. You'll learn faster, you'll learn how to recognize patterns in your tasks and you'll remember the solutions to things that you got stuck on because it becomes muscle memory.

The solutions become muscle memory. So now let's talk about documenting and ticket processes. So here's an example request from a client. So they've reached out to you. They said, hey, when I'm hovering my cursor over the subheadings, these are the subheadings on the about page. It does not change my cursor to the click-hand icon to indicate that the subhead is a link to another page. So if you compare those subheads with the ones on the books page and the user can actually tell it is there's a link to another page. So can you update the subheadings on the about page so that they behave the same way as those on the book page when hovered over? So one thing that you should not ever do when you get a message from a client is just respond and say, OK. You know, I'll get it done eventually. No, it's not how a mid-level developer would respond to the client or how they would handle this task. So don't just assume that you know what to do because the client assumes that you do. There's a process that you should follow because it will help you communicate expectations, understand the workflow, be a better teammate and showcase your ability to take the lead.

The easiest way to streamline this process is to use a ticketing system. So here we have a ticketing system. This is Clickup. This is how a junior developer A would set up this task. So is there anything here that anybody can notice immediately that's missing or that's happening here?

SPEAKER:
Definitely. You are just putting the client's words it's as is, you're not interpreting them. And the title is not something that's easy to glance at and understand.

CALEB CRAWLEY:
Exactly. So the title is vague and all they did was copy and paste what the client requested into the bio. So there's also a few other things that's missing here. But if we move on to how this thing should be set up, you know, as we said, the first thing you should do when you receive a request from a client is create a ticket for it. Then you want to make sure that you understand what the client is asking for. So you can use the ticket comments section to write out how you understand the requests, ask others on your team if anything seems confusing. So as you see, instead of putting copying and pasting the client request and just putting it in the bio, I added it as a comment. And then underneath, I put together my example response of how we'll respond to that client. So you can use the comments to write out how you understand the request, ask others on your team is there anything that's confusing? And after you understand, you want to then reach out to the client as soon as possible.

So preferably within 24 hours. So you want to relay back to them in an organized way what they're asking for. That way they can confirm or correct you. So you'll see here that I say understand it's your request and that all subheadings with links have a pointer on the hover rather than the standard mouse. Is that correct? When you confirm this, I can get started. So I didn't just say OK. It'll get done. I didn't assume that I knew what they meant. I'm relaying back to them what they asked for so they can say, yes, this is exactly what I want you to do or or no, this is what. You misunderstood. And then when they say, I misunderstood, I will do the same thing again. OK. So from what I understand what you're asking for now is this? And then once they say yes and it's a solid yes, then I can move forward. So another thing that was missing on the last test was an estimate. So it's very hard to put an estimate together when you don't have a user story and you don't have the task broken down into steps.

I know the thing is addding a branch name for the task. So making this something that will be easily transferable into, you know, get or referring to this in a selection will be much easier if I gave this task an ID. So next under there you'll see a user story. So when the client responds and says, yes, this is what I need you to do, you can come here and say, OK, as a visitor to the site, when I hover over these subheadings that have links, I should see the mouse turn into a pointer finger. Now I know what the acceptance criteria for this task is and I know how I can move forward. So knowing those things, how do I get that done based on how this project is set up, and now that we use scss. So I need to adjust the scss file and add a hover pointer on all element H2 with the subheading class elements. Then the next thing I need to do is compile the scss and test. And the branch that this is on is VP-123-- subheadings. And that's the branch name for this. So once I get that done, I can create a merge request and I can paste that merge request link into this test.

And I can say, hey, this is ready to be reviewed. Can somebody check it out, make sure it looks good? And at that point, it should be well documented and then we can reach back out to the client and say, Hey, this is what we've done. Take a look at this and see if it meets the requirements that you have. So like we said, you would come back and break down the steps. That way you'll be able to follow along with everything and everybody will be able to follow along with you rather than everyone just winging. So also top left, you can see that we have at right when we click up, they have ways to organize a status. So it's not just nobody knows where you are with this. You can see that this is a task that I'm actively working on. So it's in progress. So I'm just in progress and I put the merge request here. Then I will move it to ready for QA and I would assign that to the person who does the QA test. And the other most important thing is I had a due date. So that's how you keep yourself accountable for what you're working on.

So another way to streamline the task process is to use an email almost automation system. So we use that software at BrightPlum. So when the client reaches out and gives us the request, we have these things called macros which we use to respond to them. So we don't just wing it and make up something, you know. Even if it could be a concise response, ourselves, we do have a process that we want to stick to and say, OK. We repeat to them what they're asking for, and there's like a template that we follow with acceptance criteria then they would say, yes, it's correct or not correct. So it keeps everybody moving on one accord, basically. And it also helps you, you know, because there might be a time where somebody asks you a very complicated question, you know. So having a way to bring all of that together in a template in response to that client, you know, makes things easier for everybody. So now let's say you get blocked. Maybe after adjusting the scss file, you check the site and you don't see that the changes are reflected.

Maybe you're connected to Pantheon and the upstream pipeline keeps failing. So what do you do next? The first thing to note is did you follow the task process ensuring that you didn't skip any steps and that you did everything correctly? So did you compile the scss like (UNKNOWN) in step two? Did you clear the cache? Is there an upstream config file that's created when it comes to pushing this up through git and trying to see the changes reflected in Pantheon? After you've ensured the following steps are done correctly, then you need to research the issue that you're experiencing. If an error is being thrown, look up that error. Use stack overflow. Maybe even drupal.org can unblock you. Joining different slack channel so you can reach out to people who are a part of these slack channels like the Drupal slack, they have a ton of different channels where you know they're organized based on the topic of what you're working on or the blocker that you might be having. So those are resources that can unblock you.

So if they do, then you need to document what you found, where you found it and how you fixed it in the ticket. If none of that works, congrats. You've done what most would not do. You've tried to fix it yourself, but all of us need help sometimes. So you might feel like you need to still reach out to somebody. So let's talk about how to do that or when we're reaching out internally to our own team. So asking the right questions. When you go into any channel to ask someone for help, remember that they might not necessarily know what you're working on or even talking about because we're all working on our own tasks at the end of the day. So you need to provide context. So link to the task or mention the task name and then repeat the user story to the person who you're asking. As a user, when I go to the about page, I should see the point or click on subheadings on the about page, you know. Then what's happening instead? The the regular pointer clicker still appears on the subheadings. Four.

This is what I've tried based on this research that I did linked to the article that you read or the thread that you were using as a reference. With a link to the branch, merge request that you created. So number five, this is why I think the problem might be as part of you trying to learn problem-solving, making an educated guess on why you think you might be blocked, you might not be correct, but at least you're on the right path of trying to connect the dots of things. So by phrasing what's happening in this way, you can communicate to your team that you at least tried to solve this yourself, you told them what you've already tried that didn't work. So they don't have to repeat a non-working solution. And you're also giving them context so that they can help you out as quickly as possible and then return back to their own responsibilities. This behavior showcases your ability to be a team player, your communication skills, your problem-solving skills, and your empathy for others. In turn, they're going to appreciate you for respecting their time and upper management can see that although you couldn't solve the issue, you knew how to communicate.

This demonstrates that you're on the right track. So when you understand the differences. So here differences between being a mid-level developer and a junior developer. A mid-level developer is a leader and a self-starter, a junior developer might wait around for direction. Mid-level developer is dependable and reliable, junior dependent with a lack of experience. Mid-level developer is a big-picture problem solver and a junior developer has linear thinking. So don't just sit around waiting for others to tell you what to do. Ask how you can help based on your goals, do research, learn and practice. You were hired knowing that you like an experience. That's not the problem. The problem is being overly dependent on others and not having the motivation to be proactive. So build a reputation for yourself for being dependable and reliable. If something needs to be done, bite the bullet and get it done. We need a whole project that's been lingering around, it has to be done by the night. Bite the bullet, cut everything out.

Get it done. Linear thinking results in only being able to see the next thing directly in front of you. You're only focused on the next task or the current situation. You need to see the big picture or have an aerial view of your career, your team and the projects that you're working on and learn how they all relate to each other. So when you understand the differences, the goal becomes clear. So follow the process. What do we start off with? Delivering on value. As a junior dev, as a human in this world, it's now your responsibility to become an asset to those around you and to people who care about you, even those who don't. So prove you can hold your own and then challenge yourself to handle more, become a master of your craft so you can further increase your value to and for those who invest in you and depend on your success. So number one, communication, documentation, planning, attention to detail, time management. Follow the process, embrace your strengths and minimize your weaknesses.

Learn Cite Studio, learn Migrations, understand how Drupal works. Keep asking for tasks and projects with things that you want to learn so that you can learn how to master them. Communication is key. Your company culture, your current status and roadmap for success should be clear with an open-door policy when it comes to discussions about when you think you need to be working on five projects and clocking 80 hours a week, when really all you need to do is get Aquia certified, you know. That's the difference between communicating and not communicating. You don't want to be what I call hustling backwards. So when you communicate, you manage your time wisely and have attention to detail, practice, repetition and maximize your strength and minimize your weaknesses, it will lead to mastery. So now at this point, you can communicate expectations, needs and wants then plan and prioritize your budget schedules and expectations. Deliver those expectations on time and on target and document your process, your thoughts, blockers and fixes.

So if you follow the process, you'll be able to have conversations with clients and explain to them this is how we're delivering on what you've asked and this is how long it's going to take. You're going to be able to have productive conversations with your colleagues and tell them, you know, here's how I solve this problem. You're going to be able to have conversations with management and mentors and tell them, these are my goals. This is what I'm working on now and this is what I've completed. And experience will allow you to start coming up with ideas that work for everyone. You're going to be able to start making suggestions based on experience, and you're going to be able to volunteer to do demos for the team during meet. All these things are going to help you stand out. So I appreciate you all for taking the time to come out to this talk. This was my first talk. Are there any questions? (UNKNOWN). No questions. We all good?

SPEAKER:
Do you have tips for, like how to coach someone on this or just, like, preventing these...

FREDRICK MITCHELL:
I can answer that.

SPEAKER:
OK.

FREDRICK MITCHELL:
I'm Caleb's boss.

CALEB CRAWLEY:
Yeah. Frederick Mitchell, everybody.

FREDRICK MITCHELL:
It's a great question. So I think the one thing that I've learned while working under coaching people who, you know, to go through this process is, you know, when you're at a particular part and you're trying to bring someone along, you almost have to do the same process because they will buy in once they see you doing it. So if you have tips or things you want to say, right, communicating and writing them down ahead of time, pointing and saying, hey, this is what's going on, framing that process of where you're trying to go, why the step by step makes sense, what the broader goals are...

SPEAKER:
Chances to talk.

FREDRICK MITCHELL:
(CROSSTALK). Exactly right.

SPEAKER:
That's recorded so.

FREDRICK MITCHELL:
So that constant documentation, that writing reinforces what hopefully that person will also learn because that aspect of writing gets the thoughts out of your head, It documents it, but I think the most important thing is it allows each other to hold mutually accountable. So it's one thing, especially from an experience perspective, sometimes there's a power dynamic where someone with more experience maybe misses the fact that someone with not much experience may have some anxieties about sharing things that are not really sure. Right. And so there's sometimes we're afraid to make mistakes. In our particular case, by me taking the time to write things down and then I appointed him to have you follow this and he said, hey, I did this, but this is me. I'm saying, Oh, you're right. That's my mistake. I made a mistake. I need to be more clear on what the process is. And now our relationship is strengthened because I'm taking accountability for how I can help you better, which hopefully will translate to him taking accountability if certain things may be missed and we just iron sharpens.

Iron to that process of doing what you're trying to get the person to do builds that trust. So then that communication can flow a bit more in terms of that coaching piece you talking about?

SPEAKER:
Yeah, I mean, for me, I don't work directly with my coach every day. It's more of a (UNKNOWN), but I can see how that could.

FREDRICK MITCHELL:
Yeah.

SPEAKER:
OK. You can still translate that?

FREDRICK MITCHELL:
Absolutely. Yeah.

CALEB CRAWLEY:
Yes.

SPEAKER:
So looking ahead to becoming a senior developer, what sorts of things do you see in senior developers that you want to like work towards.

CALEB CRAWLEY:
So a personal goal of mine is to become a Aquia certified full-stack developer. And so a lot of the senior developers that I'm under now, you know, they go with Site studio. They're great with solving problems. You know I consider myself good at solving problems. They're great at it. You know. They are very independent, they have great relationships with our clients and so those are just examples of a couple of things and that I'm working on in order to, you know, become a senior developer myself. Does that make sense?

SPEAKER:
Yeah.

CALEB CRAWLEY:
Yeah.

SPEAKER:
Sorry I asked, do you think you found it more helpful for working on a team than working under like a lead developer that you guys happen to be in the same kind of stack and kind of like same RVEs, same coding style, same things like that or are you working more independently? Are you (UNKNOWN) for your quirks and likes or that is kind of iterating? Iterating like different concepts that they want you to use in order to come to solutions?

CALEB CRAWLEY:
So each of us do have our own set ups, but the coincidental part about it is we mostly love MacBooks. So I know most of us are using PHP Storm, so it's definitely helpful to be using similar tools, especially if you're a junior developer. To be using the similar tools is semi-over you because you won't be trying to solve one issue and then come across an incompatibility based on somebody using Microsoft Visual Studio and you using PHP Storm. Now y'all got to get past that blocker in order to actually solve the primary thing that you're trying to get done. So it's definitely helpful to be working on similar things. I've noticed that, you know, work of bridging the gap between the things that the senior developers and all developers had that I didn't have, you know, made it easier for them to help me out. So, but with a lot of our clients that we worked on, you know, we do end up having to use similar dev sites. So we're using Lando and Docker, you know, so we pretty much set up everything in the Lando environment so that whether they're using a Windows or where you Linux set up or I'm using Mac whatever, we all can pretty much if we're having errors, it's pretty much coming from the Landos.

FREDRICK MITCHELL:
It's always the windows. Oh, I have (INAUDIBLE) to try to get people to use iOS and Mac software. But we always have a contract with the company that they'll be trying to spin up our environment on the Windows machine and generally, even if you're using Dockers like (UNKNOWN) it doesn't work. You have to (INAUDIBLE).

CALEB CRAWLEY:
Yeah.

SPEAKER:
That's where adaptability comes in one of your points. It's like it's much better as a junior dev to use the same tools as the other devs that way you can work together.

CALEB CRAWLEY:
Yeah, definitely. Adaptability has been infinitely helpful. Just having Frederick drive that as a point towards me, you know. But the willingness, the coachability and the drive is definitely the building blocks to being adaptable because you want to be, you know. You don't want to just act like you know everything. You don't want to just stick to what you know and think that it's the right way to do everything, you know, being adaptable is going to... that's what's helped me propel myself, you know, just from junior to mid, you know. And I'm going to use the same thing to propel me from a mid to senior. Anybody else? Both, did I answer your question.

SPEAKER:
Yeah.

CALEB CRAWLEY:
OK

SPEAKER:
Is there a rule of thumb for like how long do you spend your wheels on a problem before you ask for help? And like, how do you expect, if you expect that person to be able to respond immediately or if you know you're going to have to wait, how you manage that kind of time?

CALEB CRAWLEY:
So you said is there a rule of thumb for how much research you do on a blocker that you have?

SPEAKER:
Yeah.

CALEB CRAWLEY:
That's a great question. I wouldn't say that I have one that's set in stone for how many things I'm going to try to read or not. I do know that if I'm coming across... basically, based on the results that I get when I'm searching up the error, if there's a ton of different solutions, you know, then I'll try to try as many and read as much as I can. But if there is, you know, sometimes you'll search something and then it says, you know, this isn't returning any search results, you know, or I'll hit up a selection and nobody's able to respond at the time. So it does vary. But I would say the more answers available, the more you need to be doing your own research. But yeah, as, you know, when we talk about the first dev persona, you know, asking questions and then doing a lot of waiting, that's part of having lots of different resources to use. So if I hit up a senior dev and asked him a question, I got to understand that they got a lot of things that they're working on. So that's my responsibility to make sure I'm in other slack channels where other people are available.

You know, I have good relationships with other people that we're working with so that they don't mind answering questions, you know, because I can prove myself, you know, I'm going to follow the directions then they'll be able to point me in the right direction and I can go do that and I can come back and say, Hey, thanks a lot. This work or this is happening, do you recognize what's going on here? You know, and then we can move forward that way. But you got to be understanding that, you know, everybody's got their own things going on. So you can't just expect somebody to respond to you in five minutes. But if they do happen to be the only person I feel like can answer that question at the time, I might give it, you know, 15 to 20 minutes. If they don't say anything, I'll make sure that they're online and I'll tag them again. At that point, you know, then if I'm still stuck, I'll hit a friend and say, hey, what do you think I should do about this?

SPEAKER:
So we should all ask him.

CALEB CRAWLEY:
Yeah, I'll make sure that everybody gets here. So it's like when we leave here.

FREDRICK MITCHELL:
I think the hidden point to what Caleb is talking about is what we've sort of figured out to your point about when blockers happen, that process, the thing that I think we sort of unlocked is and he mentioned about senior devs and troubleshooting and sometimes senior devs and their experience well, I've seen it before or they kind of know the system enough to see like, have you tried this, like push them in a certain direction, right? So blockers can be answered as either here's the solution or have you checked this and then they kind of go out. The reason why the process of documenting and journaling and this is what I tried is because.