loading...
Cover image for Towards Complexity

Towards Complexity

deciduously profile image Ben Lovy Updated on ・3 min read

Building A Bigger Boat (4 Part Series)

1) Towards Complexity 2) Oops, I'm Making A Framework 3) In And Out Of Rabbit Holes 4) Callbacks, Trait Objects & Associated Types, Oh My!

Harder, 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:

  1. Solitaire - Terminal
  2. Solitaire - Graphical
  3. Two-player
  4. Multi-player, networked
  5. 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:

mountain comic

source

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.

Building A Bigger Boat (4 Part Series)

1) Towards Complexity 2) Oops, I'm Making A Framework 3) In And Out Of Rabbit Holes 4) Callbacks, Trait Objects & Associated Types, Oh My!

Posted on Aug 6 '19 by:

Discussion

markdown guide
 

An in browser game using JS and something like Phaser and Rust in case you need WASM?

Or you could try using Skia with C++ which also supports WASM

 

Phaser could be a good fit. I think if I go Phaser, I won't need WASM, and if I go WASM, I probably won't need Phaser. I'm leaning further towards the C++ route for this experiment, though - I'm writing more and more C++ for school as well and find the constant context switching in the course of a day slows me down. Eventually I'd like to get better at that skill but that's not my goal right now.

I hadn't looked at Skia - have you used it? I had also thought about fastUIdraw, but know very little about either. Would you specifically not recommend SDL/SFML? Those were really all I knew about going in.

 

I'm leaning further towards the C++ route for this experiment, though - I'm writing more and more C++ for school as well and find the constant context switching in the course of a day slows me down.

Agreed!

I hadn't looked at Skia - have you used it?

I haven't used Skia but it's the rendering engine for Android and Flutter and Firefox on some platforms (I think only Windows), so it's probably battle tested :)

I've used SDL a long time ago through Python and PyGame, I don't have recent info on SDL but IIRC it's still going strong!

Ah, cool! Can't be terrible then :) I'll give it a closer look, thanks again. I think it sits at exactly the level I'm looking for in a rendering library

 

The jury isn’t deliberating. Code isn't a fashion show. It works or it doesn’t. Kruger-Dunning teaches us that incompetent people are happy with their code and craftsman are frustrated. This means that being a malcontent is what success looks like.

 

In a general sense yes, or course, and I could be incorrect, but at least insofar as it pertains to getting more calls back for a first job I'm not sure too many hiring managers take much of a look.

 

Languages and projects aside, the most useful move you can make and reap most benefits from, is to get out of your comfort zone. Try something you've never done before, maybe OpenCl, CUDA, FPGA, etc. Whatever path you choose to pursue, you will learn the most by choosing the one you know least about. I've been in your position and being scared is a normal reaction, don't worry about it. Good luck in expanding your knowledge.

 

Thanks for the tip! That's why I'm considering the SDL/native route - it's the largest departure from what I'm comfortable with, so it stands to reason it's got the most to teach me.

 

C++...? I started in C++ and I worked in an office where Bjarne Stroustrup would come in to do some consulting and talk to my boss. Being an expert in C++ means you have a rating of 25,000 on stack overflow. If I wanted to win at stackoverflow I would still write C++. Have you tried Rust?

 

That's what I've written most of! It's my favorite language so far.

 

You can tackle web and desktop in one go, and since you mention learning Rust you can do Rust+WASM which would add an extra dimension to the learning experience. Look at this, perhaps will help you.

 

This is a great idea, actually. I've built a handful of WASM demos, and always wanted to try something more significant. This project might be a perfect fit after all.

 

Great post! Thanks for sharing. It's always reassuring to see people admit to their insecurities, and encouraging to see them do something about it.

 

Part of learning is always learning how best to learn, and if something is ever helpful for me, chances are it's helpful for someone else too!