Hi, my name is Trevor.

Dev Bootcamp always stood out to me because of the culture and approach to learning that the program seemed to be centered around. After my first week of Phase 0 at DBC, I've definitely felt great about my decision to attend. From what I've experienced so far, Dev Bootcamp is culturally very similar to what I expected. All of the other members of my cohort seem to be very smart, driven, and open to help others. Phase 0 has certainly been more structured and involved than I was expecting. I was assuming Phase 0 would be more akin to long term homework that was more self-paced, though it became quickly apparent that my learning progress would be pushed even before I started the on-site portion of Dev Bootcamp. I've realized that I need to be much more structured and intentional with Phase 0's curriculum in order to be able to keep up and make the most of this time before the on-site intensive begins. While there's definitely a part of me that's nervous about the fast-paced learning that's to come with Dev Bootcamp, I'm really excited to get started on week 2!

After a rushed start getting my enrollment finalized and accidentally bricking, then eventually fixing, my computer's wifi trying to dual boot Linux, my first week of Dev Bootcamp's Phase 0 is coming to a close today. So what've I learned so far? Can I program leftove.rs, Silicon Alley's hot new app (it's like airbnb but for food)? Did I write some sweet-ass code that allows anyone to download puppies from the internet for free? Sadly, there's no downloadable puppies yet- this week at DBC was devoted to learning the command line and version control. You're probably thinking "command line and version control don't sound like the sexiest of subjects". Valid point. Also, incorrect. Here's what I've found makes git and bash both totally sexy from an education standpoint.

First things first- the command line is totally awesome. At first, I had been apprehensive about ever using the command line. Pointing and clicking around folders and files was A-OK by me, and using the command line always seemed so inefficient. Dev Bootcamp forced me to actually learn it, instead of blindly copying commands from tutorials like I had been doing, and I completely love it now. While I still have a lot of work to do before I can claim to be a command line power user (or even mildly proficient), I understand why trying to program only using the operating system's GUI is downright silly. There's nothing quite like being able to zoom around your computer's directory structure, edit things and run scripts without having to touch that damned mouse. One of the major reasons I think that touch screen computing has become so popular is because of their tactile nature- you poke something; it does something. There's seemingly less of a barrier between you and the computer. Using the command line is one step further than this, where you're totally connected to and in control of all that cool stuff your computer is doing.

Version control is another topic that probably doesn't get the masses up on their feet. Although saves were a great way to keep playing videogames by "ok-i'll-get-ready-for-bed-at-the-next-save-point"-ing, saving isn't generally all that exciting. What makes version control and git any different? Version control is sexy because of how beneficial it is developing software. From playing with git this week, the obvious benefit to using version control is being able to "roll back" changes to software so that you can undo any whoopsie-poopsies in your code. Git, more specifically, seems like it would be really invaluable when joining a new software project that has already been in development by allowing you to get a rough understanding of where the project has been and where it's going. Git makes this easy by keeping a log of all the changes made to a piece of software. These changes are grouped together into commits, which allows software engineers to track changes in a meaningful, logical way. For example, if fixing a program's bug requires edits to 3 separate files, these separate changes can be grouped into the same commit and labeled in git. This allows a programmer to review and understand the meaningful changes that have been made to software. The thing that really makes version control systems sexy, though, is that they embolden developers to try new things. By making reverting changes so easy, being experimental with your programming is a lot less scary. It seems that version control is a major driver of innovation by allowing programmers to make big changes to software. Finally, version control is important because of the collaborative nature it sends itself to. Without version control, developers would constantly be overwriting eachother's work. That would probably make for a fairly tense work environment. GitHub takes git as it's foundation, and allows users to share their code online, so that others can benefit from your good ideas while also helping improve your software.

The week 2 curriculum for Dev Bootcamp has been focused on foundations in HTML and CSS. While I've had quite a bit of previous experience with HTML, I've really relied on hacking my way through a CSS stylesheet with past projects. After this week, I feel much more confident styling HTML with CSS, and am looking forward to applying my new CSS skills on my next project. What makes CSS so important for web development is that it allows you to "beautify" websites at scale, instead of changing the styling for each HTML element separately. Two important CSS concepts that are required for styling websites at scale are ids and classes.

Ids and classes are so important for CSS and web development, because it allows web developers to add styling to specific types of elements (classes), as well as specific HTML elements uniquely (ids). Classes and ids are both set by adding them to inside of opening HTML tags:

			          		
<div id="id-name">
	<h1 class="class-name">Some Text In HTML</h1>
</div>
			      			
			  			

In the above example, "id-name" and "class-name" can be set to any strings of text you would like, and are used to identify classes and ids for styling to be applied to from the CSS file. This example's CSS might look like this:

			          		
#id-name {
	color: red
}

