Blog Moved

My blog has moved!

https://kmack.azurewebsites.net

Sunday, August 24, 2014

Setting the Standard and Practice Makes Perfect

Hello all, and I'm back again with another update, and honestly, this is a pretty timely topic for me.  We've all heard the term Coding Standards, and at many firms I've deal with they tend to be just some document sitting in a directory on the intranet collecting virtual dust.  But I want to discuss this particular idea and how this is a commonly underutilized tool for many senior developers, and something that is not being given enough weight by junior developers.

By definition, Coding Standards and Practices are a set of rules, and guidelines for developing code.  They are a formal document defining what programmers are allowed to do, and what they aren't allowed to do when writing their applications.  These standards should be enforced using tools like formal code reviews.  Honestly, when you say it out loud, this sounds absolutely essential, but in practice I find that these kinds of documents tend to fall by the wayside.  The benefits of coding standards should be fairly obvious, and I'm not going to list them here.  What I'm going to discuss is how to keep them current and make them work for you as a Senior Developer.

Step #1.)  Make sure they stay current.
The biggest reason I've found historically that these kinds of documents aren't used is because the last time they were updated was roughly 5 years ago, which in this industry might as well be a lifetime.  So what can you do?  If you're like most developers, you hear keep these documents current and think...oh god no, not paperwork.  Programmers have an aversion to paperwork like vampires do to sunlight.  The secret to this is pretty simple.  Keep the document light.  First and foremost, no one wants to keep a 50+ page document updated, and worse yet no junior developer wants to read it.  So do both sides a favor, and keep them simple and short.  Keep everything to the point!  Focus on the absolute most important standards only.

Step #2.) Ditch the master document.
Another way to help with #1, and keep your jr developers attention is to not keep one master document.  This is a huge waste of effort, it makes for having that long document, and your trying to create a one size fits all standard, which is never going to work.  Instead I propose that you create documents either by domain (web, mobile, service, database), or by technology (MVC, JS, Knockout.js, Angular.js, etc).  This will make the updating process easier, and it allows Developers to pick which standards to use on their projects, and they are not overloaded.  Also given that your standards are more targeted, the more likely they will be followed, and the better the quality of the standards.

Step #3.) Regularly meet with other senior developers to discuss the standards. 
Set up a regular meeting with other senior developers to discuss and deliberate about the standards, identifying standards that need updated, and standards that need to be retired.  This will allow for a constant updating of this document and minimize the amount of time spent by everyone on updating.  At the end of the meeting, each separate senior developer should have to update some of the standards documents.

Step #4.)  Bring a copy of relevant standards to code reviews.
If you bring them, then you will be more likely to use them.  The fact that the document is in front of you, will make you think about it more, and enforce it more.  The more you enforce it, the better the habits of your junior developers will become.

There will likely be more on this topic soon, but I wanted to post these thoughts right away.  Please feel free to discuss as I would love to start a dialog about this.

Tuesday, August 12, 2014

Exam 70-480

Hello All, I'm back.  As for the quick update, things have been particularly busy right now for the entire Mack Family.  We've been in a state of constant flux lately, both personally and professionally for a little while now.  And its been a little rough on everyone.  Professionally, I've been busy working on several projects.  I continue to work with Xamarin, on one of my companies first mobile applications to be deployed to the app store, right now specifically for iPhone and iPad.  Aside from that project, I've been doing a lot of work with SSIS lately.

For those who don't know what that is, it stands for SQL Server Integration Services.  And its a tool that allows you to build packages to help import and transform data to be added to a SQL database.  It is built to utilize tools to help import and work with large volumes of data.  Definitely possibility for a future blog post, and I probably will.

Outside of that, I've been gearing up for a new semester which starts in a week.  I am about to kick off my 7th semester teaching a course called "Development Fundamentals".  And I have to tell you, its definitely something I look forward to.  There's something really fun about helping people who are starting out in this field, find the passion that I and so many of my colleagues see in it.

