• A garden manager that lists what we're growing in our garden each growing season, when to plant them, how much to water them, and other information about the plants that would be useful.

• An app to use when I'm at the gym to record how much weight I'm currently at on each weight training machine so I can know what setting to use. It would use a Google Sheet for a data store.

• A desktop app that captures and stores code snippets that I can tag and search for later to copy and paste.

These are all neat ideas (at least they are to me) but I've only barely started one and the other I've hardly moved past the research stage. The garden manager I went a good way in before losing interest. It was more work to make the thing than to just water the garden whenever it felt like it was time.

I've given this a bit of thought, and here are a few reasons I've come up with for why I don't finish what I start (or don't even really start) when it comes to side development projects.

Too Much Friction Up Front

Ever been excited to kick off a new coding project and then found that you were going to have to wade through pages of documentation on a charting library, a full-text searching library, and an authentication module to solve the major challenges it presents? Even if you've worked with charts before, there's always going to be thirteen new chart libraries to have entered the space since you last used one, and you don't want to use that dusty old thing that's now deprecated or even no longer actively supported, right? And you're not going to be irresponsible about safeguarding your user's data when there are so many variations on authentication to parse through now. I mean, sure, you could just do an Auth0 integration and leave it at that, but even setting that up can be a chore.

I just started a new business project idea that I decided to build in Angular, because I have spent so much time working in Angular and, well, I like it. I know, you were expecting me to be all like "Because Angular is better than React and Vue and Svelte and it RULES!!!!! Everyone not using Angular is picking lice out of their hair and sprinkling it on their kombucha!" But I don't have very strong feelings about JavaScript frameworks, and I just like Angular. I know its ins and outs and I like the elegance of how the parts fit. And Angular 15 had just come out and so I'm going to use that of course. I already had an Angular project started in Angular 14, but when I tried to run through the migration process to v15 my npm install was blowing up on lots and lots of failed upstream dependencies. It took me almost an hour to work out why: I was running Node 14 and I needed to be on a much later version. This was a brand new PC I just built a week before and I had to install nvm, then the later version of node, and then the updated Angular CLI, all so I could run the migration script again, and that wasn't even the end of all the problems. This is a framework I've worked with for three years and I'm still fighting with it from the very start.

When you do nothing you feel overwhelmed and powerless. But when you get involved you feel the sense of hope and accomplishment that comes from knowing you are working to make things better.

• Maya Angelou

I should add that this wasn't even the first technology I was planning to use. I meant to build the thing in Meteor with Angular, but the documentation and tutorial for Angular Meteor are so dated that I found myself spending hours resolving one problem after the next resulting from incorrect configuration steps that no longer applied to late versions of Angular, and I finally just decided I would be better off just building in Angular and MongoDB on their own, with possibly a layer of Deno microservices. And this is just for the rapid prototyping phase.

We've reached a point in building web applications where the technologies available to us have branched in so many ways that you have to consider which version of the engine you're running alongside a framework and package dependencies galore that can all conflict with each other. The amount of time and effort I need to put into just scaffolding a lot of projects to get things rolling can suck the motivation out of me. I come in all fired up and ready to tackle the challenge of building something and I find that I can't even start building until I climb a long and winding trail up a mountain of interconnected technologies that don't want to work together even though they are designed with that in mind.

Someone Else Has Already Done It

I said earlier that I was planning to code a garden manager and got a good way into it. What took the wind out of my sails on that project was discovering another garden manager app already on the market that seemed rather well-designed. It suddenly seemed as if I would never come up with something as feature-rich and visually appealing as what had already been done. So I put that project on ice.

I'm Likely to Fail, So Why Try?

I tend to wrestle with a pervasive fear that I will be wasting my time starting a new project. The fear comes down to a few thoughts:

• I'm wasting my time on something that I will never finish.

• I'm not good enough at software engineering to solve all the problems that will emerge.

• I don't know technology X well enough to use it successfully.

