Make Your DevRel Strategic, Not Operational

As software continues to eat the world, the role of the developer advocate or evangelist – and DevRel in general – is becoming more critical. Companies now see the value in having employees who focus on building relationships with developers. Yet instead of making DevRel strategic, too many companies treat it as an operational activity.

This is a mistake. Companies targeting developers should treat DevRel as a strategic activity vital to achieving business goals.

Strategic vs. Operational

A picture of a person writing on post-it notes and placing them on a board.

What do I mean, exactly, when I talk about strategic and operational?

The business world uses the term “strategy” in different ways. I’m talking about Michael Porter’s definition. The idea that a company should undertake a unique mix of actions to help it build a moat – actions that set it aside from its competitors. These activities can provide the company a unique and defensible strategic market position.

Operational activities are different. They’re what you do daily to keep the business running. You need to do them, but they won’t help you build a competitive advantage. Operational innovations are easy for competitors to copy. 

Think of things like accounting or HR. They’re operational. Even the act of writing code is usually operational. You’re not going to develop a revolutionary way of writing code unless you’re Google. The things your code does might be strategic. But the fact you use Scrum shouldn’t be part of your strategic positioning.

Activities like DevRel that should be strategic can be merely operational. This happens if you tick the standard boxes that everyone ticks. Things like doing a bit of advertising. Or writing some uninspiring blog posts. Or setting up a Discourse forum but don’t engage with anyone who asks questions.

Why Make DevRel Strategic?

So why, exactly, should you treat DevRel as strategic? There are a few reasons why you should consider it.

First, it helps you build real trust with developers. I’m not one of those hipsters who will preach about the importance of “authenticity” when addressing developers. Instead, I’ll say you need to be bullshit-free. Building trust is difficult if you treat DevRel as a operational checkbox on a list of things you think you’re supposed to do. Instead, treat it as a core part of who you are.

This trust is important because developers are becoming the gatekeepers of technology. They decide which products and services to use and recommend to their colleagues. As a result, developers are more likely to use and recommend the products of a company they trust.

Next, DevRel – if done strategically – can help a company understand the needs of developers. Developers are a key customer segment for many companies, so it’s essential to understand their needs. Strategic DevRel helps build these relationships by talking to developers about their needs. These relationships lead to insights that can improve products and services. Operational DevRel is rarely comprehensive enough to lead to iinsight.

DevRel can also help a company position itself as a thought leader in its industry. By making itself known as the kind of company that gets developers, cares about the things they care about, and is actively invested in making their lives better, a company can set itself apart from its competitors. 

As an extra benefit, thought leadership can also help a company attract top talent. The best developers want to work for companies at the forefront of their industry. By positioning themselves as thought leaders, a company can attract these top developers to its team.

But if your treating DevRel as operational, you might not be thinking thoughts developers would consider leadership.

What Next?

DevRel can be a considerable driver of company growth – if you do it right. But you will not see the benefits if you treat it as a token effort rather than a core part of your identity. If you make it part of who you are as a company, however, you can reap the rewards of faster growth, better products, and a stronger position in your industry.

The next question: how do you make your DevRel efforts strategic from the start? And how do you move DevRel in a strategic direction if you have it, but it is operational and ineffective? That’s a topic for another post.

The Top 5 Reasons Why Software Engineers Hate DevOps

Note: This article was written by a neural network. It’s part of a series of experiments I’m doing to see how well AI can generate plausible and not-totally-awful clickbait. But I promise I don’t actually hate DevOps.

DevOps was supposed to be the silver bullet that would fix all the problems caused by agile development. Unfortunately, most developers hate DevOps. The overall cause is simple: DevOps requires developers to change how they think about software.

There are five main reasons why devs hate DevOps. Let’s talk about each one in turn.

Reason 1: Developers Don’t Like Change

DevOps is based on the idea of continuous integration and delivery. In other words, it encourages constant feedback loops. This means that every developer must check in their code frequently. Then, they have to test it. Finally, they have to release it to production.

All of this happens automatically. This makes it easy to automate. It also ensures that any bugs are found early. This gives the team time to make fixes. And it prevents problems from spreading through the whole organization.