.class-name {
	background-color: blue
}
			          		
			          	

You'll notice that id selectors in CSS are preceded by a "#", while a class selector is preceded by a ".". Any CSS styles between the following brackets will be applied to an HTML element with the given class or id name.

If classes and ids both can be used to add styling to specific elements on a page, how can you decide which you should use? Here's some common guidelines to follow when planning an HTML page's classes and ids.

• Use a class for styling that will apply to multiple elements on a page. Ids should only appear on a given HTML page once, while classes can be attached to as many HTML elements as the web developer wants.
• Use an id to add styling to a unique element on the stage.
• Use an id if you want to be able to add an internal link to a specific piece of content, or if it would be valuable for your site's users to link to a specific spot on a page. This can often be really helpful for evergreen content where there is a large amount of content on a page that is split into sections.
• Use an id for layout items such as a page's header, navigation, main content, and footer.
• Use both ids and classes in the same HTML element when necessary. The class will allow a single CSS change to apply to multiple elements, while any specific styles for a given element can be set using the id.

Properly setting up an HTML document with ids and classes initially can be a huge help when applying styling to the page and help keep your CSS code efficient and readable.

Week 3 of Dev Bootcamp Phase 0 was a crash course in the foundations of ruby. Exercises for the week covered variables, condition statements and methods, as well data structures. Data structures are an incredibly important element of programming that allow computer programs to organize data for a specific process. Using data structures in a program allows for data to be accessed in a predictable, standardized way and is one of the central concepts in programming that allow for efficient, reusable code.

One of the most widely used and important data structures is called an array. The word "array" sounds a whole lot more daunting than it is- an array is basically just a list of objects that your program can access through a single variable name. The beauty with arrays is that they allow a program to run the same code on a list of objects. This is commonly called a loop, and is invaluable for writing efficient, easy to manage code. Say, for example, you wanted to write a program to print out your favorite albums from 2014. Without an array, you would need to do something like this:

			          		
print "Ryan Adams - Ryan Adams"
print "The Flesh Prevails - Fallujah"
print "Conquering Dystopia - Conquering Dystopia"
print "Voices - Phantogram"
print "Morning Phase - Beck"
print "The Physical World - Death From Above 1979"
print "Once More 'Round The Sun - Mastodon"
print "They Want My Soul - Spoon"
print "What Is This Heart? - How To Dress Well"
print "Singles - Future Islands"
			      			
			  			

My outstandingly impeccable musical taste aside, see how verbose that is? Now think about if you also wanted your program to print out the top 10 movies and plays. There's a lot of code for a seemingly simple end goal. Now, if all of these album titles were stored in a list, our code could look like this:

			          		
top_albums_2014 = ["Ryan Adams - Ryan Adams",
                   "The Flesh Prevails - Fallujah",
                   "Conquering Dystopia - Conquering Dystopia",
                   "Voices - Phantogram",
                   "Morning Phase - Beck",
                   "The Physical World - Death From Above 1979",
                   "Once More 'Round The Sun - Mastodon",
                   "They Want My Soul - Spoon",
                   "What Is This Heart? - How To Dress Well",
                   "Singles - Future Islands"]

