Beyond the Code: Dealing with Interpersonal Conflicts | Day 13

Our regular morning schedule was put on hold today where, instead of a lecture, we had a UofT Professor come in to lead a workshop on “Communicating Nondefensively.” After weeks of intensive coding, it was nice to have a change of pace; Lil Blume filled our morning with humour and insight. The value of the workshop was in its general applicability to all domains of life, rather than entailing specific tactics for programmers in a working environment. For, in truth, once you understand the general principles, you can apply them in any context.

The axiomatic worldview underlying Blume’s approach to interpersonal communication is that everything people say are projections. This is to say that what another person communicates is an externalization of their internal state, using your phenomenological appearance as a canvas upon which to manifest and interact with their internal being. I dare say that this philosophy threatens on descending into a Husserlian-esque solipsism and, yet, it is very much an accurate depiction of life as it is experienced phenomenologically. The self is only able to determine its character, and affirm its being, through interaction with other beings in an intersubjective world. In short, we can only explore ourselves through our interactions with others. Unfortunately, the islands of selfhood are connected by bridges of communication and it is upon these bridges where misunderstandings and conflicts are most likely to occur.

The first step in becoming a more effective communicator is understanding what your default response is to perceived attacks. One can either attack the critic, distort the message, or avoid the situation altogether – Blume also reminded us that our degree of perceived power affects the behaviour that we choose to exude, where the greater the power the more direct the method. Once you have an understanding of self, it becomes easier to relate to others and to identify the underlying problems fueling any given conflict. When someone accuses you of something that clashes with your self-image – when the external validation does not align with one’s internal perception – cognitive dissonance emerges. In order to fight this dissonance and to silence it, the individual implements one of the three tactics and then a genuine conflict emerges. How can we hope to solve such predicaments?

If I could etch but a single quote from Blume’s workshop on my wall, it would be thus: “the criticism belongs to the critic until and unless you accept it.” In other words, the power is truly in your own hands, regarding whether or not you choose to accept the criticism. For, when you become defensive, you have already accepted their criticism – you have already fallen into their trap and are responding the dialectics that they are controlling. Consequently, the path to reconciliation is found in recognizing the root of the problem, which is the medium of communication itself.

Do not fight your opponent, do not flee from battle, and do not get lost in trivial equivocations on the nature of the battle; stop and recognize that the field of battle itself is the problem. Realize that the very fact that you are standing in this battleground, sword unsheathed, is the culmination of faults by both parties; realize that there is a problem and let your opponent reveal what that problem is. How? Let him strike first. The moment of attack is also the moment of greatest weakness – your opponent makes himself vulnerable by virtue of unleashing an assault. What’s the parallel here? Let your communication partner speak and listen to what he is saying. The solution to the problem can be found in the words and the tone that the individual chooses to express himself with. You must see the undercurrent of hurt and frustration that triggers the words of criticism, for therein lies the channel to reconciliation.

At the end of the day, everyone just wants to be heard – we all want to be acknowledged, to have our lives deemed worthy by another. Hear what your partner has to say, let him know that you understand what he’s getting at through one of various strategies – e.g. paraphrasing – and then you are on the right path to communicating about the issue at hand. The key point here is that all of these strategies merely help you to begin the process of reconciliation by positioning you in a state ready for nondefensive communication – the rest is up to you. Throughout, Blume encourages us to check our perceptions, to own our own feelings, and to listen actively. Only then will we be ready to engage with our partner in a constructive dialogue regarding the issues at hand and how they may be resolved.

Lil Blume’s workshop was a refreshing change of pace and added some much needed laughter to our days. The lessons were valuable not only for workplace encounters but also for those of us with romantic partners, where there will always be conflicts here and there. Understanding how to deal with these confrontations with maturity and level-headedness is an invaluable asset as we progress forward in our professional and personal lives.

A Reflection on the Entrepreneurial Spirit | Day 12

The ideation phase of the entrepreneurial journey is often one of the most isolating. The ideas are constantly coming to you and you relentlessly jot them down, perhaps in a notebook, on a napkin, or in a file on your computer. The ideas accumulate progressively and yet nothing is truly done about them. When you catch the entrepreneurial bug, it’s a though you gain a new pair of glasses with which to view the world – rather than seeing plain phenomena you glimpse at business opportunities left, right, and centre. Volumes of ideas can be recorded, but where is the action?

