DEV Community: darcylol

Starting as a junior engineer when AI is already in the room

darcylol — Wed, 01 Jul 2026 10:43:54 +0000

The other day, I had this epiphany: AI is like gravity.

Before the AI era, programming felt a bit like cross-country skiing. Your distance and speed depend almost entirely on your own skills, and quad muscles of course🙃. After the AI era, programming started to feel more like Alpine skiing. Gravity is there for everyone. You can use it to accelerate, carve a smooth line, and make a fast run with much less effort. It feels powerful.

Or you can injure yourself because you lose control. A classic theme.

In my case, I have experienced both. Gravity did not always work in my favour when skiing, and AI has definitely backstabbed me a few times while coding.

I started my first software engineering job at the beginning of 2025. AI is not the full picture of software engineering, but it is impossible to pretend it is not part of the picture at all. So instead of asking whether AI is good or bad for junior engineers, I have been thinking more about the moments when I feel grateful to have this tool, and the moments when I am relieved that it is not smart enough to take the decision-making away from me.

When AI has been helpful

As juniors, we often feel intimidated about asking senior engineers “stupid” questions. Questions about syntax. Questions about the use case of a specific method. Questions about errors caused by a misspelled word or a missing keyword.

In those moments, I could direct those very basic questions to AI without worrying that I was bothering someone else. When you are in your first software engineering job, you genuinely do not know much, yet. Having a tool that can help demystify syntax, explain a method, or point out a simple mistake is immensely useful.

When AI has made me feel privileged

Another big lesson I have learned is that your dependencies are essentially part of your code. It is your responsibility to understand whether they are fit for purpose and whether they might break your application.

Here, AI has been genuinely useful as well. It has helped me read and analyse the codebases of dependencies. In Rails, you can run bundle open gem_name to inspect the source code of a gem you are using. I have always been curious about how things work behind the scenes, and I like digging deeper. Reading the source code has helped me understand edge cases, exceptions, and the cost of certain methods.

The depth and breadth of high-quality code that AI helps me make sense of at this early stage of my engineering career makes me feel privileged.

When AI made me feel powerful

It also made me feel that there were fewer problems that were “too junior” to tackle(although company culture plays a big part in that too). With the help of AI, I was able to write more complex code, adopt more ambitious strategies, and push more changes than I probably would have attempted otherwise.

When AI helped me move too fast

Obviously there have been back stabbing moments.

One time, I was working on optimising background jobs by adding a layer of verification around API responses. From what I had previously tested, and from what is generally true in many examples, a 200 response code usually means a successful response with useful data that we can process. A 400+ response usually means something has gone wrong, and there is not much useful data in the response body.

I tested this flow with one API and it worked really well. Then I asked AI to help me apply the same pattern to a dozen other APIs. Since the pattern had already been proven correct once, I felt quite confident. I pushed my PR for my colleagues to review.

Huge thanks to a colleague who actually tested the code in her environment, I realised the assumption did not hold everywhere. Some APIs return partial error responses in a different way. Even when the request is bad, or when the requested resource does not exist, they can still return a 200 response code, with the error described inside the response body itself.

That mistake humbled me. It taught me several important lessons:

First, even in the age of AI, never skip the most basic habit of programming: always, always test your code in your own environment.

Second, do not over-generalise a problem just because AI makes it easy to produce a large amount of code. It is tempting to become ambitious and “complete” more than the task actually requires.

Third, my own engineering abilities define how far I can safely leverage AI. If AI produces something far beyond my ability to maintain, reason about, or truly understand, then it has not made me more capable.

Back to my ski metaphor, it has simply placed me on a piste beyond my current ability. Well technically, you can always get down the mountain right? But hey at what cost?🤷🏻‍♀️

When I was glad that AI didn't take that from me

There have also been moments when I was grateful that AI did not do the thinking for me.

One of the biggest learning moments I had came from a task where I needed to write a long background job. The job had to filter users based on several different criteria and use Action Mailer to send a customised monthly report email. At first, I wrote everything inside one huge job. Then I moved on to writing tests and immediately got stuck. I did not know where to start testing the whole thing.

During a coffee break, some object-oriented programming fundamentals and the Model-View-Controller pattern suddenly popped into my head. I realised there was a much better way to structure the code.

I broke the different user criteria down into smaller methods, scopes in Rails terms, and moved them into the model layer. I created an Action Mailer to handle the email logic. By the end of the refactoring, the job itself was only a few lines long, simply assembling all the pieces together.

