Computer programming overall is an odd field, isn't it? We can improve ourselves on so many fronts and yet, students tend to overlook important skills that will be game-changers in their early career.
It's this mindset that pushed me to essentially write a letter to my younger self, 5 years ago, when I was starting my masters in Software Engineering. Some tips that maybe would have given me the upper hand in class and outside of it.
I hope this post is read by people who are starting the amazingly fun, frustrating and rewarding journey that is software engineering while keeping in mind that I'm only starting it professionally. Which means that all the tips bellow come from my interactions with talented engineers that have pushed me to becoming a better developer, teachers and mentors alike.
Constant improvement is part of what we do and being out of the loop can sneak up on us rather quickly. Especially in fields such as web development where new frameworks and libraries emerge every week.
One way to improve on what you already know is to learn from more experienced developers through pair or mob programming, going to conferences and watching/reading articles (you're already on the right track by being here !).
But nothing beats working on a concrete project with actual end goals. Always strive to improve your code, design patterns and choices every step of the way. In case of doubt, always feel free to ask questions on platforms such as StackExchange.
I always am bummed out when I meet developers who categorically refuse constructive criticism (no matter how it is presented). Their mindset won't allow them to improve or discover new ways of solving problems and they tend to be a pain to work with.
Being open-minded to critique and detaching your pride from your code can help you improve and be a pleasant person to work with all at once.
As an anecdote, I used to work on a big end-of-the-year project with another developer, let's call him John. John was set in his ways, he wouldn't listen to what we would point out in his design choices. So eventually, we stopped doing code reviews with him altogether (oh boy, I wish we hadn't). This led to having us refactor a consequent chunk of his code base 2 days before the delivery. Two, very long days and nights, filled with copious amounts of coffee and frustration that could have been avoided if John had been open to constructive criticism.
Keep in mind that not everyone knows how to be constructive in their criticism, you'll encounter people who say things harshly and feel the need to boast in their experience and talent by questioning every choices you've made. You'll inevitably end up meeting people like that and you just have to learn to deal with it. Thankfully, in my experience, most developers mean well.
On a similar note, you should never be afraid to ask questions. They may sound vague at first, but as your knowledge will grow so will the quality of your questions.
This applies even more if you're surrounded by mentors and experienced people, as most of them would be extremely happy to impart their knowledge on specific problems.
Trust me, the next time you have a technical question, ask around and watch how people will rally to the white board to help you out. You'll end up with more knowledge and more importantly, you'll know how to synthesize your thoughts.
Which leads us to...
Being able to synthesize your thoughts means getting straight to the points by giving only the essential amount of information. This will help you out in your everyday life, where, as you probably have understood so far in the article, communicating with others will be essential.
But of course synthesizing is hard, really. Especially when trying to do it to complex concepts. I've found myself trying to explain problems or exercises, only to see the person in front of me squinting their eyes trying to understand.
A great way to improve on your synthesizing skills is to watch how others do it and take note. Another way is to explain technical concepts to someone who does not work in software engineering, this will force you to find relatable examples for them to comprehend.
I wrote a short article on how to start contributing to the open-source that could set you off on the right path, but here's why contributing can be beneficial for a student, you'll be able to:
As a plus, contributing to this ecosystem is really rewarding and is well perceived by recruiters and tech firms.
What I mean by that is, always explore new technologies.
Your studies probably gave you the opportunity to discover various aspects of Software Engineering: systems, compilers, embedded, web, applications etc. and that's great, it's the best way to make a decision concerning your future specialization.
But even beyond your studies, try to fiddle around with new languages, frameworks and libraries, following tutorials (which, in time, can lead to a full on personal project).
A great place to get inspired is Github's Explore page.
Last, but not least...
I can already hear you saying "but Chris, I'm a student, I don't have enough time to work on side projects", and I hear you, really. But trust me on this one: make time for them.
Just like open-source contributions, side projects are one of the best ways to improve yourself aswell as helping future recruiters note your curiosity, skill and passion. Github is a great place to display your side projects, and who knows, maybe one of yours will take off and be impactful !
It all starts with an idea and some motivation after all.
This has been a really fun article to write, it helped me reflect on the last 5 years.
I hope it will be useful to some of you, until then, if you have any questions please feel free to direct them to me on my Twitter @christo_kade.
Thanks for reading !