• Even if I do build it, I won't be able to turn it into something successful, i.e. it won't make money because people won't want to use it or pay for it. (Obviously, this only applies if I'm trying to make something that would be offered as a paid service).

Tell That Fear Voice in Your Head to Get Lost

Here are some counterarguments against not starting that new project you've been mulling over.

Push Through the Pain to Get to Breakthrough

I wish I could say I always push through challenges without complaints, curses, or fist-pounding on my desk in frustrated rage, but I'm guilty of acting out my frustrations in embarrassing displays. Still, I find it far more satisfying to push through these frustrations and keep digging for answers through Google, StackOverflow, and past experience to get through whatever is holding me up. It's not always fun but it is educational. I learn a lot working through a problem but nothing by giving up. And over time, you can start to view these as a fun challenge to overcome instead of a hassle that is blocking you from moving forward.

Review the docs again if you have to. Google the error message. Remember that someone else has already had and solved this problem 95% of the time. The other 5%, it's usually something superficial and you'll find it if you just dig a little. Prayer is sincerely always a good option and I try to go to it first.

Make Your Own Contribution

Finding out someone else already made your neat business idea or clever tool can be demoralizing, but it doesn't have to be. Make it anyway, and make it your own. No one else is going to build something exactly as you do, and your choice of features and styles are going to be different than anyone else's. Think about how many different to-do apps are out there (ToDoist, Microsoft ToDo, Google Tasks, Notion, etc.). Each one does this simple thing of helping you organize your tasks differently, with a diverse set of audiences in mind and areas of focus.

A lot of the point of doing a side project is to learn how to build something. You'll face different challenges each time. Maybe you're having to learn how to do full-text searching or handle authentication. Each project you start and work on will force you to learn new things, so even if you don't end up with a five-star result, you will still have picked up additional skills that you can apply to future projects.

Define Your Success

Failing at a project is a fear that is easy to struggle with. But we often forget that we can define what success means. For instance, if I set out to build a service that is used by 50,000 people within five years and I don't get to that number, then I failed at that goal. But if 5,000 people end up using it, or even 500, it's still offering value to a large number of users. Or if I try to build something and no one ends up using it, or forking it on GitHub, or starring my repo, or even if I don't finish it, I learned things by doing it and gained valuable experience. Maybe I try again next time and do it differently. Maybe that new framework would work better, or that library.

Our doubts are traitors and make us lose the good we oft might win by fearing to attempt.

• William Shakespeare

The thing about failure is that it's only failure if you decide it is. Sure, failure can be defined objectively if you have clear goals that haven't been met. But you can have other goals that you did. And you can celebrate those as victories on the way to a larger success down the line. Real success happens only after lots of failures along the way.

Hopefully, this gives you some ideas to chew on when you find yourself, as I often have, feeling paralyzed with inaction when it comes to starting a new project. Let's keep building, learning, and defining our success.

Cover photo by Roberto Moreno on Scopio

Here are a few software development topics that have been points of contention for reasons that seem less than entirely rational.

#1: Which IDE to Use

I'll admit the controversy around IDEs has died down considerably since the infamous Vim vs. Emacs flame wars of old. Well, perhaps "died down" is not as accurate a statement as that it has been buried beneath a wealth of other options to what originally appeared to be a binary choice for those who were not inclined to use the notepad app that came with their OS to write code.

Although a lot of the flaming on this topic is more about trolling and having a good laugh, there are those who really appear to feel that using another IDE than the one they favor is some kind of betrayal of, well, someone. The people who wrote Vim or Emacs? Microsoft, because I prefer JetBrains? JetBrains, because I prefer VS Code? All developers? All of humanity?

Come and take choice of all my library and so beguile thy sorrow. ~ William Shakespeare, Titus Andronicus

