How Will You Know if You’ll Like Programming?

Learning programming to the level of being able to create web applications or work in the field can take a lot of time and effort. But what if you don’t like it? What if you spend all that time and effort and it ends up that you hate programming and never want to see its ugly face again?

I hate to say it, but this can happen. I’ve seen it happen. I’ve worked with a couple of developers who went through the whole schooling thing, got a job and found that they couldn’t stand to sit in front of a computer all day, solving stupid, fiddly computer problems. (Their terms, not mine. I like solving stupid, fiddly computer problems.)

So how can you find out if this is something you’ll enjoy before plowing six months to a year of your life into learning it?

Take a Taste Test

Before diving into a bunch of different areas of study, I can tell you that ninety-nine times out of a hundred, the people that don’t like programming don’t like it because they don’t like solving programming problems. There’s a lot of mental work that goes into programming and some people don’t find the mental work interesting or rewarding. There’s nothing wrong with that. I don’t find solving social problems that rewarding but, thankfully, there are people out there that do.

So, how do you find out if you like mental challenges like the ones you’ll find in programming? By doing mental challenges! Here are two quick ways to do that.

Take a Programming Crash Course

There is a great book to work through if you want to dip your toes in the water of programming and it’s 100% free and online. That book is Automate the Boring Stuff with Python. The awesome thing about this book is that it is half primer in the Python language and half practical application of what you learned. It won’t teach you everything about programming–or even everything about Python–but will give you just enough to be able to dive in and solve some real life problems using programming. If you enjoy working through this book and–more importantly–enjoy applying these lessons to your own computing problems, then there’s a pretty good chance that diving deeper into programming may be for you. It also doesn’t hurt that the book is a great first step into the Python programming language, a language that is gaining a lot of popularity in the web development and AI worlds.

Go to Camp

Another great website to learn coding from is FreeCodeCamp. I would recommend working through the JavaScript Algorithms and Data Structures Certification at least up until the Basic Algorithm Scripting section. This will teach you the most popular language in web programming today–JavaScript. It will also let you flex your muscles and start solving what programmers call algorithms. A algorithm is just a fancy way of saying “a piece of code that solves a certain problem” and that’s the main thing most programmers do on a day to day basis. If you work through this and see it as pain rather than pleasure? You probably wouldn’t want to do it all day, every day either.

Try one of these sites–heck, try them both–and if you aren’t having fun or feeling like you’re accomplishing something while doing them, I would recommend not becoming a programmer. If you do like doing them, then setting up a real training regimen and tracking your progress is your next step to success.

How to Measure Your Progress While Learning Programming

Learning programming can often feel like you’re running as fast as you can and getting nowhere fast. The minute you feel like you have something figured out, five more things pop up that you need to learn before you can even do anything useful.

Measuring programming progress is extremely hard to do. It doesn’t come naturally to humans to measure progress of a mental skill. Programming is a very mental skill. It often feels like nothing is happening and–since we move on to new topics every day–that you’re constantly behind everyone else.

Physical skills are much easier to judge. You can see yourself getting better at painting. You can see your woodworking getting better. That pile of wood you are chopping is dwindling while the pile of chopped wood is stacking up. Visible progress!

Sadly, programming doesn’t really have a nice visible way of figuring that out. We could look at projects, but as we all know, half finished projects look more like failures than progress. Lines of code? Lines of code is just a number, not a clear indication of what you learned.

So what does work?

Make it Visible

Physical progress feels so rewarding because it is visible. So make your progress learning programming visible as well.

One of the best ways to do this is via todo lists. I would recommend using Trello. It’s the go to tool for many programmers to track progress on projects large and small.

Trello gives us a couple of ways to track progress and using all of them together will help give you a full view of your progress as you continue on your journey.

Create a Board

Create a new board and call it ‘Programming Progress’. Then create three lists; ‘Want to Learn’, ‘Learning’ and ‘Learned’. These are your 10,000 foot view of your programming journey. At first, everything may be in the ‘Want to Learn’ list. That’s okay! We all start somewhere.

A Trello Board called Programming Progress with three lists; Want to Learn, Learning, and Learned
Our 10,000 foot view of our progress

