Skip to main content

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.

Comments

Popular posts from this blog

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…