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 :)