As a result, DevOps eliminates a lot of the chaos that used to happen during both waterfall and agile development.

Unfortunately, many developers don’t like change. They prefer the stability of traditional methods. So they resist DevOps.

One example of this is the use of CI/CD tools. Many developers believe that these systems cause too much friction. These devs feel that it slows down their workflow.

Another example is the idea of automated testing. Most devs don’t like this. They worry that it will slow them down.

Finally, some devs dislike the idea of automating deployments. They don’t want to give up control over their servers.

The bottom line is that many developers don’t like change. That’s why DevOps is so difficult for them.

Reason 2: Developers Don’t Understand the Value of Automation

A big problem with DevOps is that most developers don’t understand what it does. For instance, they often assume that it will increase their productivity.

But that’s not true. DevOps isn’t about increasing the number of features your application can do. It’s about making sure those features are tested and released quickly.

In fact, DevOps is more efficient than traditional methods. With DevOps, you only have to deal with the problems that occur after someone else has fixed the ones that happened earlier.

So why do developers hate DevOps? Because they think it will reduce the amount of time they spend adding new features.

They’re wrong.

DevOps doesn’t mean that you won’t add features. It simply means that you’ll be able to find and fix problems before they get out into the wild.

That way, when something goes wrong, it’s easier to fix.

And if you don’t have to waste time fixing things, you can focus on building new stuff.

Reason 3: Developers Don’t Want to Deal with New Tools

DevOps uses a variety of tools. Some of these include containers, Kubernetes, Jenkins, GitHub, Docker, etc.

Many devs hate dealing with these tools.

Why?

Because they think they’ll slow them down.

For example, many devs believe that using a container will increase their deployment times. And since DevOps relies on frequent releases, they assume that they need to make frequent changes to the images.

These assumptions are incorrect.

Containers speed up the process of deploying applications. They help prevent errors from getting out to the rest of the world. And they allow teams to deploy different versions of the same app at the same time.

As a result, DevOps saves time.

However, there are still a few issues.

First, DevOps tools aren’t perfect. There may be bugs or security holes in them. As a result, some developers will avoid using them.

Second, it takes time to learn how to use DevOps tools.

Some devs might try to use the tools without learning how to use them properly. This could lead to serious problems.

Finally, it’s important to remember that DevOps tools aren’t magic. They can’t fix everything. You still need to write tests. And you still need to keep track of your code.

You just have to do it differently.

Reason 4: Developers Are Afraid of Making Mistakes

DevOps encourages developers to take responsibility for their own mistakes.

Most devs don’t like this idea. After all, they’re afraid of making mistakes.

If they make a mistake, they’ll get fired.

So they avoid taking risks.

Unfortunately, this approach usually leads to bad results.

When you use DevOps, you should always be looking for ways to eliminate risk. If possible, you should never have to fix a bug.

Of course, this is easier said than done. Sometimes you can’t completely eliminate the risk. But you can minimize it.

For example, you might decide to automate the entire build-test cycle. This would remove the human element from the process. It also reduces the chance of a human making a mistake.

Similarly, you can use containers to isolate code. Doing this prevents you from accidentally breaking your application.

Finally, you can use automated testing to catch mistakes as soon as they happen.

The point is that DevOps encourages you to accept some level of risk. This is why DevOps is so hard for many devs.

Reason 5: Developers Hate Working with Other People

DevOps encourages collaboration between software engineers and operations. This means that you have to work closely with other people. Unfortunately, many developers don’t like this idea.

They’re scared of interacting with others. They’re afraid of being criticized. And they worry that working together will cause conflict.

Of course, it’s important to collaborate with your team. But it’s equally important to know when to step back.

It’s okay to disagree sometimes. But it’s not okay to argue constantly.

Finally, it’s also important to recognize that everyone makes mistakes.

No one is perfect. Everyone needs to admit that they’ve made a mistake. Then they need to move on.

The bottom line is that DevOps requires you to interact with others. And that can be scary.

That’s why so many devs hate DevOps.

Conclusion: The Bottom Line

