You’re probably going to want to quit

This is a guest post from Mia de Búrca. Enjoy.

Dear new developer,

You’re probably going to want to quit.

The very qualities that make writing software appealing can also make it frustrating beyond belief. You’re headed down this path because you like to be challenged, to learn and grow. However, facing new harder problems day in, day out can take its toll on your morale. And keeping up to date, familiarising yourself with the breadth and depth of topics in this domain – it can be overwhelming. But if you’re reading this it’s likely you’ve already felt the deep satisfaction of writing code to be proud of, so I hope that by sharing my experiences, from early in my career and from a few weeks ago, you will be motivated to push through and keep enjoying the journey.

The Import

One of the first times I nearly quit was a few weeks into my first role as a dev. I was fortunate enough to land a great job at a small startup, and I was pretty awe struck by the talented and motivated people on my team. So after a while of pairing, I picked up a piece of work to try on my own. After doing some copy-pasta from other files and then tweaking I was chuffed and attempted to view the web page that would now be perfect, right?

Much to my dismay I was met with a blank page and an obscure error message. Baffled, bit by bit I undid all my changes, at each step feeling less worthy of the job, until nothing was left except one measly import statement. I could feel myself go red in the face as I still couldn’t understand what was going on. I should be able to do this, but I’m not good enough. Eventually, I turned to my mentor to admit defeat, and my panic dissolved when he said “oh yeah, this one is definitely confusing” then casually pointed out a simple syntax error. I realised that unlike him, I was not yet equipped with the necessary debugging skills, I was not yet familiar enough with the language I was working in to decode the error message. It takes time.

The Library

It has been four years since the import statement that stumped me, but just a few weeks ago, when I volunteered to update a library which was many versions behind, this seemingly trivial task wound up with me ready to quit yet again. Between a broken development environment, failing tests (was it the tests… or the code?), and still this library integration that refused to obey, I was at a loss. I should be able to do this, I should be good enough by now surely? These thoughts drove me to stubbornly dig my heels in and devote hours to diving into the library source code, reading in circles, dipping in and out of StackOverflow, getting more and more frustrated. Much time wasted I was no better off, so I went and made myself a cup of tea and called up a colleague and good friend to lament my problem. Typically, within seconds of this accidental rubber ducking session the solution to my worries became apparent.

The Lessons

And I could probably list countless other occasions. There may be many different things that leave you feeling like quitting, for me it often boils down to not feeling good enough to tackle a problem. But when you come up against a roadblock, you shouldn’t see it as a reflection on your own ability. If like me you find yourself paralysed by feelings of inadequacy, recognise that the foundation of all programming is problem solving – if there were no annoying problems, you wouldn’t have a job – and as you progress through your career you will gain more tools to solve them. Step back and remember, when it comes to tech, there is a reason to be found – sometimes it takes time, distance, or some help to see it.

These are lessons you should try to internalise, or like me you’ll relearn them throughout your career. You can’t change the fact that deeply frustrating problems are coming your way. You can only change your perspective. Put your energy into solving the problem and don’t assume that you’re not good enough. “Good enough” is an arbitrary concept, an ever moving goalpost. Give up on the notion of “good enough” and instead give yourself some time.

Sincerely,

Mia

Mia de Búrca is a Senior Software Engineer working full stack at 99designs, a company connecting creatives around the world. Originally from Ireland, Mia started out as a translator and computational linguist before landing in Melbourne, Australia and setting her eyes on a career in web development. Mia enjoys solving problems with a focus on bringing real value to users and seeks opportunities to create a supportive and empowering workplace. When not hiding from apocalyptic pandemics, Mia is also a circus performer and teacher.

Trade Money For Time

Dear new developer,

Don’t be penny wise, pound foolish. Your time is worth a lot, and it’s worthwhile to spend some money to accelerate toward your goals. I heard a client say once that their time was essentially free. I understood the sentiment, but the reality is that if you can be working on tasks that are higher value, it makes sense to spend the money.

Examples of ways to spend money that may not strike you as “worth it”.

Buying a book or video course instead of just reading the free docs. I remember one time for a consulting gig I needed to integrate with Stripe. I found a $30 technical ebook that I could read a few pages of and do the exact integration I needed (take money from a ruby on rails web application). The alternative would have been an hour or two reading the docs and figuring out how to do the same thing.
Buying and using tools. I use vim, but I know others who swear by IDEs like Jetbrains. Buying and learning these tools have saved them hours and hours of development and debugging time.
Opening a support ticket with a service provider. When I run into a strange situation, if I’m paying someone money, I open a support ticket. I had a colleague that had an issue with images getting corrupted across a number of places in an application. He spent a lot of time looking at our code, but eventually the issue turned out to be caused by the service provider.
Paying for commercial software. The alternative is to stringing together open source solutions. Now, open source is great and can often be a good value. But there are times when it just makes sense to pay for a solution. I often use the criteria “is this core to the business” or “what would happen if this paid service went away” to ward myself away from the idea that my time is free.
Paying for consulting or training. Sometimes a day with a consultant (even if it is expensive) can save you weeks or months. You gain the benefit of their mistakes and experience.

Now not all of these will apply to you, new developer. You may have no budget to spend at your place of work. But you can still apply this heuristic to your own choices. Get that subscription to Udemy or Safari. Buy that book. Explore that tool and see if you can recommend it.

Realize that your time is precious and you can leverage it through spending some money on tools.

Sincerely,

Dan

Deep vs wide experience

Dear new developer,

You have only a finite amount of time, and the world is large.

Technology changes so often and so fast that it can often feel like there is not enough time. Here are two strategies.

The first is to focus on fundamentals. Yes, there’s a new javascript framework. But it will still have a way to represent data, it will still use algorithms, it will still store data durably, it will still have a build system. Learn these fundamentals for two different solutions and you will start to see patterns that will allow you to pick up new languages/frameworks more easily (because you can map back to an existing solution).

The second is to choose whether you want to go deep or go wide. Going deep is focusing on one domain or language and truly achieve mastery. This is a project of years and experience. This path will lead you to interesting jobs and big paychecks, if you pick the right area. If you choose poorly, you might have only a few employers to pick from. Working for a product company is the best way to go deep.

Going wide will mean that you never achieve true mastery. You will however, learn to pick up new skills quickly. You’ll learn to map between two dissimilar situations. You’ll start to see patterns across software development and business. You’ll always be more of a generalist than a specialist, and that will limit some job opportunities. Working for a consulting company is a great way to go wide.

Neither of these is a better path than the other, and you can, especially in your early career, switch between them. Try them both on and choose consciously.

Sincerely,

Dan