When I started studying Computer Science at university, I was already working part-time and making websites in as part of my media design major. I learned about object oriented design, algorithms and networking but today, as a professional developer there’s a tool which I use every day which I never learned in Computer Science classes. Git, but more specifically working with others. Version control was not something that came up when hacking away at problems as a solitary coder. It rarely came up in group projects, possibly because “group” didn’t mean work as a group but work separately and attempt a feat of massive undertaking, merging everyone’s work into a tangled mess hours before submission.
If there is something I recommend every programmer know, it’s working with others. Programming in the real world is seldom like class work. There’s more meetings and discussion. There’s more interaction with different people with different aims. In the real world you’re expected to work together — communication along with cooperation is key.
You’ll probably never be locked in a room for 3 hours and be expected to write an algorithm with no access to outside resources, writing code with pencil on paper.
My exams were sit down, multi-hour long exams writing Java with pencil and paper trying to write code without the aide of outside resources. This is unlikely to happen in any other environment outside university. You’ll use an IDE and spend countless hours reading and digesting documentation online. You’ll trawl through issues on GitHub, finding answers to questions on Stack Overflow and ask the resident expert in your team. Programming in the real world is often spent reading rather than writing code.
You’re not marked on the how many comments you stuff into your code or how clever your solution. You won’t write that entire niche code-base from scratch.
I remember getting extra marks for adding comments that, “where there was complicated code”. Whatever that meant. In reality, you’ll use comments where sparingly. Instead of a comment, you might choose to make the code easier to understand and bypass the comment entirely. You’ll also tackle difficult problems but they wont be well defined and clean like the ones in class. When you come across problems that are too large to solve in too few story points, you’ll find a well-tested and well-documented library to do it for you. Usually you aim is to find a solution that works well enough in limited time not the best solution — the one that gets the job done.
In the real world, you’re judged by your peers on the readability and workability of your code. Your code will not be perfect, and you probably won’t be the one to perfect it. Code reviews, peer programming and time will change the code you write and improve it.
The biggest challenges as a professional developer are seldom the code itself. That’s the day to day nitty-gritty, the biggest challenges as a developer is taking the needs of a customer or a stakeholder and figuring out the best way to translate those needs into something which delivers them value within budget. The challenges are working with others to achieve that goal. To test the solution works. To review the code of your peers and be scrutinised by them in turn. To re-write and delete code that no longer serves a purpose. To negotiate with everyone else in the team where your code should be along with everyone else's. The biggest challenges are around the code, around the problems you’re used to. They are out of your comfort zone and they don’t follow your rules.