To sum up, here are the five main reasons why devs hate DevOps.

1. Developers Don’t Like Change

2. Developers Don’t Understand the Value of Automation

3. Developers Don’t Want to Deal with New Tools

4. Developers Are Afraid of Making Mistakes

5. Developers HATE Interacting with Others

Now, the real question is: are developers right, or should they give DevOps another chance?

Well, I think it’s worth giving DevOps a second look. But only if we make sure to address all of its problems.

Here are three steps that you can take to improve DevOps:

Step 1: Make Sure Your Team Knows What DevOps Is

First, make sure that everyone knows what DevOps is. DevOps isn’t about tools. It’s about a mindset. Once you understand that, it will be much easier to adopt DevOps.

Step 2: Teach Everyone How to Use DevOps Tools

Next, teach everyone how to use DevOps tools. It doesn’t matter whether you’re using Jenkins, GitLab, CircleCI, etc. Just show them how to use them. Make sure they understand the basic concepts.

Don’t worry about automating everything. That will come later. Just focus on teaching them how to do things manually first. Remember, DevOps tools aren’t magic. They can’t fix every problem.

They can, however, help you reduce the amount of manual effort needed to complete your tasks.

Step 3: Find Ways To Eliminate Risk

Finally, find ways to eliminate risk. You can start by eliminating bugs. Then you can automate more of your processes.

Also, try to limit the number of people who have access to your servers. This will prevent unauthorized changes from spreading through the organization.

The goal is to create an environment where you don’t have to worry about making mistakes. With these three steps, you’ll be able to use DevOps without having to deal with all of its problems.

How to find the version of a globally installed NPM package

Sometimes, you really want to know the version of a globally installed NPM package. That’s the position I found myself in this morning. Googling didn’t help me much. Most of the answers I found just didn’t answer my question.

Here what you need to know. If you want to see the version of a globally installed NPM package, run this:

npm ls -g package-name --depth 0

Replace package-name with the name of whatever package you’re looking for.

In most cases, adding --depth 0 isn’t necessary. But in rare cases, the global package you’re searching for is also a dependency of other globally installed packages. When this happens, you’ll see the package you want, but you’ll also see a partial dependency tree of all of the packages that use the package you’re searching for.

Adding --depth 0 eliminates this problem. Feel free to leave that part out and only add it if you need it.

WebStorm vs Visual Studio Code

I often see developers comparing JetBrains WebStorm and Visual Studio Code. There’s often some argument about which one is better. Since is the internet and every else shares their opinion here, I figure I’ll do the same. Here’s what I think:

I love VS Code and use it every day.

But I often like JetBrains’ IDEs even more, because when I’m really in the zone it feels like I’m pair programming with a psychic. If I know a symbol (class, function, constant, whatever) is defined somewhere in my code, or in a library my project can see…I just start typing the name of the thing I want to use, even if I haven’t imported it into the file I’m working on.

99 times out of 100, WebStorm (or PyCharm, or IntelliJ, or Rider, depending on what language I’m working in) knows what I intended to use well before I’m done typing it. So with a single keystroke, I’m able to autocomplete the line I’m typing, and the IDE will, if necessary, auto-add the import to the file I’m in so I don’t have to do that manually.

At various times I’ve come close to this experience in VS Code – but it varies a lot based on the language. The code indexing and intelligent code completion in the JetBrains IDEs just seems very in tune with my thinking and my workflow, and it’s very consistent across languages…whether I’m working in JS, Java, Python, C#, or TypeScript, the overall experience has the same smooth “feel” to it. So I’m very aware that my positive experience with these IDEs may be very specific to the way my brain is wired.

I find that the JetBrains IDEs also have better debuggers and better profiling tools.

That’s not to take anything away from VS Code. As I mentioned, I love it. Most days, I’ve got a JetBrains IDE and VS Code open at the same time, and often on the same codebase. VS Code feels a lot snappier and is quicker to start up. Some days I’m just in a VS Code sort of mood, and it’s the only thing I use.

