Programming Reality vs Expectations

Originally posted on dev.to

Hello, my fellow developer. Welcome to another article. Today we are going to talk about the programming and the way it actually is. You will notice that the reality differs from the expectations.

If you are a new developer just starting out your career, you might think that your job will be all about the coding and doing it all day long, writing super cool code that will make a difference out there in the wild.

Well, that's not how it is. Be prepared for that.

Coding is not just about writing code, it's about solving problems your client has. I mean, what is the use of any code if it doesn't solve a certain problem? It might be nice and it might be cool, but if it doesn't provide a real value it's not useful to anyone.

Starting Out

In the beginning, when you start your job, especially if you are a new developer, coding tasks, at least the serious ones, will not be served on your plate right away. Your employer or mentor might require some additional knowledge verification. Other than that, they might want to see how fast and how well can you integrate with a new environment. A common practice is to engage you to work on some internal projects where they can monitor your work and how do you embrace their way of doing things.

Each company has a senior, or a couple of them depending on the size of it, responsible for project architecture. Over the years they've developed habits and ways of leading the team that you must adapt to. Depending on the level of your adaptation the task difficulty will vary.

In the end, they will value how fast did you solve a certain problem, how far did you stray away from the project architecture (sometimes is not easy to do it by the rules, especially if the person that has created the architecture didn't have the time to provide a quick tour through it) and did you understand what you need to do? The last point is self-explanatory by the first two.

It's important to stress out that the programming is most commonly about the WHAT and not about the HOW.

Working for the Client

Requirements and Specs

Now you might be thinking: "Ok, when I start working for the actual client the coding will start."

The above statement is only partially true because this is where the real deadlines start. The deadline is the most important thing in the work needed to be done. Breaking through the deadline will do you no good. We can split the implementation process into the following categories:

1. Reading the specification
2. Thinking
3. Thinking some more
4. Maybe some more
5. Coding

After reading the specification, a lot of time will be spent thinking about how to solve the presented problem. In other words, you must understand what is actually required to be done. What is the value required by the client? Once you've done this successfully, only then you can start to code.

A deadline is shortened at this point, and you must write your code fast and make it accessible as soon as possible. Probably, you won't be happy the way you wrote it (only experienced developers are because they spend less time looking for the solution and more time writing the correct code), but the client usually values the end result only and there is nothing you can do about it. This leads us to the code review part, which is extremely important.

If code review is not done by one of the project seniors, which is really bad, many problems will occur, especially if the team has a lot of members. Code styles vary from one developer to another, and without control, each implementation will be different. Not only this, because by not knowing what is available within the architecture and what has been done by another developer, you might repeat your self and rewrite the existing code.

For example, another team member could have created an extension that adds three dots at the end of a string after it breaks through a certain length. By not knowing it exists, you will rewrite the code instead of using the extension.

The example above is just a simple one. Imagine what could happen if the problem scales.

Code review makes sure that everything is done by the architecture rules and it might result in reimplementing the issue.

Bugs

Be prepared for this. It's going to be a lot of bugs. This means that you will be spending a lot of time interpreting someone else's code instead of creating a new one. It can be very frustrating. I hate to break it to you, but the maintenance phase lasts longer than the creation phase. This means that the code is shipped on production, the users are using it and all that you do is fixing the issues they find.

You will be fixing bugs related to the code you've never seen and not familiar with. Often, developers with more experience, see a portion of the code done in a way that can be improved and might want to change it. This wish is usually not granted due to additional costs and time required to implement and retest the existing functionality. It's hard to explain to the client the process of refactoring because all they see is the end value. They don't look at the product from a technical point of view and usually have a hard time understanding "Why should we change something that has been done and paid for already in order to have the same end value again?"

As an experienced developer, you will struggle with this and sometimes will be forced to settle with the low-quality code.

Communication

Ah, the joy of the daily meetings. This is another thing you will be doing instead of writing the code. There is nothing like the 9 am meeting. You get up in the morning all juiced up and eager to write some code, but the first thing you will be doing, if following the agile methodology, is a scrum meeting.

On this meeting, the team is sharing their work done during the previous day, ideas and thoughts about the project requirements...etc. A good thing about it is that is should be short, no longer than 15 minutes. This applies only to daily meetings. The duration can vary depending on the sprint length and the meeting frequency. The more often you have it, the shorter it will be.

Another thing you will be doing is writing/answering to a significant amount of emails. Usually, the communication between the meetings is done via email or some task management systems like Jirra or Trello, but a lot of times you will be talking to your colleagues in person to share the ideas and thoughts.

All changes and conversations should be documented somewhere. Usually, each feature or bug has its own ticket on the management board. That means that every time you have a question or create a change related to a project functionality it will require a ticket update. This can be time-consuming.

The documenting part is really important. Why? Well first, you are doing it for your self. It's not uncommon to forget something after some period of time.

Imagine that you are working on a long term project and implement an issue without properly documenting the change. After a year and a half, you will be scratching your head so hard you'll bleed. If ever found in this situation, be prepared for specification analysis all over again, considering that you can find it in the first place.

Secondly, you are doing it for the "next" person. The next person is the person that is going to continue your work if you're not able to for some reason.

I was in these situations a numerous number of times when a feature was given to me to continue working on it, and normally, the first thing I do is check the ticket documentation. Suprise, it's a desert, nothing, dead end...The ticket has the original specs and nothing else. No comments, no updates about the changes...etc.

After seeing this, I get up off my chair, get a cup of coffee, grudge a little and start reading the specs. After that, I start code analysis and examination to figure out what is it that the "writer wanted to say".

Wrapping Up

I don't want to discourage you, I absolutely love being a software developer, and you should too. I love creating software and seeing people actually using it because it provided a certain value to them. The feeling after successful project completion is irreplaceable. The satisfaction of the client is the best gift you can receive after the project ends.

You should accept that your job as a software developer or engineer is to solve a certain problem and not just to write code whole day long. It will make your developer life a lot easier.

Thanks for reading and see you in another post.