The inherent problem, I believe, is that the emerging entrepreneurial mind views its ideas as sacred property and thus refuses to share those ideas with others. Without conversation and validation, the ideas remain but volumes of scribbles on a shelf. I’d like to build on this notion of ideational property, as it is perhaps one of the most influential elements in barricading the budding entrepreneur against sharing. The idea, itself, is not the creation of something new but the discovery of something existent. The opportunity has always been present but you were fortunate enough to recognize it for what it was. In short, you are the receiver of an insight that you stumble upon.

Any element of agency that one might presume is undermined by the pure happenstance that surrounds the ideational event. You might be sipping on a latte in a café, looking out the window, when the idea strikes; you might be waking up from a relaxing nap when a thunderbolt of creativity inspires you; you might be going for a jog and observing your surroundings when something clicks in your mind. In these states of being, you are not an active agent – you are an antennae receiving a radio wave of insight. If you are able to see the situation in this light, you’ll be much more willing to share your idea(s) with others in order to see what they think. It is in the dialogue and feedback that you will find the greatest value of sharing your ideas – this ideational exchange is exactly what you need in order to get your feet on the ground and to get your hustle muscles working.

While we were working on our JavaScript and jQuery assignment today, I decided to post about the upcoming Startup Weekend Toronto EDU event that occurs the weekend after our cohort of Bitmaker Labs comes to an end. Within minutes, Stuart approached me to say that he was down for forming a team and that sparked a brilliant exchange of ideas. I pulled out my entrepreneurial notebook and he opened his ideas file: we spent a good 15-20 minutes just talking about our various business ideas. The amusing parallel that I noticed is that we’ve been doing this for quite some time – I, in particular, have scribbling away since about my second year at McGill. While I was advocating the importance of identifying your main projects that you’re willing to devote time to, Peter countered with the equally relevant point that one must also jot down the random ideas – the ones that don’t seem like anything big at the time. Admittedly, the ideas that have the biggest growth potential are always the simplest, indeed, the ones that you would normally pass over.

In any case, although the exchange was fairly brief it was enough to bring confidence and affirmation to my chosen path and to the projects by which such a path shall be trodden. These types of conversations should occur more often, not just at Bitmaker Labs, but in daily life. I suppose the only caveat is that the people with whom you share your ideas must be worthy of the connection – cast not your pearls before swine. The conversation should be an exchange between equals where both have something to contribute to one another. To share one’s ideas is a step in the direction of vulnerability and, as such, one’s partner must reciprocate and partake in the act of sharing. When done properly, the exchange empowers everyone involved. I’m looking forward to having more of these conversations in the future – if there’s anything you want to validate, I’m always willing to lend an ear.

Relaxing Silence, Surging Inspiration | Day 11

Our morning lecture consisted of an overview of JavaScript, followed by an open day devoted to going through several important resources and slides on the language in addition to practice examples. It’s always nice to learn a little bit about the history of a language and to realize that I was growing up amidst all this development without being aware of it.

JavaScript (hereafter to be referred to as JS) was written in ten days in 1995 by Netscape, during the browser wars. I remember that Netscape was always my dad’s browser of choice, but I never realized that they eventually became Mozilla following AOL’s acquisition – I was reminded of this fact today, which I first learned when watching Revolution OS not too long ago. Another fun fact is that JS was originally called Live Script but its name was changed in a clever marketing ploy to catch the attention of all of those who used Java. In terms of its functionality in the overarching context of web development, JS is for client-side operations whereas languages like Ruby or PHP deal with the server-side. JS is what truly gives life – animation – to a website beyond the bare content and presentation of HTML and CSS.

In any case, today was uniquely contemplative in its character – we were all quietly going through the material on our own instead of having the usual clamour of group work. It was near the end of the day when a fellow student, Filip, showed me the documentary Indie Game: The Movie after we had discussed, on our Google Group, potential movies to watch on Friday. Someone suggested The Startup Kids, which I offered to provide, as I already own it; Filip passed by my desk as I was looking up his suggestion and he immediately offered me a viewing – I spent the evening enjoying it.

