Winner's Excogitations

A chronicle of the thoughts, learning experiences, ideas and actions of a tech junkie, .NET, JS and Mobile dev, aspiring entrepreneur, devout Christian and travel enthusiast.

Andela Bootcamp - What I learnt (Part 1)

7 years ago · 5 minutes read

e8ofo54o62lhuk20zcbj

I recently went through Andela boot camp cycle XVIII from the 16th of May to the 27th of May this year. I mentioned in a previous post that my experience at the boot camp was extremely informative and educative. I promised to give a synopsis of the boot camp and I aim to deliver in this post. The boot camp lasted two weeks, and we covered eighteen topics in the course of those two weeks. I will not go exhaustively into every detail of what we did, but I’ll show the broad range of disciplines we had to absorb knowledge from. All in all, I came to understand that software development was much more than writing code.

  1. Git: During boot camp, I was first introduced to the concept of version control, the root idea which spawned version control systems like Git, SVN, and TFS. I’ll do a tutorial on command line git itself in the near future.

  2. Programming Logic: We first discussed the various programming paradigms that exist and how they differ. Next, we how and why code is sub divided and grouped. We also learned the principles that help software developers decide when to group code.

  3. Relationship Building: this dealt with our ability to relate or interact with (if tautology isn’t your thing) not just co-boot campers but fellows and Andelans as well. It dealt with breaking the barriers that exist when different people from different places are brought into close proximity with and need to work with one another. To be sincere, this was the most uncomfortable part for me as I find it a bit difficult to strike up conversations with strangers, but as the trainer pointed out, you only need one thing in common with the stranger and he/she is not really a stranger anymore.

  4. Questions: a person’s ability to ask questions, not random questions, but questions that elicit thoughtful and informative answers, is an art that only practice can teach. But to in that art lie some fundamental principles that I was exposed to. I was also taught the different broad categories of questions, and when each is necessary.

  5. OOP (Object Oriented Programming): I was quite happy when we got to this topic because I had been developing in C# which has OOP principles at its core, but I tell you, OOP in JavaScript is a different beast altogether. I had to create a class, constructor and member methods in a language that until ES6, didn’t have any special syntax for any of the three and which used camel case for everything, variable names, method (function) declarations, etc. It was a grueling transition, but it was worth it in the sense that I broke me out of the shell I was casting myself into.

  6. TDD (Test Driven Development): this was arguably the most absurd thing I had to learn. Let me try and explain to non-programmers, imagine you want to cast a reinforced concrete pillar. You create the wooden cast for the pillar and set it up. But instead of putting the iron rods in, pouring the concrete and then waiting for it to set before testing for strength, you are told by your supervisor to first push the empty cast to ‘see’ if it falls. You that, and of course it falls, then your supervisor allows you to add the rods, pour the concrete and allow it to set. Then you try pushing it again and surprise-surprise, it doesn’t tip over again. That’s exactly how test-driven development works. You have a set of requirements given by the clients, based on those requirements, you the developer writes out tests. These tests are blocks of code that make sure your program delivers what it is supposed to. You run those tests and as is expected, they fail (you’ve not written the program you’re testing yet). It is only after they fail that you are free to write code to implement your requirements and handle all test cases. This process is known as the red-green-refactor cycle. If it still sounds like gibberish to you after my valiant attempt at an explanation, don’t be dismayed, if you continue down the software development path, you’ll definitely meet soon.

  7. Writing Proficiency: as a human being, you might not get to travel to every place in the world but your writings can. And you as a person would be judged based on the quality of your writing. This was the idea being hammered into us in this topic. I was taught to make my writing concise, coherent and absorbing. And trust Andela, we were tested on it.

  8. Agile Programming: In programming circles, ‘agile’ is probably the buzzword most thrown around. It is mostly used by douche programmers trying to show their self-importance (this is the opinion of the author and should not be taken as the word of the gods or Morgan Freeman). Despite this, agile is a very important software development methodology that like our fast-food age, seeks to get quality work done in as little time as possible by removing the elaborate planning and documentation processes of earlier methodologies. This allows development teams to be nimble and very adaptable to changing software requirements. This here author is very proud to say that he is a signatory to the agile manifesto (yes, it’s a thing. Google it).

  9. Feedback: I studied Electrical and Electronics Engineering at the Federal University of Technology, Akure and in the course of my studies I took several control engineering courses. One of the first things that became apparent to me was that the most robust control systems had feedback loops. This holds true for life as well, if we would develop as humans, feedback is indispensable. In software development, feedback is what makes you a world class developer. Feedback from the community (developer community, not your local government) in the case of an open source project, feedback from your colleagues and boss help you become a better programmer because they’ll open your eyes to things you may not have considered on your own. But receiving feedback requires humility because feedback won’t always come the way you like, but receive the good and the bad alike.

The post was getting kind of long and in keeping with the rules of concision, I’ll write the second set of nine topics in a subsequent post. Thanks.

Share on:
My Perfect Devices 2014
A breakdown of specifications of devices I feel would be perfect for me and most other tech enthusiasts based on the available technology.
What makes a good software architect?
A nugget I got while browsing through Quora about the attributes that make a software developer truly great
Winner-Timothy Bolorunduro
Winner-Timothy Bolorunduro is a senior .NET developer with over 6 years experience helping organizations and individuals build compelling, stable and scalable web applications. Having spent the last three years in a fast-paced startup environment working remotely, he understands what goes into being part of a team that produces value for clients.

Comments