@jasonlotito did great job saying what I'd already planned on saying. I'll just add that it can be easy to write off signs, or to say you can cope with it, especially when one is successful.
I was surrounded by clear ADHD cases growing up. They were more-or-less bouncing off the walls and constantly getting in trouble. I knew I wasn't like "those kids". But the inattentive types—those that can't focus or tend to hyper-focus on one thing to the detriment of others—fall through the cracks because they're not acting out. And, if they're otherwise high-performing, they'll be able to pull through their work with the occasional forgotten assignment or scheduling snafu. Teachers, bosses, even the affected themselves seem to think just need to concentrate harder and they'll do better next time.
But, telling someone with ADHD to concentrate harder is like telling someone nearsighted to squint if they can't see the chalkboard. And it's not a flaw in their character anymore than myopia is.
Anyway, I don't know your life or backstory, just that seems pretty familiar to me (tried pomodoro, thought of/started on a similar system before abandoning it in graveyard that is my ~/Projects folder). If any of this has struck a chord, I've found that simply changing my work circumstances have helped me immeasurably. Two years ago, I was working at home and left to figure out every choice and solve every problem in a pretty open-ended project. I'd spend hours reading papers, tutorials, and blogs with little to show. Now I'm in an office with an open floor plan and a team working toward a common goal with a time constraint. Medication would probably help me even more, but I exercise quite a bit and am wary of side-effects. Therapy would probably be even better, especially because, while my organization and execution at work has gotten better, my own tasks are about where they were before.
If you're interested, I found "Driven to Distraction" by Hallowell & Ratey to be a pretty good reference (although, if you get through the whole thing, you might not actually have ADHD).
Old, but good, and apropos given the Prop 8 and DoMA discussions in the US Supreme Court. While it uses gay marriage as an example, it's really good rundown of several things that may seem "fixed" in any database schema design problem and how you might (or might not have to account for them).
Looks interesting, but can we get some background about why it's particularly remarkable? I haven't heard of the author, and though it's an interesting topic, there seem to be a lot of other textbooks in the same field. What's special about this one?
I feel like something similar could have been said about Xmonad. Yet, through its configuration and extension mechanisms, it's become a gateway for a lot of people wanting to learn Haskell. This niche isn't likely to fragment as long as it's made up people obsessively scratching their own itches.
I think the author and Armstrong have significantly different ideas of what a "type" is. That's not a huge surprise—depending on background, you'll often get several definitions from different people.
One way to see types are things with fundamentally different access pattern: individual entities, sequentially retrieved ones (e.g. lists), fixed-length ordered lists whose elements are accessed positionally (e.g. tuples/vectors, fixed-length maps whose keys are known at compile-time/records/objects can also be viewed this way), unordered collections of distinct entities (sets), etc. I'd argue Armstrong's view is similar to this based on what he put in Erlang.
I can't tell what the author's view is, aside from "a class is a data type". This suggests that he equates a type with the set of functions that can be called on something and not have the compiler or runtime blow up (or perhaps, the set of functions that the programmer, by putting them in the same file, has explicitly said won't blow-up, whether or not that set is correct or complete). This throws fundamentally different things like lists, tuples, sets onto the same level as Person, Account, and PayrollRecord—which are often just short-hand names for tuples with different arities or names for their elements' positions.
If one has the later view, confusion over the point 3 is understandable: creating a new type for time is easy, just do class Time and define a bunch of properties and methods. In Armstrong's example, time is just a 6-tuple (or 3-tuple if all you want is hms). If you wanted to store it or send it over the wire, anything that could handle a tuple of integers would already know how to use it. If one function calls the last member "sec" and another "second", they're local names, so it doesn't matter as long as they're both accessing the same member.
One can object that it's easy to write serializers or that a compiler or library could figure it out, or that having different names for the same data elements indicates inconsistency in code that should be caught earlier. De gustibus non est disputandum. But, don't throw up your hands and say "this makes no sense!" without considering another perspective first.
Or, if the masters are too hard at first, see if their pupils have written annotations. I tried Turing, couldn't even understand why what he was talking about was important (or why his "computers" seem so much... lamer than the ones I was used to), and then found Charles Petzold's "Annotated Turing".
He takes Turing's "On Computable Numbers..." and mixes in chapters giving the necessary background on the history of mathematics, number theory, logic, etc. in-line (albeit, it takes about 100 pages to get to the first sentence of Turing's paper). I whole-heartedly recommend it.
I love Trello. I've been using it to plan my wedding. At first my fiancee was worried that it would add too much overhead. (She was never overly concerned that it was spectacularly nerdy to be using a software project planning suite—and that's a sign I found a keeper.) It's really shined with the guest selection/invitation process.
We created a couple of lists to group and sort guests into Definite, Good to Have, and Maybe lists and used labels to relations to whoever wanted them, which really helped with the friends and extended family that the other didn't know. We used checkboxes to track addresses that we were waiting on, who's save-the-dates have gone out, etc. I've used the API to total up people for the headcount (since cards we often for "Jack & Jill Smith"). If we were doing assigned seating, we'd probably make lists for each table and move the cards around. Thankfully, we decided to go for heavy hors d'oeuvres.
The thing's versatile: very few things feel like they're driven by the project planning domain (e.g. voting for cards). I'd love to see some kind of ability to embed scripts and save some checklists as templates that I could apply to cards with one or two clicks, but the API access suites my needs right now (and I know some people are using Greasemonkey scripts).
I'm only a somewhat familiar with the geography there, but IIRC, it's similar to what's described here:
"Cables almost never land in industrial zones, first because such areas are heavily traveled and frequently dredged, second because of pure geography. Industry likes rivers, which bring currents, which are bad for cables. Cities like flat land. But flat land above the tide line implies a correspondingly gentle slope below the water, meaning that the cable will pass for a greater distance through the treacherous shallows. Three to thirty meters is the range of depth where most of the ocean dynamics are and where cable must be armored. But in wild places like Porthcurno or Lan Tao Island, rivers are few and small, and the land bursts almost vertically from the sea. The same geography, of course, favors pirates and smugglers."