Initial Thoughts on C#

Having just started the second half of the curriculum here at Nashville Software School, I am neck deep in C#. It’s been a very humbling reminder of my initial feelings three months ago with JavaScript, when I had just started NSS and was desperately trying to master the syntax and possibilities for my first programming language. But that reminder is encouraging, seeing how far I’ve come in a short three months, I’m confident that I can do it again with this new language, and potentially accomplish even more. In the meantime, I’ve found it surprisingly refreshing to take a break from my C# studies by working on some side projects I had started in JavaScript, where I actually know my around (enough).

The biggest shock to my system thus far with C# has been static typing. In JavaScript I rarely had to think about what type of data a variable would hold when I created it. That was convenient at times, but also turn into a breeding ground for bugs. Not explicitly declaring types also made it that much harder for other engineers to digest my code, resulting in more comments or even longer variable names. Working through challenges in C# that I never even had to consider in my front-end life has been a rewarding experience, and I’m even starting to carry some of those explicit principles through to my JavaScript code. While jarring at first, I’m learning to find comfort and elegance in explicit typing.

Speaking of types, there are so many! I’m fortunate to have an instructor team to guide me through the jungle here, working through use cases for certain types and explaining why others have been deprecated or are not applicable to certain situations. I also gained some enlightenment by working through Cory Foy’s koans repo, which helped understand–among other things–the intricacies of Array’s and why we rarely use them.

Also finally had a proper introduction to Test Driven Development, which, at first glance, seems far more straightforward to execute in C# than in the front-end applications we had been developing. Funny side note, I attended a JavaScript meetup just last night and heard an excellent talk from Jonathan Boston that–among other things–inspired me to write front-end code that can be easily tested without browser automation. Anyway, I’m looking forward to starting a project with TDD in mind. If done properly, bugs can be identified almost as soon as they’re created, and you have an explicit jumping off point for debugging. Previously, I could have created a bug without knowing it, and by the time it reared its ugly head, I’ve already written another thousand lines of code and have a heck of a time reverting back.

We’ve also spent a lot of time as a class discussing higher-level programming concepts. I really enjoy stretching my brain with theory, and have a bit of experience from college and my past career that I can apply to concepts like Entity Relationship Models and data structure. I’m excited to dig deeper into database languages like NoSQL and finally put together the complete picture of a full-stack application.

Tomorrow we’re going to work through building our own API. It’s crazy to think that we’re at this point after just a week of learning the syntax and philosophies of C#, but that’s encouraging more than anything else. Hopefully the other languages I plan to dig into over the next few months will get easier and easier the more I have under my belt.

Until next time, thanks for reading!

Final Thoughts on Front-End Development

As I dive headfirst into server-side development with C#, I wanted to take a moment to reflect on what I’ve learned over the past three months, and what I hope to accomplish with the last half of my Nashville Software School career. While I’m sure this is only the beginning of my engagement with front-end development (I mean, I’ve only just dipped my toe into the water here), my experience with Javascript has given me some expectation of what to expect on the server-side.

After a few weeks studying Javascript at NSS, I began to wonder exactly what server-side development would answer. It seemed like I was getting a really full toolbet for developing software. What else was there that Javascript in the browser couldn’t do, but C# on a server could? In retrospect, that was a fairly naive assertion, but one that set my brain in the right direction.

As I was neck-deep in my final front-end project and started dealing with fairly large workloads, I started wishing I could hook up to a back-end to handle some of that processing and provide a more consistent experience. I ran into errors more than once on my capstone that I chocked up to performance hiccups and solved by haphazardly refreshing the page. I wonder if having a persistent backend environment would alleviate any of that unpredictable behavior.

At the very least, having a fully featured backend would help modularize my application and provide better separation of concerns. Front-end code could focus on front-end concerns exclusively, and the back-end could do more than just persist information.

One thing I’ve been told to expect about C# is a far greater rigidity. At first glance that sounds scary, but could also be comforting to have a shorter list of acceptable solutions to a given problem, framing our developing minds a little more consistently. The flexibility of Javascript can be both elegant and exhausting. When faced with a problem in Javascript, there can be as many as twenty different solutions or more. And it’s very easy to choose a solution now that spirals downward dramatically into a much larger problem later on, all because I didn’t fully consider and track all twenty solutions available to me.

I’ve also heard that there’s a longer path to results. It’s not longer as easy as refreshing the browser window to witness the fruits of your labor at any point in time. Maybe more “blind coding” is necessary, writing lines and lines of code before being able to test. That doesn’t worry me too much, I like thinking through problems and can usually write logic I need blindly without having to pause for a console.log every two steps.

More than anything, I am expecting a very different environment, and am looking forward to the challenge.

Front-End Capstone

Next week marks the halfway point for my career at Nashville Software School, amazing how quickly that time has passed. To cap our front-end coursework, every student has independently developed a client-side application (hooked up to Firebase) that we are presenting to the entire school tomorrow . With almost two weeks devoted to the task, this was really the first opportunity we had to develop something fully-featured and–dare I say–cool.