If I had to pick one and couldn’t use the other…I suppose I’d pick IntelliJ/WebStorm. But if I had no choice but to use VS Code exclusively, I’d still be a happy camper. I think they’re both awesome tools and I’m happy I live in a world where I can use both of them.

Thoughts on SQL Query Builders and ORMs

Are SQL query builder libraries and ORMs more trouble than they’re worth? A couple of days ago, I read Stop using Knex.js via a link on Reddit.

I understand the point the author is trying to make. And I used to be pretty firmly opposed to ORMs and query builders.

I like SQL a lot. In one of the large applications I’ve worked on, every database option from basic CRUD to very complex queries happened in stored procedures in the database. While it was a tad tedious sometimes, it was also really damn fast. And I wrote a heck of a lot of SQL.

But over time, I’ve come to appreciate the benefits of a full-featured ORM. I think ORMs can be great tools for developers who have lived and breathed SQL for a while. Then, you can reasonably infer what the ORM is going to do under the hood.

Recently, I worked on a new .NET Core project. I used Entity Framework Core with it. I could’ve written a SQL script to create all the tables for me, but instead, I created my data model in C#, and then let EF Core generate the migrations to create the database tables.

And to be honest, I found that using C# as a notation for describing my tables and relationships between them nicer than using SQL to do it. But if I hadn’t spent a decent amount of time learning how to create normalized relation data models using SQL, I probably would’ve done a crappy job of expressing my data model in C#. So I suppose that understanding the relational nature of relational databases is the key here. Using SQL sort of forces you to think relationally. And as a bonus, I ended up with a nice set of C# classes that I can use in my application.

On the query builder side of things, EF Core is pretty darn good. I can generally predict what SQL it’s going to generate. And if it ever does go off the rails, EF Core offers a raw SQL escape hatch. You just give it the SQL query, tell it what class to map the query back to, and things generally just work. Sure, there are times where I could write better SQL than EF Core generates. But in most cases, the difference isn’t big enough to matter. And when it does matter, the hand-crafted SQL usually tends to be a short-lived fix. Before long, you’re on the road to super-fast Redis caching. So the faster SQL doesn’t end up mattering.

Query builders and ORMs are tools that can be used badly or used poorly. It’s easy to get into trouble if you use them as a crutch because you don’t really understand how the relational data you’re using works. But if you do have a solid grasp of relational fundamentals, you can use ORMs and query builders as force multipliers.

Is Software Development a Stressful Career?

Software development can, at times, seem like a stressful, thankless career. A recent discussion thread on Reddit got me thinking and reflecting back on the decade I’ve been working as a software developer. Some people seemed to lament the fact that working as a developer can feel like a thankless task with a backlog that never ends.

A new soon-to-be Computer Science grad mentioned that the found the thread depressing. They seemed to feel like they’d made a mistake and had a bleak future ahead of them.

A very stressed out human

What should you do?

To anyone feeling the same way, here’s what I’d advise:

Keep in mind that no matter what career you’re in, there are both good workplaces and terrible ones. Before becoming a developer 10 years ago, I worked in corporate accounting and it was the same there.

The best advice I’ve ever been given was to scrimp and save and set aside 6 months of living expenses if you can. That gives you the ability to play a bit of hardball when it comes to asking for improvements to bad work environments because it’s easier for you to walk if you don’t get what you’re asking for.

I’m fortunate to work at a place now where playing hardball like that isn’t necessary. People are nice. The work is interesting. The schedules are reasonable. And I’m pretty sure I’m not the only one who has ended up in a great workplace.

So as a new grad, try not to feel depressed. Just remember that there are good workplaces and bad ones. Sure, software development can be stressful at times. But I’d be worried if I were in a career where I never feel stressed at all, because that would mean I’m probably not being pushed or challenged professionally. And lack of challenge quickly leads to boredom.

JavaScript Array Push Performance

This is a short response I wrote to a question on /r/javascript. The user who asked it was curious whether there would be any performance difference between adding elements to a JavaScript array by calling push, or manually adding a new object to an array by making a call like myArray[myArray.length] = obj. Let’s take a look at the ECMAScript specification to see what it says.  