top_albums_2014.each do |album|
  print album
end
			          		
			          	

Quite a bit cleaner, right? But what if we want to be able to add more info about each album, like the release date, genre and and a link to the band's website? While you could do this in arrays, it would be kind of messy. Arrays are really good for listing out the same kind of information, but aren't really effective when it comes to combining different types of data, because there isn't a meaningful way to access objects in an array besides their sequential order. This is where hashes, sometimes referred to as dictionaries in other programming languages, come in handy. Hashes allow for data to be labeled using a structure of key: value. Here's what a hash might look like for one of the albums in my top albums of 2014 list:

			              
the_flesh_prevails = {'album'=>'The Flesh Prevails',
                      'artist'=>'Fallujah',
                      'genre'=>'Technical Death Metal',
                      'website'=>'http://fallujah.bandcamp.com/'}
			              
			            

Now for the cool part- you can combine a list of these hashes into an array and loop through this array of hashes, accessing specific pieces of data as you go. Nerd-rad! Here's an array of variables that link to a hash like the one above, and the code needed to print this data:

			              
top_albums_2014 = [ryan_adams, the_flesh_prevails, conquering_dystopia, voices, morning_phase, the_physical_world, once_more_round_the_sun, they_want_my_soul, what_is_this_heart, singles]

print "Trevor's Top Albums of 2014"
top_albums_2014.each do |album|
  print "Album Title: " + album['album']
  print "Artist: " + album['artist']
  print "Genre: " + album['genre']
  print "Website: " + album['website']
end

			              
			            

Pretty cool, amirite? Using data structures like this ends up being kind of similar to how websites generate dynamic content, such as Facebook displaying your newsfeed. The newsfeed could contain a list of your friends posts (arrays), with each user's name, profile picture, status update ect... contained in a hash for that newsfeed post.

Besides learning web app development at Dev Bootcamp, one of the other focuses of the curriculum is for students to understand how they learn best, and to develop this as a skill. As part of this component of Dev Bootcamp, we learned about Gregorc thinking styles, a theory developed by Anthony Gregorc which seeks to classify people into one of 4 thinking styles. After taking a Gregorc thinking styles quiz, I found that I am primarily an "abstract sequential" thinker. This thinking style is biased towards enjoying when their point is heard in a learning environment, as well as enjoying analyzing situations thoroughly before making a decision. Because I'm an abstract sequential thinker, I also learn best when I have access to experts and am learning in stimulating environments.

My experience so far in Phase 0 at Dev Bootcamp has strongly aligned with what I've learned about my thinking style. I've learned a lot during each of my guided pairing sessions and have really enjoyed them, most likely because I had access to an expert during the sessions. I was able to dive deeper into the material and ask more theoretical questions, learning more about the "why" instead of just the "how" for specific learning concepts. I plan to take full advantage of this by asking questions more during my guided pairing sessions that will help me understand concepts at a deeper, more abstract level.

My learning style has also become apparent during Phase 0 in my struggle with managing my time. Because I really enjoy learning in a very detailed manner, I have often devoted too much time to challenges that I already understood sufficiently. I'm also very used to less structured learning with less specific rules, due to learning to program on my own for the past year. Learning through structured curriculum is important for me, because it is forcing me to learn in new ways and learn concepts I'm not completely interested in initially. Due to being too detailed in my learning habits often, I've been attempting to time box myself using the pomodoro technique. I've struggled with respecting my initial time boxing, though I've progressively become better at this. Outside of this, I think that the biggest opportunity to grow my personal learning competencies is to try developing my learning style more towards the abstract random learning style, specifically the focus on relationships in learning.

