Hey - it's only software, man!

January 12, 2006 5:58 PM

I have to learn some pretty tricky software and I know it's going to be a rough ride - what philosphies and techniques do you use to stop yourself being discouraged when you hit what appears to be an almost insurmountable hurdle?

The software in question is not well supported, poorly documented and also remarkably rare (no online tutorials or forums) so I know I'm pretty much on my own. I've been in this situation before and I know how mad I can drive myself when some action or code just won't work, so I'm trying to prep myself with any useful mental approaches that I can utilize when the going gets tough - you know, when hitting your head on the desk really is the best idea you can come up?

posted by forallmankind to computers & internet (12 comments total)

Just play with it a bit every day. What field does the software deal with? That would help a lot.
posted by devilsbrigade at 6:04 PM on January 12, 2006

Write documentation as you learn, so you can keep telling yourself that you are doing this for the good of all man kind.
posted by Loto at 6:11 PM on January 12, 2006

As a programmer I have a few tricks for this sort of thing:

-Sucker someone else to do it with you, either together or apart two heads are usually better than one. It doesn't have to be a co-worker, it can be a friend, or someone you know on IRC. If nothing else it helps prevent a monopoly on knowledge. If you can't get someone to do it with you, then keep someone up to date on it, tell them what you're doing, how you're doing, and where you're problems are, explain things out, as I mention in my third point, just by explaining things I often come up with new strategies.

-If you come up against a wall, be willing to step back for a few minutes and come back to it with a fresh mind. I know you can't plan for these sorts of things, but when I've run out of strategies I usually go home with the problem on the back burner of my head...cooking slowly, and 90% of the time if I haven't come up with a solution while I'm in the shower the next morning, then I at least come up with a few new plans of attack.

-Bounce ideas off the guru at your work. You know the guy who's always smoking cigarettes outside, and doesn't seem to be doing much 80% of the time but in that remaining 20% seems to output more productivity than a handful of coders? If you don't have one of those, bounce it off someone who's a critical thinker. Just by explaining things to someone (e.g. my poor girlfriend) I often come up with new strategies/solutions.

-create your own website on the software, or a wiki or forum, and add to it as you go. You never know but you might pick up a few flies along the way.

-Have you thought of newsgroups? Google Answers? I doubt you're the only one who's ever used that software.
posted by furtive at 6:14 PM on January 12, 2006

No books either?

Creating a forum might be overkill, but are there field-related forums where there will be enough people in a similar line of work that you could post to find others who use it? If you can find someone to call on for help as a last resort, that can help, then you can just give yourself a deadline on solving problems - if it takes more than an hour (or whatever is appropriate), write it down and move on. At the end of the day/week, assemble the notes into questions to send.

As to hitting the brick wall, I sometimes just challenge myself to find another way to do it, and don't pressure myself to have to get it working a particular way. If you can poke and prod and meander your way to your goals, you discover things along the way.

Deadlines don't always allow you to take your time though :(
posted by -harlequin- at 6:15 PM on January 12, 2006

Reminds me when I first tackled Linux some 7-8 years ago. It was far more difficult than I imagined. What I learned is time away is equally important as hacking and pounding away at the keys. Take kids to the park or go for a run and let your subconscious stew on it for awhile. When you come back to it you'll be in a refreshed state of mind and may very well have the answers.

A case of less being more.
posted by rinkjustice at 6:20 PM on January 12, 2006

Start a blog, or at least make the documentation public. That way, after you get "helloworld()" working, at least others will be able to leave comments and stuff. No one will care how kludgy the code you write is -- if you're the only source, then you'll be the *man* (or *woman* of course, whatever fits). I bet you there are people out there looking for help... so make a webpage and let google do her work. If there are thousands of people finding each other to dress up as furry animals and have sex, surely there are thousands out there trying to work with rare programming languages (maybe even some overlap in these groups!)

t's not jess is it? I'm working on jess right now and I can't find shit about it and the documentation sucks. I Cause I'd love a jess blog right about now!!

Also the advice to do a little everyday is good advice. I try to follow it but I'm woefully undisciplined. But if you can make yourself do even 15-20 minutes / day, things will start to happen. I hope.
posted by zpousman at 6:35 PM on January 12, 2006

Thank you for the responses so far - I guess I'm more looking for how people deal with difficult problems *before* they go looking for help. I'm sorry I can't say more on the software (for a number of reasons) but external aid simply isn't an option.

Secondary question; where can I find people who dress up as furry animals and have sex...?
posted by forallmankind at 6:53 PM on January 12, 2006

Some things I do as a programmer :

1) Don't be afraid to adjust scope.

Sometimes, to solve a problem, you must drill down deep deep deep into the code in order to find the problem.

