Can people with ADD go into computer programming jobs? (software engineering)?

Well, people with ADD can go into any job that they want, including accounting. :) (for the ADD masochists)

I think computer programming is a fairly common job for those with ADHD (especially inattentive types). While I am not formally a programmer, I do do some programming for my job (usually lower level). Whether or not software engineering is a good job for an ADDer depends on the person (whether or not taking medication is a factor here), the environment, and the nature of the job at hand. Specifically, jobs that entail making certain types of software over and over again (software factories) and programming jobs that entail large amounts of maintainence work and little original programming are probably NOT good jobs for those with ADD. Positions involving short-term projects with a variety of different problems are better. The rules with any job as far as being ADD friendly still apply here as well.

Some claim to need medication in order to focus on programming, while others find it better to program off meds. It's really a factor that changes from person to person. If one is very interested in their job, being off meds could possibly be an asset as medication tends to inhibit hyperfocus.

I'm a programmer, and I find that it suits me quite well.

For challenging, complex projects, I do better off meds. When I take them, I can't as easily get "in the zone" (hyperfocused), like HighFunctioning mentioned.

However for boring routine stuff that I don't find interesting, Ritalin makes all the difference in the world.

Short answer: yes. But pay attention to what HighFunctioning and ummagumma say about the pitfalls.

Specifically, jobs that entail making certain types of software over and over again (software factories) and programming jobs that entail large amounts of maintainence work and little original programming are probably NOT good jobs for those with ADD.
True, but the nature of programming is such that it's usually useful to put in the time to automate a task to solve a problem "once and for all" rather than make constant manual tweaks. Sometimes you end up making the manual tweaks just out of sloth, but by the 4th or 5th time you do the same thing you think, "Gee, i could really save time by automating this." And the nice thing about programming skills is, they give you the means to automate.

By way of contrast, most of my career I did software QA. At its best, it's just a different kind of development: writing code to test other people's code. At its worst, it's just awful. Enter this data again each time a new build comes out. But can't we automate it? <geekspeak>No, we can't. Just do it manually.* A</geekspeak>s a tester, I was constantly put in situations where I was asked to do something manually a dozen or more times rather than given the tools to automate it.

But the good news is, as a developer (versus as a tester) you have in your control the means to automate. All you gotta do is learn how.




Positions involving short-term projects with a variety of different problems are better. The rules with any job as far as being ADD friendly still apply here as well.Yes, this is true. I'm freelancing now and loving it (except that I'm not yet making a great living at it, but that will come in time).

Some claim to need medication in order to focus on programming, while others find it better to program off meds. It's really a factor that changes from person to person. If one is very interested in their job, being off meds could possibly be an asset as medication tends to inhibit hyperfocus. Yep. If you're on an interesting project and can bury yourself in it, you'll do great. The hard part is how to stay motivated with the grunt work so you can hang around for the interesting stuff. But unlike some jobs, there almost always is SOME interesting stuff.


----
<geekspeak>*(BEGIN GEEKSPEAK)"No, we're stuck on some old GUI toolkit that won't support it, and the code is too old and monolithic to refactor it properly so we can test it well.</geekspeak>" (END GEEKSPEAK) Pardon the jargon, but the point is that OF COURSE it's more rewarding to automate a task once rather than to do it manually 100 times.

True, but the nature of programming is such that it's usually useful to put in the time to automate a task to solve a problem "once and for all" rather than make constant manual tweaks. Sometimes you end up making the manual tweaks just out of sloth, but by the 4th or 5th time you do the same thing you think, "Gee, i could really save time by automating this." And the nice thing about programming skills is, they give you the means to automate.

By way of contrast, most of my career I did software QA. At its best, it's just a different kind of development: writing code to test other people's code. At its worst, it's just awful. Enter this data again each time a new build comes out. But can't we automate it? <geekspeak>No, we can't. Just do it manually.* A</geekspeak>s a tester, I was constantly put in situations where I was asked to do something manually a dozen or more times rather than given the tools to automate it.

I completely agree. In real software production environments producing real software, I would hope that this is the rule, not the exception (not that I work in such).

This isn't the case with me, sadly (I'm not a programmer in a full time job sense, it's only a small portion). In certain very specialized, not-really-computer-programming environments that don't usually involve coding via. language with proprietary tools (e.g. programmable controllers) in which the programs are to be read and analyzed by incompetent people and therefore restrictions may be enforced on your programming style, this luxury may not exist. Even when language is used, the programs are often expected to be linear as possible. It's just a warning, but if one finds themself in such and environment, run -- don't walk -- away.

{* That's not to say that it would be bad in every environment (programmable controllers), but most of the time, it is. *}