Monday, May 21, 2018

What it's like working in tech with ADHD

Whoa, it's been almost 3 years since I last update this blog? Geez, what's happened in the interim? Well... A lot. I'm currently coming up on two years as a software developer for Uber, and what a crazy couple of years it's been. I'm not sure why I haven't written in a while. This blog was always designed to describe my adventure, navigating from job to job and what I learned or sharing some perspective that might help others.

Today I'm going to share a personal perspective on what it's like working in tech with ADHD (if you couldn't tell from the title).

Alright, so first things first, let's define some context. This is as much for you reading this as it is for me writing it. What is ADHD? ADHD stands for Attention Deficit Hyperactivity Disorder. Okay, so that's not very useful is it. I mean there's this ADD thing which is everything minus the hyperactivity. Okay, perfect, that explains it! I have a deficit of attention.... and it's considered a disorder... Cool. Oh, and the H part in ADHD means I'm hyper. Super useful.

Yeah, no, this definition doesn't help me either. Honestly, the part I hate most about this acronym is the "attention deficit" part of it. Maybe I should switch to a Medium blog? Wait, focus. See, the problem is I don't have a deficit of attention. I've found most people define focus or attention as how long you can work on or think about a single task without switching. So when it appears from the outside that I can't stay on one task for more than all of 30 seconds, you assume that I have a lack of focus. Hence, attention deficit. I'm defined based on the neurotypical view of me. Hence, disorder. I'll get back to the hyperactivity part in a bit.

Let's reframe this in a way that's more positive for me: context switches. What's a context switch? Well this one seems easy enough. It's when you're working on one thing, and then for whatever reason something happens and you have to switch to another context. For a real life example, it's when you're sitting there, in the zone, and your boss comes up to you and says "Hey I have this one quick question". poof Everything I was thinking about before is gone. What was I doing? Oh yeah, coding on this one bug. Let's see. I was in the middle of that test case... Right right, so I need to assert....

It's because of this that context switches are called "expensive". Because in this example, you had to switch to the context that your boss wanted to talk about, then switch back to what you were doing previously. It can also happen for scheduled things. Say you're scheduled for a meeting. You waste the 10 minutes before the meeting either preparing for it or just not wanting to start another thing. And then you spend another 15 after the meeting addressing follow ups and just generally getting back in the zone.

Why is that positive for me? Well... It's sorta complicated. If your brain itself is jumping you from context to context, you might get really good at regaining the context that you jumped from. This is actually something I learnt to practice at a young age, and I highly suggest to anyone with ADHD or ADD. One of the ways you can practice is by having a conversation with someone, and continually (or even after the conversation), tracing backwards through the conversation. "How did we get to this topic? When did the topic change? Did I change the topic by going off on a tangent?"

Applying that technique really helped me with context switching. I figured that if my brain was going to jump from one thing to another, I might as well understand why or how it did that. And because of that training, I now consider it a benefit to me in my job. For example, I can look at a system as a whole, its architecture and design, and see it from that high level. I can also think of the individual classes that I know and how they piece together. And jumping back and forth from those two levels is near effortless. The benefit of that is that I can be a subject matter expert in several systems, languages, ecosystems, etc. and have a deep understanding of that technology, while being able to bring it up a level and try to explain it. Granted, my written communication itself could improve, but that's part of what the blog was for. :)

Okay, so where was I? Ah yes, focus. You know, I tried to learn to juggle once. It didn't go super well. I honestly could probably learn it right now, but don't really feel the need to. Juggling has always kinda appealed to me, because while one ball is in the air, you're already performing the motions to get the next ball in the air, followed in quick succession by the next one. My focus sometimes feels like that. On a good day, it feels like I can time any action down to the second. I can look at a clock, have hours pass, and still know what time it is to within a minute or two. I can have 30 tasks planned out in order, and just execute on all of them.

On a bad day... not so much. Everything seems difficult. What I think should only take 5 minutes ends up taking 20. I make a plan but suddenly lose focus on step 2. And that's honestly only because I made step 1 "get up from the couch". And it's unsettling, because I feel that. Like, not that I notice it's happening, but I feel it in my bones. It's uncomfortable, I feel trapped inside my own brain. In comparison to a state when I'm doing well, it's as if my entire body decided to rebel against my wishes.

That's why I don't like the "attention deficit" name. Because when I'm having a good day, there's no "deficit". I can complete my tasks and get everything done. You might say that that means I am able to focus, but just like juggling, I'm not even really thinking about the task up in the air right now. I'm just doing it. When I'm having a bad day, there's not really a "deficit" either. I didn't suddenly lose the ability to focus. The number of things I'm thinking about hasn't really changed, it's just the coordination and how I execute those things is all fudged up.

I could honestly spend hours talking about the various ways that messes with my ability to get things done. It makes things difficult to follow up on (I use todoist to help with that), remember meetings (Google calendar), or even write code. But this blog post would already take me a couple of sittings to read through, so I'm gonna jump over to the hyperactivity part and go from there.

Hyperactivity. This one's oh so much fun. I've heard so many great ways of describing that part: "ants in my pants", "won't shut up", "can't sit still", etc. So if the ADD part of your brain is hitting you with thoughts at a rate that is frankly quite terrifying, what does the hyperactivity part make more difficult? That's right! Not verbalizing them. I was told a lot growing up that I didn't have to say everything that came to my mind. That always frustrated me, because I wasn't. That simply wasn't possible.

See with ADHD, almost every thought that comes across your brain feels important. But there's no way to verbalize them all. You might try, but it won't go well. A friend gave me a great set of rules a few months ago on this. It works well! When I remember to use it, that is. "Does what I say need to be said? Does it need to be said now? Am I the one who needs to say it?" And when I remember that, it works pretty well overall. It's a train wreck when I don't, but... I'm working on it.

I wonder what my goal even is with this blog post. I could spend hours telling you about all the things that can become difficult when I'm having a bad day. I could brag on my amazing team at Uber who supports me when I'm having one of those bad days, and tries to help me grow. But really, I just want to give you a perspective into my brain. I have this label, ADHD. I've been told that I shouldn't define myself by that label. But really, that label isn't for me. It was always for you. It was always for those who were trying to understand me, to understand my brain and others like me.

I've met many people with ADD and ADHD, and although we have our quirks, the amount of creativity and passion that can come from our minds is staggering. So please be patient with us. Understand that some days we're frustrated with our behavior too. I promise that we're learning and I promise that if you work with us, you'll learn too.

This has been another day and another step in my technological adventure. Follow me @jnesselr and tell me about yours. If you want to reach out to talk about ways to handle ADHD, please do! I may do a follow on blog post with more specific examples if there's interest.

Thursday, August 6, 2015

Thoughts on working and "working" on company time

It's been a while since I've done a blog post. A lot has changed since then: I've graduated from a university, moved, and started a job. A coworker asked me to type up my thoughts on working on things that aren't exactly work related to enhance your skills, the assertion being that any new skills could benefit the company in the long run. My first thought was "Hey, blog post!" and such this post was born/forged/hastily thrown together.


I've always been a fairly laid back developer in some regards and very much not in others. That's not a very descriptive way of putting it, so let me explain. I will take my shoes off, try to relax and write some code. I'll walk around and talk to other developers, maybe even playing a game of Go or helping with a jigsaw puzzle or two. I feel that environment helps foster creativity which is good for developers. Creating software is as much an art as it is a science. I like to compare it to writing an essay, in that an essay can be beautiful if it's well written. The problem comes when the most beautiful or "elegant" solution isn't the easiest to read. It may be the most concise which many developers have made the mistake of assuming is always the best. When we read a well worded essay, we skip over the part of deciding if it makes sense and immediately are able to see its effectiveness. The same happens when we design software. If code is well written, we can discuss high level concepts without looking at the gritty details. This is where I'm not laid back. I believe in continued refactoring and improvement. If a feature you're trying to implement doesn't fit perfectly, make room for it by first refactoring enough to create a nice place for it. If you're not sure exactly how the feature will work, you can always start with pure TDD, creating tests for it until it exists by itself or you understand exactly how you want to interface with this new object/feature.


I start with that long intro because I feel the background is necessary to show exactly why I feel the way I do. I believe that working on things that aren't strictly work related can be detrimental or beneficial,but it depends on both scope and attitude. Scope is referring to how closely related to your job it is. Writing doom to work on some piece of hardware may be beneficial if this piece of hardware is something your company makes that you need to support. You might learn a lot about the system that you would have never known beforehand that could be beneficial later. It would be like if you had been using a while(True) loop with a break statement based on some variable, but later found out there was this magical thing called a for loop. Your code would be cleaner because you decided to dig a little deeper into an area you were unfamiliar.

The same thing can happen if you want to learn a new language. You might learn a new language or framework (I'm currently loving the Haskell language and the Laravel php framework) which is beneficial to your way of thinking. Haskell has been useful for me because it allows me to see things as small modular and composable functions that can each be verified individually before being verified as a whole. Laravel has given me a new perspective on IOC and Dependency Injection that I would not have seen before. (Shout out to Laracasts for posting videos about testing and SOLID)

It's fairly easy to see if your scope matches with your company and your own objectives. Try and measure it from a scale of 1 to 10. If it's a 10, then it's highly cohesive and is a very good quick side project for you to experiment with. A 1 would be a project that's going to take way too long for it to be useful and has very little to do with what you're working with or plan to be working with.

The last aspect of this is attitude. Your attitude, or the reason for trying to do a project is a very good metric to decide on whether you should do it. If it's because you have a few spare minutes at work and you want to write a C compiler in Javascript (And by minutes I mean months) just because that's a thing that should exist (And I'm fairly certain does), then it's probably a waste of time.

Also, I am not responsible for you getting fired. Always talk to your boss first.

Thursday, December 25, 2014

BotQueue client updates!

It's been only a couple of months since the last software release, but it feels like it has been far too long. Instead of releasing 0.6, I'm releasing 0.5.1 today. There are two reasons for this, which I'll get to in a minute. But first, features!

Makerbot support

Or at least, mostly Makerbot support. It supports all of the printers that speak s3g/x3g, so no 5th generation (yet). There is also way to slice things. I have a solution for that, it's just somewhat difficult to work with closed source software. For now, you can upload your *3g files and it will run them just fine. It also allows you to upload .makerbot files, but those aren't supported yet.

Automatic updates

This is something I've wanted to do for a long time, and is the first reason why this only jumped up to 0.5.1. I released version 0.5.0, and in the very next commit, released 0.5.1. This was to test the auto update feature. Every 2 minutes, if your bots are either in idle, error, or offline mode, the client will check to see if there's another version. If there is, then it will automatically update itself.

This means that installing the client is now as simple as "pip install bqclient". To run it, simply run "bumblebee" in your command line. No more "python -m bumblebee" or similar schemes. Also, make sure you run it in the same directory that your config.json is the first time. It will automatically detect it, and move it to the correct directory. If it's not there, it assumes this is a new install, and will start to authenticate.

Future plans

Those aren't the only updates at all, but it's the two major points in this release. Many more features are coming soon, but I was having an issue. I needed to know that the client code and server code would work together. The easiest way to do that was make sure the clients take care of updating themselves. The caveat to that is that it might upgrade and break. If it breaks before the point it upgrades, then it will have to be upgraded manually. It also means that all clients would break at the same time, something I'm not exactly happy about.

Nevertheless, this helps with future plans, and moving to the 0.6 release, which will definitely contain some exciting new features. I hope to release much more often. I've been keeping the server within a few commits of the current master branch. There are some changes I can do that would break clients, unless they are up to date. I'd like to get some feedback, but I think I'm going to set a day in the future (some time next year) where the server will reject clients below a certain version. This allows me to make sure that add the cool new features that people want, without constantly asking that you update the clients.


Thank you for using BotQueue!

Friday, October 24, 2014

FTDI: The Clone Wars

I saw an article on Hackaday that talked about an FTDI driver update on windows that purposefully set the PID of the device to 0 on fake or 'cloned' FTDI chips. I've also seen a bit of confusion on this topic, so I'd like to clarify a few points.

First, what is FTDI? Basically, this company makes products that allow micro-controllers to communicate to a USB host, like your computer. The make both drivers, hardware, and most importantly here, chips.

1) Many people aren't aware if they even have a fake

One of the first arguments that I saw was in regards to how users should be punished for using a fake chip. Most of the people using these products are using end products, or products that are made using these chips. It's much easier for someone to include an FTDI chip with their device than to go through all of the trouble and cost of getting their own Vendor and Product ID. So, some devices have these chips in them without their users ever really knowing. This means that if the vendor accidentally or intentionally used a fake chip, then some end consumer could have a device break and have absolutely no idea why. It would literally just stop connecting to the computer.

2) This isn't a user mistake

The second most common argument that I'm seeing is asking why on earth any user would expect FTDI firmware to work on a non-FTDI chip. One person compared it to trying to sue Sony when your Sony TV knockoff stopped working. A user didn't re-flash their chip and mess up by getting the wrong firmware version, or putting it on a device it was never intended to. In fact, what updated silently and without warning was the FTDI driver on the host side. The FTDI driver itself checked if the chip connected to it was fake, and if so, it rendered it useless by changing the Product ID to 0.


3) This was intentional