Other times, you need to take a step back and look at the bigger picture. The little problem you're working on doesn't make any sense? Maybe it's part of a larger problem, or a larger system that you don't yet understand. There's also the chance that you've been looking at the problem entirely the wrong way, and need to completely re-evaluate your approach.

2) Look at the data.

Don't understand the code? Look at what it produces. Look at how it changes the database. Look at the HTML it generates. Examine the values of your variables. I've found that this is useful even for looking at data that isn't easily understandable. Sometimes you'll notice a pattern even if you don't really understand the data.

3) Test, test, test.

Think of new ways you can test the problem. Adjust your approach. Test in in a different way. Test some other aspect of the code. Keep on trying different things. This is a win-win, because :

(A) On the one hand, you may find a test that causes different results then your previous test, thus lending insight into the problem.

(B) On the other hand, all of your tests may yeild the same results, thus allowing you to eliminate a whole problem domain.

Or, as Thomas A. Edison once said, "My experiments didn't fail 50,000 times. I just found 50,000 things that didn't work."
posted by Afroblanco at 7:07 PM on January 12, 2006

This question is a little weird; are you looking for self-help/psychology advice, or software debugging advice? Maybe you could post a hypothetical situation you might need to deal with, and your expected difficulty in dealing with it?
posted by staggernation at 7:43 PM on January 12, 2006

This is indeed a weird question. Nonetheless, I have a small thing to suggest.
Somebody wrote this to be used, rather than to be puzzling. As such, if you think of something that the software should obviously be able to do (in particular, you know would be easy to program), then it's worth your time to figure out how to do it, even if it's not something you plan to use much yourself.
Some of them will be there, some won't; finding out which will put you more in the mindset of the programmer(s).
posted by Aknaton at 8:08 PM on January 12, 2006

staggernation: it's a bit of both.
Let's say for example the software was Director and I have to create a projector, so I do what I think I should do and it doesn't work.
Now, it could be a fault with the project assets - how they were supplied or how they've been flagged in the property inspector, or it could be fault with my Lingo, or it could be lack of knowledge of what I'm trying to do and I'm simply going about it the wrong way. Either way, there are many different places I need to look and, if my knowledge is at a beginner level, I could well be making mistakes in more than one area.
So, I'm looking for philosophies to use in situations which can seem terribly discouraging (Afroblanco's "testing puts me in a win-win situation" is a great example), and also problem solving techniques (Afroblanco's scope adjusting idea is another great example).
posted by forallmankind at 8:25 PM on January 12, 2006

My problem has always been one of motivation and stress when struggling with a high-order task like this: If I hit too many roadblocks too frequently, I'll get discouraged, and I'll be less likely to either finish it on time or finish it without overstressing the deadline.

Over the years, I've developed some mental conditioning that has really taken me quite a ways toward knocking down those roadblocks and keeping me in a good mood while I do it:

- Don't feel guilty about playing games. I'm not talking about going out and shooting hoops (although physical exercise can raise your metabolism and allow you to think clearer), I'm talking about getting your head into a mode of logical thinking. If I'm taking some personal time, I head on over to the large collection of free online puzzles offered by the major networks (Yahoo, MSN, etc). A good game of Sudoku or Mah Jong will either get me in gear to logically work my way through problems, or it'll refocus me and remotivate me. The time spent playing games also lightens my mood, so I'm less likely to get frustrated when I hit the next big problem.

- As I mentioned, above, physical activity of any kind, even if it's just getting up and walking around the Pod Village, will change your atmosphere for a small amount of time, raise your heart rate, and clear your head.

- Don't sleep on your troubles. Everything you are during this period depends on your capability to get a full and complete night's sleep. Before you go to bed, either watch a little TV or read a good book. You should hit the pillow with work being the farthest from your conscious mind. This does two things for you: Lowers your overall stress level, and lets your subconscious mind continue to work on the problems at hand. Perhaps when you get to work, you'll be able to tackle the next roadblock without too much work, as your mind has already been over the particulars while you were sleeping.

- Remove the little mundane distractions. When I'm in crunch-mode, I keep my snacks and soda in, or very near to, my desk. Sure, the soda is room-temperature (which is sub-standard for most folks), and you don't want to store anything perishable or smelly in your desk, but what you can work with is enough to keep you dealing with those long periods of thought where thirst and hunger can aggravatingly get in the way of you solving the problems at hand.

- When not at work, do everything to keep your mood elevated. Dwelling on your work problems won't help you, or the people around you. The only exception I have for this is if you're socializing with a peer who could potentially contribute something to your project. Even then, you want to discuss your situation, rather than hitting him/her up for advice. Your stress management, when working on a tough project, is key to keeping your mind from locking up. The best and easiest way to manage stress is to hit some social events with friends, spend time with the less taxing members of your family, play with pets, or (if you're like me) find any excuse to get your kids to laugh.
posted by thanotopsis at 6:01 AM on January 13, 2006