The Truth About Being a Python Software Contractor

There are a lot of Myths out there

There are lot of Myths about being a Software Contractor – say, that they are delivering value from first hour stepping in the door. 

What myths did I believed to be true and they held me back from starting my career as a Software Contractor.

In the end of this post I will also elaborate on the Good, the Bad, and the Ugly thing about being a Software Contractor.

Before that, let’s just clarify what a Software Contractor is.

What is a Software Contractor?

A software contractor is hired on short contracts to help out with building software. Just like a Software Engineer, but just on a limited contract.

Why are they hired on short contracts?

Well, there can be many reasons. For one is the demand of software engineers cannot follow the supply. Hence, the competition to get software engineers is so high companies need to pay contractors to fill the missing seats in their teams.

That also mentions why you would want to become a software contractor.

The pay – you get a really good pay.

In the end of this post I will write more about the Good things, also the Bad and Ugly things about being a software contractor.

Myth #1: Software Contractors are good developers

I would say, I know a lot of software contractors and they come in all flavors.

No kidding. In general, they are not better than the average senior software engineer. Meaning, no better than someone with about 5 years of professional experience.

But there is a catch.

Software contractors are most of the time hired into projects that are understaffed and have no senior developers in them. This makes the Software Contractors seem really good comparing to the other developers in the team.

Of course, you should not underestimate the experience you get as a software contractor, you experience a lot of different implementations and see what works and what doesn’t.

This is great value to contribute with in a tech team.

Being reflective on what works, pays highly.

Myth #2: Software Contractors add value from the first day

This surprised me a lot. As the hourly salary for a Software Contractor is high, you would expect that the people hiring you would have a stopwatch counting every second to get the most out of you.

I used to think, that there would be an expectation of a Software Contractor could just sit down at a computer and immediately deliver valuable code from the first day.

That a Software Contractor is just understands the full software ecosystem from first hour and can find bugs, add new modules, and so forth just by looking at an overall design diagram.

First of all – that is not the case. As a software contractor you are not overly human.

Also, what surprised me, the first day everyone wants to talk to you and influence you. They know that your opinion matters. You are more senior. You have the external eyes on the system.

That means the Product Owner, the Scrum Master, the people Manager, the Team manager, the C-level staff, want to influence you.

Why?

For many reasons, but one is often common.

  • They want to challenge the decisions made by the team on technologies.

Myth #3: Software Contractors add value every second

To be honest, I thought that especially manager would be focused on keeping Software Contractors as efficient as possible. The main reason being, that they are expensive.

Again, I was wrong.

Actually, the managers seem more busy pushing the employed staff as busy as possible and less the Software Contractors.

The managers love to discuss things with Software Contractors. They seem to think of us as a neutral party that always will tell the truth and not be biased by the team.

Managers think that your judgement is better than employed team members.

My experience is, that you sit more often than you like it not doing what you love. You love to code – and that is how simple it is.

Myth #4: Software Contractors need a huge savings

This kept me for many years from starting as a Software Contractor.

The nature of being a Software Contractor is that you live from contract to contract, and that can be on a monthly basis.

I had noticed, that some Software Contractors seemed to be part of teams longer than the hired employees. But the reality was, that they needed to get contracts prolonged every month or similar.

Therefore I thought you needed at least 6 months of savings to start as a Software Contractor. What if you couldn’t find the next contract?

You can be terminated from day-to-day.

This sounds scary.

But the reality is, that you get offers all the time from recruiters that need Software Contractors like you. The demand is so big, that you can start in a new position the day after you get terminated from your current position.

Another reality is, that even though you are hired for short term, they almost never want to let you go. They want to keep you there.

There is simply no need to have a saving.

Myth #5: Software Contractors deliver perfect solutions

This is kind of a weird one.

I actually thought that Software Contractors were hired to make great software solutions. But that is actually not what directors in organizations want.

They want something totally different.

Guess what?

Now, I think it is kind of strange I never thought of it before. Yes, I truly believed that directors wanted good solid software solutions, that was built stable.

No, they just want results.

Teams talk about how to make the “perfect” solution, that is easy to maintain, that can be extended easy. The problem with this is, that they go into too much analysis.

Directors just want results. At the cost of making it good. They need products they have promised to customers.

They promised solutions. But the team went into hibernation (from the view of director) and did not deliver.

You, the Software Contractor, is hired to get results. Results fast.

The Good thing about being a Software Contractor

