Photo by Philippe Bout on Unsplash

Differences between learning programming on your own and on the job programming

It can be very exciting and also very terrifying when learning a new skill to enhance your career or to pick up a side hustle. I believe learning is something that stays with the person the entirety of their lifetime. So, if learning is such an important part of a person’s life, it is imperative that we should learn how to do it right.

In this article, I’ll be specifically talking about learning a programming language or pretty much anything else in the IT field. With the recent increase in jobs in the field, it has also created a large group of people wanting to learn programming and getting into the field themselves. However, in my experience, there are subtle differences and nuances that you should keep in mind when learning programming on your own vs when actually doing it on the job.

So I thought I should list the differences here and my thoughts regarding them and how can one keep them in mind when going through their own journey. So let’s start.

In summary, here are the differences. We’ll be going through each of these points in detail below.

• When learning something, people are just following a boiler plate method off of some tutorial or YouTube video to solve a dummy problem. While when on the job, there is no boiler plate method and people are solving actual real problems.
• When learning something, people are often doing something from scratch and doing it end to end while on the job, most of the time you’ll be making changes to an already present architecture to incorporate a new business use case. So it’s also very important to learn how to build off of someone else’s work as well.
• While learning, most of us make use of dummy data or already processed data off of some website like Kaggle and incorporate that into our code. While when you’re on the job, data is really messy and crude in some cases and we have to figure out a way to clean or process it.
• Localhost vs actual host. When you’re learning something, we just want to see it work so we end up locally hosting our work. No, http://localhost:8080 is not accessible to the internet :) While on the job, you’ll never be locally hosting anything.
• When learning something, we don’t take the cost of the infrastructure into account. We just want to build that one thing, using that new special tool everyone’s been talking about. While in actual on the job, cost consideration is a massive factor in all of the major infrastructure decisions as things can scale very quickly and we don’t want to end up paying $100K in the end.
• While learning something, we don’t care if a certain infrastructure is reliable or not. We just want to see it work. Doesn’t matter if it comes crumbling down in two hours (Guilty :)). While on the job, we want to make sure things stay in tact for many years to come.
• Git is also a tool that hardly comes up when you’re learning programming. We just CTRL + S on our computer and consider our work done for the day :) While in actual on the job scenario, all of our code will be version controlled using Git.
• Time pressure is also something that is very different when you’re learning something vs when you’re on the job. While learning, you feel like you got all the time in the world. While when you’re on the job and you’re team is working on a project that needs to be delivered in two days to solve for a business use case, things can get pretty intense.

So now we’ve listed down the differences. Now let’s talk about these differences in a little more detail and how you can bridge the gap in all of these cases.

1

When learning something, people are just following a boiler plate method off of some tutorial or YouTube video to solve a dummy problem. While when on the job, there is no boiler plate method and people are solving actual real problems.

When you’re learning something and following tutorials, you’re not really solving any real problem. You’re copying whatever the person in the tutorial is saying. This might help you in getting to know the tools you’re using a little bit better but this can be a problem in an interview.

The interviewer will not be impressed by you saying that you have built a machine learning model using the famous Titanic data set. No matter what complicated models you used. Mainly because of two reasons.

• Titanic data set is a very famous data set readily available online and takes no effort to acquire.
• Building a machine learning model on top of that solves no business problem.

What will be more impressive to the interviewer is that you figured out a problem that is specific to you and solved it using tech tools you’re interviewing for. You collected the data yourself and did the cleaning as per your requirement and built on top of that.

And I cannot stress this enough but, complexity of your project does not matter for the most part. Your project does not have to be rocket science and hard to understand. It just has to be solving a real problem. A real problem of extremely average complexity is a lot more attractive to the interviewer as compared to a very complex project that doesn’t solve any problem.

2

When learning something, people are often doing something from scratch and doing it end to end while on the job, most of the time you’ll be making changes to an already present architecture to incorporate a new business use case. So it’s also very important to learn how to build off of someone else’s work as well.

When you’re alone and learning and doing something yourself, you don’t care about what others have done. You just want to see yourself doing it from scratch. But that’s usually not how things are done in a real business setting. In whichever company you might end up working, its very much likely that they already have a built in infrastructure that they are using and that is solving business use cases for them.

Most of the time you’ll not be asked to do something from scratch but to rather make slight modifications to an already present system. So I think it’s important to learn to build off of someone else’s work and to understand what the other person has done.

On the flip side, it is also important to do things yourself in such a way that other people can understand what you have done.

Here are a few tips that will make your work easy to understand.

• Leave comments when you code.
• Incorporate logging into your code.
• Have descriptive variable names. Don’t name variables as a,b,c,x,i ,er. You know who you are. We’re all guilty of this.
• Incorporate Docstrings in your methods whenever you use them.
• Try to follow the object oriented approach whenever coding something.
• Follow abstraction and encapsulation principles. These are also very important from an interview stand point.
• Incorporate a linter in your code like Pylint if you’re coding in python.

When you do these things, it will not only help others in understanding your work but it will also help you in remembering what you have done if you try to revisit your code after a while :D

3

While learning, most of us make use of dummy data or already processed data off of some website like Kaggle and incorporate that into our code. While when you’re on the job, data is really messy and crude in some cases and we have to figure out a way to clean or process it.

When you’re learning data science or data engineering for that matter, we mostly make use of already available data sets that take no effort to acquire. We just download them off of some website and use them in our code.

However, this will not impress the interviewer irrespective of what you did with that data as this is certainly not how things are done in a real business setting. On the job, acquiring useful data is a mission in it of itself and should not be taken lightly when learning.

