2017: My First Year of Blogging
After a year of blogging, my initial reaction was frustration. I didn't think I had made much progress in a year. I fell short of my goal of writing a post every two weeks and felt that, as a result, I hadn't learned much during the year. After reviewing my posts, I realized nothing could be further from the truth.
I went from struggling with the difference between for, forEach, and map, to a mentorship in F#. I learned how to use Bootstrap, parse xml, and write a unit test. My understanding of JavaScript probably grew by a factor of 10 or more, and I finally got started in Rust!. And these were only the things I actually wrote about. I learned a host of other technologies and skills that I haven't "put on paper." But I'd be lying if I said keeping up with a blog wasn't a struggle. It is. In a way it's a catch-22. To have things to blog about, I need time to learn and to code. But hour spent blogging is an hour I'm not coding.
After blogging for year, I'm confident the time spent writing is worth the cost. It has helped hone my focus. Pushed me and challenged me. And most importantly, given me a way for me to track my progress over time.
I've come a long way, but there are a lot of areas where I need to improve. Since making goals in public is often more productive than not, here are my 2018 goals:
Language Focus
Since I began coding, I've dabbled in far too many languages. C, C#, F#, Java, Kotlin, Swift, JavaScript, Python, Go, Rust, Dart, Scheme, and that doesn't include HTML/CSS and SQL. A lot of smart people advocate only learning one language, and mastering it before moving on to a new one. Others believe learning a multitude of languages is more helpful. I see the former more often than the latter. It's the better path, but not for the reasons you might think.
Learning the base language itself isn't the difficult part. The trouble is learning the ecosystem. It's easy to switch from C# syntax to Java syntax. It's all the extra stuff that makes it difficult. Gradle to MSBuild, Hibernate to Dapper, Spring to ASP.NET, you get the idea.
So in 2018, I want to focus on fewer ecosystems. This will likely be my biggest struggle. In the enterprise space, I expect .NET to win out over the JVM here. My love for F# and the fact that my company is moving to .NET and C# makes .NET an easy choice. If I decide to try my hand at a mobile app, I'll probably give Flutter a shot despite my adoration for Swift and Kotlin. Writing an app once and deploying to both platforms is more efficient than writing the same app twice. In the JavaScript space Vue will likely be my go to. Of the frameworks I've tried, it's been easier to get up and running with Vue than the others.
...
Yep, definitely going to be a struggle.
Databases
Pretty simple. I've dabbled with databases, but I want to get to the point where working with databases is muscle memory.
Head in the Clouds
Cloud technology is exploding and is seriously cool. I didn't realize how interested in cloud technology I was until I saw what the team at Improbable was doing with it. So in addition to databases, I'd like to learn my way around the likes of Amazon Web Services, Google Cloud, IBM Cloud, Azure, and Heroku.
Data Structures, Algorithms, and Design Patterns
This stuff is fascinating to me, but I've never focused on it because I've been too busy trying to build things. Everything I read is some variation of the following: "Deep understanding of data structures and algorithms is important for hardcore interviews but impractical for day to day use. Focus on building something, learn the data structures and algorithms if you need them." This is great advice, but most second year computer science students have already taken a course in data structures and algorithms, so I think it's time I get started. I'm hoping the focus on fewer platforms will give me some extra time to up my algorithms game without hindering the time I get to build.
Finish
Last but not least, I need to become a better finisher. I'm a firm believer in passion driven development for side projects. If it doesn't get your gears going, drop it and do something that does. I think this is generally a good strategy, but if it results in never finishing a project, it can do more harm than good. The solution is to focus on something small, finish it, and then iterate on it if it's still worth pursuing. Approaching projects this way means I won't start climbing Mt. Everest and then realize half way up that mountain climbing just isn't my thing.