Indie Game was a moving presentation of an industry that I was never fully acquainted with. It tracked the quotidian trials and tribulations of celebrated indie game developers – a journey that bled with the entrepreneurial spirit. Jonathan Blow’s Braid is set up as the contextual benchmark of indie success; Edmund and Tommy’s Super Meat Boy is positioned as a conventional success story that begins as an underdog and rises to surpass their forefather; Phil Fish’s Fez is more or less a tragic tale of roadblocks that ends with a hope for a better tomorrow.

Jon is depicted here as the source of wisdom – he’s gone through the trials already and came out successful. To paraphrase his stronger nuggets of wisdom, Jon advocates that part and parcel of being in the indie industry is trying not to be professional. You can’t simply try to be a smaller version of, let’s say, EA or Ubisoft – they’re in the industry of making polished games. Rather, the indie game developer needs to infuse all of his personal flaws and vulnerabilities into his games. The games should be nothing less than a reflection of self – the naked child of one’s soul presented in allegory that all may relate to.  The polished game is alienating, for it is only the flawed game of the indie developer that captures human imperfection in its raw essence. The visuals bleed with sincerity and the storylines flow from the centre of one’s being – a life and ethos made manifest.

Moving on to Edmund and Tommy, we witness some of the most genuinely expressed emotions throughout the documentary. In particular, Edmund is forthright in showing his personal growth, how his childhood directly influences his work. For the pair, video games are how they express themselves – they are storytellers of the modern era, blessed with an immersive and interactive medium for the conveyance of their messages. The story of Super Meat Boy is one of authentic bootstrapping – these two put their careers and relationships on the line to make this game happen. There was a deeply affecting scene with Tommy reflecting on how he no longer has a life at ~4AM in a diner – how the creation of this game has become his life. He simply did not have the time for anything else. The message that I got from his paradoxical state of restricted liberty was: “What are you willing to sacrifice for greatness? How much are you willing to endure to have a sense of independence?” I remain speechless at their willpower and fortitude of being. Their life and times during the production of Super Meat Boy is truly a study in the ontology of entrepreneurship. Thankfully, their tale ends on a high note with SMB being a financial powerhouse, allowing Tommy to pay off his parents’ debts and Edmund to buy a new house for him and his patient wife.

Finally, we have the tragic tale of Montreal-born Phil Fish. All he ever wanted was to be appreciated and liked – don’t we all? – but his journey is certainly a modern mimesis of Hamlet. Phil’s obstacles not only derived from perfectionism and over-identification of self with his magnum opus but also from partnership dilemmas. Divisions among the founding teams destroy a healthy number of startups and it was no different for Phil where a bitter feud with his original business partner left him psychologically tattered. If anything, Phil’s experiences show us that indie development is not all rainbows and butterflies as there are genuine obstacles that can and will crush you if you are not prepared. However, by the end of the documentary we see Phil resolve his partnership issues and make significant headway in the launching of Fez. The fallen warrior has his moment of redemption.

Overall, my key takeaway from this documentary came unexpectedly from Tommy when he lamented his bittersweet state, forcing me to ask myself: how much am I willing to sacrifice for greatness? It would appear that nothing is possible without sacrifice – the scales of life mandate it so. Nonetheless, the gravitas of his revelation is softened by my solemn acknowledgement that one receives in proportion to service rendered. I cannot rise myself without raising others and commerce, indeed, is a viable outlet for such collective amelioration.

A Brief Hiatus | Day 10

Rather than attending Bitmaker Labs at a normal time today, I had to endure the drudgery of a driving test in Oshawa. Thankfully, I passed it with just eleven days until the expiration of my G2 – with this hurdle out of the way I can now focus entirely on my coding. When I arrived downtown slightly after noon, I had missed the lecture of the day and attempted to catch up with the day’s assignment. We were to work with JSON and APIs, extracting information and then presenting it in HTML. Admittedly, this is an assignment that I will have to complete on the weekend; I was completely out of it today after the driving test. On that note, I believe it is worth reflecting on the importance of focus. Paul Graham has already written an excellent post on the topic and I’ll try to give my own take on it.

