Writing Haskell every damn day

August 15, 2013

Over the past year I set a goal of becoming a world-class web developer. Perhaps that’s not a verifiable outcome, but I am happy with my accomplishments. I created tools for CSS refactoring, semantic markup, distributed computing on Amazon Web Services, living CSS styleguides, JavaScript searching, analytics, Git workflow, Vim configuration, and npm+bower package management.

I went on a programming pilgrimage to visit twelve companies in San Francisco in fourteen days. And now, one year after the 1Up project began, I found an apartment and moved to SF. Crazy year.

sf city

sf city

So what’s next? When I look at the city skyline I get excited. It’s packed with people busy inventing the future of technology. Being here somehow increases the pressure to make something great. Geography is now no excuse, my success or failure is all up to me. Some people I meet here are brain-meltingly smart, and sometimes it feels difficult to even keep up, much less stand out. I need to plan ahead and and be tenacious to have a chance.

One way to gain an unfair advantage might be to avoid trendy tech and jump right to a possibly more capable technology stack than most people use. Lately whenever I think through the best way to write code I’ve noticed that the the Haskell community seems to have already done it right. Whatever appears in tech news as a hot new idea is already done flawlessly in Haskell. I was considering writing immutable data structures in JavaScript in order to tease out ideas for what might be a better UnderscoreJS/LowdashJS, but I get disheartened seeing how well it has already been done.

So here’s my new goal: become an proficient Haskell hacker, contribute to some libraries, and build a real Bendyworks client web app using the Haskell stack.

And write about my progress every. damn. day.

Visit the blog tomorrow to see my first step.