As a software engineer, it’s easy to get caught up in the details of programming languages and practices. Maybe you believe that one language is superior to all others, or that microservices are better than monoliths.

But here’s the question you need to ask yourself: how much do these things really matter in the grand scheme of things?

I Was a True Believer

I used to think that picking the right programming language mattered more than anything else.

When I was a junior developer, I was convinced that picking the right programming language was the key to innovation. I read Paul Graham’s Beating the Averages with zeal. I learned everything I could about Smalltalk, Lisp, and Haskell.

I still think that many ‘modern’ programming and DevOps tools feel like trying to build a skyscraper with sticks and stones compared to the magic available 40+ years ago on Lisp machines and in Smalltalk-80.

Technology Matters Less Than You Hope

But the truth is, in a world with amazing open-source tools like Django, FastAPI, Ruby on Rails, Qt, and countless others, it’s tough to beat the averages because the averages are now pretty darn good. And beating them doesn’t buy you as much as it used to.

Regardless, the average user doesn’t care what programming language you built your app with.

As engineers, we’re tempted to think everyone cares about technical details as much as we do, but most people just want things to work. And when the chips are down, engineers usually don’t care either.

For example, read this tweet by @levelsio discussing how RemoteOK generates over $100,000 per month in revenue with a single PHP file as its backend.

Of all the engineers and techies who found remote jobs via RemoteOK, how many of them do you think got upset about its backend? I’d bet it’s a rounding error.

Make Pragmatic Engineering Choices, But Don’t Be Reckless

None of this means good engineering doesn’t matter at all. A maintainable, readable, and clean codebase is certainly better than a messy, hard-to-understand codebase. Testing is crucial, and following best practices for security and performance is vital.

Beware fake productivity

But it’s also important to recognize that debating languages and tools and conceptual purity can feel like productivity, when in reality it’s a waste of time.

A team that chooses ‘boring’ tools like PHP and Laravel and gets down to work will likely progress more quickly than a team that spends its first month arguing about whether to use Rust, Go, or Elixir.

Pick tools that get the job done

The same is true when it comes to the trade-offs between different libraries and tools. For example, choosing between a relational database or a document database can be a contentious topic.

But will using Postgres instead of MongoDB make or break your company? Probably not.

Will choosing Express over fastify ruin you? Unlikely.

Ultimately, the best choice depends on what you’re creating. In many cases, the specific tech you choose matters less than you wish it did.

Yes, you might make the wrong choice. It happens. Make the best choice you can with everything you know right now, and change your mind down the road if necessary.

The smaller you are, the more pragmatism matters

The idea that technology choices don’t matter as much as we think applies doubly to solopreneurs and early-stage startups. Getting a product to market and learning about customer needs is paramount.

Use, PHP, Ruby on Rails, Qt, React Native, or whatever lets you start delivering value to users ASAP.

Sometimes, Technology Gives You An Advantage

With all that in mind, you should still use your brain. Remember that sometimes technology does matter, especially when it gives you a competitive advantage.

For example, if you’re building app aimed at a niche that values real-time UI and dashboards, using Elixir, Phoenix, and LiveView might help run you circles around competitors struggling to build similar solutions using Node.js, Socket.io, React, Recoil, duct tape, and hope.

In short, remain aware of how can help you compete. If you like the idea of disrupting a market with technology, work hard to stay up to speed on markets you care about and technology that might help you disrupt them.

The Game Changes When You Need To Scale…

Making simple technology choices early means you’ll need to revisit them as you scale. For example, a startup that has found product-market fit and is consequently growing rapidly should spend serious time, thought, and salary on architecture and engineering.

But even when you’re scaling, remain cautious and try not get caught up in technical bike shedding. Twitter got a long way using Ruby on Rails, not exactly known for its speed. Yes, the fail whale showed up too often. But people kept using the platform.

And Shopify, a $60 billion company, is at its core still a monolithic Rails app (albeit with plenty of help from Go, React, and others.)

…Or When You’re Already At Scale

Similarly, when working on an app already operating at scale, aim for engineering excellence. Think about performance and maintainability.

And don’t forget that scale is relative. Ten thousand simultaneous users might seem like a lot right now. But if you’ve reached that level, there’s a good chance you’ll need to handle ten times as many in a year, so plan accordingly.

Remain vigilant, however, and remember to balance engineering goals with practicality and the need to deliver value to your users.

Finally, if you work for a behemoth like Google, Amazon, Microsoft, or Netflix, you might need to create an app that handles thousands or millions of users on day one. In that case, it’s crucial to engineer for scalability from the beginning.

Even then, you’re not focusing on technology for its own sake. You’re doing it because you must do it to meet user expectations.

Takeaway

Whether you’re a solopreneur or a cog in a big corporate machine, always consider the trade-offs imposed by your technical choices. The most important thing is delivering value to the users and meeting the requirements of the business.

Maybe you’re wondering what the heck I’m talking about because you’ve always worked on teams that made pragmatic tech choices.

If so, I envy you. I’ve worked on some great teams alongside amazing software engineers and even then, we wasted too much time on technical yak shaving that ultimately didn’t matter.

So next time you find yourself getting caught up in debates about the superiority of one language or engineering practice over another, remember: what really matters is building things that people want to use.

Without users and the business they support, there won’t be any money to pay for technology! As long as you prioritize practicality and results over conceptual purity, you’ll be on the right track.

The post Prioritizing What Matters in Software Development appeared first on Ryan Peden.

As a software developer, I know firsthand the allure of diving deep into the technicalities of creating complex applications. But it’s important not to get lost in the code. Some of the best career advice I can give other developers is that they should learn to look beyond the code they’re writing.

Getting Lost in Code

I still remember my early days of programming, when I was so excited to learn about all the latest tools and techniques. I spent hours studying code and trying out new frameworks. That was an incredibly valuable learning experience for me.

However, as I gained more experience and my projects became more complex, like creating big .NET backends and sophisticated React front-ends, I found that getting caught up in the technical details wasn’t always helpful.

It wasn’t that technical details weren’t interesting. They were! Maybe too interesting.

But getting getting caught up in technical details meant I didn’t always keep the end goal in sight. I would get lost in the code and lose track of what I was trying to accomplish.

Remember Your Users

This same dynamic can play out in development teams, whether at startups or larger companies. Developers often get caught up in debates about the minute differences between frameworks or the latest and greatest tools, rather than focusing on the needs of their users.

It’s important we ensure our work is technically sound, but it’s also crucial to remember we’re creating products and services for real people.

Coding for its own sake can get boring after a while. The real joy comes from making things that other people use and love. That’s why it’s so important for developers to keep their eye on the prize and think about the bigger picture.

Solving problems in a performant, scalable, and maintainable way is still important, but it’s also crucial to consider the needs of our users and how our work fits into the overall goals of our team, our company, and our users.

Why I Like DevRel

Focusing on awesome user outcomes and not just code is why I’ve gravitated toward DevRel and DevEx engineering over the past few years. In these roles, I still get to write as much code as I want to, and I still get to work on product features.

But I also spend a lot of time connecting with the developers who use the product. It’s incredibly rewarding to see how my work helps to create tools that developers love, and then helps the developer community discover and learn how to use those tools.

The post Don’t Get Lost in the Code appeared first on Ryan Peden.

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

Strategic vs. Operational

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 post Make Your DevRel Strategic, Not Operational appeared first on Ryan Peden.

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.

The post How to find the version of a globally installed NPM package appeared first on Ryan Peden.

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.

The post So You Want to be a Freelance Web Developer appeared first on Ryan Peden.