Sorry, I lied. We're going to talk about ADHD and coding

 

Every time I have a medication change, I watch season 2, episode 6 of Bob's Burgers. There is something about the way Gayle barges in with "Guess who's on new meds!" that gets me every time. Perhaps it is because of my own medication history. 

I haven't discussed it much here, but my genotype does not play nicely with most medications. They either don't work at all or give me horrific side effects. For most of my life, I felt like I'd been duped. I was Georgie looking at Pennywise in the gutter, but instead of promises of a paper boat, I was told I could function in neurotypical society. 

 

I didn't lose an arm or my life, just my physical health and all hope of behaving like a Normal Human Being™. After several years and two seizures, the GeneSight test rectified this for me and revealed the two medications that could treat my depression/anxiety and behave as expected.

What does this have to do with coding? In December, I had the privilege of adding ADHD to my long list of diagnoses.  Unfortunately, GeneSight does not cover the drugs that treat ADHD, so my healthcare provider and I are stuck playing the guessing game of what will actually work. 

We tried Strattera and I became like a sleeping dragon with extraordinarily high blood pressure. After work, I'd crash in my bedroom and annihilate anyone who bothered me. I use the term "bother" very loosely, as it was mostly my dear husband checking in to bring me food and ensure I was still among the living, bless his heart.  

Now I'm trying Adderall and hoping it will help my poor working memory. Working memory is what most people think of as short-term memory. While most people may be able to listen to instructions and immediately put them to use, I cannot. It has nothing to do with paying attention, it's that my working memory is so bad, I have no recollection of what I was just told. It's the same reason I may read a sentence or paragraph over and over again and have no idea what it said. 

Needless to say, this is a problem I am learning to navigate in my coding career. A lot of coding is reading, whether it be in the form of language documentation, proofreading your code, or deciphering another person's. 

My brain hates this. It causes me to make a lot of basic mistakes and I feel especially stupid when other people notice them (which happened a lot today). Here's how I'm managing it:

• I chose to stop telling myself that I am stupid. Why? Well, it isn't particularly constructive and I'm not stupid. I got here despite my ADHD, which is awesome.
  
  
• Write down everything. I do my best to keep a written record I can refer to. It isn't always helpful because I like to get hyper-focused on one thing and may forget finer details, but it's better than nothing.
  
  
• I told my boss. If you're comfortable with yours, this may help you, too. I explained that I'm in treatment to find a medication that works and I was worried people may mistake my crap working memory for not listening/caring. He was super cool and understanding about it. This helped ease my anxiety because I knew especially with the medication change that I'd be prone to leaving seemingly careless mistakes.
  
  
• Read things out loud. It will help you slow down and give you more time to process. This is especially helpful if you're facing a wall of text that looks like a blur. I will highlight with my cursor as I go along to help keep my place.
  
  
• Stop being embarrassed. This is a hard one, but when you find yourself making obvious mistakes, it is best to correct them and move on. There's no need to be constantly apologizing or explaining yourself. Your identity should not be rooted in what others think of you because people's opinions are unstable and constantly changing. You need to find your security in something immutable. 

So, that's why I haven't posted. I study a lot in a vain attempt to make up for my goldfish memory and I've been struggling with medication side-effects. 

All of that being said, I do feel optimistic. Despite my ADHD, I got through college and coding bootcamp. I can recall feeling overwhelmed/making "dumb" mistakes at previous jobs, only to excel with repetition. 

P.S. If you're struggling, feel free to reach out! I'm always happy to talk. If you also have a mental disorder, please know that you CAN  still achieve your goals! You may be wired differently and have to work harder than the average person, but it can happen! With every accomplishment, you can feel proud that you did it in spite of what can often feel like an impediment! (Disclaimer: It took me 29 years to realize this, so don't worry if you're not there yet.)

 

10.3: Behavioral vs. Technical Interviews

Prior to Tech Elevator, I didn't know there were multiple types of interviews. Software developers typically have to deal with two: behavioral and technical.