As promised, here are some of the good things I like about being a Software Contractor.

  • No employment development plan – when you are hired as a software engineer, your manager will make a development plan on how you should improve your skills and keep up to date with everything. It is a waste of time and you never follow it. Things change faster than your yearly made plan. I just love to avoid this pain point.
  • No participation in social meetings and events – you simply do not get invited into meetings where they discuss future strategies, plans on how to make it a better place to work and so on. If anything is important for you, you get a summary with the highlights. No more wasting time in these hourly meeting. You get time to do what you love without interruptions – code.
  • You are often the most experienced – you get hired into teams with less experienced. This means that you can shine with your experience. The senior in the organization you work for are often stuck supporting their critical systems.
  • Mostly Greenfield projects – the most fun projects to work on are Greenfield projects, as you built something new. Again, this is because they need to try something new and their seniors are stuck in their existing systems. This means you don’t end up in an old legacy system.

The Bad thing about being a Software Contractor

Here are some bad things about being a Software Contractor.

  • Showcase how you develop your skills – Before you get hired into a project, they always want to know how you keep yourself up to date with the technologies. They expect this to be done in your free time. So it is important you can showcase this.
  • Good at job interviews – you need to be good at job interviews, as they will run you through a lot of things in no time and expect you to be on a totally different level than normal software engineers are in job interviews. This is just practice, but you need to good at selling yourself.
  • Big network – having a big network is also a key thing you want to get the interesting contracts. Recruiters are pain, and are often hired to get contractors into projects that cannot attract anything. That said, it means using the offers from recruiters is plan B. You would want to know someone working in a project you want to be part of.

The Ugly thing about being a Software Contrsactor

Here are the ugly things about being a Software Contractor.

  • You are responsible for your code – if you work as an employee in a company, you are actually not responsible for the code you write. As a Software Contractor you are. That means, if you make some code that is the result in a company losing a lot of money, then they can sue you for that. This means you need an insurance.
  • There are no benefit – while the pay is great, you get nothing else. If you want to participate in social events where you work, you most often have to pay for everything yourself. Also, if you need to go somewhere on behalf of what you do for them, you also need to pay the expenses yourself.
  • Contractors have a bad reputation – As mentioned above, Software Contractors are most of the time hired to get results fast. This often comes with a price of quality in the solutions you deliver. Some Software Contractors don’t mind this, and just come, deliver code, and leave. I like to discuss solutions and why choices are made with the team, to compensate for the design and solution choices.

Want to learn more?

Get my book that will teach you everything a modern Python cloud developer needs to master.

Learn how to create REST API microservices that generate metrics that allow you to monitor the health of the service.

What does all that mean? 

Don’t wait, get my book and master it and become one of the sought after Python developers and get your dream job.

Do This and 10X Your Salary as a Software Engineer

The Honest Truth

To be honest, I am not really a great programmer – that is not what you get highly paid for.

This is something that even software engineers that have been in the industry for many years do not understand. Also, those that craft code that is way better what I can do.

Let’s dive into the 5 things that will increase your salary as a Software Engineer.

Key Skill #1: Decouple Code

To decouple code is about writing and designing code with loose coupling. The best way to understand it, is to understand what strong coupling is.

Strong coupling is basically what happens when you write code and it grows organically.

What do I mean?

Well, you let the code evolve from the first line of code until the last line of code solves the problem.

You end up with code, which is difficult to test, debug and maintain. If you make a change one place in the code, you do not really know what happens in the other parts of the code.

This happens for everyone, which does not think about encapsulation.

Encapsulation is about creating classes with an agreed upon interface. This hides the actual code away.

As an example consider the RestApi class above. If the way you call and parse the result from the REST API changes, this can be hidden in the method call. Hence, if you use call in your code, you most likely do not need to change anything at those places if the nature of the REST API changes, you can make those changes inside the method call.

The same for class Storage. Imagine you want to change the way you store data. You can make all the changes to that inside the Storage class, without needing to make any changes to the code where you use the class Storage.

Software Engineers that master decoupling craft code that is easy to maintain, debug, and extend. This is a key skill when you make production code.

Key Skill #2: Source of Truth

Every modern system uses data and the most common pitfall when working with data is not to understand the Source of Truth.

The Source of Truth means that data is mastered, and most importantly, edited only in one place.

You actually see this problem all places.

The above screenshots where taken simultaneously from two different pages of my YouTube channel.

It claims two different numbers of views.

