Tips from a young CS graduate that I wish I had while studying

Since I was a professional student, I wanted to share with you some of the tips I would have liked to hear when I was working on my school projects. Some of the points that I’m going to address clearly embarrass me (since they are obvious for some) but I want to be honest and share the things that I didn’t know or didn’t think were important.

Before that, however, I want to give a bit of background to help you understand the kinds of studies I made since they might be different from elsewhere in the world. The actual bachelor I have is a degree in Business Information Technologies, this means that our curriculum focus on two areas, business and IT. The business lessons I took focused on fields such as project management, competitor analysis, accounting or marketing. The goal was not to make us the best business analyst or allow us to create our own company and managing all the aspect of it but rather to give us a broader look at what a developer (depending on the company you work for) can do. It sensitized us to things other than mere programming. Tasks like discussing with the client, translating his or her needs into specifications, keeping track of the time spend,… Are, in my opinion, as important as developing the actual product.

To help us practice those skills we had a lot of projects (sometimes too much at the same time). In the beginning, they were quite simple, merely hand back a program, but as the studies went by, they became more and more demanding. We had to work on a team, use the Agile methodology, organize meetings with the clients,… I sincerely had way too much pleasure working with friends on those projects, this was a vibrant and new experience for me.

10/10 would do it again.

We used several technologies to develop those projects, most of them were websites/services written in NodeJS, ASP.NET or Java EE. We developed several Android applications in Java including my bachelor thesis, but we did not have the gut to make them on Kotlin (but more on that later). Lastly, we had to develop some desktop programs in Java. Those were the type of programming languages or frameworks I used throughout my degree. Some of the projects had a technology imposed (we wouldn’t use Java EE otherwise!), and we were free to choose on others. Other than that we obviously worked with databases, we used SQL, MongoDB, and Firebase.

Now that this is out of the way let’s jump into the things I want to share. Feel free to share any point I might have missed, those are the one I had in mind or that my roommate suggested.

Try new technologies

I learned this mistake the hard way when searching for a job. Schools are meant to make us learn new things, and I did not apply this principle during my bachelor degree. I went way too frequently for reliable and well-known technologies for our projects, whether it was NodeJS for our web project or Java for Android apps I was not very adventurous (except the project I was instructed to use something special). This means no PHP, React, Angular, Vue or, Kotlin for me. This resulted in a lack of confidence regarding my skills when applying for jobs that required knowledge of those frameworks or programming language.
Hopefully, some project had technologies imposed, without those teachers I would have selected something I already knew. However, I am not sure that students have the maturity and professional experience to understand how important it is to experiment when they have the occasion. For me, this is something the professors should have told us at the beginning of projects. Sadly, I don’t remember teachers sensitizing us to this point, but I might have skipped this point because of the following point :).

In the end, have the courage to try new stuff and learn new skills, this is the goal of the school you are in. Do not choose the comfortable and path, try going off-road is funnier.

Take your time before starting

I cannot remember how many database schemas I went through during our project. I think that every user story resulted in a new database schema (maybe not but you get the idea). I was just not spending enough time thinking of the problem I had to solve and went straight to coding. This is a well-known problem among developers.

We love coding not documenting.

Even if this is a common disease, this is something I would have loved to discover earlier. Not that it hurt me in my job, but it would have made the projects more relaxed and less stressful.
Not taking the time can, however, be harmful in situations where you have to deal with a customer, if you don’t spend the necessary time understanding and translate his or her need you might go in the opposite direction than what the customer wanted.

At the end of the day this is simple, take your time and spend one or two hours discussing the problem that you try to solve and the best way to achieve your goal.

Change the role you have in a project

I am a backend guy, I cannot fight against it, but in every project, I have to touch some (pesky 😀), HTML or CSS, and I have absolutely no clue how this works. In some area (the one I am the most passionate about) such as mobile development I can develop nice screens and user experience. But for the web, I am as clueless as a first-time Linux user in front of vim. In all seriousness, we always organized our project in frontend/backend team, and I always went for the backend. This point is related to the first I made, but on top of trying new technologies, I would have loved to know that getting out of your comfort zone and taking a new role was that important.
This is normal to go for what you know/love but going from frontend to backend (and vice-verca), even for one project can make a world of difference. If I applied this, I would know how to create some webpage and event style the object in the latter. This is never too late to learn, but I think that it’s easier to make it in school rather than in a complex enterprise project.
To be honest, I think I was aware of this. Deep in my heart, I knew that I was making a mistake. But I ignored it and kept going for the backend.

Going out of your comfort zone and try to take a responsibility, you never took might greatly help in the future.

Because, in the end, frontend and backend must work together. A good project is like a good relationship, there can’t be something holy if you can’t put yourself in the other’s shoes and understand his problems.

Keep your role but touch other parts of the code

I know, I just said that changing role is essential and now I say the opposite! But for me, this is also important. Let’s me illustrate this with an example, I do not know how to route traffic in a NodeJS app, at least make it correctly (the “top level” redirection /admin /login,…). This is an example of something that I never touched even if I was always in the backend. A friend of mine was a great dev and always took that responsibility. I cannot blame him but I can blame myself. I should have made the routes myself and taking the easy path was, once again, not the best choice.

So don’t stick to the parts that are familiar but to experiment with unknown things.

Don’t over/under do your projects

While developing the projects, I focused on delivering the best software of the class instead of trying to accumulate as much knowledge as possible. I was in a sort of competition that I created without any apparent reason (it was something special in our class, I was not the only one in this situation). This meant that I focused on implementing as many things as possible rather than learning. Furthermore, the grade was the same or not much better than other groups. I do not mean that grades are important but rather to emphasize that schools are intended to learn and not to compete against each other (in my optimistic imagination at least).
So sticking to what was asked but taking time to make them right and learn things while doing them is very important and something I totally ignored.

Make what teachers are expecting and don’t surprise anyone by implementing useless crap, it will not always benefit you and you will miss other base skills.

Make readme

I kept the best for the end! This is ridiculous and very subjective but creating a readme when developing the project is critical in my opinion. This makes your whole Github profile way more attractive and exciting (more exciting than mine). When I was searching for a job, I was a bit ashamed of my git profile because of that, but I did not bother to create readme though,…

So the quicker the readme is done, the easier it is to make them and the bigger the payoff

This is what a Git without readme looks like, emptiness and void!