But anyway, I digress.  The reason for this post, today I took the first of three exams designed to obtain my MCSD (Microsoft Certified Solutions Developer).  I've made the decision to finally pursue mine, and will be doing it in a very short timeframe.  I passed my exam today, with a pretty good score, and the exam rated me as strong in all skill categories.  I wanted to pass along the resources I had found that helped me to study for exam.

The following were resources I used:

  • Programming in HTML5 with Javascript and CSS3 training guide:  This book can be found on Amazon here. I found this book to be very helpful, and it covered about 90% of the material on the test.
  • Microsoft Virtual Academy:  I found a video course taught by Mike Palermo and Jeremy Foster that prepares you for this exam.  I found that the parts that the book missed, they covered here.
  • PluralSight:  Another great source is this plural sight course, found here.
  • Blogged by Chris Study Guide:  Another great post, this one outlines a lot of the different topics that are covered in the exam.  Found here.
I'm planning on doing more posts as I study for the second exam.  More on it then.  

Monday, August 4, 2014

Lack of Updates and Attention to Detail

Hello All, I know its been a while since my last post.  And I felt that I should at least post something up here for those who have been following along with my updates to this blog.

As for the lack of updates, the reason is actually pretty simple, I've been on vacation, and much like most of us in a professional setting.  There was a lot of work preparing for vacation, and then the actual week of being on vacation.

My wife, and the Munchkin had a great vacation, and I completely enjoyed my time but am excited to get back to work.  I have actually been working on a few new articles, all of which should start to be available as soon as the weekend.  So watch this space for those updates.  Specifically I got one technical, and one that's more like the philosophy articles I've done so far ("How to be a dinosaur" and "Taking the Romance Out of Software Development").

Thank you all for the continued support and feedback.

But I do have simple advice for anyone out there who is a junior developers out there.  And to me honestly, this is one of those things that I wouldn't think are necessary to point out.  But everyone out there wants to Steve Jobs, they want to walk into a meeting wearing bravado on their sleeve and being the smartest guy in the room.

Be honest, we all want that, we've all seen "The Social Network" and want to be Jesse Eisenberg, but again this is a distorted dream, that many junior developers fall prey to.  The truth is that the smartest guy in the room, usually isn't the one who walks in and ignores everyone else's opinion, and he isn't the guy who always gets his way.

The truth is that the smartest guy in the room, is the one sitting in the back, holding a notebook.  You've probably seen him, he's the guy who's setting up the meeting, or encouraging everyone to speak.  Truth be told he probably seems to many junior developers as a fly on the wall.  But my advice to anyone new to this field is to watch this person, and try to become him.

Solicits Opinions of Others:

There is a concept discussed in terms of Web Application Development called Collective Intelligence.  This is hardly a new concept, and its something that many of the most profitable websites / web apps have fully embraced.  Collective Intelligence is the idea that by having everyone involved in a process that we are smarter as a group than we are as individuals.  Its the age old "Two heads are better than one".  The idea that by working together and discussing ideas freely, a better solution will present itself.

Encourages Everyone to Speak:

Margaret Heffernan is a business woman and writer, and recently said "For Good Ideas, and True Innovation, you need human interaction, conflict, argument, and debate."  And she's absolutely right, the best ideas come from discussion, and the process of soliciting opinions only works when everyone is given the opportunity to free express an idea.  Truth be told, even a half baked idea can lead to a major innovation.

Think Before You Speak:

I know, this one sounds counter to the one above.  Just because everyone should be able to share ideas doesn't mean that you need to throw anything out there that comes to mind.  What I mainly mean by this, is before you give a knee jerk reaction to ideas that are thrown out to the room, think about it.  Weigh the benefits and the drawbacks, think about options for mitigating those drawbacks, and whenever you are ready contribute to the discussion in a meaningful way.

Take Notes:

The most important advice I can give, is take notes in these meetings.  Identify action items and make notes of the items discussed.  The more detailed notes you can take, the better you can walk away from the meeting with knowledge that can effect change and enable you to accomplish more.

If you follow these steps, you'll find that you get more out of these meetings and become a better member of the team.  Your peers and supervisors will take notice, and you will find you enjoy your job and the process more.