For Mak
Yes. I'm writing this in a .md file, hopefully you'll appreciate that lol.
To me this is one of the biggest luxuries of CS over other engineering fields is that our projects have almost zero monetary investment.
- If you're a civil engineer and want to practice building a small usable bridge, you have to buy materials.
- If you're a mechanical engineer and want to build a small usable vehicle, you have to buy parts.
- If you're a chemical engineer you have to buy chemicals and lab equipment.
But we just need a computer. And you already have one of those.
Our projects are pure time investment. Everyone else has to read and spend money, we get to read and immediately try things out.
Do as many projects as you can. You literally have nothing to lose.
Honestly this was half my motivation for doing CS. I was already messing around on a computer a bunch and you always run into "this process is annoying", "I wish there was a way I could do X", or "I wonder what the answer is to some bizarre/obscure data question".
So take note of those and tack them onto your project list.
It's also important to remember that even if your code is public on GitHub or on your resume, you're building for yourself first. Build fast and make the version that is the minimum of what you need. You can add on and make it user-friendly later.
Most of the time this means making CLI tools rather than websites or apps. It's a lot easier to make something like modify image /path/to/image.png than A website where I can drag in an image, and then get a displayed version back, maybe with some nice share buttons.
CLI tools aren't sexy, but getting something working is.
A lot of the time the easiest project ideas to come up with are just "how does this thing work?" or "I bet someone has already solved/answered this problem, but I want to do it on my own". The only thing you'll waste is time. The real exercise is getting good at converting time investment into knowledge + skill acquisition.
Starting out I had a bunch of these. There's complex tools everywhere for things like 3d rendering and image processing. Are there great tools to solve these problems? YES. Are they simple and free? Sometimes.
But implementing them at a super basic level teaches you a lot. My brother Logan is doing this rn with machine learning stuff, I'm sure he would love to talk your ear off about it.
Here's some examples that I did earlier in college:
If you get stuck on a project like this, then odds are there's an existing one on github already and you can try to pick it apart to see how they're doing it. Which leads into the next point.
No one likes to tell people this at the start but:
Reading other peoples code is usually harder than writing it yourself.
Even if it's well written code and you're mediocre at programming.
Reading code is ~50% of the job of software engineers. In industry writing new code and starting new projects is usually a last resort. Ideally you can add onto/modify an existing project. This is usually not fun, it is rarely gratifying, but it's a really good skill.
The more industry experience I get the more I realize how many serious products are hacked together because it's easier than starting from scratch.
Even if your code isn't to be read by coworkers or classmates, it will likely be read by your future self. Be kind to your future self and write code that is clear, coherent, commented, and reasonably organized.
(this is the most important section imo)
This is partially just the way I work (why I ended up on a labs team rather than a product team after graduation), but I rarely enjoy focusing on a project for longer than two weeks at most. But imo you can learn more from jumping between very different projects than really committing to getting them 100% done.
If you start a project and run into the hard stuff ~40% of the way in, then hopefully you can walk away with a better understanding of a problem and why it's hard. Being able to guess what parts of projects are going to be hard is honestly half the battle sometimes: "What parts of this project will just take my time and grinding it out vs what parts will have I have to dig into to learn to solve?".
There is literally zero shame in abandoning a CS project. All you've invested is your own time, and hopefully you learned along the way.
If you do run into the hard stuff and decide that it's worth slogging through, then CONGRATS now you've found a new focus/specialty. You'll run into lots of these with different subfields (3d graphics / game design, web design, & machine learning all come to mind).
These things usually make for the best resume builders, even if you dip your toes in just a little. A candidate with general software engineering experience is cool, but recruiters will gravitate to something on your resume that indicates you've dug into some industry-specific knowledge which is relevant to them. If you can have a few of these on your resume, or find projects that incorporate several (I had one project that was doing computer vision to process input to an algorithmic problem. I did not finish it lol, but got ~70% there) then you cast a wide AND deep net for recruiting.
This is mostly about languages and libraries.
Clean product pages flashing fortune 500 logos can be tempting, but most of the time they are noise (this happens ESPECIALLY in web frameworks).
Usually the best tool to use is:
- The tool you already know how to use
- The tool with the most documentation/help. The ones that have stood the test of time and have lots of StackOverflow posts and YouTube videos. Ironically this also means that ChatGPT will usually be more helpful, as its trained on years of documentation + forum posts about the tool.
- The tool that everyone else uses. This gets industry/application specific
You'll notice that "the best tool for the job" or "the tool purpose-built for my problem" is nowhere on that list. Only go for those if they happen to line up with those other 3 categories.
This is mostly about languages.
Time wasted on a project that is never finished/used is redeemable if you learned new concepts that can be mapped onto later ones. But a lot of the time learning new tools that you never really use is only a useful exercise in learning.
Yes, the industry changes. Yes, it's nice to have a leg up and already have X amount of experience with Y technology when people are hiring for something niche. But if they're not hiring for Y or something else improves to the point that the industry doesn't have to move much then Y becomes useless fast.
PS: I would argue that Python is an example of something improving enough to stay the norm. It was literally first built for children and runs slow. But some hacky stuff has made it fast enough for most people. There are some people making moves to replace python, but it'll take so much to displace something good enough that everyone is already using.
PPS: There are some exceptions to learning niche tools (like fortran developers, allegedly Delta's ticketing system still runs in fortran because it got too complicated to migrate to something modern) where you can make a bunch of money by maintaining a legacy code base. This is a supply-demand issue at work, but don't gamble on companies never replacing their niche/old tech.
This is mostly about libraries and APIs.
Learning new tools is the closest most students will get to learning a companies internal legacy code, so in that way it's a useful exercise.
Reading documentation is a skill. If you have a big project that covers a lot of concepts then you'll move a lot faster if you can quickly integrate other people's tools (for me this is usually python libraries).
- You can make a website with just HTML, but React sure helps.
- You can do machine learning with anything that can do math, but PyTorch sure helps.
- Databases, job queues, etc. are good examples for this too.
APIs are also good examples. You can get away with making a crappy web-scraper (I would even put this in the re-inventing the wheel category of projects), but practically everything has an api (Spotify, EBay, etc.) and learning to pick them up quickly is a super useful skill that dramatically expands your project reach.
There are too many tools for you to have heard of all of them, so you just have to get good at noticing when you're on a well trodden path and knowing to stop and take a minute to look for an existing solution (library or api) you can hook into.
Being comfy in a terminal is more helpful than you would hope. Having a laptop my first year that could really only run terminal + sublime text did me a lot of favors in the long run.
A list of boring things that I think are worth investing in:
- command line
- The unix terminal has been around since like the 70s and people still use it for a reason.
- It's easy to build for and easy to chain tools together.
- Pretty much any niche operation has a command.
- Ex: "I need to check for any files that I edited after date X, that are
.jsfiles, anywhere in this project, that have a very specific pattern of text which could have several forms"
- Ex: "I need to check for any files that I edited after date X, that are
- ChatGPT makes it so easy to find what you're looking for, but navigating quickly and knowing the basics is a skill that requires exercise
- git
- Getting code to work is hard enough, don't lose your working versions
- git is awkward but if you can move quickly then it pays off, especially when collaborating.
- low-key I hate to say this, but diagraming
- Doing it the standard way actually does matter :(
- I had a whole class at GT that was mostly just making diagrams to an industry standard and I thought it was BS, but there's been so many times at work that if I could've quickly cooked up a chart that was to spec then I would've been able to make my point a lot faster and clearer.
- Managers rarely look at code (even if they are super proficient programmers). The best way to communicate and make a point is to make a diagram that conforms to a visual language (standard) that they already know.
- Keyboard Shortcuts
- Hard to undersell how much faster you can get at using a computer with shortcuts
- A mouse is just a really slow way to interact with a computer. You open tabs and arrange windows all day, doing it faster means less mental overhead and you can really lock in once you're comfortable.
- If you're feeling really adventurous dip your toes into learning VIM. It's keyboard shortcuts to the extreme, but that means there is a STEEP learning curve.
Programming is a different way of thinking. It literally takes exercise to get your brain used to it.
College is all about learning to learn. Get really comfortable not knowing things. It's easy to let that stress you out, but it's literally everyones starting points. Once you get good at the process of picking up new things it gets familiar.
The gap that you've already closed from "no programming knowledge" to "basic programming knowledge" is far greater than the gap to learning a second language, new tool, or sub-field.
Eventually diving into new topics is no longer "I've never done this before" but instead:
"I used to not know anything and now I know several bits. This is just one more bit."
Good luck! And happy building!
banger