The basic goal of a behavioral interview is to prove you are not a sociopath. This is what the average person usually thinks of when interviewing is mentioned. It goes kind of like this:

1.  You sit in a tiny room with unfamiliar people and they may offer you a beverage. If you are me, you always decline because you were taught from a young age to not accept food from strangers. 
   
   
2. They will then proceed to ask you a bunch of questions about your strengths and weaknesses. You must come up with a way to answer these without seeming like a narcissist or woefully incompetent. 
   
   
3. They will ask if you have any questions for them. The answer to this should always be yes. Come equipped with at least two, but no greater than four. For the love of all that is holy, do your research and ensure these are insightful and not salary related. 
   
   
4. You will leave and cry in your car, wondering if you bungled the opportunity of your dreams. 

All jokes aside, one of the most valuable things I've learned from Pathway is you are interviewing the company as much as they are interviewing you during the behavioral. I know a lot of us fresh out of cohort will be itching to accept any job and that may be okay considering COVID-19 and the fact most of us have quit our jobs to take on bootcamp, but in general, we shouldn't. 

Know what you want from a company in advance. Are benefits important to you? What about company culture or how they give back to the community? Do you want to work for a start up or a more established company? 

Personally, I am very concerned with company culture. I value a work environment in which people are respected and harassment/discrimination is not tolerated.  It should be inappropriate to comment on someone's body or start screaming at them for no reason. If there are rules, everyone should be held to them, no matter ranking or status. Failure to comply should be met with accountability. 

The above may sound like I'm being a overly sensitive, but I have stories that will make any person with an ounce of empathy cringe, including one in which, as a teenager, I managed to acquire a stalker and no one cared, but we can talk about those in another post. :)

I know I want a 401k or something similar because I have no retirement to speak of whatsoever. I'm worried that I will be 85, on my deathbed, and still reporting to management. 

So, what do you want? What do you care about? Keep those ideas in mind and decide which ones are dealbreakers and which you're willing to compromise on. 

Now that we've discussed behavioral interviews, it is time to talk about the unfamiliar beast that is the technical interview. Technical interviews are meant to ensure you are not a fraud. You will be expected to demonstrate your knowledge of coding and may even be given a kata to solve. There is absolutely no standard for these and you may even be given a technical by someone who knows nothing about coding. 

I will be honest with you: we had mock technicals a couple of weeks ago and several people cried. They can be overwhelming, but with a bit of practice, allegedly we will become comfortable with them...allegedly. 

Tips on acing a technical will go in my next post, as we've already covered quite a bit.  At this point, I've done both internal (to TE) and external mock interviews. I wasn't asked to code for either of them,  but here's one bit of advice I'll leave you with: Review your vocabulary. You may be the greatest developer in the world, but if you can't explain your code, people will fail to see how awesome you really are. 

5.4: Why Can't I Git It?

I feel like a girl who dies in a horror movie. Not the first one --the one that is typically offed because...well, slut-shaming, but the second. 

The Second Girl is blissfully unaware of the imminent trauma. She is busy working at a hip coffee shop alone at night, hiking, or being a good friend to The Final Girl. Basically, the kind of stuff that would make a great medication commercial if played in a series of short clips with an uncomfortable smile. 

Second Girl is just trying to live her life and then she gets knifed or eaten. She takes out the trash and ignores the faint scuttling from behind the dumpster. Then poof. Gone. 

That's how I feel. 

I'm overwhelmed and second-guessing myself. There's a voice in my head that tells me I'm too stupid and might as well quit. Java is the monster and the program being executed is me...sorry, that's a bad joke and the analogy breaks down there.

I'm telling you this because I want to represent an honest look at what coding boot camp is like. It's not always easy;  there's a reason why Redrum is one of my most popular posts to date. 

