Some ramblings on job searching

I’ve been working to keep my resumé updated recently, and I realize that I’m in a tough spot where a lot of my work deals with proprietary material, so I can’t include it all in my repositories. It makes it more difficult to publish things openly. Save for those working at the biggest of tech companies, I highly doubt anyone even has time to work out in the open on Github, so I feel bad for most of us who are working simple jobs that get us by, and just want to return our families at the end of the day. Eight hours in front of a screen is damaging enough to a human being, but prolonging it for the sake of impressing prospective employers isn’t something I wish on anyone.

Everyone’s advice these days is “work on a personal project, get a portfolio, build something that makes you stand out!” I sympathize with the employers. What’s the best way to distinguish the lazy from the best? The self-starters from those who are just barely showing up? Not to disparage those ones, but the job market these days is so tight for anyone early on in his career that these things have become a necessity. I don’t like the system, but I sympathize with it. I know plenty of extremely talented developers who barely have anything out in the open. What about all the 40+ year-old developers that were getting their start before Github was even around? Where are their portfolios? I have more on Github than my last manager, but he’s 10 times the developer that I am today. I hope he doesn’t have to search for a job anytime soon.

So what are you going to do about it?

Nothing, I can’t do anything about it. I’ll play the game for now, but hopefully one day we can discover a new way to find quality employees. Finding great employment is harder than ever, so here I am playing all along.

However, what I build is built for me. I hope employers understand that. I don’t build my personal projects to scale to a million. They might, but only because it didn’t require major infratructure changes or cloud costs to run a few hundred lines of code.

Open Sourcing the Bible Reading Challenge

Today, I uploaded the absolute mess of the codebase that keeps my friends happy.

It’s a mess. I didn’t add a license. I don’t know much about them, but I don’t think I want it to be free for everyone. There’s some potential buried deep within it.

Yet here it is in all its glory! It runs, it moves, it’s not very maintainable, but I’m happy I get to show some people (looking at you potential employers!) that I do in fact work on things in my own time. In this case, it was many many (MANY) hours of my own time.

In retrospect, the codebase is optimized. It’s optimized for the only maintainer. Not for me to make a company out of it because that was never the goal. It’s optimized for me to get back into it and easily jump between functions in the most basic architecture that can support it. Because, be honest: who honestly needs or wants to wrangle yaml and kubectl on a project you only touch every other month to fix one bug?) I don’t even remember everything going on in the codebase at that point, so I just write enough personal documentation to send me in the right direction.

Why would you embarrass yourself by publishing this code?

”It’s my portfolio”. It’s ugly, but it’s mine. No one has done anything quite like this before, and maybe no one ever will. Maybe no one will even want to do something like this.

But it’s mine, and I love it!

It’s my way of thinking. It’s not an example of incredible software engineering by any stretch, but it shows I had the passion for coding to the extent that I’m willing to develop and run this application for free to benefit people in a domain that I care a lot about.

It went from 0-MVP in about 10 days, and only went through one major refactor (yes, it used to be even worse!) I think many startups run into this block at one point where they have to move as quickly as possible at the beginning to get the product out the door, but then when it comes time to scale, they have to draw the line in the sand somewhere to pay down the tech debt. Not that I’m a startup or making any money on this, but I sympathize with those new CEOs: the rush of the feeling of going live with something that works, excited to show the world how you can make their lives better, how it’s so easy to think “yeah, I can build that”, to actually building it, to then having to deal with what you built having skipped the “proper engineering” step. I assume that’s why I see so many jobs posted on ycombinator for “founding engineers” because new CEOs want to avoid this rigamarole.

Funnily enough, at this point I suppose I’m qualified for those roles because I’ve done all the same things those founding engineers are doing under the pressure of releasing the MVP.

Honestly, I don’t really care if no one else can figure out how to get this code working. They don’t need to. Like many journal paper these days, often times the only one who can implement them is the original author. It’s pleasing to think that my quality of work is on par with PhD students; I never thought I was as smart as them.

More to come

I’m using this post a sort of promise to myself that I’ll also push the code for my other multi-year passion project, the Bible Research Tool, hopefully soon because I have some time on my hands.