How to stay junior forever

·

In my last blog post, I mentioned briefly the fact that today there are more engineers than meaningful jobs for them. This means that there is an immense pressure on junior engineers. Getting a job becomes a challenge.

The other day I stumbled upon a post in /r/Programming. The post was talking about how GitHub Copilot affects code quality. You can read the post here. The only important quote from the post is this:

We find disconcerting trends for maintainability. Code churn — the percentage of lines that are reverted or updated less than two weeks after being authored — is projected to double in 2024 compared to its 2021, pre-AI baseline. We further find that the percentage of ‘added code’ and ‘copy/pasted code’ is increasing in proportion to ‘updated,’ ‘deleted,’ and ‘moved ‘code. In this regard, AI-generated code resembles an itinerant contributor, prone to violate the DRY-ness [don’t repeat yourself] of the repos visited.

This reminded me of something.

Copy-paste

I remember when I joined Autodesk, back in 2017, I got the experience to work together with different kinds of engineers. Prior to Autodesk, I worked mostly in small teams with little to no supervision. But at Autodesk I had responsibilities such as mentoring other engineers, as well as conducting pair-programming sessions. These practices allowed me to take a glimpse into how other engineers work and write code.

And I noticed that many engineers write code in, what I call, a copy-paste method. They would copy blocks of their own code around, and modify the necessary parts. Moreover, they would copy code snippets from Stackoverflow or other online resources.

I don’t practice copy-paste programming. Don’t get me wrong, I do copy and paste parts of my own code, as well as code found on the internet. But I never do it for code that I don’t understand. And this made me wonder, am I just being inefficient? It took more than 6 years to finally find the answer.

The power of writing

Last year I published one of my all times popular blog posts—Why engineers should focus on writing. It even reached the top page of HackerNews! One particular advice, that was copied into multiple publications, and mentioned by multiple people on social networks, was:

One last advice–abolish the copy-paste. So many developers, whom I mentored, simply copy-paste everything. Code snippets, function declarations, etc. I know how to initialize a git repository, because I do it by hand every time. Most people simply copy the instructions from GitHub or Google. And if you are scared about being unproductive–remember that you are not judged by how much code you write, or how fast you complete the assignment.

There is a reason why writing is a skill and not a habit. Habit is something that you do repetitively. You can’t perfect a habit, you just stay consistent for as long as possible. Skill, on the other hand, is something you can perfect. And perfection of skills is achieved by doing them over and over again, with slight improvement over time.

Software engineering is a skill, and in order to perfect it you have to write more code. The keyword is write. Not copy. Not generate. Write.

It might sound counter-intuitive, because one could argue: why should I spend time typing, while I can just copy and paste? And it’s a valid argument, but copy-pasting code is the same as watching how to drive a race car—it won’t make you into a race car driver. I know the things I know because I keep writing them over and over again. That’s why I hate all these gp and other shortcuts that people make for git commands. I type git push every time.

Not only it engraves these commands into my brain, so I won’t have to Google them every time, it also does something with the way I understand things. I can’t explain in, and it frustrates me because I’m a logical person, but writing is magical. Any type of writing. This is why students are asked to take notes because that’s how you learn. And that’s why good engineers write. Code, and blogs, and articles. The first advice we ever give to anyone who is struggling to solve a problem is: write it down, draw it on the whiteboard.

And this leads me to the main topic of this post.

How to stay junior forever

If you want to stay junior forever, keep using AI and other code assisting tools.

It’s a bold statement, but I’m willing to stand behind it. The more you use AI, Copilots, and other helpers alike—the less of an engineer you become, and the easier it is to replace you with AI. Software engineering is not only writing code. In fact, software engineers is everything except writing code. Writing code is the easiest part. Once you know 2–3 families of programming languages, all the rest are the same, just different syntax.

However, translating requirements into code, and more importantly understanding existing code—this is what software engineering is about. Writing code is the mechanical part of your hands. But in order to write it, you need a pre-trained brain that can translate the problem into code.

Now, it’s not that I’m against AI and code assisting tools. In the end, we all went up from using Notepad to using auto-completion and intelli-sense. But none of the pre-AI tools are crucial. They help me to remember what are the arguments for Array.slice function, but they do not replace my ability to understand what a given piece of code does.

With copy-paste and AI-like tools—it becomes too easy to abuse it. The best way to avoid eating sweets, is not to keep sweets at home. We are all humans, and it’s tempting to abuse what makes our life easier or brings us pleasure. Seneca used to say:

This is what I mean: pleasure, unless it has been kept within bounds, tends to rush headlong into the abyss of sorrow.

But the thing is, like with eating a piece of chocolate a day, you will pay for it in the future. And instead of becoming an engineer to whom colleagues will come for advice—you will be replaced by the same tool you adored, because you practiced the habit of typing, rather than mastering the skill of software engineering.

Farewell.

Share this:


Technical Writing for Software Engineers - Book Cover

Recently, I released a new book called Technical Writing for Software Engineers - A Handbook. It’s a short handbook about how to improve your technical writing.

The book contains my experience and mistakes I made, together with examples of different technical documents you will have to write during your career. If you believe it might help you, consider purchasing it to support my work and this blog.

Get it on Gumroad or Leanpub


From Applicant to Employee - Book Cover

Were you affected by the recent lay-offs in tech? Are you looking for a new workplace? Do you want to get into tech?

Consider getting my and my wife’s recent book From Applicant to Employee - Your blueprint for landing a job in tech. It contains our combined knowledge on the interviewing process in small, and big tech companies. Together with tips and tricks on how to prepare for your interview, befriend your recruiter, and find a good match between you and potential employer.

Get it on Gumroad or LeanPub

Did you like this post? Consider supporting my work.