In the past decade, the tech industry has amassed an astronomical amount of data, and it doesn't show any signs of slowing down. Tech giants like Apple and Google are building more and more shopping mall size data warehouses every year to accommodate the tidal wave of data being collected. A large majority of your actions, whether it's shopping online or taking the train to Brooklyn, is leaving behind a trail of data. While this data has already made a meaningful positive impact in everyday life, there's a tremendous amount of opportunity still hiding in data right in front of the tech industry's nose.

The problem with this massive amount of data the tech industry is sitting on is that it still doesn't know (or simply doesn't) analyze a large amount of it. What's more, the sheer volume of data can make it difficult to strip away the noise to find meaningful data. Picture an old chapel with multiple choirs, each singing a different hymn. Each choir performs beautifully in their own right, but their voices echoing against one another produces a chaotic hum that is undecipherable. There may be a brief moment where you can hear one song with clarity as the other songs are at rest, or the choirs may briefly unite in a musical chord for a note, only to go back to the chaotic hum. This is similar to where big data is today. Insights can be gained from isolated data like the moments when a single choir was singing. This misses a lot of the most significant insights that can be found from looking at data more broadly. Techniques like predictive modeling allow for the voices of the choirs to to be aligned briefly to make a chord, but a majority of the song will still be that chaotic hum.

This big data problem has been caused by the tech industry approaching data with a “data first, meaning later” mentality. If data is not meaningful, all it does is dilute any data practices. While advanced data analytics techniques are making it easier to cut through the noise, more attention needs to be placed on data collection by ensuring data has value.

One of the most useful Ruby methods I've learned about so far at Dev Boorcamp is the #map method of the enumerable class. This method iterates through an array or hash, running a code block on each element and returning an array or hash of the altered values. A quick demonstration to drive things home is always nice:

				          		
> [1,2,3,4,5,6,7,8].map {|x| x + 100}
=> [101, 102, 103, 104, 105, 106, 107, 108]
				      			
				  			

Running the above code in IRB will iterate through each of the array elements and add 100 to each of them. The |x| portion of the line of code is setting x as the code block's variable which, in this case, corresponds to the current element in an array as it's being iterated over. Arrays are pretty easy-peasy with the map method, but-

Using the #map method on a hash is pretty similar to an array, spare 3 key (no pun intended) differences:

1. The map's code block variable needs a buddy. Each iteration of an array just contained a single object, but each iteration of a hash has 2- one for the key and one for the value. This means the map method code block needs a variable for each. Ruby developers commonly use |k, v|, where "k" is the key and "v" is the value.

2. The code after the block variables needs to be in those cute little curly brackets or else your code will throw errors.

… and I can't remember what #3 was. Oh well, moving forward. Once again, a demonstration is worth a thousand words. Unless the demonstration is already a thousand words, then it's worth like a billion or something.

				          		
> hash = {"one"=>1, "two"=>2, "three"=>3, "four"=>4, "five"=>5, "six"=>6}
> hash.map{ |k, v| { k => v + 100 } }
=> [{"one"=>101}, {"two"=>102}, {"three"=>103}, {"four"=>104}, {"five"=>105}, {"six"=>106}]
				          		
				          	

Hold the phone. The output looks like it's actually an array? Ah, that's right- that's what key difference #3 was.

3. Using #map on a hash will output an array version of the hash.

While you can hack this array of key/value pairs to be usable, it definitely isn't ideal because it won't behave like a normal hash. I found a really handy-dandy solution to this that requires you to extend the standard Hash class in Ruby. No worries, it's not as scary as it sounds.

				              
class Hash
    def hmap(&block)
        Hash[self.map {|k,v|| block.call(k,v) }]
    end
end
				              
				            

This new method looks like this in practice-

				              
> hash.hmap{ |k,v| [ k => v + 100 ] }
=> {"one"=>101, "two"=>102, "three"=>103, "four"=>104, "five"=>105, "six"=>106} 
				              
				            

That's hot biscuits, right? Special thanks to Chris Holtz for the great #hmap method.