In any domain that requires creative problem solving, programming being a prime example, having large blocks of uninterrupted time is essential to one’s productivity. These kinds of tasks require the complete immersion of one’s mind, where the slightest distraction can completely derail the train of your thoughts. There is a fundamental lack of linearity in the problem solving process, where your solutions come from the most unexpected places. Personally, if I’m ever stuck on a problem I take a nap and wake up with an idea of how to solve the problem – this kind of behaviour can only emerge when the individual has the assurance that nobody will bother him for an extended duration. However, there is another important element to it regarding the quantity of problems that one is engaging with.

Singular focus on a single problem is really the only way to go about problem solving, effectively. When the mind must balance the weight of multiple problems, it is truly hard to tackle any of them. In short, he who is pulled in multiple directions finds himself going nowhere. For me today, although I described the driving test as drudgery, it was truly nerve-wracking as it was my second last shot to get my G before having to redo the multi-year process all over again. It is easy to say “just live in present” but so hard to put that catchphrase into action when one has a future-oriented mind that is ever aware of the potential negative outcomes. Nevertheless, that brings me to another key point: the problem solver needs to be focused on the immediate present.

The temporal aspect is often overlooked, as it is nested within the notion of having a singular focus, but it is still an element to consider in its own right. One could reasonably provide a programmer with a single problem and an uninterrupted period of six hours and still have him be ineffective if there are thoughts pulling him ever into the past and the future. Don’t we all experience that? A continual haunting of the past and dreading of the future that prevent us from embracing the present wholeheartedly? Debts to pay, mouths to feed, family to take care of – a whole gamut of non-work related problems that affect work performance. I suppose it can only be countered by higher pay and promoting work as a form of escapism, so to speak. The employee can find solace and meaning in his work as he avoids the troubles that await him on the commute home. Of course, this doesn’t help with his personal development – growth lies in the areas of greatest conflict – but at least it will allow him to enjoy his indentured servitude. I suppose one could say that the employer must succeed in creating an environment where employees want to escape to. It’s all a matter of perspective but I do believe the notion of escapism hits the nail on a head. The CEO is a systems designer who must construct a macro environment that retains his top talent. You need to provide top dollars (or at least enough so that money no longer becomes a problem), engaging problems, a ritualistic routine that separates home from work, cult-like adherence to a unifying company ideology, etc. However, the most important aspect is to appeal to their dormant ‘religious’ sentiments

Not every man may consider himself religious but he nevertheless endows certain aspects of his life with what can only be expressed as religious fanaticism. Whether it is some New Age spirituality, a sports team, veganism, a certain band, or even our conference-fueled cult of entrepreneurship, man has the capacity to worship something with mystical devotion. Mysticism, itself, is something that one escapes to – placing one’s faith in the inexpressible, the numinous. Your company must become the church that your employees worship and you must become their high priest.  Your words become the catechism and doctrine and they become the righteous believers of a new prophet. Your pitches are prophecies, your actions are miracles. In sum, you create an environment that is the complete antithesis to their mundane lives. As such there will be no need to command them as they will genuinely and willingly want to come to work. Why? Because in your church-mongering, in your appeal to their religious fervour, you have allowed them to glimpse the greatness that dwells within them, which they project onto you and your company. In time, they will recognize that it was always within them but, until then, they will happily build your company with you.

Well, that was a major tangent. Late nights bring out my inner Machiavelli. From driving tests, to problem solving, to the politics of company cult creation – non-sequiturs abound.  I suppose what I was intending to convey was that you need to be fully immersed in the present, without any distractions, to be an effective problem solver. In order to create an environment that facilitates an ideal state of mind for problem solving, the CEO must think on a macro-systems level in order to create an Elysium that his employees – his problem solvers – want to escape to. Oh, and one more thing: driving tests are pure drudgery. That is all.

Reverse Engineering Websites and Tech Entrepreneurship | Day 9

In today’s lecture, Khurram took us through the process of reverse engineering websites using Chrome’s developer tools. Being able to view a site’s source code is an invaluable asset as one deepens one’s understanding of web development. The façade of the interface is torn down as we glimpse into the inner workings of the code.

Of particular emphasis was positioning, which is typically the most burdensome element when laying everything out through CSS. Understanding how to weigh out the padding and the margins is essential. More importantly, we delved further into the benefits of responsive web design as content consumption transitions to mobile devices – static pages won’t cut it anymore.

