Ben LovyHarder, Better, Faster, Stronger
I received a helpful bit of constructive criticism recently. This post is about what I'm going to do about it.
I've long felt insecure about my portfolio of code samples, because I had no idea what it "should" look like in order to look hire-able. I had no idea if my code was a complete mess, or in the wrong languages, or bad examples, or not polished enough, or you know, any of the ways I could have mucked it up. Side-effects of self-learning in near complete isolation, who'da thunk. I also didn't know if it even mattered, and the jury's still deliberating on that one.
As it turns out, overall usefulness aside, I do have a fixable hole in my body of sample code. I have a bunch of small things in a variety of tools and understand how to compare and contrast these tools along various axes, but I haven't demonstrated I can orchestrate a bunch of small things into one big thing. My largest samples max out around 1,000-1,500 lines total. I have a good command of the tools and can solve micro problems, but who's to say if I'm good at macro problems?
I think I kind of knew that, but I don't think I understood exactly what the difference in scale represented until it was laid out in this way.
It's time to level up, abstraction-layer-wise.
The Remedy
I think I'm ready for the challenge, but there's only one way to find out. The project I was suggested is a simple game but occurs in stages:
- Solitaire - Terminal
- Solitaire - Graphical
- Two-player
- Multi-player, networked
- Computer player
I don't anticipate a complexity issue with any of these components in isolation (except perhaps #5), and have tids and bits scattered throughout my hard drive that actually do cover a number of these various parts. The parts I haven't solved I'm confident I can figure out, too. I know I can solve micro problems with with the tools I have. The problem is that I've never tried juggling a bunch of little solutions, which is exactly what I'm trying to get myself hired to do.
Choices
I'm not sure what to use to build this. Part of me wants to go basic as possible with the tools and explore the whole problem myself - full-stack JavaScript with zero frameworks for the web route, or take the opportunity to learn SDL/C++/sockets or something, to keep closer in line with my schoolwork and not get too spread out. That way I focus on the problem, and not the tools.
That also might be shooting myself in the foot. See? I have no idea! Never done it. Maybe I should use Flask and React, and abstract away a lot of the finicky stuff and use a platform and paradigm I'm more comfortable with, but end up with a less general solution and possibly a less effective learning experience.
I've got to think about it.
This will also mean neglecting two other side projects I've started recently and would like to finish someday. Both are fun, but both are similarly small problems and neither are urgent. I'd like to make the most of my side project time right now, and perhaps revisit when I've got a little more free energy to spend.
Our Work Is Never Over
I used a mountain analogy at the end of my C++ journal post, and you may be familiar with this comic version:
This applies to all sorts of fields, not just language learning, and feels especially apt now. I think I've hit the ridge, time to practice bouldering. It only gets rockier from here.
Photo by Neil Rosenstech on Unsplash.
