Tag Info

Hot answers tagged

76

Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.


46

I solved my burnout by quitting software as a profession (I remain active as an enthusiast hobbyist) and becoming a teacher. Your answer doesn't necessarily involve becoming a teacher, but probably will involve, in some way, a career change. The key problem I faced was that I loved software. It wasn't a job, it was a calling. The compromises -- often ...


42

Before ten hours go by, I would get some help. Describe the problem to someone else, anyone else, even your rubber duck. Ask someone else to take a look at the code, or step through it with them. Isolate it. Delete a bunch of stuff, then bring it back bit by bit until the problem reappears. Get some sleep!


37

Professionals in every profession have a way of thinking that differs from the others. After all, 'tis natural - you went to school and studied exactly for that reason; so you could develop that way of thinking. So yes, to that first questions. What one should never do, however, is think he is better than others in any way. And that is something IT people ...


35

Reading your post, all I could think was - ARE YOU ME SIX MONTHS AGO??? - I also burned out after working the last six years for a trading systems company. If you check out my profile, you'll see some posts (and my blog) which are exactly about this. I quit in January and have taken this year off as a self-funded sabbatical, and the first four months have ...


29

After 30 years as a contractor, it's mixed. It's all disposable. I've worked with hundreds of clients. I'll never see the code again. Why become attached? There's no sense of ownership. It's very visible. It's more expensive than in-house code, so it gets a lot of scrutiny. Since I won't be around to maintain it, it gets a very great deal of scrutiny. ...


28

Ban phone calls If your users are across the globe they surely can't expect you to pick up a phone when it's 4 AM in the morning and you're in bed. I would ban phone calls and switch to other means of communication that can serve this scenario better (email or some issue tracking DB). But even at the office make a scheduled phone accessibility schedule. ...


25

The recipe is: Slice the big problem into smaller chunks. Solve each small chunk separately. Link the chunks together to get the final result. It's logical to feel fear when being in front of a large monolithic problem that you cannot solve quickly. You can easily start to think this way: Where to start? OMG, I don't even know where to start, how would ...


25

How can I change my mindset to focus on task instead of contemplating how bad is the codebase I have to deal with? By realizing that by making this assumption: In this question I assume that obvious solution, i.e. fixing the bad code is not possible/applicable: it works, is too big, fixing it would take too much effort, it will be soon phased out, ...


23

There's actually some hard research data on this, mostly collected over the past 35 years, and I also have experienced a few similar phenomenons, though not on a regular basis. See below for more. Research Data There appears to be some but minor correlation based on research performed and summarized in the following works. As often with research though, ...


19

I wrote a fairly complex custom web application for a Federal Regulatory agency once with an IT Manager who was seriously ADHD, had administrator rights, and an itchy trigger finger. So one day she calls me up for support on the app. It was a fairly minor issue that was only experienced by a couple of users and I think ultimately was probably the result of ...


19

I'm sorry to tell you, but not all jobs are full of sunshine and glamor. The majority of development tasks involve drudge work like this. Sad, but true. You are tasked with an important job, even if it's boring to the point of watching paint dry. It's important for two reasons: 1. It add much needed logging to a large system so that when something goes ...


18

If you don't like the work, move. You have valuable skills proven in a relatively demanding environment, so you could get a job at most startups with no problems. If you want a meaningful work experience, look for educational startups, or similar companies that actually do want to make a positive difference (non-profits, edu-startups, certain startups in ...


18

Sometimes you have to understand these things in the context they were concieved in, then built in, then maintained in. Some of the worse offenders that I have seen probably started out as very nicely written programs. You can see a bit of well-thought out architecture trying to poke out through the mess. But as it happens, the requirements change during ...


17

One word, timebox, set a limited amount of time to work on something, and if it isn't solved, move on to something else and come back to it the next day with a fresh perspective. That and another set of eyes, is always worth more than any time you can waste staring at something. I would never spend more than 45 mins to an hour trying to solve something in ...


17

Depending on what you need out of the code why read it all. Searching by the words you need lets you jump to the parts you actually need so you can read smaller chunks. Most modern IDEs I've used lately let you do some flavor of a project or directory wide search for a given term which allows you to jump between references even if you don't really know ...


16

I interned at a financial firm my first year in college. At that job, I wore many hats: programmer, help desk, network admin. One day I had to hook up a printer for the secretary of the SVP of Investments. This SVP worked 15 blocks away and wanted the printer hooked up in a back room, 50 feet away from the secretary's desk. This was nearly 20 years ago, so ...


16

It's a bit like creativity. You can't force it, you can only prepare conditions favorable for it to appear. Some of the most important requirements: Distraction-free environment (you'll need hours of uninterrupted concentration). Clear goal. Genuine, intrinsic interest in that goal. Clear mind; not too much "should do this, should do that" issues nagging ...


14

This is actually quite a good question. Here are some things that work for me: First thing, break down the problem into manageable segments. Or at least break down the first part of the problem into small starting points. Second: solve the small stuff. This is some of the idea behind TDD and similar buzzcronyms. There is a psychological reason for ...


13

Unless you're the only person on the team - in which case, you're probably more than half-way down the road to burnout - take turns with 'the pager'. That should lighten the load for now. Then you need to pitch to management that they need to schedule a phase to pay down the technical debt - that means testing, code cleanup, refactoring. And it needs to be ...


13

I think developers are the only people I know who use nested brackets in written communications (Because we use them all the time (unless your language doesn't support them)).


13

What I do is harmful to the world: it just takes money out of the market, put in some pocket. It's just gaming the rules to make it more like pre-SEC trading. Believe me, it sucks. Amen, brother. In the early '90s, my wife and I wrote software for evaluating derivatives... and then, thanks to derivative speculation (but not our software) Orange ...


12

I'd be inclined to think they are thinking about the "Bus factor" ...a software project's bus factor (also known as truck factor, or bus/truck number) is a measurement of the concentration of information in individual team members. The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) ...


12

Minimize interruptions. Only check your email twice per day. Let phone calls go to voice mail. It's all too easy to get caught up in the urgent, but not important. Commit to doing the important things first. This is really important; you can always check teh facebooks, watch that really important youtube, or talk to your coworker about your fishing ...


11

I was in a similar situation, tasked with cleaning up a large body of poorly written, massively copied-and-pasted code. To maintain my motivation and my sanity, I wrote a script called current_score that counted the LOC in the project (which steadily decreased, as I eliminated duplication and switched to better algorithms) and compared it against the LOC ...


11

Keep a file of candidate code snippets for submission to thedailywtf.com. Even if you don't really intend to submit them, it gives you a bright side to finding some code that's even worse than average.


11

It's been demonstrated that there are two kinds of thinking (logical and intuitive) and most people have a predisposition toward one or the other. I personally think that many programmers are balanced between the two (whole-brained is the term mentioned in the article), based on the fact that we understand things like elegance and "good-looking" code (as ...


10

I know I answered already, but I have a few of these as I work in web development. My favorite (least favorite?): I was hired to build a website for a relatively high-profile name in the sports world, so all of the communication was done through his lawyers who obviously knew not a single thing about web development. I got the job because a friend of mine ...


10

I think the real reason is that ordinary computer users, even if they should go on to become programmers, are conditioned to believe they can't do anything about errors. Think about it. What do non-programmer types do when they encounter a cryptic error message*? They might read it, but nine times out of ten they'll simply dismiss it and try again. Only if ...



Only top voted, non community-wiki answers of a minimum length are eligible