Which one is right, which one is wrong?

The problem is, that it reads the data from different places. That data is stored temporarily in different places and not synchronized fast enough to be given the same numbers.

Consider the following problem I just encountered. I was creating a system view of the data types of files in a storage and exposing them.

Now the Truth about the data types is in the Storage, not in my view.

Now someone else needs the Data types of the data in the storage. Since I already extracted them, they were inclined to just take them from my new system (see image above).

The problem comes, when someone changes the data type of, say, Data A. Then it is wrong in my system (the middle one), and surely wrong in the last system (on the right).

I might remember to synchronize the data types, but what about their system. Did they remember? Anyhow, it can easily end up with a data ecosystem, where there is a lot of wrong data.

Understanding this is crucial when creating systems.

Key Skill #3: Think Long-Term

Most developers only focus on solving the programming problem they are hired to do. They get a feature they need to implement. They just implement it and move on to the next one.

A more experienced programmer, and highly paid programmers think differently about it.

They try to craft code in a way that makes it easy to.

  • Find a bug in the code.
  • Extend the code with more functionality.
  • Add tests to make sure someone in the future does not break the code.

But not only that, also consider the following.

  • What can go wrong in the module?
  • How can you make logging and metrics to know if it would happen?

Key Skill #4: Terminology

This one was a big surprise for me.

But actually how we use words and concepts is very different from team to team, and it also change over time.

What can go wrong?

Well, it does it all the time. You sit in a meeting with someone else, another team. You agree to implement some things. The meeting ends and everyone thinks they know what to do.

The problem is, that you all understand the concepts you use differently.

A highly paid software engineer will always ensure that all participants have a common understanding of what is agreed on. Asks about what is meant by the used concepts.

You will be surprised by the different ways we understand things.

Key Skill #5: Persistence Debugging

Most only care about finding the bug and move on.

When a system goes down, it can cost organizations millions of dollars per hour. Being able find bugs and ensure you catch them faster next time is crucial.

This is where concepts like leading indicators pays a big role.

A leading indicator, is something that can indicate that a crash might be on the way.

Sometimes bugs only show up on certain occasions, and you cannot reproduce them. Then you need to add logging and metrics to your module to get more evidence to your hypothesis.

Want to learn more?

Get my book that will teach you everything a modern Python cloud developer needs to master.

Learn how to create REST API microservices that generate metrics that allow you to monitor the health of the service.

What does all that mean? 

Don’t wait, get my book and master it and become one of the sought after Python developers and get your dream job.

Ultimate Guide to the Data Science Career Path

What does it take to become a Data Scientist?

Data Science is in a cross field of different fields.

This means you need a lot of different skills.

By experience, most Data Scientists work in teams, and do not necessarily need to be expert in all areas. Hence, the list of skills is an idea of what you need.

A great way to look at it is in hard and soft skills.

Hard skills

  • Math and Statistics
  • Programming
  • Domain knowledge
  • Data visualization

Soft skills

  • Curiosity
  • Communication
  • Storytelling Skills
  • Structured Thinking

I would say, that the soft skills you learn by experience and but you need an interest in them. The hard skills are the ones you need to get good or at least decent at.

Looking at the hard skills, you do not need to master all aspects of it.

Before we dive into the hard skills, let’s also understand what a Data Scientist does.

Math and Statistics

I understand that many get scared of this one and if you take a formal education in Data Science, you will learn a lot of Statistics.

Experience shows, that it is the few specialists that need a high level of statistics as a Data Scientist. That said, you still need to understand some aspects in-depth.

What does that include?

The most important are.

  • Count– a descriptive statistics and counts observations. Count is the most used in statistics and has high importance to evaluate findings.
    • Example: Making conclusion on childhood weights and the study only had 12 childing (observations). Is that trustworthy?
    • The count says something about the quality of the study
  • Mean – The average value.
  • Standard Deviation – is a measure of how dispersed (spread) the data is in relation to the mean.
    • Low standard deviation means data is close to the mean.
    • High standard deviation means data is spread out.

Also understanding box-plots.

What correlation means.

You can learn more about it here.

Programming

Python is used in the scientific communities for a set of reasons.

  • Ease of use and simple syntax.
  • Easy to adapt without engineering background.
  • Many libraries.
  • Wide community.
  • General purpose makes it easy to collaborate.

Python is the most popular programming language in the Scientific Community including Data Science. It is a solid choice to learn.