One of the most important aspects of Dev Bootcamp is its focus on peer programming. As I've solely coded alone up until this point, the thought of pair programming had me somewhat anxious initially. The most significant struggle I continue to have with pairing is feeling pressure to respond immediately instead of being able to take a moment to think through the problem at hand. I can have much more developed ideas and solutions when I have some time to think on my own.

Into the second half of Phase 0, while I feel like I can still improve greatly in my pair programming skills, I definitely see the value in pairing. Programming with a pair has helped me catch mistakes or save me from going down a rabbit hole for a challenge through my pair suggesting a new route. Pairing has also helped me think through my code more thoroughly and solidify what I'm learning by requiring me to talk about different techniques I'm employing.

The feedback component to pairing has been tremendously helpful in helping me develop both my programming and pairing skills. I think that the most impactful aspect of pairing feedback is having a log of ways that I can improve. Every week, I re-read the feedback I've received in order to focus my work in the next week on developing these areas. As programming feedback is concerned, one of the more common piece of feedback is that I can be better with sublime and command line shortcuts. In order to develop this, I've been practicing with ShortcutFoo. I also have had issues occasionally in pairing sessions communicating my ideas and explaining my thought process. As the curriculum has gotten into more complex Ruby concepts, I have definitely felt that explaining my thought process has become more challenging. Writing feedback has generally been fairly natural, though sometimes it has been difficult to find actional feedback to give. In order to develop this and give better feedback, I have been making a conscious effort to keep feedback in mind throughout the pairing session, instead of just thinking about it after the pairing session is over.

This week in Dev Bootcamp, we focused exclusively on Ruby classes. Classes can be thought of as a blueprint for computing objects that a program creates. Objects created from the same class follow a shared "blueprint", which allows for software to interact and manipulate these objects in a standardized way.

Say, for example, you were shopping for a new guitar in a music store. It's fairly intuitive to tell the difference between a guitar and a drum set when shopping through the store, but computers need a bit more help when it comes to differentiating between the two. Here's how you would "teach" the computer what a guitar is using Ruby:

				          		
class ElectricGuitar
  def initialize(brand)
    @stringed_instrument = true
    @strings = 6
    @brand = brand
    @pickup = true
  end
end
				      			
				  			

The initialize method is a special method for classes that tells the computer about various attributes of the object. Each attribute is assigned just like a standard variable would in Ruby, except that the variable name starts with an "@" symbol. The ElectricGuitar class above is "telling" the computer that electric guitars are stringed instruments with six strings and a pickup. It also allows for the guitar brand to be set for new objects of the ElectricGuitar class by passing in the guitar's brand and setting it to @brand. Lets see what creating a new ElectricGuitar object looks like:

				          		
guitar = ElectricGuitar.new("Gibson")
				          		
				          	

This creates a new instance of ElectricGuitar and sets it to the variable name "guitar". Now, anytime Ruby sees the "guitar" object, it knows that it's a stringed instrument with a pickup and 6 strings that was made by Gibson. Now, if your computer were walking through the music store shopping for a new guitar, it would be able to identify products in the store as electric guitars.

You can't really shop for guitars without trying them out, but it would be pretty inefficient if you had to re-learn how to play a guitar with each guitar you tested out at the music store. Since your computer now knows what an electric guitar is, it can easily perform the same actions on any of the electric guitars at the store. This is done by setting instance methods when defining a class, which looks like this:

				              
class ElectricGuitar
  def initialize(brand)
    @stringed_instrument = true
    @strings = 6
    @brand = brand
    @pickup = true
  end
  
  def play_ironman
    <block of code>
  end

  def play_free_bird
    <block of code>
  end

  def shred
    <block of code>
  end
end
				              
				            

This means that any instance of ElectricGuitar would be able to use the play_ironman, play_free_bird and shred methods. Here's how that would look using the "guitar" object from earlier:

				              
guitar.play_ironman
guitar.play_free_bird
guitar.shred
				              
				            