Today, each of my classmates presented their MVP as a “soft demo” to just our class, and I must say, I’m very impressed. Among 25 different applications, almost every one had at least one feature or view that wowed the audience and prompted a “how did you do that?!” question at the end of their demo. This struck me as inspirational, that just because your app doesn’t necessarily look as polished as Facebook (and probably has a few bugs under the carpet), doesn’t mean that it isn’t an impressive accomplishment. Everyone in the room had no trouble looking past the shiny exterior and appreciating the individual coding feats that everyone was able to achieve.

Personally, I have a lot of frustrations with my final product, but that doesn’t stop me from being proud of what I’ve been able to accomplish so far. And I am by no means discouraged from continuing to work on this app in my free time over the next three months. That being said, this was a learning experience like no other and I wanted to share a few of my “lessons learned” from this project.

Prioritize features and know when to give up (or ask for help)

While I maintained a fairly extensive Trello board to organize my thoughts and maintain focus, I found myself getting distracted by that “shiny feature over there” more than once. Sometimes I was able to accomplish that feature quickly, sometimes it took me a while, and sometimes I couldn’t get it working at all. At the end of the day, especially if that feature didn’t come easily, I might have neglected a feature more important to the user experience because I wasn’t focused correctly on my priorities. This will be a little easier in a professional environment where I don’t get to determine the priority (the product owner does that), but is still a weakness I need to be aware of and improve upon.

Know how your frameworks work (and cooperate)

A lot of the major challenges I encountered while developing my project were specifically a result of combining TurnJS with AngularJS. See, a feature of TurnJS is to only keep 6 pages of your flipbook in the DOM at any one time (for resource utilization, I think). The problem is, when TurnJS removes that content from the DOM, all of the Angular bindings are destroyed and basically need to be recompiled before added back to the DOM to maintain functionality. The first time this happened, it took me hours to diagnose. After I understood that interaction, it was much easier to troubleshoot future Angular issues, and I started getting pretty creative coming up with workarounds.

Don’t forget to have fun

The best decision I made was to pick an app that I actually had a need for personally. Being able to put myself in the shoes of the user, and work on features and functionality that I specifically have yearned for over the years, made all of the pitfalls and stressful moments much easier to power through.

Curious to check out my app? It’s live here, bugs and all:

My first pet projects

One of the biggest challenges I’ve faced about learning in a classroom is relating my coursework to current, real-world applications. Don’t get me wrong, understanding theory is essential to mastering the concept, but it’s all for naught if you can’t apply that concept to a real project. Similarly, being hyper-focused on a single topic is required to pick up the fundamentals, but without drawing relationships to your existing knowledge base it can feel like learning in a silo.

After completing dozens and dozens of exercises throughout my first month at NSS, I’m very skilled at standing up bare-bone apps quickly, each satisfying a short list of focused requirements; but most of these I may never revisit. I’m just hitting the quarter mark this week of my journey through NSS, and with that I’ve started feeling an itch to develop more fully-fledged projects.

Of course, I’m expecting to complete three major, capstone projects amongst all of the individual exercises and group projects as part of the curriculum, but personal projects sound way more exciting. Not only is it fun to own the vision for your software, but these apps will flex all of my brain’s muscles, grow alongside my study of development, and eventually be “pageant-ready” to showcase to potential employers and the development community at large.

That being said, I’ve already started work on few projects to take me into the next few months. Mentioned in the last blog post, I’ve built the base wireframe for my personal website (check my progress here). Currently I’m working to rid myself of the WordPress overlord by implementing Jekyll to publish this blog directly to my website.

A second project is related to the group messaging app that my friends have used for years, GroupMe. We’ve always wanted to export our entire conversation to potentially print in a book, analyze statistics, or pull out a few stellar quotes, but I was never able to find an easy-to-use solution. Anyway, I decided to dig into GroupMe’s API to make that happen, and a few hours later I had basic functionality up and running, pulling over 22,000 messages from our primary group chat. It feels pretty great to reach MVP so quickly on an idea that I’ve been struggling with for so many years, and there’s so many features to be added still. If I can launch a polished version of this in a few months, I expect it could get a fair amount of attention online.

Lastly, I’ve started meeting weekly with a group of like-minded students interested in learning the ins-and-outs of Raspberry Pi. One of our classmates set theirs up for us to SSH into, and later we decided to work on a simple photobooth project for use during Demo Days at NSS. I’m very excited to work on something a little more “physical”.

If all goes well, at some point it will be difficult to prioritize personal projects, school projects, community projects, etc. Right now I’m just starting to dream and it feels pretty good.

Beginner Product Management

At some point in High School I learned that finishing a creative thought is really hard to do. I remember performing a song I wrote to 1000+ people at a school talent show, and even in the green room before the show I was committing rewrites. Perfection is a fairly impossible goal, but as a creator it’s hard to settle for anything less; it’s hard to stop working on any project (well, deadlines help).