Topic Cards

Now add a card for each language or library you want to learn. That could be ‘Python’ or ‘React’ or ‘WordPress Development’ or even ‘Algorithms’. The key is that these are major Topics of learning. All of these cards go into the ‘Want to Learn’ list. Don’t go crazy on this yet. You can always add more topics to this in the future and having too many cards here can be more depressing than helpful.

Also remember when filling this list out what order things need to be learned in. You’ll need to learn ‘JavaScript’ before you can learn ‘React’, for instance. Focus on the topics you need now, you can always add more later.

Checklist of Learning

Now, go find a good tutorial on that Topic. For Python, maybe you’ll decide to learn via The Python Guru site. I’ll use that example here.

First, take the link to the tutorial and add it as the description for the card. That way–when you come back later after taking a break–you’ll have a link directly to the tutorial you were working on.

Go to the table of contents for that tutorial. Make a new checklist in your Topic card and add an item for every section of the tutorial.

A progress checklist for Python containing the table of contents for a Python tutorial
Our progress in learning Python

We now have a progress tracker! As you complete the sections on the tutorial, check them off the list and the progress meter will advance. When you look at the main board view, you’ll also see how many sections you’ve finished right on the front of the card.

Use this as your main learning dashboard. And feel good as check boxes get checked and cards move from left to right through the list.

Learning programming is hard, but keeping your motivation up by making your progress visual will certainly help you along the way.

Sign up for my mailing list so you don’t miss a post.



Java: Unstrung

So Strings are built for optimisation, but are you using it in an optimised way? If you understand interning and immutability, you can start looking at ways to use those features to your advantage.

How to Waste Memory Without Really Trying

Thinking about a String’s immutability, let’s look at String concatenation:

Okay, how many Objects did we create?

Seven. One for name, one for "Welcome " when first assigned to a, one for "Welcome Joe" on the first concatenation, one for ", Good to See You.", and one for the final String assigned to a, "Welcome Joe, Good to See You.". Not only does it create all those Strings, it also creates two StringBuffer Objects. Since you can’t change a String, the JVM needs to create an object that allows you to concatenate Strings. So for:

the JVM creates a StringBuffer Object that equals a, appends name and then converts back to a String and assigns it to a.

In fact, for every += you see, there is a StringBuffer Object (a rather expensive object to create) that is being created, used for one operation, and then being thrown away. And that happens every time this code it run. That adds up quick on a busy program and will make the Garbage Collector run much more often than it should.

A better way to do this would be:

Not only does this create less Objects, is also calls less functions during the process. This is important enough that the compiler tries to do some of this for you. The below example is equal to the StringBuffer example:

And when I say equal, I mean exactly equal. The resulting bytecode is exactly the same. This is because we’re using +, which the compiler converts to a StringBuffer first.

So the key is, Never use += with Strings. Use a StringBuffer instead.

Again, Again

One more point that has to do with interning. Interning only works with String literals like:

If you create a String like this is won’t be interned:

This actually creates two Strings; one that’s interned and one that’s not. Do you need two Strings equal to "Welcome "? No, you don’t, so Never create a String with a constructor (new String()).

For more info, see http://www.javaworld.com/javaworld/jw-03-2000/jw-0324-javaperf.html

Java: The Unchangeable String

One of the fundamental data types in Java is the String. In fact, it’s used so often that most people don’t even think much about what a String is or how it works. But a String Object works like no other object in Java in two important ways; immutability and internment.

You Can’t Touch This

Immutability means that an object can’t be changed. Ever. You can’t modify any of its values in any way.

While this might not sound very useful, it actually allows Java to optimize how it handles Strings — which is important since they’re used so much in the language — and brings a sense of security to using Strings. As we saw last week, when Objects are changeable, weird side effects can pop up when one variable changes an Object and all the other variables see the change and don’t know what happened.

Strings sidestep this issue by never allowing you to change a String in place. In programming parlance, this means Strings never have side effects. So in this operation:

a and b are now pointing to two different String Objects. a is pointing to the original String of "hello" while b is pointing to a copy that’s all uppercase of "HELLO". Even though a and b were pointing to the same String originally, the method toUpperCase() makes a copy and assigns the copy to b. This leaves a untouched. 1