With the lecture completed, we continued on with the data mining and visualizing assignment of yesterday. Although I did express my qualms about data mining in my previous post, it is nonetheless quite an empowering feeling to be able to scour the web to get whatever information you desire. Simply put, in knowing how websites are put together you are in the best position to extract information from them – it is truly an ad hoc process. For instance, if you are trying to scrape a site for its prices you would look through its source code and observe how the prices are presented through its HTML. Once you’ve determined the price’s id, you would write your scrapper to target that particular id to get the information. This information could then sent off into a .txt or .csv file for further manipulation. More importantly, I want to highlight that this entire process can be conducted from your command line, which is deeply humbling as you witness the potential of what your computer is capable of.

Finally, the day ended off with a talk by Aditya Bali, cofounder of BufferBox. He shared with us his entrepreneurial journey from modest beginnings as a Waterloo engineer, to being a cofounder of a YC-backed hardware startup, to finally being acquired by, and working for, Google. I was fortunate enough to have heard him speak on a similar topic at CUTC’s Infect conference in May; when he spoke today, I captured certain elements of his talk that I had previously missed. The essence of Aditya’s talk and entrepreneurial journey can be summarized thus: be relentlessly resourceful. As a startup founder, you truly have very little going for you besides your inspiration, motivation, and effort – in short, you really have to create your opportunities. It is in having very little that you learn how to optimize your situation to your advantage, playing on any strength that can take you forward as you build a beachhead in a given market. Furthermore, I was extremely impressed with the degree of Aditya’s success given that he chose to embark upon an unconventional hardware startup and still was selected by YC. His actions, and those of his cofounders, exist as a continued source of inspiration for GTA and Tri-City entrepreneurs striving to make Southern Ontario a world-class entrepreneurial ecosystem. The future is definitely brimming with potential.

Mining the Interwebs | Day 8

With our explicit focus shifted away from Ruby, today was mostly a review of HTML and CSS. Beyond mere conceptual reiteration, we delved into the interesting world of data mining and visualization. For our task at hand, however, using Ruby was inevitable – we had to use the Nokogiri gem, after all – but the emphasis was on the structuring and presentation of such mined data through the markup language and style sheets, respectively.

Although I had read up informally on HTML and CSS in the past, it was nice to have it all laid out so concisely. Internalizing today’s lecture, I see HTML as the skeleton and CSS as the flesh – the two together create a vessel, but one without life. JavaScript, in this metaphor, would be the animating force that gives the vessel facial expressions and movement – nonetheless, this vessel would still lack a soul. Content is the soul of a web page; content is king, as they say, and everything exists in web development to enshrine the content. The internet is merely a channel of communication and one would be a fool to get lost in the intricacies of the medium, losing sight of its teleological orientation: the transmission of information. As such there are many ways to provide the vessel with a soul, as content comes in many forms. Contributing original text, images, audio, and video can be considered a form of direct ensoulment – manifesting new life into your web vessel. However, for every primary level of existence, there are always secondary and tertiary derivatives that mock the original form – that’s where Nokogiri and data mining come in.

Rather than originating life, data mining is the bastardization of content for utilitarian ends. It is not life manifest, but life recycled and recombined to serve the wishes of its coding master, so to speak. Here, we are creating chimeras. Accepted as an axiom here is that the internet is channel of communication – to recombine and represent existent information is still communicating something, but it is at a lower level. Of course, this is all occurring within the human flavour of creation, in which recycling and recombination are fundamental tenets – everything’s already been said – and, yet, there is something off about data mining. If we could personify web pages, original pages with genuine content would be free men, whereas these secondary tools would be mindless slaves – that’s what feels off. When engaging with Nokogiri to extract information and then parse it, I feel like I’m instantiating a digital slavery of sorts and dirtying my hands.

I’m losing myself in an incredible tangent at this point, but the extended metaphor of originating life in a vessel brings me to a solemn thought on the nature of language. The adepts of the past have never left but merely changed the medium in which they engaged. Language has always been the truest magic – logos is the root of creation. The spellings that were once restricted to small groups and communities can be broadcast around the world at the tap of a key and the click of a mouse. However, beyond languages of interpersonal communication, these programming languages have their own domain-specific magic of sorts. Forget the days of sigils, sacrifices, and summoning – you can now code your own tools to do your bidding.  The mages of our time no longer wear robes – they’re sitting on beanbags and coding away.