That's all well and good, but what if your computer happens to be a metal-head and is shopping for a sweet-ass 7 string guitar? The computer currently thinks that to be an electric guitar, it needs to have the standard 6 strings. You can fix that by creating a sub-class of ElectricGuitar:

				              
class SevenStringGuitar < ElectricGuitar
  attr_reader :strings
  attr_reader :brand

  def initialize(brand)
    @strings = 7
  end
end

blackjackatx = SevenStringGuitar.new("Schecter")

blackjackatx.strings
=> 7
blackjackatx.brand
=> Schecter
blackjackatx.shred
=> play some rad solo
				              
				            

Adding the "< ElectricGuitar" lets Ruby know that objects from the SevenStringGuitar class are just like ElectricGuitar objects- they're stringed instruments with a pickup. Though, the SevenStringGuitar class overwrites the @string variable to 7. Now, as your computer is shopping for a new guitar it will be able to know that 7 string guitars are just like electric guitars, they just have an extra string.

One of the core tenets of efficient and easy-to-manage software is the DRY, or "don't repeat yourself", principle. Reusing code where possible makes debugging and updating code much easier than the alternative. Two of the main ways to keep your code nice and DRY is through class inheritance and composition.

Inheritance is the concept of creating a parent-child relationship between two classes. The child class inherits the methods and variables from the parent class, which helps software avoid repeating itself. Here's an example:

				          		
class Musician
  def initialize(name)
    @name = name
  end

  def play_music(music)
    play(music)
  end
end

class RapMusician < Musician
  def initialize
    @genre = rap
  end

  def rap(lyrics, beat)
    play_music(beat)
    print lyrics
  end

end

jova = RapMusician.new("Jay-Z")
				      			
				  			

The RapMusician class is a subclass of musician and is said to have an is-a relationship to the Musician class. You can think of this in that a rapper is-a musician. The RapMusician class inherits the @name assignment and the play_music method from the Musician class. The issue with inheritance in some instances is that as software is developed and classes are built upon, the child class can become increasingly different than the parent class until they are only loosely similar.

Composition, on the other hand, creates what is called a "has-a" relationship between objects. In practice, this essentially just looks like an object being instantiated inside of another class. An example of this kind of relationship would be a Person object that has-a Car object.

				          		
class Person
  def initialize(name, car_model)
    @name = name
    @car = Car.new(car_model)
  end
end

class Car
  def initialize(make)
    @make = make
  end
end
				          		
				          	

The key to differentiating whether to use composition or inheritance to keep your code DRY is thinking about the nature of the relationship between the objects.

This week in Dev Bootcamp, we switched gears from Ruby to JavaScript in our challenges. I had hacked my way through some JavaScript before, but had always felt somewhat intimidated by it for some reason. I think that coming from Python, JavaScript syntax felt a lot messier and more difficult to understand at the time, though learning Ruby before diving into JavaScript this time around felt much more natural. Just the little bit of extra training that Ruby provided with things like remembering to close off blocks of code made it much easier to come from Ruby to JavaScript, compared to from Python.

After a week of focusing solely on JavaScript, one of the most significant differences between it and Ruby is how the languages create new objects. Ruby is a lot like Python, in that it relies on using classes as a kind of blueprint for making new objects. Here's an example of how you'd create an object in Ruby:

				          		
class Car
  def initialize(make, model, year, color)
    @make = make
    @model = model
    @year = year
    @color = color
    @speed = 0
  end

  def changeSpeed(mph)
    @speed = mph
  end
end

car = Car.new("Ford", "Mustang", 1969, "red")
				      							 
				      		

And now, here's how you'd create the same object in JavaScript:

				          		
var car = {
  make: "Ford",
  model: "Mustang",
  year: 1969,
  color: "red",
  speed: 0,
  changeSpeed: Function(mph) {
    this.speed = mph;
  }
}
				          		
				          	

