<!DOCTYPE html>
<html>

<head>
    <title>Boatz'n'Blogz</title>
    <link rel="stylesheet" href="../bootstrap-3.2.0-dist/css/bootstrap.css">
    <link rel="stylesheet" href="../stylesheets/index.css">
    <link rel="stylesheet" href="../stylesheets/blog.css">
    <meta name="viewport" content="width=device-width">
    <link rel="icon" href="images/favicon.ico">

</head>

<body class="bg-img">

    <!-- _______________Bootstrap Nav _____________ -->
    <nav class="navbar navbar-default" role="navigation">
        <div class="container-fluid">
            <!-- Brand and toggle get grouped for better mobile display -->
            <div class="navbar-header">
                <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1">
                    <span class="sr-only">Toggle navigation</span>
                    <span class="icon-bar"></span>
                    <span class="icon-bar"></span>
                    <span class="icon-bar"></span>
                </button>
                <a class="navbar-brand" href="../index.html">Boatz 'n' Blogz</a>
            </div>
            <!-- Collect the nav links, forms, and other content for toggling -->
            <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
                <ul class="nav navbar-nav">
                    <li><a href="../index.html#tech">Tech</a>
                    </li>
                    <li class="active"><a href="../index.html#culture">Culture</a>
                    </li>
                    <li><a href="../index.html#projects">Projects</a>
                    </li>
                    <!-- Contact Dropdown -->
                    <li class="dropdown">
                        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Contact <span class="caret"></span></a>
                        <ul class="dropdown-menu" role="menu">
                            <li><a href="https://plus.google.com/117925567488555774987/posts">Google+</a>
                            </li>
                            <li><a href="https://github.com/sspread">GitHub</a>
                            </li>
                            <li><a href="https://www.linkedin.com/pub/sam-spread/1a/a20/396">LinkedIn</a>
                            </li>
                            <li><a href="https://twitter.com/scspread">Twitter</a>
                            </li>
                        </ul>
                    </li>
                </ul>
                <!-- RIGHT SIDE NAV POST TOGGLE -->
                <ul class="nav navbar-nav navbar-right">
                    <li>
                        <a href="culture_wk6.html">
                            <span class="glyphicon glyphicon-chevron-left"></span>Later Post</a>
                    </li>
                    <li><a href="culture_wk4.html">Earlier Post<span class="glyphicon glyphicon-chevron-right"></span></a>
                    </li>
                </ul>
            </div>
            <!-- /.navbar-collapse -->
        </div>
        <!-- /.container-fluid -->
    </nav>

    <!-- _________________End Bootstrap Nav_________________ -->

    <div class="col-sm-9">

        <article>
            <h2>Pair Programming</h2>
            <h4><small>July 21.2014</small></h4>

            <p><b><i>Two heads are better than one</i></b>, goes the 16th century proverb. For the most part, I'm inclined to agree. Two minds can blast any task with a 2x beam of creative cognitivity. But do you get 2x the output? DBC has given me an opportunity to tackle new challenges in programming with a pair. While I'm used to working in groups to complete projects, group work usually involves a great dividing of the tasks. Pairing is more like tutoring, wherein two people work on the same exact problem at the same exact time. Except, there is no mentor-student relationship; the pair is theoretically in the same knowledge ballpark.</p>

            <img class="image" src="../images/pear.jpg" style="float:left; padding-bottom:0;">
            <p>So, pair programming is new to me, as I think it is for many of my pair peers, especially over a video chat. Like anything new, pairing takes some getting used to. Needless to say, my last session ran more smoothly than my first session. At the end of my sessions, I generally feel a sense of accomplishment, not only from completing a challenge, but from navigating newfound knowledge in semi-synchronized style. All this accomplishing can be exhausting. As opposed to only learning this rather difficult material en solo, pairing demands the added labor of being considerate of another's learning. You will never be on the exact same page with your pair. Someone always knows more about something, if not everything, in the realm of the challenge du jour. While it is fairly simple to relay information and fill in the knowledge gaps, it can be tricky to do so in a driver/navigator agreement.</p>

            <p>For example, if I'm driving, I'm sharing my screen and typing in the code as instructed by the navigator. If I have an idea that might alter our course, I would politely wait until the navigator is finished with the thought before raising it. When I propose my solution, I would ideally be navigating then and our roles would switch. We would have to then work out of two different files. That's why we have Stypi, right? Stypi is a nice idea, but it is buggy and impractical and I'm under the impression that I'm not alone in abandoning it. As a convenient result, I end up navigating and driving when I have an idea. That doesn't follow the driver/navigator protocol! Of course, this would all be easier to do in person.</p>

            <p>Aside from the inefficiency and maybe stress that are borne in maintaining a driver/navigator relationship, pair programming is a terrific strategy for <i>learning</i>. Even if there is a significant knowledge gap between the pair, neither party walks away empty handed. The more learned one benefits from teaching and guiding, and exposure to varying insights and approaches fortifies the less tangible problem-solving skills for both parties. That being said, I'm skeptical that pairing would be best practice in business, wherein budgets and finite human resources would not allow for such duplication of efforts and intermittent learning. The client pays for a product, not for developers to grow existentially.</p>

            <p>If you've made it this far, you can stay for a brief chat about feedback because it is so important here at DBC. Exchanging feedback is a challenge in itself because people are hesitant to be say negative things about one another. Yes, I know, it's not "negative" feedback, it's <i>constructive</i>. But, there is a hint of "you did not do this thing as good as I would have liked" in every constructive feedback, and even that can be hard for us to read and write. Because giving constructive feedback is part of the requirement, in giving feedback, I try to always come up with something that my pair could improve, even if it wasn't something that struck me at the time of our session. Sometimes I have to dig for it. I hope this does not come across as nit pickin'. In light of these attempts, I was surprised when I read the feedback @me because it was so positive. I would've been harder on myself.</p>

            <p><b>TLDR</b>; Pair programming and feedback are often tedious and uncomfortable, but serve as invaluable tools to becoming world-class beginners.</p>

            <footer>--- Week 5 ---</footer>
        </article>
    </div>

    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
    <script src="../bootstrap-3.2.0-dist/js/bootstrap.min.js"></script>
</body>

</html>