Overall, I think what I’m getting at here is that it’s easy to see the code that one is creating as purely data, as an exercise in logic. However, this logic is not divorced from life – it interacts with life and helps to shape it by virtue of what it facilitates. Rather than depersonalizing the code, it helps to think of it in human terms, to embody the seemingly lifeless with the life that it secretly contains. Language is an animating force and to refuse to see it in its proper light is to distort its true potential. If one were to see each line of code as a cell contributing to the life of a breathing organism, there is much philosophical and psychological enrichment to be attained. Change the way you think about your coding, and the code itself changes. Programming gives life to logic and logic to life – open your eyes to its dignified stature and you are thereby empowered in your act of creation.

Testing: The Art of Iterative Development | Day 7

As our final day on the Ruby language, we further engaged in a discussion on the nature of Test Driven Development (TDD). The difficulties and sheer counter-intuitiveness of this approach for the beginner cannot be understated – it is difficult, plain and simple. To learn the philosophy of TDD is quite nice, but to actually engage in the process of its enactment is a case study in frustration. Naturally, one desires genuinely to write code immediately so that a foundation of functionality is attained; to write the test first feels, initially, like an obstacle. Nonetheless, deep down, I understand this to be a necessary behaviour to be acquired by the developing programmer.

The frustrated beginner must ask himself: to what extent have all techniques in life been truly intuitive? And further: if these techniques were not intuitive, did they not help one achieve maximum efficiency in a given domain? Having participated in fencing for half of my university career, after a lifetime in karate, I can think of no better example than a simple lunge. In karate, we are taught to lead with our base and then follow through with our strike; in fencing, we extend our arm first before engaging in the lunge. Although it seems counter-intuitive, it is the optimal approach should one desire to gain points in competitive fencing – the behaviour is optimized for its particular context. Likewise, although TDD may seem counter-intuitive for the amateur programmer, it has its merits in the context of a company devoted towards the production of reliable code. Moreover, the fact that Ruby is an interpreted language means that the tests that we write are truly the only filter gauging the quality of our code – there are no compilers here! It is what it is: I can live with this process if I was working in a development shop but I would absolutely not use TDD if I were building the prototype for a startup that hasn’t yet begun customer development and is still engaged in discovery mode.

Hindrances aside, TDD has its merits when truly mastered. The process forces a ruthless minimalism upon its user, who must build progressively at the most atomic level. Moreover, as having a well-defined scope allows you to write essays with relative ease, TDD permits you to write code, incrementally, into clearly defined project milestones, building the structure of your program code-brick by code-brick, so to speak. The tests are not so much blueprints as they are design specifications; however, rather than laying out the specs in their entirety from the get go, you’re incrementally specifying the needs of the structure, taking the environmental and topological contexts into close consideration every step of the way. In many respects, TDD is the epitome of a personal philosophy that I hold near and dear: freedom through restriction.

The blank page is awfully intimidating for the unseasoned writer, just as the blinking cursor of a new tab in Sublime Text 2 is for the emerging web developer. How does one resolve such uncertainty? For the writer, it may help to break his writing project down into its elemental structure – we’ve all gone through the process of identifying the introduction, thesis, body arguments, and conclusion. In an analogous sense, TDD does the same thing for the web developer. In short, with TDD there is much gold hidden in plain sight – while the beginner trifles over the barrenness of the surface, the adept digs just a little deeper and remains masterfully content. Benefit accrues to those who conduct their present affairs in the context of a long-term vision and TDD is an optimal development framework for writing code that withstands the impact of inevitable obsolescence.

Wrapping Up Ruby, Serenely | Day 6

It seems as though the biggest hurdle has been overcome, with the foundations of Ruby out of the way. Today was mostly a discussion on the fundamentals of test driven development (TDD), as it relates to development in Ruby, along with other similar testing philosophies. The week ahead feels much easier as we transition into HTML, CSS, and JS – a place of relative comfort for me compared with Ruby. Personally, I’d like to think of this week as the calm before the storm: we begin with a direct immersion into Ruby, followed by a breather with HTML/CSS, followed by a tumultuous plunge into Rails. I’m really looking forward to catch my breath this week!