Right off the bat, there's a big difference- no mention of class. Although JavaScript is also an object-oriented programming language, it doesn't actually have any classes. Once you look past the lack of a class keyword, you can start to see some similarities between the two languages when initializing an object. The newly minted objects from both JavaScript and Ruby have the same properties, and it's fairly easy to see that this.speed is similar to Ruby's @speed, in that it is JavaScript's way of accessing the object's speed property from within the object.

Since there are no classes in JavaScript, how do you write DRY code in JavaScript? If you had to create 100 Car objects, you can see how bloated your software would get, and how much of a pain it would be if you wanted to add the license plate number as a property for each of those objects. JavaScript handles this through object prototypes. If classes are blueprints which instruct how a house should be built, then prototypes would be a model home in a sub-development. The blueprint isn't a house itself, but it's used to let the builders know how many rooms it should have, what the square footage should be ect... In contrast, a model home (the prototype) is a fully functioning house in it's own right, but, like the blueprint, is used to define what characteristics other houses like it have.

In general, I feel like I'm pretty good at avoiding or neutralizing conflict. I live by the phrase "walk a mile in their shoes", and try my best to understand other's point of view or actions. While this means that there isn't too much conflict in my life, I've learned over the past few years that conflict actually plays an important piece in nurturing healthy and strong relationships. If someone's actions are frustrating to me, my default is to focus my energy solely on neutralizing my frustration instead of communicating my frustration with the other person sometimes. While I'm generally able to neutralize any feelings of frustration, sometimes the best course of action is to allow for healthy and empathetic conflict to happen.

One example of this is at my current job at a marketing agency. In early 2014, our practice had a string of significant, large projects and clients on-boarded which happened to coincide with a few members of our team leaving. I had volunteered to take on some new responsibilities in areas of our practice that I disliked. In the coming months, our practice had shifted to much more heavily focus on these areas. Since I was the only one on the team with experience in these areas, my work week became more and more centered on work I disliked and felt unhappy doing, and 40 hour work weeks quickly turned into stressful 70-80 hour work weeks. I felt frustrated internally for a while, and after a few weeks, was really becoming resentful of the situation. I finally discussed this with my manager, who was really understanding and worked with me to try to shift my time away from these areas. Looking back, I realize I should have communicated my issues much more quickly. This would have calmed my negativity earlier on and let me solve the issues instead of just avoid them.

One of the main reasons I decided to do Dev Bootcamp, instead of just continuing to learn programming on my own, was to force myself to learn some of the aspects of coding that aren't as glamorous or necessarily “fun”. Learning on my own, I would always focus my time on learning how to make cool new stuff, but neglected learning some of the less-sexy development concepts like version control or testing methodologies. Now that Phase 0 is nearly complete and I've had more exposure to automated testing, I definitely understanding the value of TDD.

TDD may sound like some kind of virus that spreads through college dorm rooms, but the term stands for Test Driven Development. The essence of TDD is for software to be developed through very short, specific development cycles that are focused on passing a set of automated tests that prove the software is doing what it's supposed to do. Test Driven Development is an iterative process consisting of three steps. The first step in TDD is to write code that tests the functionality or improvement that you or another programmer will be developing. Why start out with setting up your test before you start coding? It not only enables you to think through what you'll be doing to ensure that it's actually testable, it also makes a programmer pause to think through the goals of what they will coding in a detailed, tangible way. After writing the test, the next step is to write the minimum amount of code to pass the test. This helps produce more efficient, less bloated code. The last step in Test Driven Development is to take the minimal code that passed the unit tests and refactor them for readability and to follow best practices.

For this week's Dev Bootcamp culture blog, we were to research Stereotype Threat, a social theory where members of a social group are anxious about fulfilling or confirming negative stereotypes about one's own social group. This anxiety has been shown to reduce performance among those affected by stereotype threat in a number of studies. Although most research on stereotype threat has been focused on race, many other forms of this exist, just as gender, nationality, or profession.

