These are general case studies and it is important to stress from the outset that there will always be exceptions.<\/strong> The purpose of this article is to encourage you to take responsibility for what is under your control, not<\/em> to have you consistently blame yourself even in the most extreme circumstances. So if your personal experience tells you something different than this article, well, go with your personal experience!<\/p>\n\n\n\n That being said, let\u2019s get started with\u2026<\/p>\n\n\n\n For developers emerging from an educational environment, it\u2019s often a minor shock to find that most of their new teammates may not be proficient with technology at all. If luck isn\u2019t on your side, this may well include management, and as a result you will find yourself surrounded by people who do not understand what your work really involves.<\/p>\n\n\n\n If that is the case, it\u2019s your responsibility to make sure that others understand the way you contribute to a project and that they appreciate your value to the team<\/strong>. This is not to say that you should spend half your day bragging, but if an idea you came up with improved the performance of your company\u2019s website, or something you worked on by yourself enhanced your user experience, then the next time you sit down with your boss or at a team meeting, tell<\/em> them what you did and how it made a difference. Don\u2019t just clam up and expect others to simply know<\/em>.<\/p>\n\n\n\n Also, do not fall for the common misconception that \u2018good work speaks for itself\u2019. That may be true if you\u2019re painting a house \u2013 it doesn\u2019t really translate to software development.<\/p>\n\n\n\n Every developer knows at least one story about some legendary, cryptic bug that was impossible to find. Many will find themselves as the protagonists of such a story at some point in their careers.<\/p>\n\n\n\n But these stories should really be the exception, and if you regularly find yourself wasting hours or even days looking for bugs that turn out to be relatively simple in code you wrote yourself, then it\u2019s high time you changed something about the way you write code in the first place.<\/p>\n\n\n\n Wasting too much time on bugs is a classic sign that you are not testing your code properly, or perhaps only testing it it as a finished product, in big chunks<\/strong>. Instead, develop a habit of writing unit tests, which proof your code at much lower levels. That should drastically reduce the issues you\u2019ll encounter at a later stage. If you\u2019re wondering where to start on this, Katy A has an excellent introduction to unit tests<\/a>, and you can also take a look at our previous articles on the art of debugging<\/a>.<\/p>\n\n\n\n It goes without saying that this argument only holds for code of your own writing. If someone puts you to work on poorly-written legacy code created by somebody else, well, that\u2019s not a bed of your own making.<\/p>\n\n\n\n Here\u2019s one mostly for freelancers and solo (or semi-solo) developers in start-ups.<\/p>\n\n\n\n \u201cHow long do you need to add this feature to the project?\u201d<\/p>\n\n\n\n \u201cSeven days.\u201d<\/p>\n\n\n\n \u201cThat won\u2019t do. Can you do it in five?\u201d<\/p>\n\n\n\n If you are ever asked that question by a client or by management, the correct answer is always no<\/em>.<\/strong> They asked how long you need to get your work done, and you told them. If this is not acceptable to them, then they can either look somewhere else (as clients) or you can explain to them that a delay in the project is inevitable.<\/p>\n\n\n\n Do NOT, under any circumstances, commit to completing a task in a shorter time than you know is possible. If you do that, and you find yourself up at 3 a.m. on Sunday working on your console, then you really have nobody to blame but yourself. Don\u2019t become the sort of developer who doesn\u2019t know how to say no<\/a>.<\/p>\n\n\n\n Of course, freelancers working with clients have some room to be flexible \u2013 for example, you may choose to charge a premium if you think working longer hours is worth the money. But even then, be careful what you\u2019re signing up for. No premium is ever so high that it\u2019s worth risking burnout for it.<\/p>\n\n\n\nCase 1: \u201cMy teammates don\u2019t understand how useful I am\u201d<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.wbscodingschool.com\/files\/AdobeStock-by-fizkes_261828721-1024x682.jpeg\")
Case 2: \u201cDebugging my own code eats up a ton of my time\u201d<\/h2>\n\n\n\n
Case 3: \u201cThere is no way I can meet the new deadline\u201d<\/h2>\n\n\n\n
Case 4: \u201cI used somebody else\u2019s code, but now I no longer understand it\u201d<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.wbscodingschool.com\/files\/AdobeStock-by-PheelingsMedia_416178569-1024x682.jpeg\")