Monthly Archives: May 2019

20 web dev portfolio project ideas to make your resume shine

If you don’t have much web development experience, and you’ll be looking for a job soon, you want to do everything you can to make yourself an attractive candidate for the positions that you’re interested in. That means polishing up the resume.

Want your resume to shine? Think about adding a “side project” to it.

A side project can be any software that demonstrates your skill. It doesn’t have to be super complicated, like the next Facebook or whatever. It’s just there to give hiring managers help in evaluating what you can do.

Unless you’re a masochist, you should focus on a side project in an area that interests you. If you create a project that builds a robot buggy using the raspberry pi, that’s definitely pretty cool… but if you’re going to be applying for web developer positions, you may lose out to someone else whose portfolio demonstrates web programming experience. So don’t go for something that’s got a million bells and whistles if it doesn’t interest you. Work on a project that you like. That way, it will be easier to work on it, and get it finished. And it will be more likely to lead to a job that you like.

If you’re having trouble coming up with ideas for side projects, here is a list of 20 different ones to help you get started, including links to example sites:

(1) A to-do list. Examples: or

(2) A slugify tool:

(3) An online stopwatch, timer, or alarm clock. For example:

(4) A web shop which displays images from Amazon: has a lot of APIs and SDKs – pick one that interests you and build something!

(5) A tic-tac-toe game

(6) A simple login page which uses the Google login or Facebook login API

(7) A tip calculator e.g. or

(8) A URL encoder or decoder

(9) A histogram generator which plots a histogram from some input, e.g. and bonus points for taking input from a Google Drive spreadsheet.

(10) A MadLibs game site, for example

(11) A hangman game site

(12) A web scraper

(13) A site which consumes the MediaWiki API e.g.

(14) Build an “echo” chat bot

(15) A word counter service

(16) Something like MindMapper

(17) Build a REST API that takes a zip code as input and returns the average income for that zip code using

(18) A word cloud generator

(19) A URL shortener

(20) A bookmark (URL) manager

As you develop your side project, think about the following things:

(1) Use version control from the get-go. Having a git commit history with informative comments demonstrates that you care about code maintenance.

(2) Plan things. Create a README and if possible draw some wireframes.

(3) Write unit tests.

(4) Maybe add documentation using a wiki.

(5) Include code documentation such as Javadoc.

(6) Keep a consistent naming convention.

(7) Use consistent tabbing/whitespace/source code formatting.

(8) Avoid code duplication. Copy/paste is lazy and leads to unmaintainable code – refactor!

(9) Think to yourself – is the code maintainable, organized, and easy to understand? If not, refactor.

(10) If possible, use a continuous integration (CI) system for deploying to a hosting service.

(11) Use tools to compute code coverage and code complexity.

(12) Validate user inputs and handle exceptions nicely.

(13) Do not ignore security! Have you avoided SQL injection and cross site scripting attacks? If this is a web app, make sure it’s secure by using HTTPS.

(14) Work together with someone else, if possible, to show you can work on a team.

(15) Be able to demo your software live during an interview.

(16) Be able to talk about it comfortably and answer questions about your design and coding choices.

(17) Avoid surprise bugs during the demo – make sure you have performed QA on your application.

Once you finish one project, you will probably want to start on another one. Over time, you’ll be able to show prospective employers a portfolio of working projects. This won’t guarantee you a job, but it will probably give you an edge over other candidates.

If you want some real world experience, I’ll be honest and tell you that I never had a portfolio of projects that helped me get a job. I came to software development as a STEM graduate (not computer science), and I relied on that background to help “ease” my way into dev work. In fact, it was not easy! I found that some computer science majors are very skeptical of people who make lateral moves into software. They assume the worst about your coding style and competency. When I look back, I wish someone had suggested to me that I build some small projects that would have helped to demonstrate my abilities, especially when finding my first job. I think my job searches would have been easier.

If you found this interesting, click the subscribe button below! I write a new post about once a week.

which is better: full stack, frontend, or backend development?

The answer is “whatever you like”.

