In the modern technology industry, the sheer volume and turnover of technologies makes it reasonably impossible to keep up to date. No one is going to understand everything. Gone are the days when mastering a single technology stack could sustain a career for decades. The now constant churn demands that software professionals such as ourselves are able to adapt and pick up new skills and repertoires on the fly in order to keep up with the times. And this makes the development adventure a scary path to walk at times. But let’s circle back to this.

My development adventure began in high school when I elected to take information technology. From the first moment of delight, in writing and successfully testing my function to sum 2 numbers together, to moments later when I got presented with a confusing error message when writing the division function, I had gotten my first taste of what the adventure held. Feeling like a genius, to becoming helplessly lost and confused. Because of course the big scary DivideByZeroException error message and all the jumble of letters and numbers proceeding it made absolutely no sense to me at the time. And so, the adventure began.

By university, I had a much better understanding of basic coding principles. But again, we soon dove into interesting and complex topics and courses that challenged us to try and understand the magic behind the high-level programs we had built at high school. We got our first taste of all-nighters, and each developed the coffee addiction requirement needed to earn your aspiring developer badge. We tackled tough assignments and went deep into theory. Nevertheless, we were safe in our little university bubble where you could work together on the same project together with your friend or nag the lecturer for extra direction on assignments when you got lost.

But that bubble bursts abruptly when you arrive in-office for your first day. You will very likely be expected to use a whole new set of tools that you’ve only heard thrown around by the ‘smart’ kids from your course. You’ll probably be expected to learn a whole new language or framework to the one you’ve been using for the past 4 years. And, you will certainly wish you had paid better attention in lectures or had a better memory so that you could recall all of those times when the lecturer emphasized the importance of that thing you never thought you’d have to use again.

Safe to say the first few weeks as a junior developer form a blur of new tech and terminology, being intimidated by your seemingly genius colleagues, and long hours trying to learn from all the constant mistakes you are making. But if you manage to survive the trial and keep trying, you will soon be able to submit your first proper piece of work that passes quality assurance. For one sweet moment you might think, “Wow, I actually understand this”. And maybe you do, but then you get assigned a new task that you’ve never even heard of before. And the loop begins again.

Luckily in my case, I was surrounded by a community of experienced and understanding developers that helped guide me in my infancy with wisdom that they’ve gathered on their own journeys. They reassured me that you’re never going to understand everything and that all I needed to do was be constantly making little increments of learning and progress.

They taught me that embracing failures as an inevitability and framing them as learning opportunities is vital for learning and self-growth. I was given the freedom to make mistakes, with the agreement that I should fail fast. However, a license to fail cannot entirely ease the stress associated with failing frequently and it’s easy to get in one’s head and begin doubting your abilities during the early stages. But software development is challenging, and each time we choose to persevere, we grow.

Sometimes developing is just pure frustration and confusion. Every developer has their own long list of times that they sat behind their screen for hours, days, even weeks just to find that the cause of all their distress was one erroneous line of code or one incorrectly set configuration setting. Estimating that a task will be quick and easy, just to end up chasing a strange error deep down the rabbit hole is a common occurrence.

Sometimes the experience is glorious. The satisfaction of watching the well-designed, interlaced logic that you wrote come together to produce the desired outcome is what software developers thrive on. It’s our self-proclaimed ‘God’ moment. And where life can be chaotic and unpredictable at times, the determinacy and logic involved in building well-designed software is beautiful in the developer’s eye.

And so, this is the roller coaster that we ride on the development adventure. In each development (learning) cycle, there are elements of each. You journey from new concept to solution through attempting, failing, and fixing for however long it takes. And as my senior colleagues assure me, this pattern doesn’t change as you get more experience. However, it’s the confidence in oneself that grows. As one colleague of mine with 10+ years of professional experience describes it, you go from panicking a lot at the start, to “Ok, I don’t know” and you find surety in knowing that you can learn it.

Our solutions are not always as neat as we would like them to be though. Sometimes, in order to deliver the product on time, we have to make compromises. Is the resulting solution unstable or not secured? No, of course not. But there’s no need to go build golden gate bridges over quaint streams.

This is one of the hardest things for developers to realize and consistently apply in their practice. We love designing flawless highly abstracted systems that are optimized and generalizable. But at the end of the day, if the solution takes you five times longer to implement than the less clean, slightly slower brute force approach, you’re effectively wasting either your time or the client’s money.

That’s why being a good developer is about more than just producing high-quality code. I’ve learnt that one needs to balance and understand three key components. They are:

• Improving your skills and knowledge as a developer,
• Producing the output that your company promises its clients, and
• Delivering what the client truly needs.

The first is the easiest to practice, and the most intuitive while the other two are more difficult to hold in balance and separate in your mind. The second component speaks of fulfilling your duties to your company by producing timely, high-quality software.

The third is about truly understanding the client’s intentions. Without enough context of who the client is, what their timelines and stress points are, and why they want this thing in the first place, developers can easily get carried away. They may end up building solutions that don’t truly achieve the client’s end goal or don’t meet the client’s timeline. Balancing all three components is an act that all developers must practice.

You learn a lot more than just how to code along the development adventure. Your ability to communicate and discuss complicated, contextual problems with your colleagues improves. You quickly learn accountability and time management. And most importantly, you learn how to problem solve in a general sense so that you can apply it to anything. You learn to ask the right questions to ensure you identify the core issue or goal and then break down the problem into smaller achievable tasks. And through all of this, you slowly learn how to embrace the unknown and grow faith in yourself that you are capable of solving the problem.

So here are some final tips for anyone just behind me on the adventure:

• Stand up and clear your head regularly. Tunnel vision is a very common and often times dangerous phenomenon in programming. You’d be amazed what solutions come to you as you walk around your garden.
• Spend an extra thirty minutes to an hour after work when you can, looking up terminology or something you didn’t have time to figure out at work that day. This does wonders for your growth and confidence the next day.
• Don’t be shy to ask questions if you’re stuck. Remember, seniors know you know nothing. Just be sure to construct (e.g. write down) your question with context on your own first. This ensures good communication or oftentimes helps you realize where you were going wrong during the process.
• And lastly, it’s also important to remember as a developer that your mind is your one true tool. So, while the adventure can be scary and unknown, maintaining a healthy lifestyle helps you prepare yourself, no matter what is to come. As a junior developer, I like to focus just as much on ensuring healthy sleep, an active lifestyle, and proper food as I do behind my desk.

The development adventure is a rollercoaster of a ride. From the despair of debugging something invisible for hours on end, to the blissful moment when you write a piece of code that runs perfectly the first time, there is never a dull moment. An enthusiasm for and enjoyment of learning is essential for developers if we embrace the idea that we will never understand everything and that failures are our most powerful learning opportunities. With the right support, from both your seniors and that which you provide yourself, your development toolkit will grow and empower you to navigate the unknown.