Settling on an IDE you like is largely a matter of discovering how you like to code and what features help you the most (syntax highlighting, bracket colorization, AI-driven code suggestions, integration with Git, etc.). And in truth, there's a ton of overlap in the most popular IDEs out there, such as VS Code, WebStorm, Atom, Sublime, or Visual Studio (and if I left your favorite out, I meant no slight by it). They all have their strengths and weaknesses, and you're liking one over the others says little about you as a person.

#2: Mac vs. PC

Outside of the charming ads of my youth starring Justin Long and John Hodgeman, which were not a debate at all since they were there to sell Apple products, this long-running controversy has been a head-scratcher. What's the big deal about using one over the other? I've used a Mac for development in the past, and they are great development machines.

When it comes to my own personal investment in computer equipment, I favor the PC. Why? Simply that I can get a laptop that can (potentially) outperform a Macbook Pro for two-thirds of the cost. Look, when my employer is footing the bill, I'll work on whatever hardware they want me to use. But if I have to fork over $2500 for a laptop, I would prefer to get the laptop that offers me the most power and performance.

That being said, I totally get why some people love to write code on Macs. They have a great OS, they run in a Linux environment, and they have a lot of great software. My personal preference might tilt toward PCs but certainly not because I think Macs are bad machines. And if you want to build native mobile apps for the iPhone/iPad, you pretty much have to have a Mac involved at some point in the build process.

Personal preferences aside, the idea that you are supposed to be loyal to one brand over another when it comes to these critical tools for building the software that runs the world is fairly absurd. Go with the one that fits your style, your budget, and does the job best, and forget about whose name is on it.

#3: Tabs vs. Spaces

I only watched one episode of Silicon Valley, but as it turned out, it happened to be the one where Richard breaks up with his girlfriend over this peculiar controversy. Right up to the big moment, they are both contented with each other. But his colleagues have foreshadowed that he will mess things up, and I won't spoil what happens (spoiler alert: he seriously blows things up). An otherwise peaceful relationship between like-minded souls gets trashed over, of all things, tabs or spaces.

This was a funny scene, made all the more humorous by how stupid this whole debate about tabs vs. spaces has been. And frankly, it shouldn't be much of a thing. If you are working solo, then you get to decide which way you prefer to indent your code. Indent it with 10 spaces if you want. If someone wants to fork your repo and doesn't like your 10-space indentation, well, that's why we have Prettier. If you are on a team, then you work with whatever format the team has settled on and stick to it. Because you have far more important hills to die on than insisting that everyone should be using tabs. Or spaces. Or whatever.

#4: If Statements

I was once told by a former manager of mine that my code had "too many conditionals." He did not elaborate on that point even when I asked, and it took me a while to realize the reason for that was that the right answer to the question "How many is the correct number of conditionals?" is "As many as the demanded business logic requires."

This isn't to say that I couldn't have handled those conditionals more gracefully, or simplified the logic to its base conditions more thoroughly. But it was a wake-up call for me to how widespread this belief is that if statements are just bad. As if the ternary operator can handle every case you throw at it and still be readable to other developers. The ternary operator is a useful device if you have two or at most three possibilities to evaluate, but it's extremely unwieldy if you have more than that.

Follow the path of the unsafe, independent thinker. Expose your ideas to the danger of controversy. Speak your mind and fear less the label of "crackpot" than the stigma of conformity. ~ Thomas J. Watson

#5: Commenting Your Code

This one may seem less controversial than the others and I would tend to agree that code conventions trend more heavily toward commenting than not. But there are those who take Robert "Uncle Bob" Martin's advice in his well-known and regarded book Clean Code to such a degree as to discourage any comments at all in favor of naming variables and methods in a way that describes what they do. One should not dismiss Martin's considerable experience and wisdom when it comes to producing clear, well-written code. And there is merit to the idea that you should name things such that their purpose and action are clear, at least wherever possible.

But let's get real for a minute. Would you really prefer calling a method named GetUsersFilteredByNameIdAndPhoneNumberAsync over and over or would you rather call GetUsersFilteredAsync and have the comments explain which parameters you can filter by? I know it's not the best example and naming the arguments well will make that clear enough. But remember, you aren't just writing that code for yourself, you're writing it for the next person who had to work on it. Code comments sometimes just make more sense than not.