So, what set this off today? I had an issue with an optional exercise and went to my instructor for help. He explained some things but when I went to implement his instructions, my code still didn't run and so naturally I assume I am dumber than the troll in the girls' first-floor bathroom. It is late and I am too ashamed to admit to him I didn't understand his instructions, thus the natural decision was to admit it publicly to a bunch of strangers. :)

I will play around with it more tomorrow after some rest. I didn't really get to stop coding today, so I'm feeling fried. If I don't figure it out, I'll swallow my pride and ask again because I really care about learning this stuff.

Just an FYI: I know that this shroud of despair and self-doubt will pass. I will be able to look back on this post with a feeling of accomplishment, just like I do with Redrum. Eventually, I understood how to use loops and arrays. The same will happen for this concept, too. 

~~~~~~~~~~~~~~~~~~

TL;DR: Coding boot camp is hard. You will have bad days. It gets better. 

5.1: I Was Publicly Wrong and Didn't Burst into Flames

Fear and pride are two things you need to get rid of if you're going to be a (happy) software developer. 

I don't know why, but for whatever reason, I have a deep-seated need to be correct. Perhaps I think my value comes from being right all of the time or fear others will think I am stupid, but it's there. This desire for perfection has made me terrified of answering questions in class. If I am wrong, everyone will know and my value in their eyes will be diminished. 

Guess what? It doesn't matter. 

Today, I awkwardly offered to try a problem in front of the whole class. We are learning how to select things with SQL in DbVisualizer. I got most of it correct, but floundered on further refining the data, which rendered an error. 

I did not burst into flames. 

It was seriously okay. Maybe I've grown since college, but I didn't mind being wrong. Brian didn't make a big deal out of it either and showed me how to fix my mistake. 

I didn't feel like my classmates were judging me and if they were, that's on them. By taking a chance at being wrong, I got a learning experience. I won't make the same mistake in the future and hopefully neither will anyone else who may have been confused about the same thing. 

Life gets easier if you don't take yourself so seriously. Correction is a good thing; it allows for improvement. Remember that you are not your code and your value as a human being is not linked to it. Even the best software developers have to Google things and need help. :)

2.3: Find Your Coding Bootcamp Learning Style / What to Do With Your Body During Lectures

Think about the last time you were in school. How did you best retain information? 

Some people may:

• Take notes (typed or handwritten)
• Fidget
• Sit there and do nothing (listen intently)
• Practice the concepts while they're being taught

There's no right or wrong answer, but for coding bootcamp, you may need to adjust. 

For example, I like the tactile feeling of handwritten notes, however, material is covered so quickly, I frequently get behind.

If I don't take notes, I need something else to do with my hands, lest destruction ensues.  I will absentmindedly pick at my fingernails until they bleed. Sound gross? It is and I am, but I have the feeling you can relate (I'm looking at you, America, who needed literal hand washing instructions at the start of the pandemic). 

So, if handwritten notes are out for me and so is sit there and do nothing, what can I do? Well, I'm still trying to figure that out. I've currently settled on a combination of typing notes, fidgeting, and practicing concepts while they're being taught. 

I feel like that's fine enough for the lectures, but my retention isn't as good, so I will probably have to go back and copy lecture slides by hand. This is annoying, because it seems like even more work, but it is how to get the information to stick. 

You may have to play around and see what works for you, too. 

As for what to do with your body during lectures:

• If you fidget, be discreet and quiet! There's nothing wrong with fidgeting, but make sure your hands are off camera or under your desk. You don't want to distract other students.
• Don't lie down in bed on camera. It is weird. 
• Make sure your body is appropriately dressed before getting on camera
• Standing up/stretching is fine in casual settings. 

Also, because we are all human, there will be a point where you just can't pay attention. Maybe the teacher is progressing too quickly or you have sleep deprivation or personal issues; it doesn't matter. 

Make a note to yourself about the topic before you zone out so you can catch up later. Try to pay attention enough to list any other topics being covered so you don't miss out. Then, this is the most important part:  REFER TO THOSE TOPICS LATER when you are in a better state of mind. 