In the case of Array.prototype.push, the JS runtime must first call toObject on the argument passed to push. It must also do a bit of work to handle the case where more than one item was passed to push, since you are allowed to make a call like this: abc.push(1,2,3). After from calling toObject and checking how many arguments were provided, it then goes through each one and does a regular property set call, which ends doing the same as myArray[myArray.length] = obj.

If you’re only adding one thing to your array, you may as well call push, since it is easier to read and the toObject call and args length check is going to make an immeasurably small difference to execution time.

If you’re adding multiple things to your array, then call myArray.push(...things). because when you do that, the JS engine’s compiled C++ will handle all of the iteration, instead of thunking back and forth between native code and JavaScript if you’re looping through yourself and calling push every time. In reality, with all of the optimization and JITing that modern JS engines do, looping through yourself probably isn’t all that much slower than passing everything to pushat once. I haven’t tested this to verify, though.

JavaScript indexOf vs includes performance

This is a short response I wrote to a question on /r/javascript. The user who asked it was curious whether there would be any performance difference between using a JavaScript string’s indexOf vs includes performance when trying to find a substring within a larger string. 

Let’s take a look at the ECMAScript specification to see what it says.  

In the case of indexOf vs includes, you’ll find them right next to each other here in the ECMAScript spec. The only difference is that includes checks if you’ve passed it a regular expression instead of a string, and throws an exception if you have. indexOf will accept a regular expression but always return -1, which isn’t too helpful.

So while includes will be a tiny, tiny amount slower because it has to check if you passed it a regex, in reality this will make no difference to how fast your code runs. You should use indexOf if you care about where the substring is in the original string. If you don’t care, just call includes because it makes the intent of your code more clear.

You should also consider that indexOf won’t find the location of NaN values in an Array. For cases where you really need to find the first location of something that indexOf can’t find, and you don’t want to loop the array through yourself, then Array.prototype.findIndex is your friend. You can pass it a function that returns true when it sees the value you’re looking for. So [1, 2, 3, NaN, 4].findIndex(Number.isNaN) would return 3.

The verdict: in most cases, in terms of JavaScript indexOf vs include performance it doesn’t matter much whether you use index vs includes. You should pick the one that’s the clearest fit for the problem you’re trying to solve.

If you liked this, you might like these other articles I’ve written:
Using Web Components with React in 2019
An Angular Roadmap – The Past, Present, and Future of Angular
How do JavaScript Arrays Work Under the Hood?

How to remove /api from Azure Functions URLs

Note: All of the following assumes you’re working with Azure Functions 2.0.

Azure Functions are great. By default, all HTTP functions on Azure have their URLs prefixed with /api. For example, if you have functions named Function1 and Function2, you’d reach them by calling http://my-app.azurewebsites.net/api/Function1 and http://my-app.azurewebsites.net/api/Function2.

Usually, this is fine. But it seems like an arbitrary restriction. What if you’d rather not have it?

Fortunately, there’s a configuration option in your function app’s host.json file to change it. Unfortunately, as I’m writing this, Microsoft’s documentation is incorrect.

It tells you your host.json should look something like this if you want to remove the /api prefix:

{
    "http": {
        "routePrefix": ""
    }
}

This won’t work. If you’re running Visual Studio, it’ll tell you Property name is not allowed by the schema. Instead, the http object must be placed inside of extensions:

{
  "version": "2.0",
  "extensions": {
    "http": {
      "routePrefix": ""
    }
  }
}

Setting routePrefix to an empty string removes /api from the URL. Now, to access Function1, you’d call http://my-app.azurewebsites.net/Function1.

Also note the version property. If you don’t add this, the Azure Functions local simulator will flip out and fall into an infinite loop of scary-looking error messages:

If host.json is blank, the simulator will be fine. But as soon as you add anything else to host.json, you also have to add a version, or the simulator will go crazy.

And that’s it! You now know how to remove /api from your Azure Functions URLs. You can also use a non-blank string to use a prefix other than api. If you’d like your functions URLs prefixed by popcorn or cats, there’s nothing stopping you!

So You Want to be a Freelance Web Developer

