Three Advice to Newbie Programmers

It has been almost 4 years since I've started programming. In this period I've learned how to read code and how to write (more or less) readable code; worked on various small projects, and now regularly managing the codebase of one of these projects for 1.5 years. So now I can claim that I am not a complete noob anymore, probably a 'Junior Programmer', or a Level 1 programmer according to Programmer Competency Matrix who is slowly making his transition to level 2.

Being a student, sometimes I get help requests from classmates and juniors - especially in the last weeks of the semester when the deadline of the assignments and the term projects are approaching. It gives me a way to analyze what problems other starters are facing. Generally I help someone generously when he asks for guidance (I want to develop a chatting system for my Java term project. Where to start?) or he can express clearly what problem he is facing and what he has done so far to solve the problem. Unfortunately, most of the requests are "my code doesn't work, help me!" kind. I get really irritated when someone throws me some messy, semi-indented code which contains all the a-z alphabets as variable names and then tells me he doesn't know what error he is getting. Most of the cases, the only thing they tried to 'fix' the code is to do Voodoo Programming - changing this and that randomly and hoping that something magical would make the code work.

So if you are a newbie programmer, and you regularly spend hours in Voodoo programming, and then ask someone to fix your mess (or ask a question in Stackoverflow and get downvoted), here are three advice you might find very useful:

1. Learn how to identify the source of the error

In my opinion, finding the source of an error in a faulty portion of code is much more difficult and important than solving the error itself. Often it takes only a minute to solve a problem when the source is known. Finding the source is much more tricky. So, how do you find the source of the error? Debug it!

I often get astonished observing the lack of debugging knowledge in newbie programmers. Probably it is the fault of the learning system. Programming courses or books spares thousand words to teach you how to code - but often they won't teach you anything about how to debug. This is unfortunate, given the fact that you would spend a large portion of your time in debugging while developing something. Learning how to use a debugger is probably the single most important thing about programming that you can learn in 10 minutes. Of course, learning how to effectively use a debugger takes time and practice, but the basic operations of (e.g. setting a breakpoint and stepping through your code) shouldn't take more than 10 minutes. Search Google, pick a tutorial on how to use a debugger on your favorite IDE, learn it and use it regularly.
Of course, if you use the debugger for every single error, it will cost you a lot of time. Generally I try 'log based debugging' aka 'printf debugging' before starting my debugger. It is always a good idea to log important events and expected results in your code to catch the error early. Frameworks like Log4j makes it much easier to deal with a lot of logs.

