Hi all,

I want to address a specific question to all those involved in computer science/software engineering. I have problems finishing things through (programs, peaces of code, algorithms). The problem is in keeping my mind relaxed so as to get to the end of what I want to write, without loosing myself in details on which I insist too much. I am getting very tired very soon, after 30' or 1 hour. My day goes by without having much accomplished, feelings of guilt, frustration, and a lot of mental fatigue which also make me think the problem will affect my personal life forever!

Anyonw has this problem ? How do you deal with it ? What is the role of medication in your profession ? What is the role of your colleague in your work ? Do you get them involved, is it a team work ?

I am actually doing a PhD in computer science, which involves a lot of programming, testing, changing, testing, and programming, again etc., all mainly based on some fuzzy specification and requirements which we define ourselves ... it's not industry. However, I also had my share of industry, I did an internship at a Software Development company: clear requirements, but always the same problem : too much attention to details which lead to quick mentral fatigue, and at some points some sort of mental blank when I did not even know what action to take next. It did not end so well: final result - "You have very good technical knowledge, but lack working skills ". And I agree :rolleyes: But it gets to me after a while :( :)

With ADD, it is all about planning, but how can you plan in that micro-detail ? And I've also been said I am perfectionist - nothing seems to be good enough, and I get lost in the multiple ways of doing things (in this case, programming): I cannot decide to take one path alone... and now in research, there _are_ more ways of doing something, and they need to be addressed for comparison.

Similar thoughts? And some possible approaches/solutions ?

All the best to everyone here,
Cristian.

Kristy, have you used modeling tools like UML , etc.. ? Do they help / hinder?

I've been a professional software developer for 15 years and have only recently figured out that I have ADD. I can absolutely relate to your problems and I have some suggestions but I won't get into them now because I have to finish some programming ;) I'll check in again on my lunch break.

OK. Blood sugar is back to normal now.

I won't say much about my college experience, other than it was 4.5 years of near hell. I don't know how many week long programming projects I started at 10PM the night before they were due.

Overall, I've managed to do quite well in my job. This is due to several things that I learned the hard way before diagnosis. Some of these apply to professional life but some should help in a school environment, as well.

Disclaimer: This is what works for me. Depending on your situation, you may find that only some or none of it helps. I hope some of it does, though.:)

1. Try to find a company that is flexible in your hours and lets you have some say in how you approach problem solving. Try to avoid being boxed in physically or mentally.

2. Perfection is subjective. Perfection assumes that requirements are perfect. Requirements will not be perfect in the absence of a live system to work with. There are some exceptions but any application that involves user interaction will likely not be perfect for release 1.0. Do the simplest thing that will possibly work and promise yourself that you can come back later and improve it.

3. Focus on your strengths. If you're like me, you can see patterns and innovative approaches to solving problems far easier than the farmers. An organization needs a combination of conceptual thinkers and steady code writers to be successful. I have met few individuals that are both.

4. Get help where you need it. Nothing is more irritating in professional software development than the guy that sits in the corner struggling with a problem and not asking for help and holding the team up. I have a good buddy at work that I often talk to about algorithms that have me stuck. In turn, I supply ideas and innovative approaches to solving problems.

5. Find a development methodology that suits your way of thinking. The AgileAlliance has some great methodologies that focus much less on detailed design and more on iterative passes with lots of testing and feedback. They also recognise the value of intuition in software development. My bet is that this way of development will be mainstream in 10 years.

6. ADD people are generally lousy linear thinkers. If you have a complex algorithm, simplify it. Remove some of the variables or leave out complicated sub-routines. Use stubs or dummy values to get it to run, if needed. Get comfortable with the simple execution first, then start adding whatever else is needed one step at a time. Generate lots of output along the way with unit tests or debug lines so you have a nice visual indicator of your progress.

7. Write your designs on note cards, if possible. Don't get mired down in big, clunky, designers full of distractions and their own frustrations. Ultimately, the code is the truth, not the design.

8. You may have heard otherwise, but most documentation, including the detailed design, is written after the code is complete. Most companies do not have a fully detailed specification of what they need prior to a project starting. The ones that do are usually building something that will kill people if it's wrong (e.g. aircraft control systems) so a detailed design is very important.

9. Have courage. If SW professionals got fired for making mistakes, there would be none left.

10. So far, medication is helping. It has increased my ability to stick with cumbersome problems where I would have walked away before. It has actually enhanced my conceptual thinking and innovation because I am better able to focus on what the rest of my team is doing and see patterns and solutions emerging.

11. Be patient. It took me many years of struggle to really start writing some good code and all the tests, docs, and details that went with it. It is a learned skill, after all, and takes practice and experience to become proficent.

I hope this helps some. I now wonder what my college and early professional life would have been like if I had known about my ADD. Oh well, no time to dwell in the past ;)

Hi all,

Thanks for the replies. You are right, and I can relate a lot to the points. Especially to those which refer to doing quick design, and also to the necessity to talk to other people. Actually, I have a really good supervisor, famous in his field, really pationate about what he is doing. He has a very nice and calm way of planning when writing software, and he does some quick diagrams (he likes E/R, they are even more simple than UML, plus we do database reasearch, so ...), and just jumps into action. It does not seem difficult until I do it myself...

My big problems are: when I do some design (esp. using UML tools) I overdoit, just like when using an electronic planner - I do not stop improving my time plan. (Note cards seem therfore a great alternative since it imposes limits). When writing software, it is ok when I have courage to change things and improve things. However, I spend a lot of time thinking if some variable or parameter could be changes so that everything still fits together afterwards and nothing breaks - it is like I am trying to anticipate everything in my mind so that my carefully planned design and routines do not fall to peaces. It must be the "writer's block" for software writing. This is what I meant by perfectionism. I also think of more ways of doing the change and I end up doing none. Mental fatigue also comes quickly this way. I need to find a wat to get out of this pattern, otherwise ...

So I will keep trying to improve and avoid these mental traps :) Somehow "simplifying" seems pretty tough for me... This must be strange for you, as far as I understand.

Cristian.

Over anticipation and engineering can be a real problem when designing systems. Simplifying was one of the things I had to learn the hard way. It is absolutely essential when building large systems because there is no way to grasp 300,000 lines of code as simply lines of code. Here are a couple of things that may help.

1. My favorite design practice is encapsulation. Have clear boundaries between the parts of your system and give them concise interfaces. This way, if you do make a mistake, it is isolated and much easier to fix. This also makes refactoring easier.

2. Check out Martin Fowler's book on refactoring. It gives you some tools to know that you can make compromises initially and then optimize them on later iterations.

3. Use design patterns whenever possible. Look on the web or the Design Patterns book to see if there's something that will solve one of your problems. Also watch for patterns in what you're creating. Take some time to step back from your system and look for similarities in its various elements. This will help you have a better conceptual understanding which will take some of the pressure off of implementing with code.