Dev Bootcamp: Phase 2, Week 2

Last week was the most difficult week DBC has to offer, or so they say. I can attest that it was massively challenging, and this week was no cakewalk either.

Monday - All I need is a break

We had our weekend code reviewed today. The session was positive and encouraging. We got some valuable firsthand experience on Big Design Upfront (BDUF) vs. Agile. The short version is that BDUF is only viable if you have large amounts of time and money to spend ( as is often not the case ). With agile development, the idea is to have a functional solution at each stage of development. Speaking from experience, it’s more fun to improve upon a simple something that works than to build a more complex something that may not.

Today we covered basic javascript and relaxed a little. Some of us went to EscapeTheRoom - Spaceship Edition and managed to solve all of the riddles and puzzles before our hour was up. Apparently only 25% of groups ‘escape the room’ in 60 minutes … go team Fireflies!

Team photo

The Happiest Nerds on Earth

Tuesday, 6:11 PM - Somehow, still moving forward

I am beat. I’m an introvert, and I din’t get my prized solo time this weekend to recharge. It’s starting to get to me. JS/JQuery is not nearly as difficult for me as Sinatra was. We’re learning AJAX tomorrow, which is JS’ version of Sinatra, so I expect to be lost once again in the seas of binary. Most of the cohort is dragging, so I don’t feel too bad about my energy level.

TIL: “We have this problem, as people. To find an answer, we first need to know the shape of the answer, or else how will we know we have found it?” - S.Harmes, teacher extaordinaire. As a new web developer, if I’m going to ask a more experienced person a question, I need to do the work to determine what I think the shape of the answer will be. If I do this, my chances of receiving effective assistance will increase exponentially.

Wednesday, 12:48 PM - Why DBC?

JSYK, this is going to get a little personal. Everyone has a story, and this is mine.

I didn’t decide to come to Dev Bootcamp for the reasons you might think. I applied to this program, made the choice to invest myself in it, because I had lost touch with meaning and happiness in my life. This program advocates ‘whole self’, and it’s been pulling me in. I know my challenge will be to build a community like this for myself when I graduate the program. Perhaps I will chose to stay, to integrate myself into the NYC tech community. What I know for certain is that I’m going to enjoy this time I have where I get to put in as much effort as I like, and still feel as though I belong.

Along a similar vein of thinking, I took this fun strengths assessment quiz and discovered that, included in my top 5 strengths are: Appreciation of Beauty & Excellence, Curiosity, and Perserverance. Given this, I think I would excel in a front-end development role where the projects rotate every few weeks / months. I’m entirely optimistic about my chances of finding such a role, post-graduation.

We learned ajax today - asynchronous JavaScript and XML. I found Sinatra to be incredibly challenging. Now that I’m used to thinking about http stuff and routes, ajax wasn’t so bad. It helps (so much) that we had an instructor to break it down piece-by-piece, and allow/encourage questions for each bit.

In EE today we did “Difficult Conversations.”

What I took away from the experience was that receiving feedback (even ‘difficult’ feedback), when it’s presented in a specific format, can be very helpful. The format they gave us: 1. What happened? 2. How you felt. 3. The ‘ask’.

I learned that I need to slow down, always consult with my pair before asking a coach for help, be deliberate about asking my pair my questions first, instead of assuming that they do not have the answer. Verbalize when I’m feeling stressed, or challenged, or whatever, so that my pair knows it’s not anything that they’re doing that’s making my behavior seem ‘off’. Basically, slow down, share more, be considerate, and trust that my pair is a smart, capable human being. Good, actionable feedback to work from. What made this feedback so effective, was that the people giving me the feedback were sharing their feelings. I don’t want to cause anyone annoyance, or irritation, and so I’m motivated to address my pairing style in a way that I would not be if the feedback had been conveyed in another way. I can envision myself saying at some point in the near future “Hey, I know that when I’m tired, I tend to be a less considerate pair. Could we stick to the traditional driver/navigator roles so that we have one less thing to worry about?” Now that we’ve had this conversation amongst the group as a whole, I could give feedback to anyone, should the need arise, and I know that they will listen.

We did improv today! It was hilarious. Great team building activity. Highly recommend to all teams, everywhere.

Friday - The Happiness Advantage

Friday I learned about cargo-cult programming in the context of $(document).ready. The idea is not to use code unless you know why you’re using it.

Our ‘mock assessment’ for phase 2 was cloning hacker news. we literally built a whole website in less than one day, as individuals. It amazes me how far we’ve come in just a few weeks.

Something I heard in a TED Talk: “Every moment of high human potential occurs in the midst of stress, not in the absence of it” -Shawn Achor. This program is very stressful, but it’s also full of meaning and social connection. It’s the best.

This is how we learn here: we fail at a thing to understand it’s contextual importance and to become more confident in dealing with failure. It’s a brilliant teaching strategy, and I think that everyone here will reap humongous benefit from it.

Saturday, 3:26 PM - The Weekend Project, Take 2

I learned a painful lesson just now. I was trying to use flash errors, and I just assumed that I knew how to use them. Turns out I needed to add ~3 lines in my gemfile and environment before using. Step one was narrowing down the issue to a single line using debugger & binding.pry, then googling, then talking to my team. Next steps would have been talking to a coach, and then talking to an instructor. Thankfully, I was able to solve the problem before getting to the top of the chain. Hooray debugging!

I wrote out all of the above in case I need it in an interview question …

Final Thoughts

What works?

  • Seek out what inspires you. There’s so much the world has to offer.
  • Believing that I could solve the error.
  • Naps Forever!

What doesn’t?

  • Letting the belief that I could solve the error get in the way of asking for another perspective.
  • Getting frustrated and walking away. A better strategy is to slow down and dive in. I’m starting to understand that ‘lean in’ thing that people talk about.