Besides, never forget the importance of statically analyzing your code before running it to catch common errors. Unit tests also make finding errors quick and easy, but probably it would be a bit advanced for a beginner (I myself haven't used unit tests in any non-trivial projects so far, but I expect to do it in near future).

2. Learn how to solve the error

Once you have identified the source of the error, the solution would be obvious in most cases. But what if you face some NeverSeenThisKindOfException? Just Google it! It is surprising how many newbie programmers doesn't know that Googling using the compiler error/exception message will lead them to dozens of results from Stackoverflow and other forums. If it is not the error message, but some seemingly strange behavior of code that is bothering you, then try to formulate your search query using a few keywords. As a newbie programmer, it will be highly unlikely that you will face a completely new problem. So if you don't get any relevant search result, maybe you are searching using the wrong query. Try a new query which expresses your problem in a simpler way.

3. Learn how to ask for help

Certainly there will be cases when wouldn't be able to solve the problem on your own. Then you have to seek help from other people, either in person or through a forum. This Stackoverflow article covers almost everything about asking a good question, I'll emphasize on a few among those. Never ask someone to debug your code for yourself. Ask specific questions, like "I'm trying to do X in this part of the code, I'm expecting Y but this is giving Z output/giving this error". Briefly mention what you've done so far to solve the problem. This will make people more friendly towards you.

Another very important thing is to write readable code. Nobody expects modular and manageable code from a newbie programmer, but they would certainly expect you to write codes that won't hurt their eyes. You don't need to spend a day learning how to write readable code, just follow the style of the code from your favorite book/blog. Examine the how indentation and spacing are used. Always give variables meaningful names and follow the naming convention of the language. It may take some time to come up with good variable names, which will slow you down a little. But it will pay off when other people will read the code, or you would come to that code one month later and trying to figure out what the heck you've written earlier. Try to group logical pieces into functions. You will fall in love with your code soon.

Writing My Resume

Back in the days in school and college, we were asked to write a CV or resume during English exams. Resume templates were found in different writers' books, sometimes teachers gave us their own templates. All the templates were almost the same under the hood. They would begin with a cover letter stating something like: "Dear Sir, I've seen your job posting in Daily Ittefaq on day X..." and then continued for one or two lines. The rest of the first page would be covered with a giant table. You would throw out all your personal information in that table: your name, father's name, mother's name, current address, home address, marital status, religion, nationality and what not. After that, there would be another table where you would list your educational qualification, from Masters to SSC. And you would list your interests, extra-curricular activities (debating was a common choice for everyone) etc. Finally, you would close your resume with some references. Any recruiter would probably throw out these resumes now.

I wrote my first real resume when I applied to TopOfStack as a software developer. Saadi vai (CEO of TopOfStack Software) later told me he was pretty impressed watching my resume, he didn't expect the projects listed in my resume from a 2nd-year undergraduate. After that, I didn't care to update my resume. Some days ago I came across some Quora questions regarding software engineer resume. That reminded me that I haven't updated my resume for more than 1.5 years. So this Eid vacation might be a good time to create a new version of my resume.

Before starting, I've done some research on how a software engineer resume should look like. I got some pretty interesting advice:

Don't put anything irrelevant

We all know that, right? But have you thought what information is really relevant to your job? Recruiters only care about your skill. Why would they want to know about your marital status or father's name? Why would they care about your SSC result? Why they would be interested in whether you like Cricket or Football?

Don't put your picture

Once I thought putting a picture in my resume would make it look cool. But it turns out than most people highly recommend not to put your picture on the resume because the recruiter can subconsciously discriminate you from others. Besides, it's distracting.

Keep it Short

A long resume means you don't know how to prioritize important things over little details. Most people recommend one to two-page resume, depending on your experience.

Formatting might not matter

Might not, because I don't know about Bangladeshi companies, but many companies use resume parser to extract information and present only the plain text to the recruiter. And all your careful formatting, colors - they are gone. (Good for me, because I hate spending time in formatting some piece of text.)

There are numerous other common advice like being specific while writing, being careful about spelling and grammar, using third person etc. Note that I'm not an expert on resume writing, all I've written is a result of my one hour research. So you should better not take it seriously and do your own research before writing your resume ;) 

Anyway, I've finished my resume and uploaded it here. Let me know if you've any suggestion.

Using SVN as a Git Guy

If you have been introduced to version controlling system through Git and later someday you stumbled upon SVN, then you know what I mean. It feels... weird. And pathetic.

I've been using Git since my second year at university, soon after I started working on software development. I was introduced it at the very first session of BSADD, and later Shafiul Azam vai gave a nice presentation on it. At first it seems to be a little difficult but later I got used to it. The common workflow is easy, clone or fork a project, code, code, commit. Again code, code, commit. Made a mistake? Checkout to last commit. Fix it and commit. Feature complete? Push. Again code, code, commit.

