A Job Offer

I accepted a job offer this morning. It’s quite different than what I used to imagine as my career. It’s exciting though!

As far as I can tell, I’ll be querying and analyzing data from big ol’ databases, which is vague, but super interesting.

Many people say stuff about how they never would have guessed where they ended up later in life, so I’m not special or anything. But, it feels strange.

I went from a relatively good student in high school (but I hated it), to a lazy kid working crappy retail and telemarketing jobs, to a Korean linguist in the Marine Corps (wtf?!), to a computer science student, to a stay-at-home dad and hobby programmer. Now I’m going to be an “Operations Research Analyst.” It has been a windy path.

I’ve also changed a lot, hopefully for the better, and life continues to get more interesting.

 

Beginner Programmer

I still feel like I know nothing about programming. Even though I have been programming since 2011, it feels like I’m clawing my way through every block of code.

Of course, there are some things I understand, but it doesn’t seem that way when I’m constantly learning new things. There is never a point where I can stop and be happy with what I’m capable of.

There will always be more to learn. Programming is hard.

 

Coupling Code

I like the word ‘coupling‘ when talking about writing software, as opposed to what we don’t want: entangling. The way I think of it is that we want to attach code together in sequence, but avoid tangling up the code by attaching tendrils everywhere.

In a talk that I watched the other day, the speaker used images of train tracks to represent code, which made a lot of sense. We want data to come in, get processed, and get spit out the other end. We also sometimes want to redirect code, a lot like switches on train tracks.

The reason I bring this up is that I’ve been learning OpenGL again, and I’m in dire need of some good abstractions that couple my code together. While I’ve been following the tutorial, I frequently make changes in one place, while forgetting to change related code in another place. When I find good ways to prevent that mistake, making changes will be much safer and easier.

Avoiding too much abstraction is also important, because I don’t want to get into entanglement land. Once stuff gets braided together, it becomes a huge mess.

The goal is to think carefully about how each abstraction might affect the rest of the code.

 

The Long-Term Story

Sometimes, short-term results don’t tell the whole story.

How many times have you gone down a rabbit hole of programming, just to find out that the feature you added wasn’t needed, or that your approach didn’t work? Typically, we don’t know what implementation is needed until we can see our first attempts at a solution. The short-term gains shown during early attempts aren’t telling us how the end product is going to look or perform.

Have you ever tried a diet that helps you lose weight in the near-term, but you either end up feeling like crap, or gaining it all back? I wonder what the research says about health expectancy for people who stick with fad diets, lose weight, feel great, but then die early…

How many trips to the gym does it take before you start to see the health benefits? You have to stick it out long enough to find out.

Do you know of any companies that like to focus on quarterly earnings, all the while ruining their reputation, losing customers, and failing in the long run? Sometimes, doing the right thing and, taking some early losses can set you up for success later.

One of the reasons we say that hindsight is 20/20 is because we can’t predict the future far enough in advance. If our short-term goals were indications of how things ultimately turn out, we wouldn’t have to worry so much about hindsight.

 

Beliefs

People rarely go through significant change. Even if you want to change, it’s hard to recognize when you’re making biased decisions (spoiler: all of our decisions are biased).

I’m in the middle of reading Thinking Fast and Slow by Daniel Kahneman, and it’s outstanding. He talks about ‘system 1’ and ‘system 2’ where the former is where you think fast, and the latter is where you think slowly. (It’s way more complicated than that. Go read the book.)

Getting past system 1 is not easy. All of our associations, assumptions, and beliefs are already baked in. Our brain makes life easier by making decisions for us, before we even recognize we have a decision to make. If it didn’t do this for us, we would be debilitated before getting out of bed in the morning.

If you really want to make sound decisions, you have to work at it. The first step is to be aware of what your mind is doing. It sounds simple, but it’s actually the hardest part.

Once you start noticing how you make decisions, you can pause for a moment in order to move those system 1 decisions into system 2. If you can get good at step one, step two is almost guaranteed.

Spend some time noticing your thoughts.

 

Too Many Things

I think that most creative people have this problem. We have new ideas all the time. Interesting ideas that would be fun to try out, but time is limited.

You might also have the nasty habit (like me) of trying to do too many projects at once. It’s a vicious cycle.

Focus is key. Focus and Deep Work.

 

Engineering

Sometimes I take for granted the engineering part of software engineering. Since I’m usually working alone, on my own projects, it’s easy to get tunnel vision, and forget about the important stuff.

Many of the fields of engineering have been around for a long time. With under 100 years of history, software engineering is kind of an infant.

When it comes to building software, I’m also kind of an infant. Even so, I like to think that I care about what I do. I want to make things that last, and engineering can certainly help me with that.

Don’t forget about the other half of software engineering. Software is everywhere, and it needs to be good. I don’t want to think about what will happen when it all comes crumbling down.