My B.A. is in Creative Writing. I applied to study a Masters in Computer Science to get better at theory, fill the gaps in my knowledge, and to be a better software engineer. Here are a few things that weren't on the curriculum.
Markdown
Using markdown is straightforward and can be learned in fives minutes. However, effective use of it is a little harder. Writing good technical documentation is a separate skill to Computer Science. Have you ever visited a repository on GitHub and the README just clicks with you? Your questions: answered. Your eyes: rewarded.
Directing where a visitor looks and shaping their experience of your text is something that is understated. I've been asked to review portfolios and have found fantastic libraries with textbook clean code and patterns out the wazoo. But all of this hidden behind a cold markdown page with minimal formatting. A few short sentences squashed together doing zero justice to the beautiful code a few clicks further. Most hiring managers would have stopped right there.
Studying Computer Science in academia is quite separate from the reality of programming, which is all about humans connecting. We write code for humans, not machines. No one wants to start reading code without an intro. A nicely marked up README softens the blow — and will help you get that job.
Clean code
With deadlines looming and marks not awarded for neat code, it's hard to learn to write code cleanly. Going through a few review processes at my first job shaped me up fast though. There's a big difference between writing code for a professor — with the only requirement being that it works and is 'readable' — and writing code for a team that you care about. Projects in academia are built and thrown away for the most part. We all grumble about the code behind some fantastic papers. (Although, a few of my classmates did open source parts of our projects).
People have their own definition of clean code. For me, I'm interested in writing something that can be easily extended or altered in about three to four months. Code with comments only where necessary, cached variables to help cohesion, everything formatted per the style guide and then further for readability. I wish someone told me at school: don't forget the human.
Code review
While there were one or two opportunities to work in teams, it wasn't a high priority to set up a code review process. All coding — from launching spaceships to writing iOS apps — will involve reviewing other people's code and preparing your own work for review. There are two parts here, reviewing and being reviewed.
Reviewing code is a practice in building mental models and applying empathy. If you're reviewing properly, you're not only concerned about how the code reads line by line but how it affects the code base today and also this time next year. You have to ask questions and provide feedback with the utmost empathy. You are not a scorned theatre critic — you are trying to help your teammate improve their code. Be polite, err on the side of being courteous. Though, when you have a rapport, slather on those GIFs.
Preparing code for review is a skill in itself. Your review should be a logical chunk. As small as makes sense. Describing the problem or story your code is solving is important too (I personally use markdown for this). It will arm your buddy as they go to battle in the depths of an attempt at your first bug (sorry, Jamie). It will save them rolling their chair over to you and going so about that review.
The edges of languages
At school we applied languages like Java, JS, and Python, to solve algorithmic problems. We built databases, management systems, navigated mazes, and touched a bit of full stack too. We optimized. We did all this with the core tools. Data structures, algorithms, Object Oriented Programming, and a dash of math. However, I had to learn on my own how setTimeout, delete, and this interact inside a production code base. No one told me about decorators, or how ES6/7/8 was bringing us into the future. I like bugs that take me somewhere I haven't been before — when I crack open the spine of StackOverflow, the esoteric and unknown interactions. For JavaScript, I can recommend You Don't Know JS and Eloquent JavaScript (both free). For Python: So you want to be a Python expert?.
~
Although I worked hard, I learned more by trying to be creative on the web, entering game jams, and hacking away at weird projects. I pretty much consider myself to be self-taught except I'm lucky enough to put the letters MSc on my resume. The skills that I used to consider paramount have fallen away. I once thought being a programmer was all about eureka moments and collecting a library of algorithms in your brain.
When I hear that someone new is joining our team, I don't worry how good they are at writing code. I want to know that they'll listen to my comments in their review (and tell me how I'm wrong!). I want to be able to communicate with them about technical subjects. I want to learn from them but not just about code-related things. Most of all, I hope they are fun to work with.