I originally wrote this as a comment on Reddit. Since it ended up being 1700+ words, I figured it would be worth posting here too!

A caveat upfront: I haven’t done these things myself, because I’ve been lucky to have some awesome jobs I don’t want to leave. However, I’ve watched many of my peers try to freelance – some successfully, and some unsuccessfully.

So I think there’s still value in my observations. I’ve worked closely with marketing and sales teams more than once in my career, as well as having to deal with clients in an agency setting – so my marketing and sales advice is hands-on, real-world advice from the trenches.

Keep in mind that it’s entirely possible to follow the default route most people seem to when they try to go freelance – ditch the job, and try to pick up work by browsing Craigslist and /r/forhire. Or go to a freelancer marketplace like freelancer.com. The freelancers I’ve seen who attempted and failed never really advanced beyond trolling job boards, responding to lots of ads and hoping for the best.

The people I’ve seen do this successfully long term have realized that when you’re freelance, web development is no longer your #1 job. 

Job #1 – Marketing

The goal of marketing is to generate leads. You can do this online, but it might be easier to do in-person networking. Having a good story helps here. “I’m a freelance web developer” isn’t a great story. It makes you sound like an undifferentiated commodity.

When you’re starting, something better might be “I’m a React developer who helps funded startups deliver features more quickly.” Now, instead of describing yourself in terms that don’t distinguish you from the tens of thousands of people in low-cost countries who will work more cheaply than you, you’re expressing yourself in terms of the business value you deliver.

And by specifying something like “funded startups,” you’re opting into a) a market that has money to spend and b) is in a position where they need to trade money for time because VCs want to see ROI on their investment quickly.

Note that I’m not saying that funded startups are necessarily what you should target. But you should have a target market in mind beyond just “anyone in the world who might need web dev services”. Preferably a target market that tends to budgets to spend and isn’t afraid to use them.

Another example might be positioning yourself as a front-end specialist for Java or .NET shops. Companies that use these technologies tend to be larger, and dev managers might just have a budget to bring in a front-end specialist to do fancy-pants JS work the back-end enterprise developers are too busy to do.

Hopefully, those examples give you a starting point for finding a perfect target market for you!

In the long term, saying something like “I’m a React developer” might not be a great play. Technologies change, sometimes a lot more quickly than any of us expect. But when you’re just starting, if you know a super in-demand technology, using that to help describe yourself can be a good play. Over time, as you work with more clients, you’ll often find that you end up working with lots of them in a particular niche – medtech, or fintech, for example.

Then, your value prop becomes something like “I’m a developer who helps fintech companies deliver features quickly. Unlike my competitors, I have a deep understanding of finance so I’ll deliver work your customers will love.”

Job #2 – Sales

The goal of sales is to qualify and close the leads generated by step 1. 

Qualifying leads means making sure they’re serious about needing your services, and not just “kicking the tires” or trying to get you into a race to the bottom bidding war against other freelancers or agencies. If the lead already sees you as an undifferentiated commodity, you’re starting out in the hole.

The sales process also includes things like sales calls, writing proposals, and then following up relentlessly to turn those proposals into signed orders. If a client asks for a proposal, always ask them to schedule a call or meeting to discuss the proposal together. Some people will ask for a proposal as a way to blow you off. If they’re not willing to do a 15-minute proposal follow-up, there’s a good chance they aren’t serious.

When I say follow up relentlessly, I don’t mean that you should be annoying. If someone tells you to get lost, then get lost. The freelance devs I’ve known who seem to have lots of well-paying work seem to follow up using a sort of loose exponential backoff algorithm if a client ghosts them.

You’d be surprised at the number of clients who really want to work with you, but your $50k proposal isn’t one of their top 5 priorities because it’s the only 5-figure contract they’re dealing with right now. Ensuring these potential clients don’t fall off your radar can be vital to having a happy, successful, profitable business. If you don’t hear back from someone who has otherwise seemed polite and professional, they probably aren’t ghosting you. They’re likely just busy.

