This past weekend I launched this site. It’s built using Jekyll and I made the first sketches for the index page a couple months ago, and finally found some time to finish building the first draft and launching it. Monday morning I figured out how to set up a blank Ubuntu server on Digital Ocean without messing up too many things and then, finally, the DNS resolved and winstonhearn.com was live. Yay!

A site that I designed and coded (the front-end) and all content is mine and woohoo. It’s a good thing. I mean, sure, the design is terrible, there’s so much work to be done, the to-do list is long, but it’s live and now I can start refining. I can iterate.

And in the process of launching this and getting it out, I realized something about what makes me happy: I like working on things that already exist, as opposed to building new things. I think this is really strange? I have no clue. But it’s a truth for me, perhaps, at least for where I am now in my career.

I’m working on building a new project for a client. It’s a marketing site that will also hold documentation for the product and I’m having fun thinking through the things that need to be built so that my foundational choices can scale. It’s a challenge to organize directories, design style guides, create partials in smart ways that don’t over complicate things but also don’t hinder our ability to build things in a year or two.

Decisions like this require imaginary context, I have to make a decision, build it out a bit, then try to think through theoretical futures and guess, as best I can, what the implications of the decision will be on those futures. It’s very hard, and to me, very stressful. I am not yet educated enough to trust my theoretical futures, which leads me to overthink and unfortunately over complicate out of a fear of making a bad decision. My lack of confidence, for better or worse, reduces my ability to do well in my tasks.

But when I work on projects that already exist, I don’t have these stresses. If I’m tasked with solving a bug in an existing app that I’m just ramping up on, it’s easy enough to work within the visible constraints; how do the previous builders write their code, what are the idioms of the app and the styles implicit (or sometimes explicit) in the existing code. I can work with that, it gives me context and a framework to place my work into.

Time spent in the app then allows me to gain a fuller picture. My first week on the project may be me trying to understand the rules of the existing code and chafing at things that go against my preferences, but I’m probably not identifying actual issues in the code. My opinions and the solutions I’m working on are superficial. But with time, I get a sense of how things work, which past choices were bad, which ones were good, and how I can make improvements with every commit.

That’s the point at which I find myself fully engaged. It’s also the point where I tend to be tackling complex or subtle bugs, the ones that require all my creativity to suss out, and then all of my current experience to solve in an elegant, non-regressive way. I love doing that. I want to do it more.

This site now exists. That’s exciting. But now the real fun begins. I have forced myself to create the new, and now I get to enjoy the long, fulfilling journey of improving the existing.