So basically it is just a series of commits, with some push and (sometimes) checkout/reset interleaved with it. Of course sometimes you need to deal with other issues, handle conflicts while working on a team (code conflict, to be clear), delete accidentally pushed binaries when you forgot to put those in gitignore, create branches when you wish to do some experiments and so on. But Git will give you everything you want from it. I don't remember a situation where I wanted something, but Git doesn't have support for it. Besides GitHub has all those goodies - network view, issues page, pull request. (I don't know why but many open source organizations using SVN host their code on their own site, uses that ancient mailing list system and their own version of bug tracker - which in most cases not even close to GitHub in terms of usability).

My first introduction to SVN was during my part-time job at TopOfStack. I had to send codes of a project to a senior developer, so I uploaded my codes to GitHub and send him the link. He said he is not familiar with Git, so I had to send it using SVN. Strangely enough, I couldn't find any quick tutorial on SVN. Probably my fault, I should've search for "SVN for git users". Anyway, I fiddled around it for about an hour trying to figure out how to do basic things like connecting remote repository and push, then gave up at the end. I was under the time constraint, so I decided to send him just a zip file containing the codes, instead of fighting with this seemingly strange system.

I took a deeper look into SVN when I applied to Apertium for Google Summer of Code. Their repository is an SVN one. This time, I found a nice blog post of Abu Zaher vai introducing SVN. Reading that blog post, SVN seems to be pretty easy. In fact, I thought SVN is just some kind of older version of Git, until I had to make my first commit.

In Git, commit and push are entirely independent. I commit changes frequently - whenever I write a method or do some large refactoring or add documentation. After making several commits I push those to a remote repository, generally when a feature is complete and I've finished testing and documentation of that feature. This way the master branch of remote Git repo (typically in GitHub or BitBucket) always remains stable. Another way to do this is to create a separate branch when you start e new feature, do whatever the heck you want to do with that branch - commit, push, then after finishing the feature, merge that branch into the master one. I tried to understand SVN branching, but soon my head started blowing up. It seems to me that in SVN, creating a new branch for implementing a feature is like launching Eclipse to edit a readme.txt. But what strikes me most is that you can't commit locally because you don't have a local repo. SVN dcommit will push all of your changes to the remote repo.

This is especially intimidating if you don't have write access to the remote repository, which happened in my case. You can't push the changes, so you have to create a new repository (oh, I miss GitHub's fork!) and commit everything there - and whenever you want your updates to be merged with main repo, you need to submit a patch for review. Often it takes several days before the patch is reviewed, so if the reviewer wants you to change something and if you've already started working on a new feature on that codebase, things will be messed up. Compare it with GitHub's branch, commit, pull request strategy.

Later, I found the solution - track the SVN repository using git-svn. Do everything using Git in your local repo - local commit, branch, merge. And whenever you want to push your changes to remote SVN repo, perform a dcommit. It's not as flexible as Git, and you would still miss GitHub, but I can live with that.

Anyway, I might be biased towards Git, and I admit I know very little about SVN. So if you find any mistake in my writing, feel free to correct me :)

A beginner's Guide to Start Freelance Software Development

It's been a year since I started freelancing as a software developer. I opened my Freelancer.com account in March 2013 and got my first job in April 2013. In last one year, I've completed more than 40 projects. Most of them were small Android or Java apps - but it was enough for me to pay the bills and also make some savings.

So why freelance, instead of doing a job? I'm a student, so a full-time job wasn't an option to me. I can't do internship because almost no software company in Bangladesh offers it. I worked as a part-time developer in a company, but the salary was too low there. So I decided to leave that job and start as a freelancer. That decision was proved to be right very soon. I started making more than twice money than I've expected. And it's more than just money - I got a chance to develop my communication skills, made connections, got more control over what to do and when to do. Of course there are some downsides - now I need to spend a significant amount of time in bidding on projects or communicating with my clients, and some clients are not easy to deal with - they give very vague requirements and demand changing things after they've been developed, but still the benefits outweigh these issues.

When my friends heard I've started freelancing, many of them asked me how they can start freelancing, too. So I've decided to write this post based on my short (but successful, I think) experience as a freelancer. This is mainly for students who want to earn some extra money besides their regular course of study, but it will be also useful for you if you want to do freelancing full-time.

I know, many of you have already tried to start freelancing. You've opened accounts in one or two freelancing sites, got scared after browsing the projects. Maybe you've placed bid on some projects if you're brave enough, but then you gave up. What is the problem? Is it really so difficult? Maybe not - here are three possible reasons why you didn't succeed:

1. You don't have skills

Seriously? I'm the best coder in my class. I got A+ in all my programming courses. I've done well in various programming contests. And you are telling me that I don't have skills?

Yeah, dude. You might have successfully completed your term project on Java, but you don't know how to modularize and document your code. So after one month when you decide to make some changes, it all looks cryptic and you find yourself spending a night just to decipher it. You might know how to code a Hash Table in Java, but you might not know Java has HashMap or HashSet built in, so you might waste an hour coding it by hand. You might not know how important it is to validate user input before processing, so your program crashes whenever the user makes some mistake. And there is no other thing that makes a user more unhappy than crashing a program.

Now, if you do a lot of coding besides your academic study and read other people's code, you might know all of these. But even if you know all of these, it might not be enough to get a project (even place a bid in a project). How many softwares you've seen made using Java Swing? Or how many software do you use built with just plain C++ (No GUI, no networking or multi-threading)? You need to learn at least one popular technology. IIf you know Java, then learn Android development. f you know C++, then learn Qt to make desktop applications. If you know Python, then learn how to make web applications using Django. You will get plenty of resources in web to learn any of these popular technologies. But don't try to learn everything at once - learn one at first, do some projects using it, then consider learning another one. I'm working on Android for about two years, but still I consider myself just a beginner.

One thing to keep in mind, clients expect professional quality from you. They want a well designed, stable, bug-free product. So just knowing how to develop an app might not be enough, you need to ensure it has high quality. A good way to test if you've professional level skills is to look for project postings related to your skills in different freelancer sites, and ask yourself if you can to do these projects. If you can't, find out what else you need to learn, give some more time in developing your skills, and come back some days later.

2. You don't know how to bid

Communication skills are just as important - if not more important - than technical skills to get a job. You need to compete with people all over the world. Why would an employer choose you, specially if you are a beginner with no previous work experience in that freelancer site? You should keep an updated portfolio on the projects you've worked before. But the most important thing is, you need to convince the employer that you are able to do the job, and you can do it within his budget and deadline. Here are some tips to convince him:

• You need to convince yourself first. You need to be sure that you can complete the project properly in due time, and the employer will be happy with your work. If you take a project and can't complete, you will get a negative review and the employer might refuse to make the payment.
• Read the project description carefully. Sometimes employers post additional files (detailed requirement, existing codes etc). Take a quick look over those files before placing the bid.
• Most projects have vague requirements. Ask questions to the employer for clarifying the requirements. Seriously, this is the easiest way to convince him that you're serious about his project, because asking questions means you've read the project description carefully. But don't ask dumb questions - whose answers can be figured out easily by analyzing requirements or searching Google. 
• Place a bid which is at least 20% lower than any other experienced freelancer bidding on that project. Why would a employer hire an inexperienced freelancer who demands more than an experienced one? Don't bid too low, though, it might make him suspicious. 

3. You haven't tried hard

Let's say you've enough technical and communication skills to start freelancing. You've placed bids in many different projects, but you didn't get any, so you gave up.

Let me ask you, how many times you've placed a bid? 10 times? 20 times? 30 times? I got my first job after continuously placing bids in three freelancing sites for three weeks.

For three weeks, I've logged on to each of those three freelancing sites several times a day, searched all projects on Android, Java, and C++, read all the project description carefully, decided if I can do the job, and if I can do it, should I place the bid (there are limits on the maximum number of bids that can be placed in a certain period of time), then placed the bid if it seems appropriate and tried to communicate with the employer. In 95% cases, I didn't even get a reply, they hired some experienced guy. Then one day, I luckily found an Android project with very vague and confusing description - no one made a bid on that project before me, perhaps they didn't even understand what the employer actually meant. I read the description over and over to understand it, sent messages to the employer to clarify the requirements, and discussed with him how should I go on developing the app. He gave me the project and I successfully completed it after a week. After that, I didn't have to look back. So don't lose hope after making a few bids. Place more and more bids, and place those very carefully.


To summarize, here are the steps you need to go through to start freelancing:

1. Choose a popular technology (Android, iOS, PHP, Ruby on Rails, Qt or whatever) and become master on it.
2. Do some small projects using that technology. See if you can write an well designed (both in terms of code and UI), easily modifiable and bug free app.
3. Keep an eye on the project postings in some popular freelancing sites (Freelancer.com, Odesk, Elance etc). See if you've enough skills to do those projects. If you don't have, then go to step 2.
4. Now you are ready to start bidding. Keep aside 1-2 hours everyday to spend on bidding. Read project descriptions carefully, and place bid if you're absolutely sure that you can do those projects. 
5. If any employer communicates, reply him back as early as possible. Sometimes employers communicates long after posting the project, so consider turning on email notifications on your phone or browser.

A lot to do, huh? If you have a friend who is already working as a freelancer, I'll suggest you approach him first, ask him if you can work with him. An experienced freelancer with good review always gets a lot of work, so if you have skills, he will be happy if you join with him. This way you can avoid (most painful) step 4 and 5.

Before finishing, I want to discuss one other thing. A common question I face from my friends is "How much do you earn by freelancing?" The real answer is, "it varies largely from project to project." Generally I try to charge my clients about $10 - $15 per hour. But unfortunately, besides developing the app I need to spend a lot of time in bidding and communicating with clients. I need to pay fees to Freelancer.com and Skrill, too (I use Skrill for transferring my earnings in my bank account). So in the end it's a lot less compared to my original earning which is about $7 - $10 per hour. This might not be enough if you are a developer from Europe or the USA, but as a Bangladeshi freelancer with only one year of experience, I'm happy with it.