This article is mainly aimed at junior software engineers. It's kind of a set of tips to improve your everyday workflow, be a better programmer, find your dream job, or more generally, improve your skills in Computer Science.
As a Software Engineering Student, I meet every day a lot of people learning programming languages, trying to build databases, creating websites. We, at the UTC, have a lot of projects, each semester. I feel so sad each time they fail at using best practices. Among them, the worst, in my opinion, is being stuck in Windows, the operating system. They simply miss a lot of things. They are ignorant, they have no idea how their computers work. But that's my opinion. Now, let's begin with a list of best practices I've learnt from great people.
Use the right tools
Or at least a Unix-like system. The terminal should be your best friend, be familiar with it. It's a lot more powerful than user interfaces. Unless you want to be a web designer, you must know how GNU/Linux works. Why? Because almost ALL servers rely on Unix systems. Another argument would be privacy, but that's another topic.
There are plenty of user-friendly distributions, like Ubuntu or Xubuntu (my favorite one). As Windows users, you will hardly notice any difference, except for software compatibility. But hey, there are alternatives. And yes, you can keep Winodws on a separate partition for video games. I also wrote an article about GNU/Linux.
I've seen sooo many people sending each other source code via emails, or worse, Google Drive! What a pain in the ass! A lot of tools exist, such as Subversion, Mercurial, or Git. Obviously, Git is my favorite one (one of the reason is because it's Linus Torvalds himself who wrote it). And it's also more powerful than any other tool. For more information, checkout my talk about Git.
Show the world what you've done
Every programmers should have public Git repositories. Github is a good platform for exposing your source code publicly, for free. I've heard a lot of recruiters asking for source code to browse, in order to see what you do, how good your code is (or is not), what kind of personal projects you have. They want to make sure you'll write good code if they hire you. Having many projects available on the Internet is also a proof that you're passionate about Computer Science. That's a huuuuge plus!
Github. Recruiters love it. Literally.
A blog is another good way to express your feelings, write down your thoughts, your discoveries. Setting up a blog doesn't take more than 5 minutes!. Further reading about blogs here.
Great inspiration from... inspirational people
Learn from them. They're all around us, just find them. Go to conferences, follow them on Twitter, read blog posts. During my last internship, I met a lot of talented people. I learnt a lot from them at that time. They're full of good advice. They have experience (and you don't, as a student).
Never stop learning
RSS is not dead and is still a really good ally to be kept up-to-date with the latest news in Computer Science. RIP Google Reader, long live FreshRSS!
Be a super-programmer
Some basics I used to neglect... but now I regret. Every programmer should know those basic things. Once again, it helps a lot when it comes to interviews (for either an internship or a job). And this will be useful all your life. The Joel Test is also a good indicator about how good your are with code.
Pair programming is an incredible way to learn from your friends (or teach them) as well.
Data structures and Memory management
Know the basic data structures, such a hash tables, primitives, etc. Those are the very basics of every programming language. You can't avoid them.
You use Java everyday? Then you should know everything about Java memory management. Where are stored primitive types and objects? Stack? Heap? Doing C++? Where are stored lvalues, rvalues? And so on... A brief explanation about memory is in one of my articles
This kind of advice applies to every language you claim to know.
Know them. At least bubble, merge, quick sort, etc. Here is a great website. Half the time, recruiters will ask you something about array sorting or things like that. And most of all, know their complexities!
Backup every little thing that is on your computer/servers
Consider everyday as the day your PC is gonna die. Projects should go to Github (or alternatives) if they are not confidential, personnal files to external hard drives (backed-up as well, so use at least two hard drives) or to the Cloud (I personally installed ownCloud on one of my servers). Once again, backup everything. Losing a whole hard drive disk is such a terrible thing, you can't predict nor prevent it. Be prepared. And for sure, you're gonna experience it, sooner or later.
English, English everywhere
Programming languages use English words, manuals are mostly written in English, almost everything in the Computer Science World is in English. So you'll have to get used to it. Be fluent. Set-up your devices to be in English. Same thing for your computer(s). Watch talks given in English. You will have to write English documentation, even though your company is not English. I wish every software engineer was bilingual, it would make things way easier. And guess what, learning a foreign language is not that hard!
Know how to use search engines
People whom repeatedly ask you simple things are such a pain! We have the entire world at our fingertips, thanks to the Internet. And we have Google. So please, Google everything! Google is smarter than us (or at least, he knows much more things). But first, learn (by yourself) how to use it. For instance, don't type whole sentences, use keywords.
Teaching people around you is a great way to stay "up-to-date". Sharing your knowledge, your passion, allows you to first organize ideas, sort them out, remove what's unnecessary. You then reach an even greater understanding of what you believed to know. Giving talks on a regular basis is a good way to practice.
A while ago, I came upon this talk, given by Quentin Adam (CEO of Clever Cloud) at Mix It 2014. Last year, I had been given the opportunity to do an internship at WhoWanna, a French startup. Back then, we were working in the same open space as Clever Cloud. Consequently, I was working very close to Clever Cloud, thus Quentin Adam. And I can tell you, he is a very good developer, and above all, a very good CEO, full of good advice. But let's move on to his talk.
The full talk (video), with its slides, is accessible here. For those of you that don't have the time to watch it, I summed up the content right below. But the video is worth it, you should watch it (although it's in French, the slides are in English).
For your information, the article's title is shamelessly copied/inspired from his talk :-)
Sum up (in order of appearance)
- Be happy: always try to work on projects you love. Work processes matter. Why people are happy? Cause they know that, as developers, they solve problems. They're not useless at all. Get inspiration from Open Source.
- Get the right environment: work wherever you feel good. As developers, we only need a laptop and an Internet connection.
- Be able to deploy seamlessly: release early, deploy often. This step should be easy. without any human interaction. Be focus when you code, on your code, not on deployment. You should be context-free: your application should not depend on the production environment. What's more, everyone should be able to deploy, not only one person. The team should not rely on a single person.
- Deploy as often as possible: ideally, many times a day.
- Split your apps into small modules: then you'll get a smaller codebase for each app. Each module is a service for other modules: use HTTP or AMQP between them.
- Use the relevant technology, not the one you prefer: the language (or any other related tool) should be chosen according to your needs.
- The two previous points refer to the KISS philosophy
- Use online databases: then you'll be ready to test in a few minutes. Your sys admins will love you: they won't have to edit any conf file.
- Make all deployments asynchronous, module by module
- Avoid host-specific things: refers to point 3.
- Do not use file system to store something: not its purpose. It doesn't scale. Use databases, or external services such as Amazon S3.
- Modularize your team: avoid meetings, they're painful and almost useless. If anyone in your team has trouble, there's a problem. You have to maintain an internal documentation, clear, accessible to everyone, that gives you a good overview of your infrastructure.
- Know your code and trash it if needed: it's sometimes an excellent idea to rewrite a whole module.
- Use the right tools: no one should be forced to use a specific IDE.
- Use a version control system for code and APIs, log EVERYTHING: you'll then know if an old API is still used. Ideally, use Git.
- Use HTTP the right way: wanna throw an error? Use 40x or 50x codes. The body of a request is just complementary information.
- Use a build manager and a configuration library: anyone should be able to build your application, no matter what IDE or platform you use (also refers to point 14). Don't hardcode your variables or settings.
- Learn Git: ideally, use the command line interface. It's far more powerful than graphical tools, and more clear.
- Avoid early performance optimization: compilers often optimize your code. Promote code readability. You will measure your code performance later.
- Always think like it's your first day on the project: is the project easy to compile and run? Is the documentation clear? Make things easier for other developers.
- Documentation matters, a lot: write everything. Oral communication is not as efficient as a good documentation. Refers to point 12.
Hope you'll find it useful.
Well, that's all for this article. Some very simple tips to follow, and then you'll become a real software engineer (in my opinion, at least).
- Why tabs are clearly superior
- "Development Principles and Philosophy" par F.G. Ribreau
- getAwesomeness: to retrieve all amazing awesomeness from Github
- Les 9 règles de Tim Minchin
- Les étapes vers le succès
- Why Knowing Stuff Doesn’t Really Matter
- Being A Developer After 40
- Am I really a developer or just a good googler?
- Teach Yourself Programming in Ten Years
- How does Clever Cloud work? (Clément Delafargue - Quentin Adam)
- Silicon Valley Etiquette
- Deep work in practice: reimagining my workflow for radically less distraction
- La revue de code bienveillante
- How I Write Tests
- Why open offices are bad for us
- Introduction aux structures algébriques
- Normes utiles
- General Coding Guidelines: Clean Code From Day 1
- GUIDE D’HYGIÈNE INFORMATIQUE
- What Can I Do For Mozilla?
- Top mentioned books on stackoverflow.com
- Principles for C programming
- Articles about x86 assembly, C, C++, Nodejs, Git, etc
- Visualizing Garbage Collection Algorithms
- Getting Started with Headless Chrome
- Ratez vos revues de code en 5 leçons ! (Michel Domenjoud)
- 10 méthodes pour rendre heureux les développeurs (Cyril Lakech - Romain Linsolas)
- Gérer sa carrière
- H.264 is Magic
- Learn regex the easy way
- How to Do Code Reviews Like a Human (Part One)
- How to Do Code Reviews Like a Human (Part Two)
- Why Focus Is Your Greatest Competitive Advantage at Work (Plus 19 Ways To Actually Do It)
- Effective Engineer - Notes
- If You Multitask During Meetings, Your Team Will, Too
- The Feynman Technique: The Best Way to Learn Anything
- Egoless Programming
- Revue de code : quel format choisir ?
- Elon Musk reveals his productivity rules in a letter he sent to Tesla employees
- Simon Sinek: How great leaders inspire action | TED Talk
- Comment négocier son salaire
- Linux - The beginning of the end
- Software disenchantment
- This Is How Successful People Manage Their Time
- What makes someone a good front-end developer?
- Google Search Operators: The Complete List (42 Advanced Operators)
- The Importance of One-on-Ones
- It’s probably never going to work in German
- How to Make Other Developers Hate to Work with You
- Famous laws of Software development
- Carbon: Create and share beautiful images of your source code
- Storing UTC is not a silver bullet
- Éteignez vos appareils
- Awesome Uses
- How to Deliver Constructive Feedback in Difficult Situations
- Great developers are raised, not hired
- When we rush development, skip tests and refactoring, we get “Escalating Risk.” Please give up the “technical debt” description; it gives businesspeople a very wrong impression of the tradeoffs.
- Too DRY - The Grep Test
- La dette technique : une supercherie mythologique pour galériens de l’IT
- How to build a startup engineering team
- #21 – Une organisation libre où prime innovation et bonheur – Quentin Adam
- Shitlist-driven development and other tricks for working on large codebases - RedDotRubyConf 2017