Should You Hire a Freelance Developer?
Should You Hire a Freelance Developer?
This article was originally published by LightStep
Your developer talent is directly related to the quality of your application and getting functionality out
the door. A common path to quickly on-boarding new dev talent is to consider freelance developers.
In this post I cover what I’ve learned about vetting and recruiting freelance developers, and when it
does and does not make sense.
I address the need to hire someone outside your company, most likely part-time, to build your
applications. For the purpose of this post, however, I don’t talk about the difference between
on-shore and off-shore freelancers – two distinctly separate models for freelance services.
Been There Done That
Over the last 10 years, I’ve hired six freelance developers and eight full-time devs. My experience is
that there are clear benefits to both formats of the role. To realize those benefits, however, it is critical
to first assess your company’s work environment to determine if it is conducive to the success of
freelance dev talent, or if it is more favorable to onboarding full-time employees in this role. With that
knowledge, you are then ready for the secondary challenge of finding a good developer to meet your
specific needs.
Most organizations neglect that first introspective step. Consequently, all too often, good talent is
destined to fail simply because of a poor fit with the company’s environment. It can be challenging for
even the best freelance developer to succeed if the company doesn’t provide a dev environment
where they can hit the ground running.
Understand Your Developer Environment
On a fundamental level, assess the dev environment by defining primary objectives and then
differentiating each as either strategic or tactical. The strategy needs to be owned by the
organization, and nine times out of ten should be the responsibility of full-time members of the team.
On the tactical side, a freelancer could be expected to learn the delivery chain, get briefed on the
backlog, and start coding. I.e., freelance developers should be hired to execute, not build strategy.
At a more granular level, recognize the differences between development strategy, application
architecture, DevOps and coding.
●Strategy: Building applications has a conceptual element. This includes how you build, and
what is included in your application. Strategy is everything from feature definitions to design
patterns. It requires creativity and intimate knowledge of the value your application is
bringing to the user. Strategy should be conceived by those who own the application and its
concepts.
●Architecture: Applications, like buildings and cars, are designed based on plans for how things
should be put together. More advanced applications include complex algorithms. Architecting
involves making decisions about where your application should run and if, for example, you
should use microservices or not.
●DevOps: This is where your organization defines tactics for how it will deliver its application,
including how its release is automated and how it’s tested. Larger organizations may also
include application security. DevOps should also comprise your monitoring tools, APM tools,
log analysis tools, incident response tools, etc.
●Coding: Coding is tactical, and is where a strong developer takes the requirements of
functionality and turns them into code in the language specified, with the stack specified, in
the process specified. This is the most tactical element of building any application, and usually
does not contain much subjectivity, nor requires much creativity.
Strategy and architecture determine what your application is; it will become your core IP. DevOps is
an execution component of building an application, as well as part of the delivery chain; it is inherently
expected to evolve. Responsibilities in these three areas – strategy, architecture, and DevOps – are
most appropriately owned and managed by staff in the company.
Involving freelancers at these levels should be avoided as it has the potential of introducing an
unnecessary knowledge management challenge. A common mistake, especially by organizations with
little to no application development experience, is to expect the freelance developer to take over from
a strategic perspective.
Ideally, freelancers should be hired only for coding. In some cases, you might ask them to help guide
the delivery chain (DevOps). They should not, however, be hired for strategy or architecture.
Setup for Success
Any developer new to the company will need to understand how to collaborate with the broader dev
team; or, if there is no broader dev team, the product owners and visionaries.
An environment that is set up for success for either a new full-time developer or a freelancer will
have:
●Vetted and approved dev environment and stack: You should know in advance where your
application runs (e.g., AWS or Azure), what programming language you will use (e.g., Node or
Go), and what your backend is (e.g., MongoDB vs Postgresql).
●Established software delivery chain and process: You should already know your desired
release cadence and how you deploy and test your application. For example, do you use
Jenkins for release automation? How are you testing the front-end, and running unit tests?
How are you monitoring and measuring application success? The freelancer should be told
how you expect them to deploy their application, not be left to decide on their own.
●Clear feature backlog: Verbally communicating the features you want the developer to create
is ineffective. You should have a backlog tool that clearly defines features, with user stories
that describe the features in as much detail as possible so that any dev can pick it up and
know what to build.
●Clearly defined architecture and design patterns: If you have specific ways you want code
written such as naming conventions, class structures, etc., you need to have those
documented and clearly communicated to any new developer. A developer – even a good
freelancer – can help define these, and the organization should try to establish conventions
moving forward.
●Policies and security practices: Depending on the size of your organization, you may have
security as well as compliance considerations that require you to have policies and security
practices in place, and in a format that is easy to communicate to a new dev.
What to Look For
A good freelance developer will:
●Be familiar with your stack: You can and should be very specific with your freelance
developers. Seek people who have experience with your stack. If your application is NodeJS
with a MongoDB backend, expect your freelancer to have healthy experience in both.
●Be full-stack: To be a full-stack developer means being experienced in front-end
development, backend development, and (in my opinion) application testing and release
automation. I.e., someone who can look at the development environment they work in,
holistically.
●Be mindful of application security and quality: This goes hand-in-hand with full-stack and is
very important. There are documented case studies of organizations leveraging freelance
developers that take shortcuts. The most common one is storing passwords in a database
clear-text (unencrypted). These types of shortcuts put the organization at risk. Your
freelancers – and everyone in the organization – should be accountable for the security of
what you deploy, and mindful of quality. Bad application quality and exploits will put you out
of business. This is as much a technical understanding as it is a cultural alignment that you
should look for even with outside contractors.
Every Company is a Tech Company
In order to compete in the modern world, every company must become a tech company. As such, they
quickly identify the need to build an application, and they know its value to their users. What they
often neglect to realize is that the way the application is built is as important to its success as is its
core functionality.
Hiring freelancers is a great way to fast-track functionality in existing applications, build your dev
resources, or get new applications into production quickly. But there are a lot of critical considerations
that go into hiring a freelance dev, above and beyond just their ability to code.
Chris Riley GUEST WRITER
Chris Riley is a technologist who has spent 15 years helping organizations transition from traditional
development practices to a modern set of culture, processes, and tooling. In addition to being an
industry analyst, he is a regular author, speaker, and evangelist in the areas of DevOps, BigData, and
IT.
This article was originally published by Lightstep”
Should You Hire a Freelance Developer?
This article was originally published by LightStep
Your developer talent is directly related to the quality of your application and getting functionality out
the door. A common path to quickly on-boarding new dev talent is to consider freelance developers.
In this post I cover what I’ve learned about vetting and recruiting freelance developers, and when it
does and does not make sense.
I address the need to hire someone outside your company, most likely part-time, to build your
applications. For the purpose of this post, however, I don’t talk about the difference between
on-shore and off-shore freelancers – two distinctly separate models for freelance services.
Been There Done That
Over the last 10 years, I’ve hired six freelance developers and eight full-time devs. My experience is
that there are clear benefits to both formats of the role. To realize those benefits, however, it is critical
to first assess your company’s work environment to determine if it is conducive to the success of
freelance dev talent, or if it is more favorable to onboarding full-time employees in this role. With that
knowledge, you are then ready for the secondary challenge of finding a good developer to meet your
specific needs.
Most organizations neglect that first introspective step. Consequently, all too often, good talent is
destined to fail simply because of a poor fit with the company’s environment. It can be challenging for
even the best freelance developer to succeed if the company doesn’t provide a dev environment
where they can hit the ground running.
Understand Your Developer Environment
On a fundamental level, assess the dev environment by defining primary objectives and then
differentiating each as either strategic or tactical. The strategy needs to be owned by the
organization, and nine times out of ten should be the responsibility of full-time members of the team.
On the tactical side, a freelancer could be expected to learn the delivery chain, get briefed on the
backlog, and start coding. I.e., freelance developers should be hired to execute, not build strategy.
At a more granular level, recognize the differences between development strategy, application
architecture, DevOps and coding.
●Strategy: Building applications has a conceptual element. This includes how you build, and
what is included in your application. Strategy is everything from feature definitions to design
patterns. It requires creativity and intimate knowledge of the value your application is
bringing to the user. Strategy should be conceived by those who own the application and its
concepts.
●Architecture: Applications, like buildings and cars, are designed based on plans for how things
should be put together. More advanced applications include complex algorithms. Architecting
involves making decisions about where your application should run and if, for example, you
should use microservices or not.
●DevOps: This is where your organization defines tactics for how it will deliver its application,
including how its release is automated and how it’s tested. Larger organizations may also
include application security. DevOps should also comprise your monitoring tools, APM tools,
log analysis tools, incident response tools, etc.
●Coding: Coding is tactical, and is where a strong developer takes the requirements of
functionality and turns them into code in the language specified, with the stack specified, in
the process specified. This is the most tactical element of building any application, and usually
does not contain much subjectivity, nor requires much creativity.
Strategy and architecture determine what your application is; it will become your core IP. DevOps is
an execution component of building an application, as well as part of the delivery chain; it is inherently
expected to evolve. Responsibilities in these three areas – strategy, architecture, and DevOps – are
most appropriately owned and managed by staff in the company.
Involving freelancers at these levels should be avoided as it has the potential of introducing an
unnecessary knowledge management challenge. A common mistake, especially by organizations with
little to no application development experience, is to expect the freelance developer to take over from
a strategic perspective.
Ideally, freelancers should be hired only for coding. In some cases, you might ask them to help guide
the delivery chain (DevOps). They should not, however, be hired for strategy or architecture.
Setup for Success
Any developer new to the company will need to understand how to collaborate with the broader dev
team; or, if there is no broader dev team, the product owners and visionaries.
An environment that is set up for success for either a new full-time developer or a freelancer will
have:
●Vetted and approved dev environment and stack: You should know in advance where your
application runs (e.g., AWS or Azure), what programming language you will use (e.g., Node or
Go), and what your backend is (e.g., MongoDB vs Postgresql).
●Established software delivery chain and process: You should already know your desired
release cadence and how you deploy and test your application. For example, do you use
Jenkins for release automation? How are you testing the front-end, and running unit tests?
How are you monitoring and measuring application success? The freelancer should be told
how you expect them to deploy their application, not be left to decide on their own.
●Clear feature backlog: Verbally communicating the features you want the developer to create
is ineffective. You should have a backlog tool that clearly defines features, with user stories
that describe the features in as much detail as possible so that any dev can pick it up and
know what to build.
●Clearly defined architecture and design patterns: If you have specific ways you want code
written such as naming conventions, class structures, etc., you need to have those
documented and clearly communicated to any new developer. A developer – even a good
freelancer – can help define these, and the organization should try to establish conventions
moving forward.
●Policies and security practices: Depending on the size of your organization, you may have
security as well as compliance considerations that require you to have policies and security
practices in place, and in a format that is easy to communicate to a new dev.
What to Look For
A good freelance developer will:
●Be familiar with your stack: You can and should be very specific with your freelance
developers. Seek people who have experience with your stack. If your application is NodeJS
with a MongoDB backend, expect your freelancer to have healthy experience in both.
●Be full-stack: To be a full-stack developer means being experienced in front-end
development, backend development, and (in my opinion) application testing and release
automation. I.e., someone who can look at the development environment they work in,
holistically.
●Be mindful of application security and quality: This goes hand-in-hand with full-stack and is
very important. There are documented case studies of organizations leveraging freelance
developers that take shortcuts. The most common one is storing passwords in a database
clear-text (unencrypted). These types of shortcuts put the organization at risk. Your
freelancers – and everyone in the organization – should be accountable for the security of
what you deploy, and mindful of quality. Bad application quality and exploits will put you out
of business. This is as much a technical understanding as it is a cultural alignment that you
should look for even with outside contractors.
Every Company is a Tech Company
In order to compete in the modern world, every company must become a tech company. As such, they
quickly identify the need to build an application, and they know its value to their users. What they
often neglect to realize is that the way the application is built is as important to its success as is its
core functionality.
Hiring freelancers is a great way to fast-track functionality in existing applications, build your dev
resources, or get new applications into production quickly. But there are a lot of critical considerations
that go into hiring a freelance dev, above and beyond just their ability to code.
Chris Riley GUEST WRITER
Chris Riley is a technologist who has spent 15 years helping organizations transition from traditional
development practices to a modern set of culture, processes, and tooling. In addition to being an
industry analyst, he is a regular author, speaker, and evangelist in the areas of DevOps, BigData, and
IT.
This article was originally published by Lightstep”
Comments