As I’m picking up this craft of software development, I’m trying to be even more deliberate about how I spend my time and on which material. As the pace of this curriculum accelerates, I need to achieve an understanding of every core concept as quickly as possible. This means not going on a deep dive of every fundamental, every time I start a new app. Many of the exercises on my GitHub at this point utilize very sparse CSS rules or none at all, and that’s because the curriculum places a bigger focus on JavaScript and manipulating the DOM (which is understandable, Bootstrap does a lot of work for you).

That being said, I have some work to do on my styling skills, especially after starting to get dirty with Bootstrap late last week. Tonight I’ll start building a personal website to showcase this blog and some of my major work from Nashville Software School. This personal project, along with several other large projects to come at NSS, will provide plenty of keyboard time to channel my inner designer and dig deep into stylesheets.

Anyway, lately I’ve found myself getting lots of “products” (read: classwork and other online exercises) up to the standards represented by the picture below…


…and it’s hard to put my name on this and call it a pizza. But I accomplished the goal, so maybe I’ll spend a little time refactoring my solution to add elegance and readability, I decide to move on. I understand that larger projects won’t necessarily offer this luxury, but having a constant focus on your minimum viable product is key to effectively distributing your time.

When I’m allotted a specific amount of time to complete a product, I focus my complete attention on completing the MVP ASAP, before any other features or styling. After MVP, you can assess your available time and make more intelligent decisions about which features would have the largest impact (and which are reasonably attainable). This can produce some unintended challenges later on–requiring you to refactor some code–but those are great learning experiences as well.

At the end of the day, I am proud of the quality of the time I’ve spent with software development, even though I don’t necessarily want to show off all of my apps. I’m still pretty far from having any sort of reasonable code portfolio to share with potential employers. But hey, for being a month in, I’d say I’m doing pretty good.

Group Projects

A couple of times last week, for most of the day the class was split up into small groups of three to complete an assignment. Primarily, these exercises were intended to introduce collaborating via git, but I was also introduced to the challenges and value of coding in teams.

The most immediate hurdle was deciding how to divide the work as intelligently as possible. For example, one of our projects was to build a simple website with at least three pages, and to fill one of those pages with product “cards” generated using JavaScript. I noticed immediately that many teams were assigning work by individual webpage, and and that’s exactly what I wanted to avoid.

Without clear style guidelines, everyone could construct their HTML DOM with different element names and structures, which would complicate styling immensely. Either each person would have to style their pages individually–requiring separate CSS files and redundant or even conflicting rules–or several pages would have to be rewritten to some extent to generate consistency.

Our group decided instead to divide up the work by feature, assigning responsibility for creating a nav bar, building the boilerplate HTML pages, writing the JS function, etc. I created a Trello board and began tracking features in three categories: ‘to do’, ‘in progress’ and ‘complete’. A lot of conversations occurred along the way to make design choices or help troubleshoot, but rarely was anyone duplicating or refactoring someone else’s code to accomplish the objective.

That being said, our project was not without challenges. While we did divide the work by feature, I wanted to make sure everyone in the group was confident with every piece of our app, which meant lots of review and starting-and-stopping. This slowed us down, but the experience was invaluable. We were able to learn from and to teach each other on a fairly constant basis, and heard up to three different approaches to the same problem at every step of the way.

The first pair of group projects were certainly a rough start, but I’m quickly acclimating to the pace of collaboration and already see the value in it. I’m expecting to collaborate dozens of times on small and large projects throughout my time at NSS (and obviously in the professional world at large). I’m excited for the challenge.

Beyond the Basics

I’m still getting a feel for the pacing at Nashville Software School, and resetting my expectations along the way. Perhaps there is no typical pacing–except for “everything at light speed”–as one might expect from a professional setting, which is potentially by design.

The biggest delta between my expectations and actuals has been the amount of classroom instruction. After so many years of classes where instruction would consume 90% of every day, experiencing the flip side of that equation was abrasive at first. But after a few days of minor irritation, I realized that this is exactly the pacing I was looking for.

One of the prospects of software development that drew me to the field originally is that of a constant learning curve. There’s always going to be some new technology or language or application on the horizon, waiting to be studied, understood and innovated upon. This classroom I’m in for the next ~6 months is a luxury. For me to realize that opportunity after graduation and for the rest of my career, it is going to be all on me.

One of my complaints about the higher education system today is that after so much time spent working in theory, many graduate without any of the soft skills or the real professional experience required to land a decent entry-level job. I am appreciating more and more the focus on “figuring it out” and collaboration that NSS offers, and am confident that I will have some rich experience to share with prospective colleagues and employers by the time December hits.

In terms of actual coding concepts, we started and finished JavaScript fundamentals last week. I’ve written over a dozen mini JS programs, and I finally understand what JSON means. There was a big focus on arrays and objects; I even borrowed Roger Sperberg’s amazing idea to print business cards with your contact information represented as a JavaScript object. My results below, click zoom in:

business card results

This week we’ve started on our first group project and are really challenging ourselves with Git. Also getting familiar with Trello and tiny-scale workflow management. Good times to come!