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.

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.

The post The Top 5 Reasons Why Software Engineers Hate DevOps 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.

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.

The post WebStorm vs Visual Studio Code appeared first on Ryan Peden.

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.

The post Thoughts on SQL Query Builders and ORMs appeared first on Ryan Peden.

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.

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.

The post Is Software Development a Stressful Career? appeared first on Ryan Peden.

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.

The post JavaScript Array Push Performance appeared first on Ryan Peden.

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?

The post JavaScript indexOf vs includes performance appeared first on Ryan Peden.