Lastly, if you're curious about what we covered in class today, we focused on maps, sets, and algorithm problems. Most of it was very interesting, but algorithm problems is where my brain decided to tip its hat in farewell and hop off the wagon. I will have to review those concepts later tonight. ;)

Note: From here on out, I'm going to reference the week and day in this format:
Week.Day
so 2.3 is Week 2 Day 3

Week 2: Day 2: Squeaking Out Questions

Brian is really good about pausing to ask if we have any questions. 

The problem is, I am still learning how to be comfortable talking on Zoom and am afraid to ask any. 

Well, I am proud to report that today I did ask a question! I was awkward and squeaky, but did not die from it. 

Please learn from my thought process:
1. Your instructor is there to help you.

2. You're receiving a ton of information! It's okay if you missed a bit and need clarification. Don't worry about whether or not other people think you're stupid.

         a) Most likely someone else also had that question
         b) Review benefits everyone
         c) On the off chance they think you're dumber than Victim #1 in a horror movie, so what? It's               not like you want to hang around people like that anyway.

3. Everyone in my cohort has been incredibly supportive and awesome. I'm honestly not too worried about c). 

4. If in some alternate universe, everyone in my cohort was judgmental and mean, so what? I'm here for me. I want to learn about software development and the opinions of others shouldn't affect that.

I mention this in case one of you lovely readers is going through a bootcamp or considering it. Don't let fear hold you back! 

Another quick note: 

I often talk about how hard this program is, but you want to know the truth? 

I've never been happier. 

It is hard, but I absolutely love it.  

I enjoy the difficulty. 

It is exhilarating to spend an hour on a program, research what's going wrong, and finally solve it. I enjoy running tests in Eclipse and seeing "Failures: 0".

End of Week 1: I Am Just a Husk

 Scenario:

I am at my desk immersed in correcting my homework. What did I miss? Probably left out a bracket or semi-colon because life is a sick joke and if you miss just one of those symbols, it throws the whole program off. 

I hear the crescendo of footsteps drawing closer. The door creaks open and then the dreaded words:

"Whatcha up to?"

"NOTHING, MIKE. JEEZ!" I reply without looking up from the computer. Suddenly, I remember that is a human being that I am talking to and not the Charizard I "rubber duck" with. 

Snapped out of work mode, I am suddenly filled with shame. I turn to my wonderful husband of eight years and say, "Sorry, Mike. It's been hard. Just doing homework. Oh, and happy birthday!" 

Week 1 Summary: 

Tech Elevator was not lying when they said the program would be time intensive. I don't go to bed until around 1am most days. While the scenario above has been slightly embellished, it is fair to say that I don't have nearly as much time to spend with Mike and my friends. I know it's only temporary, which helps. Plus, you just can't beat the thrill of struggle busing through code until you finally find a solution that works. 

I feel very lucky. My instructor, Brian, is not monotone and comes up with great analogies that make concepts like loops and arrays easy to understand. On Friday he included a very helpful bit about peer programming etiquette and assigned us our first partners. 

I was extremely nervous about starting peer programming. My fear is that I don't know enough and will be deadweight. Thankfully, Ross, my partner, seemed to be in the same boat and was incredibly patient and up for trying anything. For the final exercise we were searching Stack Exchange and Googling different ideas and plugging them in until something worked. One of our classmates, Christina, also swooped in to help and gave us a fresh way to reconsider our code.

It's been hard, but tons of fun. 

Some practical takeaways:

• "Rubber ducking" is the practice of explaining code to something that doesn't talk back. It really is helpful for recognizing errors.
• I took a writing class in college where the class mantra was "kill your darlings". Basically, it means you shouldn't get too attached to what you write; there will always be something better or a way of improving it. You are not your writing. Don't take criticism personally or be afraid of throwing things away. The same principle applies to code. 
• Step away from the computer. Take a break every fifty minutes or so. If I'm feeling really frustrated, I will go to bed and tackle things again in the morning. It's like flipping a switch; I wake up and suddenly everything clicks.