Thursday, May 29, 2014

Let's Talk Tools

There's thousands of blogs, tutorials, and YouTube videos on how to write if statements and for loops.  There's thousands of different recommendations on good practices and what it means to write "good code" but the truth is, I was coding for a long time before I had any idea how many tools there were out there.  So this blog post is for the newbie programmer.  I'm going to recommend some tools for you and explain what they're for.  Maybe you'll be smarter than me, and start using them early on in your career.  Everything I'm listing here is free. Yes, there are pay versions of some of these products, but I'm linking you to free downloads, because coding isn't about waiting until you get a job.  Start using these at home today. They will make your career.

Your pencil and paper, the Text Editor:

The text editor is your sketchpad, your quick note taker, and your spare code storage.  Every programmer has his or her favorite.  The important thing is that you find yours.  Every useful person has a way of jotting down information so that he can relieve his busy brain from the burden of remembering it.  That's what your text editor is for.  Notepad or gedit/nano just is not enough.  You need syntax highlighting (after all, you're writing code).  You need tools for things like annotation and techniques for file organization of your notes.  It's an extension of your brain, so you'd better love it.  Here are a few:

Your office, the Integrated Development Environment:

Your IDE is where you go when you need to get actual work done.  It's what you use to help you focus on the code and how it all works together.  From your IDE, you can see it all.  Your Text Editor may try to act like it, but it just isn't an IDE.  Your IDE combines the text editors features with automated builds, the ability to preview code changes, and examine compiler errors more closely.  It truly is an entire environment in which you must immerse yourself to work on programs.  It is more like an office than you think.  Like an office, you need to customize it for your personal use.  And like an office, the company you work for is probably going to choose which one you get.  Learn as many as you can, so you're prepared when you work for a company that doesn't work with your favorite.  Here are a few:

Your filing cabinet, Source Control:

Source control is just as important as your IDE.  It keeps track of everything you've done, and everything everyone else has done, just in case you have to take over after them.  It's historical data, detailed and extremely extensive.  It's not the sort of thing you have to deep dive every day, but you should be checking in code daily, just as you'd file things in a filing cabinet every day.  Source Control seems like a tedious addition to the novice developer, but I can tell you from experience that it actually makes things easier.  Plus, and this should be very important to you as you're getting yelled at by more experienced developers every time you make a tiny mistake: it accurately places blame.  You can prove when things aren't your fault.  That alone should make it worth your while.  Like your IDE, most jobs are not going to let you pick your own Source Control, but understanding the basics of how Source Control works (and using it at home) can really benefit you in any position.  Here are a few:

Your employees, the Build Server:

Sure, entry level jobs don't usually come with employees, but if you ever want to move up, you benefit from learning how to configure builds on a build server.  First, configuring a build server at home, allows you to save time when building personal projects (when they're big).  Second, knowledge of how builds work allows you to avoid common debugging pitfalls, and convinces your boss that you're due for a raise. Plus, automatically building code is soothing.  Less work to do, more stuff that you can get done.  Especially if you want to write enough code to fix the whole world, you really need to save time wherever you can.  A build server is a lot like having employees.  You have to teach them how to do the job, which can be tedious and difficult because it's not always easy to explain it.  Then, when you change things, you have to reinvest time in retraining them to do things the new way.  But it's soooo much better than doing it yourself.  It's fairly likely that your company will not use a free one, but the things they do are pretty much the same.  Here are a few build servers you can try at home:

The reports for your boss, Requirements Tracking (aka Bug Database):

As programmers, our bosses really have no clue what it is we do.  But, like all good bosses, they need reports from their employees about what they're doing.  So a requirements tracking tool can do this for them.  It allows us to show them what specific things the users asked for that we're working on, and how hard it is to do.  This, again, is something you'll want to know how to manage to impress your boss, but you also benefit from it, so you don't forget what you need to work on, like the in-box on your desk.  Again, it's fairly likely that your company will not use a free one, but the things they do are pretty much the same.

Your conference room, a Forum:

This can be a bulletin board, a shared wiki, or just a work-only chatroom with easy to read logs.  The point is that you don't work alone.  You need to collaborate with other people you work with, and that collaboration needs to be tracked, so that the new guy who joins your group can go and read up on all of the previous discussions before he interjects something crazy like "Let's all switch to PostgreSQL".  Here are a few, but there are literally thousands out there:

  • Discourse - Jeff Atwood built it
  • PHPBB - You can set this up in just a few clicks on a Windows machine
  • MediaWiki - Free Wiki you can set up for yourself

Your phone, IMs:

You need to collaborate with other developers, but we all know that phone calls are way too intrusive during a normal development day.  Furthermore, one of the biggest mistakes new developers make is hovering around the Senior Developer's desk when they've got a question.  It's much less intrusive, and you're much more likely to get polite explanations if you use IMs to communicate.

  • HipChat - This thing is getting huge fast
  • Skype - Most Popular
  • AIM - Been around forever
  • Internet Relay Chat - The dangerous underground internet, linking you to mIRC, a client that is used to connect to IRC, but there are many different clients for it also

Your Google, the Open Source world:

While you'll use Google all the time for coding questions, most office people use it only on the rare occasion that they don't understand something about their job (we developers always are confused about something).  So in this sense, Open Source is our resource for solving problems that are waaaaaay out of our league.  If the boss suddenly needs a solution to a problem that's way over your head, there's a good chance someone else has solved it, and you can look like a hero by just running that program.  That's what I'm talking about here.  There are lots of great places to find code out there:

  • GitHub - The most popular right now
  • Google Code - By Google, for Everyone
  • BitBucket - Free private code storage on the internet too
  • StackOverflow - Q&A for coders, including chat and much better than IRC

If it's not clear at this point, what I didn't realize when I was a young programmer was that, if there's a tool I need, it probably exists.  Don't do things the hard way.  Take the time to learn the tool that will make your life easier.  It will make you a better developer.

Monday, May 5, 2014

Work Smarter, Not Harder

So a few weeks back, I checked in over 600 files worth of code in one day, and it occurred to me that that was a lot.  Why so much?  I was reorganizing code that was scattered about one large project into multiple projects so that it would build as libraries and so that there was some semblance of sanity to the location of things like objects and methods.

I know that I'm a fast programmer, but I think other people believe that I spend all day at the keyboard sweating trying to get that much code in, and that simply isn't true.  So here's my tips on how to work smarter, not harder, and get a lot of code on the books.

I should note that all of these screen shots I'll be presenting were taken during the actual exercise of cleaning and reorganizing code.  These are not "examples" or "samples" but actual code in a real environment.  The things I'm showing here are the actual things I did in the course of building the 600 files that I checked in.

Use your IDE

I cannot emphasize the value of an Integrated Development Environment.  In the examples I'll be giving you, I'll be using Visual Studio, but there are dozens of spectacular IDEs with very similar features out there.  Using your IDE is not just a matter of understanding the text editor.  You need to explore plugins, learn the shortcut keys, try out different features, and ultimately figure out what makes you most efficient.  Yes, the learning period for an IDE is extensive (took me about 3 months to learn VS) but the payoff is worth it.  For example, in Visual Studio, the shortcut Ctrl + . is a quick way to add using statements when your cursor is on a class name that has not been imported into the file you're working on.

Learn Regular Expressions

Don't be fooled by jokes about RegEx.  Regular Expressions save my butt every day.  During my 600 file change day, I updated about 80% of the files with 2 Regular Expressions, saving myself a ton of time.  No, I absolutely do not advise you to live by them, but the rule applies with everything.  Use the right tool for the right job.  In the case of RegEx, we're talking about a jackhammer.  It can seriously dig through the crap for you, as long as you don't try and use it on a porcelain vase.

Read Documentation

In this case, I'm referring to MSDN, and how you can quickly find the assembly for a strange class so you can reference it, but the same thing applies to all documentation.  It's extremely easy to find things in the documentation if you know how to read it.  And the only way to get used to reading it is to read a lot of it, so read your documentation.

Read The (Build) Errors

Build errors aren't the only kind, but chances are your IDE is constantly presenting you with error information about your code.  Read it, and learn how to read it quickly and identify the important information.  It can save you a ton of time to know how to read a stack trace, or even just memorizing common error messages and their causes.  Below, notice how I've highlighted an example error message that is a result of other errors (the library didn't build, so the other libraries that depend on it couldn't find it) and then an example of an actual error that was part of the source problem (missing a reference).

Build Everything

Visual Studio has a feature called "Rebuild" which deletes everything in the directories before running "Build".  Most developers use "Build" because it's faster, and only builds files that VS is aware of changes to.  Most of the IDEs (well, the build commands because most IDEs are only wrappers for build commands) have configuration settings or something to define this same concept.  I always recommend taking the longer, delete first, approach to building software, because the IDE is stupid, and I once spent 6 hours debugging a project only to find that an artifact had been left behind in the build directory and was causing everything to break.  Never again, I said.  I mean it, the extra 30 seconds for a full delete and rebuild are worth it to avoid debugging hassles and serious strangeness.

Save All

This is a simple one.  Visual Studio, Eclipse, Android Studio, and heck even most text editors have a feature to Save All instead of just Save.  This saves all the file you've made changes to.  This is particularly useful if you change a ton of files at once with, for example, a regular expression.  Use Save All to save large sets of changes.

Use Search

There are literally hundreds of search features built into most IDEs.  In fact, there are even search Plugins you can download to enhance the search capabilities of your IDE.  The search box is literally thousands of times more efficient than trying to scan the code with your eyes.  Ctrl + F will save your career.  Use the search to find anything and everything, and if your IDE has fancy quick search features, all the better!  Master them!

Simplify it

The reason I made all these code changes in the first place was because the code I was looking at was basically unreadable.  Nothing pointed directly at anything.  Objects and methods were mishmashed into horrifying blobs of spaghetti code.  I couldn't find anything.  This is why code quality matters.  Taking the time to clean up code, or at least break what you're working on into small bite-sized chunks makes the extremely complex logic that is programming manageable, and even nightmarish spaghetti-code can be enjoyable.

If you guys have an other great tips, drop them in the comments.
Happy Coding.