There will always be controversies in the development world, but these are a few we might benefit from if they were to fade away into the mists of nuance and reasoned viewpoints. We can always hope, right?

Interestingly, I don't skip over these articles because I can often learn something from the point of view of the author about the challenges and problems posed by some technology or project management style that I might not otherwise have considered. I love Angular, and I've used it for years. That being said, no framework is perfect, and reading about the author's challenges with Angular can be enlightening and help me avoid such pain down the road. It is useful to know the limitations of a technology and recognize that it may not be the best choice for certain use cases.

I do, however, try to remain objective when I read these pieces. It can be destructive to my morale to take them too seriously, because then I would have to believe that pretty much every framework, library, or best practice out there is terrible, and then where would I be? Blog posts like these often leave little room for the technology to redeem itself or consider whether it might have its strong points. They often appear to have been written in a state of exasperation by someone ready to quit it altogether.

I'm not knocking anyone's right to express their opinions. But I do have to express concern about the fact that feelings among developers about the state of development seem to be on a negative trajectory within a subset of the community. The reasons could be lots of things. One thing is that developers complaining about this or that framework often have valid points to make about its problems. Another might be that we're failing on some level for experienced developers to share their knowledge with greener members to show how to get around those problems. I can't help but wonder how many negative opinion pieces are driven more by poorly managed teams or toxic work environments than by the utter awfulness of the thing being discussed.

I can only speak from my own experiences. I have worked on teams that use Agile and Scrum and I didn't find it so terrible that I left my job over it. Yes, I haven't always liked the daily standup or how it's applied, but in most cases, it was kept short and provided a useful forum to bring up concerns or address problems. I have yet to work on a team that followed a "pure" Agile workflow (and I question that any such team exists). Most teams seem to apply certain aspects of Agile and roll their own way of doing things for the rest.

I've used Angular for years and I recognize it has plenty of weaknesses, but if it didn't also solve a lot of problems, most developers would stay away from it. It was, after all, developed by Google, and while Google doesn't have a perfect track record with everything they've invented (I'm looking at you, Google Glass) they are hardly slouches in the engineering department.

I haven't worked with React a whole lot but given it remains among the most popular JavaScript libraries in the industry speaks to its charms. I would not be too quick to dismiss it as an unmitigated disaster that has ruined UI development. I have used it enough to decide that JSX wasn't my style, but who knows, if I had stuck around, I might have grown to love it. I'm certainly not going to start writing opinion pieces calling for React to be burned to the ground because it doesn't suit my personal style as a developer or because it was developed by Facebook.

If you aren't a fan of React or Angular, there are plenty of other frameworks. If Typescript hasn't won you over with its static typing, fine. Write your code in JavaScript instead. I mean, that is why there are options out there. If you are going to write a piece that trashes a technology or methodology, you should at least be aware that you might be influencing new developers that haven't worked much with that thing and depending on your tone and/or choice of words might be led to believe that they need to stay away from it. That could end up costing them potential opportunities down the road. I wouldn't want to counsel a new developer to not learn React when it could lead them into their first role.

I love where we are in development today. When I look at how things used to be, when I first started out, I am amazed at how fast the industry has evolved. Sure, some stuff has stuck around longer than perhaps it should have, and other new stuff isn't as great as the promises of what they would offer. But overall, we're surrounded by a vast number of great technologies that have made UI, application, and back-end system development faster and easier than ever. It costs less than ever to actually get an application up and running and we can scale them faster and easier than ever before.

We're sitting on the bleeding edge of ever-increasing gains in productivity, scalability, cost-management and performance. It's good and right to acknowledge the weaknesses and failures of the tech we have today, but let's not forget the good things also, lest we nudge ourselves ever closer to drudgery. The best way to enjoy what you do is to be thankful for what you have, and there's a lot to be thankful for the state of software development today.