That being said, I’m still building on the weaknesses that I feel in my grasp of Ruby. I’ve gone through most of the Treehouse content on Ruby fundamentals at this point, along with finishing Huw Collingbourne’s beginner’s course on Ruby; I plan on going through Codecademy’s Ruby’s content before the end of the week. I think these three resources are perfect for any beginner when used together. Treehouse and Collingbourne’s course provide an informational context through lecture heavy content while Codecademy provides direct coding practice. These resources have been invaluable to me in tackling the various coding projects at Bitmaker Labs. Eventually, I will be rounding off my Ruby basics with Code School material and the Hartl tutorial, but that is still further down the road.

Anyhow, with TDD on the list of priorities for today, we built tests for the programs that we wrote earlier in the course. During our lecture, we learned that these tests are written principally to catch errors, to save time (spend time to save time), and to have clean code. The two major schools of thought that we looked into were Test First and TDD, which actually have more in common than they are different. Broadly, you can say that Test First applies when you have a conceptual understanding of what your program will look like and hence you can architect all of your tests at the beginning, before building out your product. When I heard that description, I immediately thought of the traditional waterfall development process. On the other hand, when you’re not exactly sure of how your end product will look like, TDD is your true companion. It seems to work best with an agile development process where the testing becomes an essential component of the development – an intermeshed unity.

In terms of the levels of tests, there are unit tests, integrative tests, and functional and acceptance tests. You can think of unit tests as atomic in nature – they deal with isolated chunks of code. Integrative tests are a step up from unit tests and focus more on the interaction between the various units. If the unit tests focused on individual islands, the integrative tests would focus on the ecosystem of those islands as a collective entity. It is important to note that these first two tests are from the developer’s perspective. The functional and acceptance tests are viewed from the user’s perspective (e.g. black-box testing) such that you’re focusing on the deliverables that your average customer will be concerned with. For instance, the average Facebook user does not care what specific code is being used at any given moment – one is simply concerned whether or not one can connect with one’s friends, upload photos, and send messages etc. Following that discussion, we also took the time to go over the Ruby testing frameworks: (1) Test-unit, (2) Mini-test, and (3) Rspec. Personally, I feel better suited to Rspec as it is focused more on writing specifications rather than explicit tests; perhaps, as I grow in skill, I’ll see the value in Mini-test but that won’t be for a while.

Finally, one key take-away from the lecture on TDD was the five elements of a good test, namely:

  1. A good test is isolated,
  2. A good test, tests the APIs, not the internals,
  3. A good test is quick to write,
  4. A good test is quick to run, and
  5. A good test is unique.

Following the content portion of the lecture, we explored various test files on Github like Shopify/active_merchant, sparklemotion/nokogiri, stripe/stripe-ruby, and colszowka/simplecov (with an emphasis on how useful simplecov was as a barometer for how well a given program is being tested). Nonetheless, what I gathered from this little excursion is that if one is launching a tech startup, one definitely needs to have a GitHub account exclusively for one’s company – not contributing to the open source movement would be a fatal move. On that note, I recently initiated a Quora question, asking for good introductory texts on the history and philosophy of the Open Source movement. Two prominent texts that came up were “The Cathedral and the Bazaar” by Eric S. Raymond, and “The Open Source Alternative” by Heather J. Meeker.  I recently bought them and would recommend them eagerly to my fellow open source enthusiasts, so we may learn more about the history of the movement that we are contributing to through our growing GitHub profiles.

Time to Get Serious | Day 5

We’re all rolling up our sleeves now as the first week has come and gone. Those who have grasped Ruby are sailing through calm waters at the moment while the rest of us will be spending the weekend cracking down on the gaps in our understanding. The common insight that I’m gathering from various conversations is that, over the weekend, most students will be reviewing certain aspects of the prework and all of the assignments that we have gone through over the past few days.

