TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

100% Burnt Out

10 点作者 djmill将近 10 年前
What do you define as burnout?<p>When did you first experience burn out?<p>How long before starting a new job should you start feeling the effects of burn out?<p>Were you ever burnt out after the 1st month constantly trying to play catchup?<p>Is your team so disorganized that you&#x27;re constantly playing catchup and fixing everyone else&#x27;s spaghetti code?<p>I&#x27;m curious what other people have experienced. I started experiencing burn out after 1 month at a new job. Was hired into a &#x27;Jr&#x27; role (not included in title, but still a Jr role), but I&#x27;m doing the work of a Principal engineer who left 1 month after I joined. On top of new features, I have the joy of refactoring thousands of lines of code just so I can build the new features the &#x27;right&#x27; way. I&#x27;m constantly playing catch-up, always doing patch releases within the next release&#x27;s sprint (it&#x27;s like having 2 jobs!), and I&#x27;m always the &#x27;go-to&#x27; guy for specific things that I&#x27;ve already taught to the other devs. I&#x27;ve taught others how to do things the &#x27;right&#x27; way, but things are rarely built the &#x27;right&#x27; way.<p>Playing catchup is 50% of my job.<p>Working on the current sprint is 25% of my job.<p>Fixing other people&#x27;s bugs for a release I&#x27;m not scheduled to work on is 25% of my job.<p>Mental break downs have occurred twice in the past 5 months.<p>When do I call it quits? Am I just that self-loathing that work and experience is worth more than my mental sanity? Are my expectations of the industry skewed and everyone is always this miserable?

5 条评论

saltvedt将近 10 年前
You&#x27;re not required to set yourself on fire to keep others warm.<p>There is such an incredibly huge gap between what is considered good software craftmanship and what is actually happening in practice in the industry. Nobody really talks that loudly about the ugly parts - it&#x27;s embarrassing and just reflects badly on your employer (or worse - client). But judging from my own experience, and what my friends working at other places tell me, and how much articles like &quot;Programming Sucks&quot;[0] resonate with people, you are very likely to run into the same problem at your next job if you decide to quit.<p>It sounds like you&#x27;re doing a good job, so instead of quitting, consider caring less about the company, the project and your own reputation. Let deadlines slip. Don&#x27;t do patch releases. Go home at 5.<p>You might catch some extra flak at the start since you&#x27;ve been doing this stuff so far, but at worst you will be as ineffective as your coworkers. The company is probably better off with you working normally than quitting.<p>[0]<a href="http:&#x2F;&#x2F;www.stilldrinking.org&#x2F;programming-sucks" rel="nofollow">http:&#x2F;&#x2F;www.stilldrinking.org&#x2F;programming-sucks</a>
kpil将近 10 年前
&gt; I have the joy of refactoring thousands of lines of code just so I can build the new features the &#x27;right&#x27; way.<p>Maybe don&#x27;t do that. Build what you CAN the &#x27;right&#x27; way, accept some shitty code, and most importantly - don&#x27;t try to kill all the shitty code on your own as a side objective.<p>Take a step back.<p>Look at what is required of you personally.<p>If you can make a case of rewriting the shitty parts, then do that. Presumably if the old bugs are catching up and wastes a lot of time for you and your team, and pisses of the customers, then it it won&#x27;t be any problems to make the case for rewriting the worst parts. That means that other things have to be prioritized lower.<p>If you can&#x27;t sell a refactorization, maybe because it&#x27;s not worth it - as in no economical benefits, maybe you need to adjust your expectations. Shit happens, also in code. You are not paid to write code &quot;the right way&quot;. You are paid to write whatever that brings in the money.<p>If you can&#x27;t sell it although there is a clear economical benefit, then find another job.<p>Good luck.
MattGrommes将近 10 年前
Sounds pretty shitty. You&#x27;ve been there 5 months? I&#x27;d say that&#x27;s probably long enough to see if this is just a temporary period of craziness or just the way things are. If things are unlikely to change just by waiting, I&#x27;d say you need to leave.<p>But first, I&#x27;d personally start making noise about the way things are. Maybe the bosses think everything is fine. If you&#x27;re mentally done anyway, there&#x27;s no barrier to speaking up. Start making the case that the way things are is unsustainable. If they don&#x27;t listen or you can&#x27;t push through any changes, start preparing a story you can tell your next employer and get out the door. No, this particular job is not worth your sanity.
评论 #9785071 未加载
shoo将近 10 年前
All the other suggestions here are pretty good.<p>here are some from my personal experience, they probably do not all apply:<p>(i) establish clear boundaries as to how much time&#x2F;energy you are willing to put into your work. don&#x27;t do unpaid work - this devalues your own time and devalues the time of your coworkers. don&#x27;t silently absorb the consequences of bad decisions made by other parts of the company. push back! if you are overloaded with work, clearly explain this, and force clear prioritisation decisions. it is better if management rapidly feels the discomfort caused by their own poor decisions (similar to CI!).<p>(ii) if there are serious problems with existing code that need refactoring (there usually are), and it needs a substantial investment of time, make a business case for it and get someone with authority to make a clear business decision. people who are not getting their hands dirty with the code probably don&#x27;t have a clear idea of the reality, so you need to find a way to explain that, and what the future consequences will be. it might be necessary to gather metrics and make some kind of argument focusing on which parts of the code attract the most bugs &#x2F; are impossible to test &#x2F; are frequently undergoing change, and how this impacts the business.<p>(iii) sometimes you may be in an environment where hastily writing lower-quality code is the best option. some organisations have found markets where perhaps this is necessary. e.g. more consulting-ish work where much work is client-specific and there is not enough money in it for a lot of development effort. if you take pride in higher standards of craftsmanship you might be far happier working somewhere else, where there are clear business reasons for doing things at a higher level of quality.<p>(iv) if management&#x27;s response to your concerns boils down to &quot;after [some duration] things will get better&quot;, they&#x27;re probably just stalling, and they do not want things to change. if they want things to get better they need to actually start making changes for the better, perhaps small, immediately.<p>(v) seriously consider quitting. try to find a few people (outside of work) who you can talk through the decision with.<p>(vi) make sure you have positive things happening outside of work. exercise. eat properly. do fun things unrelated to your job. spend time with friends and family. if you do not have that much else going on aside from work, it is easy for work to expand to fill the void. this will not make you happy.
fsk将近 10 年前
Here&#x27;s what happens at my current job:<p>The boss assigns me 5 tasks. I ask him what is the priority (offering my guess). He tells me the priority, and I do them in that order, and he understands that the low-ranking stuff might not happen for a few days.<p>Here&#x27;s what happens in a toxic environment:<p>My boss assigns me 5 tasks. I ask what is most important. He says they are all equally urgent.<p>The 2nd example shows an ignorance of how programmers work. You do one thing, finish it, then do the next thing. If you try to do 5 things at the same time, it&#x27;ll take much longer than doing them in order.<p>What you have to do is make sure your boss tells you what is the most urgent stuff, and let the less urgent stuff slide.