Here is what I recommend.

• Think about the problem that you want to solve and what data is required for that problem.
• Then think about where you can get this data.
• Then think about how you will get that data i.e. scraping or REST API
• Then write up the code to acquire that data directly from the internet.
• Pre-process that data and then use it in your project

The interviewer will be a lot more impressed if they know that you have acquired the data yourself rather than downloaded pre-processed data off of some website.

4

Localhost vs actual host. When you’re learning something, we just want to see it work so we end up locally hosting our work. No, http://localhost:8080 is not accessible to the internet :) While on the job, you’ll never be locally hosting anything.

While it certainly feels like an achievement whenever you write http://localhost:8080 in your browser and you see your work in the shape of a web page and you want to tell the world about it. Things work a little differently in a real business environment.

On the job, we want our work to be accessible to the entire internet, or just our colleagues depending upon what it is. So locally hosting your work will not do. You actually have to hire a server and put your work there so that other people can see it too.

Here is what I recommend

• Go on to AWS console and launch up a free tier EC2 instance.
• SSH into the instance and figure out how to host your work there.
• Host it and then access it through a specific IP address specific to that instance.
• Configure the security groups appropriately so that you can show it to everyone else as well.
• Maybe purchase a domain name and set it on top of the IP address. Access the site through the domain name.

Voila! now you have an actual website that you can link to in your CV and that everyone can see.

If you want to take a step further than this, I’d recommend you set up a database at the back-end as well. But this is a separate topic for another time.

5

When learning something, we don’t take the cost of the infrastructure into account. We just want to build that one thing using that new special tool everyone’s been talking about. While in actual on the job, cost consideration is a massive factor in all of the major infrastructure decisions as things can scale very quickly and we don’t want to end up paying $100K in the end.

This is something that rarely comes up when learning something new. Usually when we’re learning something, the scale of project tend to be small and not enough to make us think about the cost impact of our infrastructure.

But in a real business setting, things can scale pretty rapidly, especially when its a startup.

Here is what I recommend we should do in this case.

• Think about what if your data was a thousand or even a million times larger than it is now. What would you do?
• Think about what if the traffic on your website suddenly grows a thousand times. What would you do?

Try to factor in the cost of your approaches in these scenarios and how would you go about making a decision.

Usually decision making consists of the following factors

• Is it cost efficient?
• Is it scaleable?
• Is it reliable?
• Is it easy to integrate with our other infrastructure?
• Is it easy to understand and pick up for a new hire?

Although, you might not have to deal with these things while learning but going through this thought process and explaining it in an interview will 100% put you ahead of the other candidates :)

6

While learning something, we don’t care if a certain infrastructure is reliable or not. We just want to see it work. Doesn’t matter if it comes crumbling down in two hours (Guilty :)). While on the job, we want to make sure thing stay in tact for many years to come.

This is also a very technical detail that we mostly overlook while learning something new. We usually don’t consider the impact of what if this particular thing stops working and what steps can we take in that situation.

This step is a major factor in making infrastructure decisions in all companies. In a real business, we want to make sure that things stay in tact and plan for a time when they don’t.

Here is what I recommend we should do to bridge the gap

• Think about the different variables that will be interacting with your system. They can be anything from company people to foreign factors.
• Think about the likelihood of the system crashing whenever one of these variables go rogue.
• Think about what kind of failures can happen e.g. system outages, gaps in processing, down times etc.
• Then plan a strategy to execute whenever these specific failures happen.

This is again one of those points that you might not have to think about while learning. But knowing these things in an interview and explaining them clearly will certainly put you ahead of the other candidates.

7

Git is also a tool that hardly comes up when you’re learning programming. We just CTRL + S on our computer and consider our work done for the day :) While in actual on the job scenario, all of our code will be version controlled using Git.

Git is something I learned on the job as I hadn’t come across it while my learning phase.

While it is also okay to save your code in your hard drive and retrieve it whenever you require. But ask yourself this.

• What if instead of just 1 file there were 100s of files.
• What if I was not the only person working on this project.
• What if I wanted to see what changes have I made since I last saved my code.
• What if I wanted to see what changes other people have made.

You see the problem of not using Git?

I know that these things you will only need to worry about in an actual company and most probably in your own learning project, you will be the only person working on it and there will most likely be very few files you’re working with.

But I would still suggest to go ahead and push your code to an actual Git repository i.e. GitHub or GitLab anyway. This will not only give you all of the above benefits, but at the end, you will also have a very much rich Git profile to showcase in your CV and then you can talk about it with your interviewer.

You just can’t go wrong with using Git :)

8

Time pressure is also something that is very different when you’re learning something vs when you’re on the job. While learning, you feel like you got all the time in the world. While when you’re on the job and you’re team is working on a project that needs to be delivered in two days to solve for a business use case, things can get pretty intense.

While it is okay to take things slow while learning, it is also important to note that in a real business, you will not always have to luxury of having ample amount of time. There will most likely be multiple projects that you’re working on, all of which have their own deadlines that you have to manage.

I do think it is okay to start your learning journey thinking that you have ample amount of time but I also think that after a while it is important for you to start giving yourself realistic deadlines to meet. And then you have to work extra hard to keep up with those deadlines.

This I think will condition you for how an actual business environment is like and will make you more likely to adapt quickly wherever you choose to work.

So there you have it, things that everyone should keep in mind and lookout for while on their learning journey. Do let me know if you can think of some other differences. I’ll be happy to add them here :)

Hope you enjoyed the read!