A CRM can be a massive help here. It’ll help you remember who all your leads are and see exactly when you’ve contacted them. It’ll even remind you to follow up when people haven’t gotten back to you. Salesforce for small business is $25 per user per month. Since you’ll be a one-person company, this might be $25 very well-spent.

99% of your freelance competition isn’t treating the sales process professionally and seriously. Many of them have vague worries about sounding too much like a salesperson. This is great for you! Good clients with real budgets are very familiar with the sales process. They expect you to sell to them. They expect you to suggest that you send them a proposal.

A professional sales process gives ideal clients confidence because it’s a strong up-front signal that you know what the hell you’re doing. It’ll increase the chances a client will want to work with you.

On the flip side, be wary of clients who argue on price and try to nickel-and-dime you on everything. Don’t be afraid to walk away if something seems off. Your instinct will usually be right. Walking away doesn’t mean you think a potential client is a bad person. Sometimes, you and the other person aren’t a good fit. It happens.

Job #3 – Project Management

You need to be your own project manager to ensure you deliver promptly on the deals you closed in step 2. 

Failing to keep clients up to date and deliver on time will ensure you have lots of one-off clients. Delivering great work on time, every time will help guarantee lots of repeat clients. It’s way easier to sell to existing clients than to new ones, you making your clients happy is essential.

As a one-person shop, you’ve got some flexibility when choosing what process you use. Scrum is probably overkill unless you find it valuable to have a daily standup meeting with your cat. Kanban often works well for solo developers.

As an experienced developer, you probably have a good idea of what will work well for you here.

Job #4 – Business Administration

Business administration means things like tracking your expenses, writing contracts, keeping track of business accounting, invoicing clients, and making sure your clients pay their invoices.

You’ll probably want a Master Services Agreement (MSA) that covers all the work you do for a client across all projects, then a separate contract or statement of work (SOW) for each project you do. This ensures that both you and the client know precisely what the terms of your business relationship are. Ideally, you’d get a lawyer to help you create these. But when you’re a new freelancer, that might be too expensive.

A while back when I was considering freelancing, I bought Brennan Dunn’s Double Your Freelancing Rate, and it has contract documents you can modify to suit your business. It comes with templates for MSA, SOW, and proposals. I think it’s worth the $297 for these documents alone. But it also comes with a great course that will shape your whole mindset toward freelancing. I highly recommend it. If you buy one thing in preparation for going freelancing, buy this. I’m not affiliated with the guy at all. I’m just a happy customer.

Job #5 – Web Development

Hey, we’re finally at the fun part! I won’t go into too much detail here since you already understand this part well.

It might seem disappointing that this is so far down the list. And it might seem like all of the items above are huge. At first, they will be. But the more you do marketing and sales, the easier they’ll become.

The marketing and sales work you do will land you good clients with large budgets, the kind of clients other freelancers aren’t able to get. And those good clients will become repeat clients, and so you’ll find that you’re spending most of your time on web dev work and the marketing, sales, and admin aspect fade into the background.

Or, you’ll find that you enjoy the marketing and sales so much that you want to hire a developer or two or three so you can spend all your time making deals. If that happens, congrats! You’re not running an agency.

Resources

Here are a few resources you might find helpful in your journey:

  • Jonathan Stark’s Hourly Billing is Nuts. Even if you decide you do want to bill hourly at first, reading this short book will ensure that you do so as a conscious choice after knowing what your options are.
  • Philip Morgan’s The Positioning Manual for Technical Firms. This will help you think about how to position yourself vs. your competition in a way that makes you stand out.
  • As mentioned above, Brennan Dunn’s Double Your Freelancing Rate is a great course that comes with some great document templates to help you get started. The course will help frame the way you think about freelancing, so I think it would be a worthwhile investment.

I’m not affiliated with any of these guys in any way. I just like their work, have found it informative and valuable, and think it would help you start your freelancing business on the right foot. In total, it’s an investment of maybe $400, which I don’t think is a huge price to pay considering how lucrative freelancing could be for you – if you do it right.

Holy crap. I apologize for the huge reply. I should turn this into a damn blog post or something.

Hey, look, that’s exactly what I did! Thanks for reading.