Many people don't seem to understand how this could be intentional. One commenter on the Hackaday article asked how they could be expected to support all of the clones. It's not that they tried a new feature that only worked on the real ones but not the clones. The essentially initiated a challenge response protocol. The gave the chip some data or some set of data. The official ones would return one thing, the fakes another. After the fakes were identified, they were dealt with with extreme prejudice.

How does it work?

The FTDI device essentially makes a serial port through its driver. A USB device has several layers to go through. The first of which is a device descriptor. The descriptor has a lot of information on how to go through the layers, but most importantly, it has a vendor and product ID. The vendor ID is unique to the vendor, and the product id is unique to the particular product or chip. This attack sets the product id to 0 which makes windows fail to acknowledge its existence. A product or vendor id of 0 is considered invalid, so it will no longer be recognized by the computer much less the drivers.


I hope I've cleared up a little bit regarding this issue. My opinion is that it might have been better to give a small alert to users letting them know that their chips are fake. I don't think it was within their rights to destroy peoples' products, mostly because they were not aware they were using a fake chip. However, even if they did know they were using a fake, I still don't think that they should have morally done that. As far as market share goes, it might be a good decision, it might not be. The answer to that will lie in whether people keep buying their products after this.

Tuesday, September 9, 2014

Setting up Bumblebee to run on boot