This property allows Strings to do another cool trick. They can Intern.

Lowly Paid College Students?

Interning is a method where you cache objects in memory to speed up creation of those objects. What that means is, all String literals are interned, and if you define the same literal, it will actually be the same Object. A little illustration:

It looks like a and b are pointing to two different Objects, but they’re not. Here’s why.

When Java sees the "hello" for variable a, it creates a new String Object with the value and assigns the reference to a. It then saves that Object in a table in memory, also called interning.

Then Java sees that b is getting a String with the value "hello". It checks it’s intern table and sees it already has that Object created. Since Strings can’t be changed, it doesn’t hurt to just give that Object reference to b too, and so it does. Even though the programmer didn’t explicitly say so, a and b are now pointing to the same Object in memory.

In fact, Java is so good at this, it’ll assign to same Object to these variables too:

String is the only Class in Java that does interning in the JVM.

Next week we’ll talk about how to use this knowledge to build better programs. (Hint: it has to do with memory management.)


  1. Strings aren’t the only Objects that do this in Java. Can you think of any others? 

Thread Safety Dance

Another blast from the past.


If you’re working with Servlets or in a Threaded environment, you need to be thinking about thread safety.

Thread Bare

Java has built in support for multiple threads in all its objects. The way it handles this, is each thread can get a handle on the object and run its methods at the same time which, for something like a servlet, cuts down on the amount of memory needed to load the servlets and the amount of time needed to instantiate multiple objects. This can be a huge improvement in performance for web-based applications.

But what does it mean when objects are used by multiple threads? To answer that, we’ll need to look at variable scoping.

Scoping It Out

Let’s look at a simple example:

When an object is created from this class, that object will have two things in scope; the variable a and the method scopedMethod. The variables b and c don’t even exist until the method scopedMethod is called.

What does this mean for threads? If multiple threads use the same object, like for JEE Servlets, they will share things that are in the object scope when it’s created. So all threads will share the variable a and the method scopedMethod. Sharing methods is okay since every thread will create it’s own execution stack when it calls the method. That means every thread will own the variables b and c when scopedMethod gets called.

But what about variable a?

Crossing the Streams

Imagine two threads executing at nearly the same exact moment; we’ll call them thread 1 and thread 2. Thread 1 calls scopedMethod and passes in 50 to b. Thread 2 then calls scopedMethod at the same time, passing 700 to b. Since both threads have their own variable b, this doesn’t cause any problems. Now, thread 1 creates variable c and calls a = c + b;. Then, thread 2 will create it’s own variable c and call a = c + b;

Now a equals 710 in both threads. Since the threads share the variable a, both threads will now return 710, which is obviously wrong for thread 1. Imagine if this was a servlet and a contained sensitive customer data for two different customers. Now, both customers would see the data for the customer in thread 2!

S – A – F – E – T – Y, Thread Safety

Don’t use instance variables in multithreaded objects.

In a servlet environment, if you have data you need to store “globally” for this thread or user request, use the session or request objects. There shouldn’t be a need for changeable instance variables. If you have constants in the class that don’t change, it should be okay to make those instance variables, but declare them as static and final to make sure that they never change and all threads get the same value from them.

And remember, you won’t see threading problems in testing. When your application is being tested, it’s usually by one person on the system by themselves and they will never hit a threading issue here. You will only see threading issues in real world situations, when there are so many people hitting the application that your object will be executed twice at the exact same time. You can’t rely on testing to find these problems for you, you’ll need to do it as you develop your application.

For more info, see http://www.javaworld.com/javaworld/jw-07-2004/jw-0712-threadsafe.html

Programming to Interfaces

Yet another article from the archives. Hope it’s useful.


There is a common Object Oriented axiom that says “Program to the Interface and not to the Implementation”. But what does that mean and why is it useful?

Concrete Shoes

Let’s say that we have a class that calculates the number of Strings that begin with S in a list:

This function works great as long as we’re only working with ArrayList. But an ArrayList is a concrete class; it’s an implementation of the List interface. There’s nothing in our function that specifically requires using ArrayList and so we’ve crippled what we can do to this class and how it can be used. We’ve prevented ourselves from using this in a number of other cases for no real reason.

Talk to the Interface

Someone may want to call this function with a String[], but won’t be able to until they get that String[] into an ArrayList. But that’s an extra object you have to create, along with shoving all of the String objects into it, that you’ll just throw away afterwards. But if we change our method to accept List instead:

and we have a String[] words, we can call it like this:

We might also need to update legacy code that uses Vector. (Remember those!) Sun has discouraged the use of Vector, but they have retrofitted the List interface onto it. If your function accepts List instead of ArrayList, you could use it with legacy code that uses Vector too.

But why stop there? If you used:

You can now use this method with Set and Queue and Stack and it will still work. We’ve made the function support every Collection type in the language and it really didn’t cost us a thing. I’ve personally run into libraries a number of times that only supported List but, with one simple interface change, could have supported the Set that I needed to use with it.

So, when you code something, be sure to ask yourself “Do I really need to code this to a concrete class, or can I use an interface instead?” Walk up that interface tree and see what’s the highest level interface your code can support. You may be able to make your code more powerful by just changing a single word.

A Couple Pointers

This is an article I wrote a while ago, but is still relevant to many languages still in use. Figured I’d repost it to this blog.


Many of you may have learned the following in Java 101, but I thought I’d repeat it just in case.

Most of the variables you’ll use in Java are going to be Objects. So in the following code, we’re creating three Objects:

The first case is using the standard constructor of a Class to create an Object, the second is creating a String via a String literal, and the third is creating an Object via a Factory (an Object that creates other Objects). All of these create an Object and puts it in the variable to the left.

Except I’m lying. Do you know where I’m lying?

Little Errand Boys

number, welcome, and conn aren’t holding Objects, they’re holding references to Objects. These are called pointers because they “point” to an Object and don’t actually do anything except pass messages along to the Object they’re pointing at. They’re basically the Objects’ errand boys. When you say something like:

You’re basically saying “Hey, errand boy. Go ask your Object what its string value is and then let me know.” That becomes important when you consider that you can do this:

sameNumber is now pointing to the exact same Object as number. That means that one Object has two errand boys. If I tell one errand boy to change the Object, then the other errand boy sees the change too, because it’s the same Object! This can be confusing if you’re not expecting it.

Cha-Cha-Cha-Changes

This has important repercussions when looking at methods calls. For instance:

So even though our code didn’t add anything to the List Object, listToAdd() did. Since they point to the same Object, both errand boys see the change. This is very important to remember when coding in Java.

Remember: Multiple variables can point to the same Object, so be careful changing them!

Double Trouble (Don’t use doubles for currency or accurate decimals)

This is an article that I wrote a few years ago that still applies today.


Working with decimal numbers can be more complicated than it might seem. Many a Java programmer has been bitten by using doubles when calculating currency or another decimal value that relies on precision.

The problem

Let’s say that we need to calculate a customer’s bill. They used 80000.01 kWHs (big bill!) and we charge a dollar per kWH for this customer. To calculate that in cents, we just do:

The answer we expect from this is 8000001. What we actually get, however, is 8000000.999999999! Why is this? Because doubles are inaccurate with large numbers. They just can’t handle the calculation. They are actually made to be fast, not accurate.

You see, the decimal number must first be converted into a binary number. Due to the way that works, it can be impossible to store that decimal number into a binary representation, Just like you can’t make ⅓ into a decimal number.

The threes just never end! If you want to store that number somewhere, you’ll have to eventually cut it off somewhere, and that means you’ve lost your precision. It’ll be almost correct, but not quite.

If you’re not careful with this, you can start to drop cents and, with enough accounts being calculated this way, dropped cents will soon mean a dropped job. When doing large financial, with-real-money calculations, almost correct is not correct.

So what should we do?

The Java language has anticipated this and created an object that can handle decimal numbers accurately. That class is BigDecimal. Using BigDecimals, our previous example would look like this:

More complicated but we get the right answer of 8000001.00. It’s important to create the BigDecimal with Strings so that we keep the numbers safe from being accidentally converted into doubles at any time. If we called this as new BigDecimal(80000.01);, the number would be translated as a double first and then a BigDecimal, and we’ll have the same problem we had before. We should avoid using doubles at all when dealing with important decimal numbers.

Remember: BigDecimal, not double or Double!

Being a Craftsperson

Being a Craftsperson

I used to play role playing games in High School. Namely, the Teenage Mutant Ninja Turtles Role Playing game. I was the GM. I played almost every weekend with my brother and my best friend–the center of the football team. I loved those games. I think we ignored half the rules, but the stories we created are still some of my best memories from that time.

Jump to today and my kids have gotten to the age where they are starting to stretch their storytelling wings a bit. I’ve helped them along with that by talking about stories and doing NaNoWriMo with them, but I held off a bit on playing RPGs with them. I bought all the D&D 5th edition books, but the amount of crap you have to keep track of to play even a simple game is astounding. It ended up being too much work for me and we never really got into playing. I remembered it being all about a shared story that we would create together, but D&D just felt like accounting most of the time.

Then I heard about the Open Legend RPG system. It was just as their Kickstarter was starting. I dove into the rules that are freely posted on their website and liked what I saw. I could tell right away that this project had a mission, and it was being driven with a passion by its creator, Brian Feister. In fact, right on the front page, the system’s Mission Statement is proudly displayed:

Open Legend is a streamlined system designed to let you tell big stories using small rules.

And it does that, very well. Since the system is open source, there are many rules discussions that go on about adding or changing rules and if there’s anything I’ve seen from these discussions, it’s that Brian will never complicate these rules. Brian has a mission and a vision; to create a set of rules that are simple and flexible and don’t get in the way of a good story. If a new rules supports that, it’s in. If it doesn’t, it’s rejected with great prejudice.

You see, Brian is a craftsman. He has a vision and he cares enough about that vision to say “No” to things that won’t get him where he wants to go.

The same has been said of Steve Jobs, Bill Gates and Elon Musk. They have personal philosophies that drive their work. They aren’t out to please everyone but they are out to make an impact, to accomplish what they see as important. To follow their vision. And that’s what all successful craftspeople do.

This is something that I struggled with for a long time. I can do anything, so what the heck do I want to do? Without a framework in which to choose what I say no to versus what I say yes to, I could never focus my energies enough to make a real impact. So I’ve started stepping back recently and am trying to decide, what kind of impact do I most want to make? What do I find fulfilling and how can I leverage my experience to focus my energy in those directions?

I think this is the next level that I need to get to. I’m working it out and I also think that hearing from you has been a big help in that regard. If you find any of my writing here helpful or interesting, let me know. Send me an email at joe@jerickson.net or fill out the contact us form and tell me about your struggles. If my past students are any indication, I usually have a helpful tip or two to pass on.

One thing I do find fulfilling now–playing role playing games with my daughters. Thanks to Open Legend and Brian’s vision, I can now continue a tradition from my childhood with my children and delve deep into our imaginations and create whole new worlds, together. I hope it’s as memorable for them as it was for me.

Would you want an email like this?

Take a look at this email and think about what it would mean about your career.

This is the kind of offer I get routinely.
This is the kind of offer I get at this point in my career.

What about this email is different than most of the job postings out there that you routinely see?

Obviously, I put a big fat outline under one of those aspects; that they don’t care if I even know the language. The thing that most starting or junior developers are most worried about–“I need to know XYZ”–a hiring business in my area doesn’t even care about. The big list of qualifications you must have for this job are no where to be seen in this job posting. They’re not asking for 5 years experience in X or 3 years experience in Y.

Why is that?

The answer is the difference between a Senior Developer and a Junior Developer. I’ve been thinking a lot about this lately. How to quantify this difference and how to explain this difference to those who have only seen one side of it. How to show someone what they need to know to go from a Junior Developer to a Senior Developer. And if you think it’s just work experience that makes this difference, you’re absolutely wrong. Going from Junior to Senior has much more to do with how you approach the job than with what you do on it.

But what are some things you notice in the email above versus the job postings you get as a new or Junior Developer? What do you think those differences mean?