Being a male of European descent, I'm lucky enough to avoid a lot of the nastiest negative stereotypes held today. The stereotypes that I've been affected by are insignificant by comparison. One such example is the stereotype of being lazy or unproductive because I currently work remotely from home. While this is far from true, I find that it's often an opinion that people have when first learning that I work from home. After learning about stereotype threat, I believe that I have felt this negative stereotype and have often responded by over-working myself in an attempt to compensate for it.

Although I don't anticipate this negative stereotype to continue while I'm attending Dev Bootcamp, since I won't be working from home anymore, I will make sure to be especially vigilant in recognizing and rejecting stereotypes. The most significant way to fight stereotype threat is to encourage self affirming behavior and reduce focus on identifying social groups.

A lot of our lives are determined by the values that we hold. These values drive our actions, dictate the respect we have for others, and influence how others view and interact with us. From as far back as I can remember, I always valued creativity above pretty much everything else. There's something special about being able to create something new, useful and different. When I was in elementary school, I even had a notebook full of “inventions” that I would bring with me to school with me every day. Whether it was nonsensically boyish, like missiles that shot lasers, or kiddish, like a spoon with a secret chocolate syrup reservoir for making undercover chocolate milk, I loved thinking up new things. As I've grown older, I've gotten a better understanding of the deeper value that drives my interest in creativity, which is uniqueness and challenging the status quo. At my current job at a digital strategy agency, I feel the most successful when I'm able to pitch new, unique strategies for stagnant client accounts. I think that I can leverage this at Dev Bootcamp by challenging myself and my pair to try new things in our challenges and projects. One other way that I can help change my mood when I'm frustrated or struggling is to take a moment to think of a way that I can inject some more creativity in the challenge that I'm having issues with.

During this week's phase 0 curriculum, we took a bit of a breather from learning new material and reviewed Ruby, JavaScript, HTML and CSS. I was also able to revisit my site's design, this time using Twitter Bootstrap, a front-end framework that I've toyed with a bit in the past. Bootstrap makes it easy to test new ideas and deploy MVPs quickly. It also takes a “mobile-first” approach to web design, by prioritizing mobile user experience. Using a front-end framework like Bootstrap can help you spend less time making the foundation of a site, and more time testing new design elements.

Using Bootstrap, I completely revamped my site and changed the design to look more modern. I researched some current design trends, and decided that I wanted my site to be much bolder, simpler and cleaner looking by using a flat design. In order to do this redesign, I started by essentially just started at the top of my existing page's design and moved down, focusing on each of the 4 major sections of the page at a time. The other most significant change made to the site was removing the blog section of the site, instead replicating each blog post in separate modals (just like this one!).

One of the reasons that I love programming, and the reason I think I am generally able to learn programming concepts fairly quickly, is my ability to “figure it out”. I love jumping into something and being in way over my head, using that as a foundation to learn. An example of this is the first complete program I wrote, which was a reporting dashboard for the marketing agency I worked for. Getting started, I had no clue how to query APIs or databases, or even the first thing about Visual Basic, the programming language I was supposed to use. Although I was able to complete this project, it took me a lot longer than it needed to. Through this experience, I learned just how important it is to know when and how to ask the right questions.

The most important step in asking good questions is to do your own due dilligence first. This could mean searching on Stack Overflow or even just making sure that you've thought through the issue thoroughly. Not only will this enable your question to be more detailed and increase the likelihood you'll ask the right question that encourages the right answer, it also shows respect for the person or people taking the time to answer your question.

Another significant factor in asking the right question is to be as specific as you can, while focusing only on the details that matter. This makes it easier for people to know if they are able to help you and avoids wasting their time on needless details. If posting a question online, include the specific code in question without including the code for the entire program you're writing. Finally, make sure you proof read your questions before posting them online. Edit any grammar or spelling mistakes- you're asking others to take time out of their day to help you, the least you can do is show them respect by making your question understandable.

Here is some test text for the blog post.