DEV Community

Bartosz Mikulski
Bartosz Mikulski

Posted on

My first day as a programmer

It was eight years ago, I arrived at the office around 8:30 in the morning. It was way too early because I was supposed to start at 9, but they were already waiting for me.

The office was in a semi-detached house repurposed to be an office.
Programmers were sitting in two rooms on the third floor of the building. When I entered my room, I saw that one of my two colleagues was already there. Later I learned that he was usually coming early and working 9 hours because he was leaving earlier on Friday to travel home.

I sat at my desk. I was given a not very powerful desktop computer running WindowsXP. Fortunately, I was using it only for a few weeks. After two months of working, I started using it just to check my email.

Usually, I was pair-programming on another computer with a colleague, so I did not need my own machine. I was pair-programming every day for two years. To be fair, I was doing most of the typing, and he was doing most of the looking at the screen. I did not like pair-programming ever since ;)

The first line of code

I was supposed to work on a network sniffer (it was a tool used by companies to track websites visited by employees and record email communication), but on my first day they told me that the tech lead of my project is on vacation, so I should begin with another project and work on that during the first month.

That was the first surprise. I was employed as a Java developer, but they gave me a PHP project. I was sure that the language would not be a problem because all code is just "ifs" and loops. I was not wholly wrong.

They gave me a link to the repository and the issue tracker (in the case of that project, the issue tracker was just a Google Spreadsheet), and I began looking at the code.

An hour later, the lead of the PHP project arrived and asked me whether I want to test the product or write code. After one hour of looking at code which I did not understand, I had to choose to be a tester for a day.
I was testing for three hours and added a lot of bugs to the issue tracker.

Some of you may be surprised that I did not have any pair programming on the first day or onboarding. I didn't because there wasn't any. All they gave me was a computer with all the software installed, the code, and a list of tasks.

After three hours of testing, I looked at the code. I was devastated. I could not understand most of it. Fifteen minutes later, I was sure that I should not be a programmer. I was thinking of apologizing for trying to code and leaving the building. I did not do that. Mostly because it would require human interaction and eight years ago I was terribly shy (now, I am just normally introverted).

Instead of that I looked for the easiest task in the spreadsheet and started coding. To be fair, I spent most of the time googling, moving code around and copy/pasting. One hour later, I had fixed the first bug. A trivial one. I think that, after reverting unnecessary changes, it required two or three lines of code and most of it was changing "and" to "or" in boolean expressions.

The first fuck-up

The company was using Mercurial. It is a distributed repository similar to Git. I was not familiar with that because I had been using Subversion or just copy/pasting directories with the code to a new location.

In Subversion when you commit the code to the repository, it is sent to the server. You don't need to push it to a server. I was not familiar with distributed repositories, so I did not know that pushing changes was required.

At some point, I announced that I have fixed two small bugs and committed the changes. "Great, so where is the code?" they asked. "Did you push it?"
Sure, it was not a real "fuck-up" just a silly mistake, and everybody (including me) was laughing. It may be not a serious mistake, but I still remember it. After all, it was not a pleasant experience to have on the first day of work.


Do you wonder why I did not write anything about a code review? There were no code reviews. The lead reviewed my changes after I pushed them to the repository. I guess it was okay because there was no continuous deployment either. My code was not running anywhere yet.
Looking at it from a different perspective, we may say that I had a safe environment for learning because I could not break anything even though there were no tests in this project ;)

Right now, I think that the lack of onboarding process was great for me but harmful for the company. I had to learn a lot on my own, and I loved it, but the company wasted a lot of time. I could be more productive way faster if they had a proper onboarding process.

Their "sink or swim" approach would not work if there weren't any easy bugs to fix. The only thing that kept me motivated and convinced me that I can write code for a living was that minor bug which I fixed on my first day as a programmer.

It may be surprising that a new developer managed to write any code on the first day in a project with no tests. In my opinion, that was possible only because the team produced good quality code. Sadly, after a week of reviewing my commits, they left me unattended, so the quality started to degrade slowly.

Now I think that allowing a new person to be productive quickly (preferably on the first day) is crucial during the onboarding of new programmers.
If I spent four hours on my first day at work looking at code with no progress, I would return home depressed. I wouldn't quit, probably. Actually, I don't know. Maybe I would.

Follow me on Twitter:
If you are interested in data science, machine learning, or data engineering, check out my personal blog at

Top comments (3)

eidsonator profile image
Todd Eidson

Sounds a lot like my first day, right around the same time. At least you knew what version control was.

sumukhesh profile image

Relatable 🔥

sophiabrandt profile image
Sophia Brandt

Thanks for sharing, that was an interesting read for me.