BotQueue's client code no longer requires there to be a tty to function. You could simply add a line in your /etc/rc.local file to run bumblebee as your user:
( su -c /home/user/bumblebee user ) &
the /home/user/bumblebee file would just be an executable that runs the python code. An example:
#!/bin/sh
cd ~/Bumblebee/
screen -dR botqueue python -m bumblebee
It's a much simpler process than previously. This should work exactly the same on a raspberry pi too.

Monday, September 8, 2014

BotQueue 0.5 released!

I know it's been quite a long wait since version 0.4 was released on July 4th, 2013. Since that time, Zach Hoeken has moved away from supporting BotQueue in code, but he still believes in the project and has continued to help whenever possible. For that support, I want to thank him. Now on to the fun stuff!

I'm so excited to release this for a couple of reasons. The main one is that this is my first major software release, so I expected it to be a bit rougher. Still, I expect bug reports in the future, so please post those here for the server, and here for the client.

I was originally going to summarize every cool now feature about this release. This release doesn't have too many amazing new features, but it has quite a few bug fixes. I wanted BotQueue to be more solid than ever, because that's what you should be able to expect. This involved fixing everything from UI issues, to a ton of fixes in the background so that everything runs smoothly.

Some of the new features I'd like to introduce are:

Auto Slic3r downloading

