In today's episode, I answer a question from listener Charissa about her stressful work situation as a brand new developer. Today's episode is sponsored by Linode. Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
In today's episode, I answer a question from listener Charissa about her stressful work situation as a brand new developer.
Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
Please take a moment and subscribe and review the show and share with another developer you think will enjoy this episode! Click here to review Developer Tea in iTunes.
Hey everyone, I'm Monkman2 Developer Tea. My name is Jonathan Cutrell in today's episode. We're taking a short break from the developer career roadmap to answer a fantastic question from listener Carissa. Before we jump into this question from listener Carissa, I want to take a moment to thank all of you once again for listening to this show. And for becoming involved with Developer Tea, I would love to see that involvement just continue to increase. And there's a ton of ways to get involved. One of them is to join the Slack community. You can go to spec.fm slash slack. That's free and it always will be for everyone who listens to these shows. Me and every other spec show host is hanging out in that Slack community. And we have over 6,000, in fact, 6,549 people as of the time of this recording are in that Slack community. Most of them, if not all of them, are designers and developers around the world. So go and join that Slack community. We have tons of great conversation in there. Of course, once again, all of the spec family is in that Slack community. Another way is just to send me an email. You can send me an email at Developer Tea at gmail.com, the same email that we've had since the very beginning of this show since episode one, basically. So go and check out the Slack community and of course send an email. That's exactly what Carissa did. And it was just a few weeks ago that I got this email from Carissa. Carissa wrote in and said, hello Jonathan, before asking my question, I just want to say thank you so much for your podcasts. They have been very helpful in my learning process and have given me the encouragement I need when I was feeling down or frustrated. The question I have for you is about my first real job and project deadlines. Well, this is awesome, Carissa. I'm so glad that you're asking this question. This is going to pertain to all of you who have been listening to the developer career roadmap, who have been listening to this podcast. Even for years now, actually, we're coming up on two years of developer TVing out. So Carissa, I am humbled by your appreciation for this show. So thank you so much for writing in. Carissa says, I recently started my very first job as a web developer. I work for a graphic designer who has been running her own design and marketing business for a year now and now wants to branch out and include web development. She hired me as a web developer and another graphic designer just a few weeks ago. There are many things I love about this job, such as finally getting the chance to really use my skills in JavaScript and PHP and of course, getting spend all day developing websites. While I love all of these things, I also have a few concerns. The two designers I work with don't seem to understand how the coding process works and often want me to jump right into coding without any real planning. I've just finished my first real project and I'm feeling very stressed out. My boss wanted me to create an entire website hand coded from the ground up in one week. The site was for a client that had a strict deadline, which I understand, but they constantly changed the project scope in the course of this one week that I had. The site ended up being over 10 pages requiring database functionality and the clients had requested many unique features requiring JavaScript to write. This was incredibly difficult for me to complete in one week. I'm not allowed to work overtime and I don't get paid for it, but in order to meet the deadline for this project, I went well over 40 work week hours. I tried talking to my boss and explaining to her that I needed more time or at the very least for the scope to stop changing, but she was unwilling to change the deadline or keep the original scope. On top of this, I never received important information from the client, such as contact information, photos, and content that they wanted on the site, or even database access and information for reports from their database that they wanted to include on the site. On top of all this, in the same week, my boss also added another project that she wanted me to begin work on. A project to create a mobile application with cloud server access and entire database and more that she wanted complete in two weeks. I don't mean to bash my boss at all, but after this, I'm feeling overwhelmed, I'm feeling stressed, and concerned that this may be the norm for what is expected of me. The real question is, is this normal? Does a single web developer knock out an entire site like this in one week in a normal job setting? Would you be willing to give any advice as to how to handle the situation or how to better approach my boss? I understand that this is my first job as a developer, and thus I have much to learn and many skills yet to hone. I also love coding, and I'm content to sit at my computer and code all day long. For this reason, I do not want to just give up if this is a normal work environment, but I could certainly use some advice as to how to cope and thrive. I certainly hope this isn't an overwhelming message, and would so greatly appreciate any advice you have to offer. Thank you so much for your time, sincerely. Kharissa, a person who is most definitely not curled up in a ball and crying under their desk. Kharissa, first of all, let me say you are not alone in these problems. There are many other people. In fact, I would say most developers have experienced at least a slight version of what you are experiencing, and perhaps just as extreme or more extreme than you are experiencing. So that's kind of the starting point in the sense that other people have experienced this feeling of being constantly behind, being overwhelmed, feeling constantly stressed, feeling like this is never going to end, and that you have no way out. There are tons of people who feel this way, and there is a way out. We're going to talk about a lot of the things that you asked about here, Kharissa, because in the reason I decided to read this, this is probably the longest listener question that we've had. The reason I decided to read this one is because this is the sentiment of so many developers, and this problem that Kharissa is experiencing ends up, for a lot of people, it ends up being the way they view this industry, the lens they view the industry from, and a lot of the other problems that we talked about in the past on this podcast, such as cynicism or estimation issues, a lot of those stem from this specific kind of situation, especially if it happens as early as it is happening to Kharissa. I feel like this is an incredibly important topic to discuss. It's actually a suite of topics, quite a few things going on here, and we're going to talk about all of them right after this quick sponsor break from our great friends at Linode. You've heard all the details about Linode before on this podcast, so we're going to do something a little bit different. Linode has been sponsoring Developer Tea for such a long time, and they have made a lot of what we've done this year possible. So first of all, a huge thank you to Linode. Linode is showing that they support the developer community by supporting this show, and that they want to get closer to people like you, the young developers who are starting out building their brand new projects, and they need a place to put them, right? You have side projects that you're building, you have your own personal websites that you're building. Perhaps you have some experiments that you want to run, or maybe you are working for a large company, you're an experienced developer. Linode is wanting to get close to you because they have a product that they believe will make your life better. How do I know that? Well, primarily because Linode offers a seven-day money back guarantee. On top of that, they're offering $20 worth of credit, so you can actually get a server running with Linode in just a few minutes, and that server can run for an entire year for $100. They're plans start at $10 a month, and they have two gigabytes of RAM on that $10 a month plan. And you can do pretty much anything with these servers. You have a root access, so you can go and create pretty much anything you want to create. Whether you're working on node or you're working on Ruby or Python, or maybe you want to run your own private Git server, whatever it is that you want to do, you can do that with Linux, and therefore you can do with Linode. Go and check it out. Once again, Linode is providing you with $20 of credit, seven-day money back guarantee. Check it out. Spec.fm slash Linode. Thank you again to Linode for sponsoring Developer Tea. Okay, so Kharissa is facing a mountain of stress. It feels like she can't climb out of this hole that she was put in with this project. This one week, 10-page project. And really, if you break down the numbers, we can start out by saying that yes, this was absolutely too much to ask, especially of a brand new developer. So let's start there. I think that just based on what I know about this project, based on what you're telling me, Kharissa, that your boss was probably asking more of you than you were able to deliver, even in the best of circumstances. And that was the case. You worked all day long for multiple days. You worked past what your normal working hours are. Now, on this show, we don't like to go against the boss. And what that means is at Developer Tea, we don't believe that bosses are inherently bad. And Kharissa, it sounds like you believe the same thing that you aren't trying to bash your boss. And in fact, you're trying to do as good of a job as you can in the scenario that you're given. So, Kharissa, there's a lot to consider. And I'm really just going to run through this list. I don't have bullet points as much as I have just some things that I want to give you to consider. And anyone else who is in a similar situation as Kharissa, you don't have to be in a small company for this to apply. This could apply in any size company at any job level. Really, it just kind of depends on your specific scenario. But Kharissa, your boss is the owner of a new company. And she may not know how long it takes to develop a website. She may be learning this for the first time. And she's learning with someone who is relatively new with her job. So, you're kind of learning this for the first time. Of course, it's going to be extremely difficult to determine how long something should take. It's hard for somebody who's been doing it for 25 years to understand how long something should take. We are notoriously bad at estimating things. Most likely, she's being driven primarily by the goals she has for the company. And she may be setting those goals based on an accidental misunderstanding, kind of blind spot about how long it takes to deliver something in development. Now, where this misunderstanding comes from or where this blind spot hasn't been filled in, I can't really tell you. It sounds like this person is very driven and that they want to accomplish as much as they can in the shortest amount of time. That is kind of the entrepreneurial way of thinking. So, that's probably what's happening in you just happen to be on their team and they're pushing you to accomplish as much as you can and to adopt the same spirit they have. You did the right thing by trying to talk to your boss, right? But perhaps the timing was wrong. The hardest time to discuss a problem, and you know that's probably from other conflicts that you've had, the hardest time to discuss a problem is while that problem is occurring, the best time to discuss a problem, especially in a professional setting, is right after that problem is resolved. Okay, and there's a couple of reasons for that. One of them is because, well, the stress of solving that problem is gone. So, you aren't standing in the way by discussing it. In fact, by discussing it, you're showing the intention that you have for making things better in the future, for refining and investing in this company that your boss is so clearly invested in as well. But beyond that, another reason that doing this after the problem is resolved and doing it right after more specifically is because it's still fresh in your mind. You still have a lot of what just happened in your mind. And hopefully you've taken some kind of notes along the way. Maybe you have an email chain, a paper trail, so to speak, that details what happened that you would like to talk about, to polish, fix, whatever the case may be. But the idea is, don't try to do this during the project because your boss's goal is to finish the project. And by trying to talk about the problems that you're having, that you want to fix in future projects, you're kind of holding up the progress on the project that you're working on now. So, it's a little bit of a difficult balance of when you should talk about conflicts, when you should talk about business problems. From your perspective, Karissa, I would ask your boss to debrief with you this project specifically and share the following concerns. Number one, you want to produce excellent quality work. This should be something that you lay out as a absolute value, something you are not willing to compromise on. You want to produce excellent quality work. But there is a limit to the combination of quality and quantity that you can produce in an extended period of time. Right? Let me say that again. There is a limit to the quality and quantity combination. Right? In other words, how much quality work you can produce over an extended period of time. You can't produce an exorbitant amount of high quality work at a constant rate. And if you're unwilling to budge on the quality of your work, well, really, that means that the quantity is the thing that has to change. Right? Think about that for a second. You're not able to do higher quality things faster, except over the course of your learning process in your in your career, you will get faster as you go along at certain things. But there will still be a ceiling to how quickly you can produce high quality work. You can't force something to be high quality in a shorter amount of time. So that's the first concern. You want to produce excellent quality work, but you can only do that at a certain rate of work. Right? Number two, as an entry level web developer, you are most likely being paid at an entry level developer rate. Furthermore, the expectations of an entry level developer shouldn't match those of a highly skilled developer. As someone who has built quite a few websites myself, I would say that it is unlikely that a high quality custom built website will take any less than at least one day per page at minimum. And preferably significantly more, even for highly skilled developers, the demand on an entry level developer should match what they are being compensated for. And even for a highly skilled developer, more than one page per day, that's a lot of demand. That's going to be very difficult to accomplish. And you can even let your boss listen to this. This is something that a lot of people don't know. This isn't ingrained knowledge. We shouldn't know this intuitively. It really takes some time working with this stuff to learn these kinds of things. So yes, absolutely. One page per day is kind of the absolute maximum that I kind of go off of. Some people do it differently. Some people have found a way to do more than one page a day. And it kind of depends on the type of page, but we are going to get into the semantics for the sake of today's episode. Really, what we're talking about here is as an entry level developer, the demand on you should absolutely not be to produce at the level of an expert level developer, especially if you are not getting paid for the extra work that you're putting in for the extra time that you're putting in. The third consideration or concern that I think is important to outline is the foundation of a positive working relationship is trust. And really, this is the most important thing that you're going to take away from today's episode. The foundation of really any relationship, but especially positive working relationships between a boss and an employee, that foundation is trust. Both sides have to trust the other side. If the boss does not trust you, you will never see eye to eye on energy, output, or expectations or really anything. If there is a trust issue between you and your boss, such that your boss doesn't trust you to be knowledgeable about your own capacity or about how long it's going to take you to do the thing that you have been hired to do, well, that has to be fixed. That trust issue has to be fixed. Or else, ultimately, you'll end up always finding yourself in the disadvantaged side of the relationship. And this is how resentment and cynicism can set in because you have this set of knowledge and you're not being trusted to use it. That can be incredibly frustrating, even insulting. So make sure you reestablish this concept of trust that goes both ways. When you say that it's going to take you longer than a week, your boss should be willing to trust you. And when they ask you to do it in a week, they should be willing to compensate you for that. Now, this is going to be a little bit of a mini rant, but your boss can't just set an arbitrary deadline for a set amount of work and a static amount of energy. By doing that, especially if you do it over and over and over, you're lying to yourself about something. Now, that something may be the quality of the work itself. That something may be about the amount of energy that that work is going to take. Or that something may be the amount of time that that work is going to take. But something has to give. And sometimes you will under shoot it. Sometimes you will overshoot it. Sometimes you will accidentally land right on the mark. But ultimately, those kinds of estimations, they absolutely depend on the information that a developer has to provide and the expertise that a developer is building. So that foundation of trust has to be there. Now, there's a couple of other things to consider, and these are not in my list of things that you should discuss with your boss. But a number one, it is much harder to do two things in parallel than to do two things sequentially. We've talked about this before on the podcast. We talked about focus and many other things, multitasking, that kind of stuff. Human brains are not built for multitasking. So doing two projects at once is kind of a meta level of multitasking. But having two big projects on your plate at one time, it will kill your productivity. It will kill your output and your focus levels. And it will eventually add to your stress and your frustration because you're not working at the rate that you know you can. There's a certain kind of homeostasis that we reach when we get to this flow state when we're actually working at a rate that actually matches our skill level. And you can't really do that when you're working on two things sequentially. This is also why developers get frustrated when they are interrupted on a regular basis throughout a day is because our flow is interrupted and therefore we can't quite get to that space where we are producing at the level that we know that we can. We have an intuition about how much we can produce. So explain this concern to your boss and be certain to frame this by once again explaining that your intention is to do the best work in the time allotted and that you have an unwavering commitment to quality in your work. Your health will depend on balance. A healthy developer is not producing at 100% of every minute that they're at their computer. In the same way, they're running an engine at full speed all the time, redlining all the way up to the top RPM on that engine that will stress it out and it'll break it down much faster than running it at a lower RPM and running your mind or your body at 100% in any one category is terrible for you also. Let your boss know that you want to prioritize your mental and physical health so that you can be in this job for the long haul. What this means to you is that if your job is willing to sacrifice your health, okay, think about this for a second. This is kind of deeper discussion here and you really have to decide if your boss feels this way, Karissa, if your boss, if your job is willing to sacrifice your health and your balance as an individual as a rule, in other words, regularly. Sometimes you will have weeks that go over 40 hours. Sometimes you'll have weeks that go under 40 hours, but if as a rule, your job is constantly asking you to hit 60 hour marks all the time, well, you have to decide if you're willing to not only work over time without pay, but also continue these unhealthy patterns for the sake of your job. I can tell you there are other jobs that will not take advantage of your health and your sanity. Never confuse commitment with obsession. That's what we're really talking about here. Never confuse commitment with obsession. You can be committed to your job without being willing to sacrifice everything for it. There's a huge difference. There's a huge difference in being committed to your job and being obsessed with it. So make sure you keep that difference at the forefront of your mind when you start thinking about these things, Karissa. When you work with other people who don't understand your process, you talked about the designers who didn't understand your process, it is your opportunity to teach and guide and collaborate so that they understand your perspective and your limitations. This may mean sitting down with the designers and showing them the difficulty of the things they are asking you to do and don't expect this to stick on the first time. This may take quite a long time with both your boss and the co-workers that you have. They aren't going to get this ingrained immediately and change their ways right away. So understand this is a work in progress that people change very slowly. As you teach your designer co-workers what the development process is like, they will slowly change their behaviors because they also assuming they have the best in mind both for you and for the quality of their work, they want to work well with you. Nobody wants to work poorly with their co-workers. That obviously means that they aren't generating value for the company. So once again, it is your opportunity to teach your co-workers and to lead them forward by giving them new knowledge they didn't have before. Ultimately remember that humans are very bad at estimating and typically we see things through a limited perspective. A limited perspective is, well, it's our own. Your perspective is always going to be different from everyone else's. In fact, Karissa, your perspective is different from mine. And the best way to understand the problems you face with others in order to fix those problems, the best way to understand and fix those problems is to start sharing and adopting each other's perspectives. This means you have to work to have an open culture where new information, new practices are invited rather than rejected. This means that your boss needs to be open to having these debriefs and to changing practices so that you can produce the highest quality work. And Karissa, if these things do not line up at this job, if the culture is not open to feedback and to getting better, and to listening to each other and working better together, if that is the case and it stays the case, if you see no movement of the scales, if you see no tipping point, well, maybe that is the point where you start looking for a new opportunity. But culture is everyone's responsibility. Collaboration is everyone's responsibility. And a great developer, especially a great developer in a small company, they take ownership of these kinds of things. You take the lead on owning the culture and progressing that culture forward so that you can get better at what you do so that your boss can get better at what she does. The designers can get better at what they do and that you all get better at collaborating with one another. Ultimately, you're going to create more value in the company if you do it this way. Thank you so much for this question, Karissa. And I hope that number one, I've said your name right this whole episode. But number two, I hope that this was encouraging to you. And hopefully you have a way forward. And I hope that since you sent this email in, that things have started looking up for you and you're out from under your desk and you're not crying anymore. Thank you so much for listening to today's episode. Thank you again to Karissa for sending in that great question and to Linode for sponsoring today's episode. Go and get $20 of free credit for Linode at spec.fm slash Linode. Thank you again to Linode. And thank you so much for listening to this podcast on a regular basis. Of course, you can make sure you don't miss out on future episodes by subscribing and whatever podcasting app you use. We will be getting back to the developer career roadmap. I know there are people who are looking forward to the next step. So if you don't want to miss out on that, make sure you subscribe and whatever podcasting app you use. Thank you so much for listening and until next time, enjoy your tea.