It felt as satisfying as building a Lego set.

I do not think this experience is unique. There is no real shortcut to comprehending something conceptual. It is by immersing yourself in the code, getting stuck, and constantly challenging whether there is a better way that you start to develop the so call "taste" and "instinct" in software design.

Had AI simply spoon-fed me the right answer from the beginning, I probably wouldn't have learned that lesson as deeply.

I wanted to write about my journey of changing jobs as a software engineer because I have just completed my first software engineering role. Mumbling this experience is my way of processing the complex feelings that came with saying goodbye to this job.

I also recently attended Brighton Ruby(for Rubyists in the UK or beyond, I highly recommend that) , where I joined a workshop discussion about AI. During that conversation, some people mentioned that juniors are drowning. Others questioned whether it is still meaningful to recruit juniors at this stage.

Well, I can only speak from my own experience. To me, it is not a replacement for learning. It is not a shortcut to judgement. But it is a new force in the environment, like gravity on a mountain.

And you still need to learn how to ski, metaphorically. You really should.

Many ways to express one thing in Ruby (_n syntax, _ prefix, & ampersand)

darcylol — Tue, 08 Apr 2025 21:55:50 +0000

Today, coding in Ruby reminds me of the days when I was learning French. I wasn’t bad at expressing myself, but I struggled with vocabulary. One day, I needed to draft a professional email in French. After spending hours checking my grammar and searching for the right words, I hoped my language teacher would give me the green light to send it out.

While she acknowledged that I had conveyed the meaning correctly, she also pointed out that I was repeating myself. She then introduced me to different ways to say the same thing, just to avoid using the same word.

Below is an example of expressing the same thing in many ways in Ruby. This is an array of arrays, where each inner array contains a date and a volume value. Our goal is to calculate the total volume.
[["2025-05", 1400], ["2025-04", 4200], ["2025-03", 3100]]

Here are a few ways to do that in Ruby:

Deconsctructure manually by assigning variables to each element
total_volume = data.sum { |date, volume| volume }
Deconsctructure manually and only assign variable that you are going to use. '_' in this context is considered as a thrown-away or not-used element
total_volume = data.sum { | _, volume | volume }
You can use chain map and sum.
total_volume = data.map { | _, volume | volume }.sum
Deconsctructure and make use of numbered parameter. Ruby reads the patter of each inner array (e.g ["2025-05", 1400]), first element("2025-05") as _1, second element (1400) as _2.
total_volume = data.sum { _2 }
reference: https://ruby-doc.org/core-2.7.0/Proc.html#class-Proc-label-Numbered+parameters
It felt odd, but saving time and space to name your variable in an iteration. Why not?
Here is the part when things get "Frenchy"(aka inconsistent and full of exceptions). Let's say now the data I need to deal with changes to
new_data = [[1400, "2025-05"], [4200, "2025-04"], [3100, "2025-03"]].
Now the volume is the first element of each inner array, and we want to sum all those volumes.
From what we learned earlier, it might feel natural to write:
total_volume = new_data.sum { _1 }
But nope! ❌ Since there is only 1 parameter, the destructuring magic disappears and _1 just gives you the whole pair, not the first item in the pair([1400, "2025-05"]).
Hence if you are only passing _1 in the block, you have to index into the array explicitly. Like this:
total_volume = data.sum { _1[0]}
To go back to the example at the beginning of the article, you can write below to achieve the same result
total_volume = data.sum { _1.last}
Confusing! Isn't it?
Use & ampersand operator to represent the iterating element. Note: This approach calls a method on the element, so use : instead of .
total_volume = data.sum(&:last)
total_volume = data.map(&:last).sum
Ruby 4.0 introduces another possibility using it, which is like a variable automatically assigned to call the iteracted item.
total_volumn = data.sum { it.last }

Ruby often feels like a language built on the motto:
“There should be many -- and sometimes too many ways to do it, implicit or explicitly.”

(Yes I am trying to contradict the Zen of Python: "there should be one-- and preferably only one --obvious way to do it")

I like shortcuts. I like flexibility. But I’m not always convinced a language needs so many different ways to say the same thing. Ideally, I’d rather use a language to express many different ideas.

So, what about you?

What’s your favourite (or least favourite) Ruby shorthand? And if you code in another language, does it offer similar shortcuts?

Let’s chat 👇