It's not perfect yet, but it's definitely pretty awesome. Basically, instead of downloading a bunch of huge binaries, bumblebee has been stripped of any extra weight, making it fast to download, and easy to run. It will automatically download the slic3r version you choose for your OS. This also makes it easier to run other types of slicers like Cura.

Local storage

It's long been a request to support storing files locally on the server instead of having to set up Amazon S3. I'm glad to announce that this support now exists in BotQueue.

Easy server install script

Now, it's pretty easy to run install/first_boot.sh on your debian/ubuntu server. It will ask for some configuration values, and install everything it can for you. If the options are filled out correctly, your site will pop right up, giving you your own BotQueue instance. This is useful if you have a private university and want the students to use a local server.



All in all, I hope you enjoy the new release. If you have any questions at all, feel free to comment here, or ask on the Google groups.

Monday, April 28, 2014

DSLogic unboxing

Today, my DSLogic came in the mail. For those that don't know about it, it's a logic analyzer with the ability to act as an oscilloscope and a DAQ.

Here are the unboxing pictures for those that want to follow along with this review. Note that I haven't actually gone and analyzed anything, so that review will come later.

The first thing I noticed is that the box that the logic comes in looks nice, but isn't going to make a nice case for it at all. I would have rather had a nice case that all of the probes and everything would fit into that I could carry around. It has four phillips screws on the bottom, so if anything goes wrong with it, at least the case is openable. There's a little hole for an LED, that really needs a lightpipe because it's down inside the case. I'm sure it will still be visible, just not diffused as well.

After seeing some other reviews,  I checked the cables to see what they meant by the poor quality. I hate to confirm that they're correct, but they are. The wires are very thin, and seem breakable. I know that eventually some of them are going to break.

I really am not fond of the clips. The first thing I noticed is that the part where the wire attaches isn't only in the center back of the clip, but that the pin was at an odd angle. After bending it back, it hooked on decently well, but not as well as I'd like. I prefer the pin to be off to the side of the clip so that I can press on the clip with my thumb completely. Also, in the last picture, I notices that the probe uses more of a claw mechanism, rather than the hook that I've seen on previous probes, so I don't think it will hold onto the pins as well.

That's all for now, but I'll add more posts once I start using it.