But do you need to master Python programming on a high level?

No, you need to understand Python programming to a simple level where you master the following.

  • Basic understanding of programming – how Python code works.
  • Variable and Data Types.
  • Calculations with simple types
  • Loop over Data Objects
  • How functions can help you work.
  • How methods can be applied on Data Objects.
  • How to read and write data.
  • Master Data Types: Lists, Dicts, NumPy, DataFrames.
  • Use of Machine Learning Models

This sounds like a lot but can be broken down in steps.

Python Basics

Most beginners courses in Python will do fine, while some specialize too much. But what you need to understand and get a feeling of, is how Python code works.

Some common things you learn in Basic Python course.

  • Variables and built-in Data Types like Lists and Dicts.
  • How to calculate with variables.
  • Looping over Data Objects like Lists and Dicts.
  • Built-in Python functions to ease your work.
  • How to work with files.

Other things you learn, that is good to understand, but not needed to master.

  • Object Oriented Programming (OOP) – you need to understand the idea of OOP, as it will help you understand how a computer works, and how it works on your Data Objects.

A great source is this free course.

Learn NumPy and DataFrames

For the most part, you get really far with pandas DataFrames as a Data Scientist. If you understand them and can work with data with them. Then you are really far.

NumPy is an extension on top of DataFrames (even though it is implemented opposite).

But what are DataFrames and NumPy?

They are data structures used to contain the data you work with as a Data Scientist.

A great place to learn about DataFrames is to follow this free course.

Machine Learning

The Machine Learning models you create are the one that creates your insights to deliver value to your clients. Therefore you need skills to master them and understand how they work.

There are a lot of models and you don’t need to be an expert in all of them. But it is a great idea to understand them.

A few ones could be.

  • k-Nearest-Neighbors Classifier.
  • Linear Classifier
  • Support Vector Machines
  • Linear Regression
  • Q-Learning
  • k-Means clustering
  • Deep Neural Network (DNN)
  • Convolutional Neural Network (CNN)
  • Recurrent Neural Network (RNN)

And be knowledgeable in frameworks like.

  • Sci-Kit Learn
  • Tensorflow
  • PyTorch

You can build up your skills in this free course.

Domain Knowledge

This is actually often the key to get a job as a Data Scientist.

If you know a lot about Windmills, power prediction patterns, and so forth. Well, then it will be easier for you to get a job as a Data Scientist for a company predicting power productions by Windmills.

Or you are an expert in weather forecast. You can also, get a job as a Data Scientist for predicting power production by Windmills.

The point is twofold.

First, if you have worked in an industry for a few years, then you have deep domain knowledge about that field. Is there is cross-field where you can apply Data Science? Well, find those jobs and you will have a great edge to get it.

Why?

Well, most say that it is easier to train people to make Data Science, that giving them 3-4 years of experience in a Domain.

Take advantage of that.

Second, if you have an interest in some specific area of Data Science. Focus down on it. Become an expert.

Again, having Domain Knowledge is crucial to set yourself apart from the other applicants.

Data Visualization

Data Visualization if often misunderstood by beginners in Data Science.

It is actually crucial in 3 different aspects.

  1. Data Quality: Explore data quality including identifying outliers
  2. Data Exploration: Understand data with visualizing ideas
  3. Data Presentation: Present results

Most only focus on the Data Presentation – presenting your findings. While this is an art in itself, most do not fully capture the importance of the other ones at first.

Our human brain is not wired to understand data as digits, but when we see them visually on a chart, we can immediately see and understand it.

Just look at this one.

What is wrong? Well, it looks that some heights are not fitting the other heights.

This tells you something about the Data Quality. Is there something wrong with it?

The chart would tell you something is wrong no matter how many data points you have. But image you had to look through 10,000 of data points manually in a table. That would take hours and you might miss it.

When it comes to exploring data, seeing it visually on a chart shows you patterns.

Again, you would notice that looking at the data in a table.

Finally, data presentation is an art in itself.

Does this one tell you a story?

A great resource to learn about Data Visualization can be found here.

Does that map out a what you need as a Data Scientist?

This gives you the hard skills you need as a Data Scientist.

A great way to think of it is also to understand the Data Science Workflow.

It gives you an idea of what steps a Data Science Project goes through.

If you are new to Data Science a great thing to do is to start on the Data Science Career Track bundle that covers all the above, plus it gives you access to discuss your learnings and troubles with the instructor.

Check out the offer here.