To make sure we’re on the same page, a frontend developer is someone who is comfortable doing user interface work – the “front end” of a software application is the part that the “user” sees. For example, a frontend dev creates your login screen, or writes code to make requests to a server for data that is displayed to the user.

A backend developer usually writes programs that run out of sight of the user, but are just as vital to the application. For example, their code accesses a data store, or implements business logic.

A fullstack developer is comfortable doing both sorts of tasks.

For context, the software being written may not necessarily be a web application that runs in the browser. Rather, it could be used to create an executable that runs on the desktop. It could be an app which is installed on a mobile device and which connects to a server in the cloud. The idea is the same: there’s a piece which is shown to the user, and a piece which is hidden.

There is an advantage to being a fullstack developer. There seems to be more demand for fullstack devs, these days. Part of that is because some managers have bought into the idea that if they hire a fullstack dev, they can have “two for the price of one”. They’re looking for a bargain.

This can work out, but there are some caveats.

The workload has to be reasonable so that a single developer can do it all in the allotted time. So if you genuinely have only enough frontend and backend work to fill a single person’s time, then it makes sense to hire one person having both skills. Otherwise, your developer may very well burn out before the job is done, leaving you in the lurch.

In addition, the fullstack dev must be skilled enough to get both kinds of work done. If they aren’t, it may take a lot longer to get the task done than if two specialists had been working on it. This is a problem if you’ve got hard deadlines! It can also mean that your “bargain” wasn’t a bargain at all. You might wind up paying the same, or more, for the same work that could have been done by two more specialized devs.

Good managers know this. That’s why there’s still plenty of demand for developers who specialize in frontend and backend work.

It’s probably best to go into fullstack development only if both frontend and backend development interest you. Unless you’re interested, it’s going to be difficult to stay motivated and learn the new skills that keep you competent and employable.

If you’re having trouble finding a dev job, and you think it’s because “only full stack devs are getting hired!”, think again. You should probably look at your job search process before you decide to train for full stack work in a panic.

If you found this interesting, click the subscribe button below! I write a new post about once a week.

difference between == and === in javascript

The “triple equal”, “===”, is a strict comparison operator in JavaScript. It is used to compare two “things”, and returns either true or false.

The “double equal”, “==”, is an abstract comparison operator. It is also used to compare two “things”, and returns true or false.

They seem like the same thing! So, what’s the difference between “===” and “==” in JavaScript? And how do you remember which is which?

abstract comparison operator ==

When the “==” operator is used, the two operands – the things being compared – are converted to the same type by JavaScript before comparing.

This can be a source of some headaches! If you don’t realize that the two operands are actually being “messed with” before the “==” comparison occurs, you’re going to find this operator very confusing at some point!

You should mosey on over to the ECMAScript 5.1 specification, where the abstract equality comparison operator is explained.

Go ahead, take a look! Notice that there are 10 logic steps that are considered in computing the result of this operator, and the first one has 6 different substeps. It starts to become clear why the “==” (double equal, abstract equality comparison operator) can lead to “gotcha” bugs in code!

I am not going to quote the ECMAScript spec here, nor am I going to explain it in detail. Instead, I will give a couple of examples:

var a = ("1" == 1); // a is the boolean true
var b = ("true" == true); // b is the boolean false

If you aren’t already familiar with this behavior, the fact that ("1" == 1) is true may come as a surprise. And given that ("1" == 1) is true, it seems non-intuitive that ("true" == true) is false! This is where bugs can creep into code. For example, suppose an object {"custom" : "true"} is sent from the server to your client in the web browser, and the code to check for this custom option reads:

if (obj["custom"] == true) {

The bug report says that when some custom option is checked, the doSomething method is not called, but it should be. So you start by printing out the value of obj["custom"], and you see true in the JavaScript console… how is that possible? Pain ensues!

strict comparison operator ===

In contrast, let’s take a look at what the spec says about the strict equals operator. There are 6 logic steps for this operator, and no substeps. It’s still not 100% straightforward (what’s that stuff about GetValue)? However, it’s definitely a bit less confusing.

Let’s look at how the triple equal plays out in the above code snippets:

var a = ("1" === 1); // a is the boolean false
var b = ("true" === true); // b is the boolean false

At least to me, these results seem much more obvious than the ones using “==“.

a mnemonic for remembering the difference

It’s difficult to get a truly intuitive feeling for what values will be returned by these two operators. However, I have a mnemonic that I use to help me. The three equal signs in the strict equals operator make me think “really, really, really!”. As in, the two operands are really, really, really equal. In particular, there’s no type conversion before the comparison. So if one operand is a string and the other is a number, you will always get false. On the other hand, the == operator will return true even if the two operands are “sort of” equal. That’s the way I think of it.

I almost never use the double equal, abstract comparison operator. In fact, I cannot think of the last time I used it! It strikes me as a source of hard-to-uncover bugs. And it’s hard to remember all the rules when using ==. However, I do know that there’s a difference between the two different operators. I think that’s the most important thing: experienced JavaScript developers should be aware that there’s a difference, and have a pretty good idea of what that difference is, even if they can’t quote the spec on it. If you’re a person who has expertise in several different languages, it gets hard to keep track of the finer details of a language. But you can still be very productive as long as you keep in mind some fundamental principles. In this case, make sure you notice when == is used and when === is used, be careful about which way you use them, and if you’re looking for a bug, keep in mind that the comparison operator is a place to check for the problem.

If you found this interesting, click the subscribe button below! I write a new post about once a week.

how can I increase my wages? – part ii: niching down

Forty-eight percent of respondents to Stack Overflow’s 2018 developer survey described themselves as “full-stack developers”! That’s a lot of full-stack devs out there!

Many developers love their work, and are perfectly happy that they are paid anything to do what they love. However, just because you’re getting paid to do what you love doesn’t mean you don’t need or want more money! Money is like a road: it helps you get where you need to go. It helps you get where you want to go. When you’re sick, it can pay for health care expenses. If you’ve got a family, it pays to put the food on their plates, go on vacation together, send your kids to college. Even if you don’t have responsibilities, it pays for fun stuff – whatever you like to do when you’re not coding!

I would argue that there’s no such thing as “too much” money. After all – you can always give your money away if it causes you problems! So, maximizing your income seems like a no-brainer, as long as doing so doesn’t impact you negatively in some way.

You can increase your wages simply by asking for more. But what happens if you’ve asked for “more” many, many times, and people keep telling you “no”? Then the problem may be that the value you provide is not worth what you are asking.

One possible answer is to drill down into a niche area. Adding a subspecialty to the skills that you’re offering can be the thing that makes a higher paying client find you appealing. But, how do you choose a niche? And how do you get experience in that niche if you haven’t already worked at it? It’s a catch-22.

Looking back at that Stack Overflow survey again can help! Scroll down and look at all the commonly used technologies… Hopefully, you will have one or two of those under your belt, and maybe more. Now look at some of the less commonly used techs. For example, under the databases section, we see that MySQL is the most popular database. Chances are that you have experience using a MySQL database, either with a hobby project, with a current client or job, or sometime earlier in your career. That’s great! But look down the list a bit more, and you’ll find there’s quite a long tail of databases listed. For example, we see things like Neo4j, Cassandra, and Google Cloud Storage listed.

Drilling down, of all 100,000 developers taking the survey, 3.7% said that they use Cassandra. At first glance, that doesn’t seem like a lot, and you might think you are better off experimenting with PostgreSQL or SQL Server. However, 3.7% of 100K is 3700 devs. And that’s just a small fraction of all the devs in the world. So there’s definitely a market for people with Cassandra skills. In 2017, 3.1% of respondents said they worked with Cassandra. It looks like there might be an uptick in this skill.

But, you say, why not broaden your skills with PostgreSQL? There’s clearly far more demand for that skill than for Cassandra.

Well, there’s nothing wrong with doing that, of course. But there are a few reasons that something less popular is a wiser choice.

First, a skill that is common to a very large pool of developers becomes commoditized. You won’t stand out from other devs if you have experience with PostgreSQL. You will if you’ve been using Cassandra. No doubt, many clients or hiring managers will skip right by “Cassandra” on your resume. However, for the client who absolutely needs a developer with that skill, your resume will be exactly what they’re looking for.

Second, when skills are hard to find, (and I don’t mean skills like “playing the nose flute“) you can often charge more for them. I don’t have solid proof of this. However, ZipRecruiter claims that the average salary for a “Cassandra developer” is $122K/year. In contrast, the average salary of a “MySQL developer” is $104K/year. I don’t want to use those figures as definite proof of what I’m saying because I don’t know how ZipRecruiter got their data, and I’m sure there are lots of other factors involved in salary comparisons. Also, I don’t think there’s a job title such as “Cassandra developer” or “MySQL developer”. However, it does give you some indication that there’s more money sloshing around for those who have rare skills.

A little research like I’ve done above can give you an idea of where the trends are going, and what skills might be hard for employers or clients to find. If something looks appealing, it can be worth investigating the technology. Can you add it to one of your side projects, so that you can say you’ve got experience in it? You don’t have to become an expert. You can explain to a potential client what your experience is, and let them decide whether that is enough.

Niching down” is one way to get yourself a pay increase.

If you found this interesting, click the subscribe button below! I write a new post about once a week.

how can I increase my wages?

As a fullstack developer, you ask, what additional training can I do to increase my wages?

The advice below applies whether you are a full-time employee (FTE) or a freelancer.

I’ve got some bad news for ya. As a software developer, you’re used to solving problems with technology. This problem, however, is not technical in nature, and the answer isn’t, either. You may not want to hear this! The answer to increasing your wages is in sales, marketing / public relations, and – here’s the kicker – just raising your rate!

But how can I just unilaterally raise my rate, you ask? Well, there’s a whole course about that called “Double Your Freelancing” (I’m not an affiliate, and I make no money if you click on that link!). I suspect you can learn from that course. But I don’ know, to be honest: I haven’t taken it! And I’m sure there’s a lot more to it than the name, but that name gives you a place to start: just raise your rates. Here are some quick tips that can help.

Suppose you’re a freelancer, and you only have one client. You’re afraid to raise your rate with the client! You do everything they ask, without complaint, because you’re afraid they will drop you, and use someone else.

Here’s where the sales and marketing come in. You should spend at least 20% of your time marketing yourself to get another client, and at a higher rate than what you currently charge. As your freelancing career matures, you will probably spend more than 20% of your work time on marketing and sales, but for now aim for 20%. You’ll put in the work to find good clients who pay more, and you’ll build your reputation so that they can find you.

The same applies if you are a full-timer. Shop yourself around. Do the work to get interviews at other companies when there’s no pressure to take a new job – you are just testing the water. Make positive contacts with other developers at other companies. When there are openings at their companies, you want to be the person who comes to mind to fill that role. The beauty is that you don’t have to take any position if it’s not right for you. But it gives you more freedom and more options.

When you have more options open to you, you don’t have to be afraid, and you don’t have to tolerate low wages.

I’m going to be honest with you, though. I was in the situation where I had exactly one client. When I was first hired by him, he asked me to do a few things that were fairly difficult – for example, find and fix a race condition in a complex (and awful) Android code base. I did that at a very low price because I was new to freelancing, fairly new to Android programming, and I just wanted to get some experience under my belt.

Well, over the years I kept taking work from him. He started asking me for other kinds of work – web development (backend and frontend), database work, systems administration. I felt like I should be paid more, but I felt really awkward asking for an increase.

I finally announced a 20% increase for new work, and my client did not complain one peep.

A few years later, I was still limping along with just one client. I’ll talk about that later. But I finally decided that the client work I was doing was not worth the trouble. I’ll talk about that later, too. The end result, however, was that I announced another rate increase, by about 40%. The client grumbled and mumbled, but they agreed.

The point is the same, though. I was willing to lose the client over this rate increase because I had other income. This is why you should always have a back-up plan when demanding a rate increase. You control your rate, but not everyone will pay you what you want. If you ask for a rate increase and your client balks, you need to be able to say “bye”, or it just looks like a sad bluff.

If you found this interesting, click the subscribe button below! I write a new post about once a week.