Before one jumps to the conclusion that we’re slow at grasping concepts, it’s important to understand that the second cohort of Bitmaker Labs is doing far more than what the first cohort did a couple of months ago. What we touched on the second day was equivalent to what our predecessors did in their second week. The prework for this course was significant in order to get us up to the level necessary for the significantly increased expectations. Nonetheless, no amount of preparation can make you ready for the actual experience – something we’re all learning as we’re faced with the coder’s equivalent of a blank page and told to make something out of it. It doesn’t matter how many times you’ve shadow boxed if you’ve never been in the ring – we’re in the ring now, we feel the pressure, and we’re training for our next fight. Or, rather, we’re stuck in the ring in a multi-round fight and the only way to survive is to keep pushing forward.

Really, I think that’s one of the benefits of going to these types of bootcamps. In the end, the learning is in your hands – it always has been and always will – but they provide you with a facilitative environment and an atmosphere of high expectations that helps you along your path. After finishing my final university exams I had a month to prepare for this course yet I did more work in the past week than I did over those thirty days. Goals and expectations are set and it is up to you rise to them; your peers inspire you to work harder in the same way that you inspire them; everything exists to energize you. Moreover, if you ever encounter a problem, there’s always a fellow student or the instructors who are able to point you in the right direction. Finally, the most important element that I see at BML is the general freedom that you have in your day – other than the lecture, the structure of the entire day is at your discretion in how you choose to solve the problems presented to you. In many ways, it’s the perfect preparation for a startup environment and I’m glad that it’s structured in such a manner.

Before wrapping this up, it’s worth mentioning the fun project that we had to do. Does anyone remember IRC? I certainly don’t – I was part of the MSN generation. Nonetheless, I had always heard about IRC but steered away from it because I always assumed it was through IRC that little kiddies met “friends” who ended up being Bob the child molester. That aside, we were learning how to make IRC bots in Ruby today; nevertheless, we all downloaded LimeChat and decided to troll each other on the bitmaker channel during the lecture. Creating bots? Naw, let’s pretend like we’re in middle school again – it was good fun.

In short, a weekend of hard work awaits us but it’s within an environment that is pushing us to be our best. Time to buckle down.

Consolidating Ruby Syntax | Day 4

Rather than going through a traditional content-based lecture today, it was more hands-on such that we went through an ad hoc problem as a class – it was helpful in that we had the opportunity to crowdsource the problem in a heuristic manner. The benefit was really in just being able to approach the problem with an open mind and, yet, in a methodical manner – the paradoxical state of freedom emerging through accepted constraints.

With each day we’re progressing deeper in our understanding of the Ruby language and its underlying syntax – it is essential to have this foundation before moving forward with the Rails framework (you have to walk before you can run, after all). After the lecture, we were presented with a CRM project to work on, in the spirit of 37signals. I’ll most likely be finishing off that assignment on the weekend.

In any case, most of the day was really spent consolidating our understanding of Ruby. I spent several hours reading through Huw Collingbourne’s “The Little Book of Ruby” and then, afterwards, there was a group session on Ruby fundamentals. One of the highlights was Will explaining the mechanisms of the initialize method, regarding how it possesses an internal form of communication, which could be constituted by random words, and a global one which is accessible from descendent classes. Also, it was beneficial to be able to ask any question that one wanted, even if it appeared trivial. For instance, I wasn’t sure what the self in something like self.method meant and Will clarified for me that the self referred to the class itself. Small things like that, but asking those questions helped everyone in the session grasp the intricacies. Another moment that distinctly stood out was, again, when we were discussing the initialize method. I knew that initialize and .new were constructors from my readings but never really grasped the interrelationship between them: having someone explicitly making the connection for you, saying “initialize is performing .new,” helps you cement the blocks of your partial knowledge into a structure of consolidated understanding. There should definitely be more sessions like this in the future, especially when the concepts become more complex.

On a less serious note, I had the opportunity to discover Toronto’s underground PATH today and it reminded a lot of what Montreal has. Being a suburb kid who immediately went to Montreal after high school, I never had the opportunity to explore Toronto. I often joke to myself that I know Montreal better than what’s supposed to be my hometown – that’s going to change. I definitely won’t have much time to explore Toronto while at Bitmaker Labs – the workload is pretty heavy – but I’ll be making the effort to do so afterwards. Can’t wait to immerse myself more fully in TO’s tech and entrepreneurial scene!