Another year has gone by and so, I’m writing another year-in-review article. As always, it’s been pretty crazy for me. From expecting a second child, to using an iPhone. I wanted to share my thoughts and some of my journey. I feel like doing this kind of a retrospective as well as a “goal setting” for the next year is great and listing back through my “overviews” is also a lot of fun.
Quick recap of the goals
Looking back at my 2015 article, I had some interesting ideas about what I’d do and it’s been interesting getting to where I am so without further ado, here’s my paraphrased goal list from last year:
- [x] Use ES2016
- [x] try Purescript and/or Elm
- [ ] try out Terraform
- [x] try Flux + React architecture for smaller apps
- [ ] give Go another shot
- [ ] make a game in C++
- [x] customize Emacs
- [x] get into PostCSS
- [ ] learn about AppSec
Overall, I got a few of these done but most of them ended up getting lost by the wayside.
What I’ve Learned
While writing this section of the article, I realized that, unlike last year, my focus this year has been higher-level concepts rather than specific technologies. I hope that I can take that as a sign that I’m growing as a developer but who the hell knows, right?
The year of indecision
This year, more than ever, I could not, for the life of me, decide on what I wanted to learn. There was a lot of React, and Redux, I tried Elm and built an app in Angular 2. I looked over Vue and spent some time with Ember. In short, I’ve been all over the place, trying to figure out where to go next after Angular 1. I came to a difficult conclusion about who I am rather than what framework I’d like to use.
On the one hand, I’m a huge fan of enterprisey architected stuff. I love C#, I was a fan of Java when Android first came out. I love Typescript. Back in PHP days, I enjoyed working inside of Symfony. Well, you can see where I’m going with this: I like object oriented programming and I like programming with big heavy frameworks.
On the other hand, I actually spent more time working with the lightweights. I’m still convinced that KnockoutJS was the framework of the future. Don’t even get me started on it (and how I still see VueJS as the spiritual modern successor!). I enjoyed using Angular back when people built small SPAs and I built a couple of apps in Laravel in my PHP days. The experience of writing apps with lightweight frameworks is amazing.
On both sides, there’s something missing and that’s why I’ve been going back and forth between Typescript and Babel. Between React and Angular. Between using Knex query builder or an ORM.
The freeform frameworks are great because you can start out really freaking small and pick it up quickly. It’s also pretty easy to add new features and have this small core grow up to be a big beast. The structure is up to you, the decisions are left up to you, and, best of all, it requires less time to learn than the alternative.
But there’s this draw inside of me toward that structure that Angular 2 provides. Toward Typescript. I like that it makes decisions for me and I just need to learn how to navigate that system. When the system starts to grow, it scales nicely because the entirety of the structured frameworks is meant to scale.
In the end, I know that if I can’t quickly build something small, I probably won’t use it. The React ecosystem has matured considerably and I can easily solve a problem with React in my head while Angular 2 took me by surprise when things “didn’t magically work”.
Any kind of scaling. From performance, to memory, and even all the way down to deployment orchestration, scaling is hard. It’s difficult and you start to see problems that you didn’t at a smaller scale. I spent the year constantly praising and lamenting my decision from the previous year. Decisions like architecture, third party libraries, database, and even naming schemes have been hitting me left and right. Fortunately, with good and bad alike.
This year has been a lot of that for me. Internally, we switched several big architecture pieces because the original decisions made at the inception of the app did not fit anymore. The product started to mature and grow out of its original codebase architecture and that resulted in a good deal of difficult lessons. It’s taught me just how important it is to keep code self-contained and as dependency-free as possible. As the saying goes “keep things isolated”.
On the other hand, keeping code as specific as possible is a good idea too. I gave up on being DRY when I realized that not everything needs to be broken down to reusable base components. A good example of that is CSS. There’s really no reason to have to add 5+ classes to an element to style it just so you can use those styles elsewhere. Might as well write one class that imports the five others. Or write 15 classes and replace the point of classes in the first place.
Not Invented Here vs. Invented Here
The node eco-system encourages the NIH principle. There is a module for pretty much everything, including an ASCII Art module and so much more. I’ve been back and forth on the NIH and IH boundary for a while but holy shit did I get smacked in the face with it this year. I’ll add to the IH principle and say “Running Here”, as in, running everything on your own hardware/VPS/whatever.
So earlier this year, we started adding Excel support for our reporting system and the thing that popped up immediately was that the library that did fix our problem was obsolete. In fact, it had a ton of open PRs that were supposed to fix issues the lib had but no admin to approve them. One user took matters into his own hands and created a duplicate library, merged in their fixes and after a year dropped support. This great library had two copies and it turned out, a lot more that weren’t publicly published but were privately used. So what did we do? We made our own copy -.- Yeah.
There were a few other situations during the year where NIH basically meant “I hope someone supports this!” and it made me immediately reluctant to use 3rd party libraries. We had a PDF generation library with a 1 year old bug that was discovered soon after we started using it. Confident that the library was well-maintained, we went on ahead. And it hasn’t been fixed. Not that there weren’t any PRs that tried to solve the problem but the problem persisted and the issue grew older and older.
Now whenever one of my fellow engineers approaches a new problem and mentions a 3rd party library, I’m more than reluctant to say “Yeah, okay, let’s do it”. And honestly, so are they.
On the other hand, the IH principle (and more importantly the “Run here” or “Run only here” principle) resulted in weeks of headaches as well. I built Ansible scripts and a deployment infrastructure (check out my last year’s review for more info). Shit runs great! It powers our Vagrant machine, it’s always up to date but…I’m not an IT person and screwing up settings for several big pieces of infrastructure has cost me more time than I’d like to admit.
A few months ago, a fellow developer finally convinced me to offload the biggest pieces of our infrastructure onto Heroku and ever since then, things have been exponentially better. Let’s just say that I don’t wake up to “NOTHING WORKS!” message on Slack anymore.
Balancing between IH and NIH is difficult but ultimately, the more I learn and the more I code, the easier it becomes discerning where we need to roll our own library and where we need to invest into a 3rd party solution.
I tried to work with Electron this year and managed to build two apps. The first one, hRPG is a simple front-end for Habitica. The only offline feature is storing access tokens in localStorage for later retrieval. The UI was built with React.
The second application was a Markdown editor called OMEN. OMEN was built with Angular 2 and offline-only. It can access files in a specific directory.
What I found really interesting in Electron was how simple it was to setup and work with it. Within a few minutes, I had a simple index.html file running within its own window. A few months later, I was running hRPG and used it instead of the web client for Habitica. I wrote almost the entirety of NaNoWriMo book using OMEN. I documented the entire process of writing that application on my youtube channel.
I wanted to build a tray application with Electron but haven’t had time but it’s been continuously impressing me and I hope I can build more stuff in it next year and improve OMEN so that I can use it full-time.
Webpack (and new tech in general)
I’m usually staunchly against new technology that people proclaim will change your life. When React came out, I scoffed at the notion that it would change everything. When Webpack came to replace Gulp and Browserify, I stayed behind. This isn’t a sign of a developer not wanting to move on, that’s a sign of a developer who has invested time in new technology to either waste it or be forced against an edge-cases that can’t be resolved. It’s happened far too many times where a technology was supposed to “make everything so much better!” but in fact, had the same warts as everything else.
And in fact, I was right to do so. React is a great library but until Flux came out, it was unmanageable. When Flux came out, it just became confusing. With Redux and Facebook’s effort to make developing React seamless, it finally started to flourish. I’d argue that Webpack was the same way until you realize that you can do code splitting, something that Browserify is just not built to do.
So this year, I took a head-first dive into technologies that people have been throwing at me all year. I tried out Ember, Elm, Webpack, tons of Typescript, aforementioned Electron, oh and I built a Babel plugin!
Developer experience wasn’t really much on my mind until this year. I went from a skeptic of how developer experience can help productivity to a believer. And not only does it help productivity but it makes work more pleasant to do which brings a peace of mind. I finally found a justification for setting up my editor just right! But besides setting up an editor, DX involves diving into tooling that helps development including CLIs, frameworks, and even library APIs.
At work, I saw the impact of this first-hand when we cut down on compile time and fixed bugs that prevented files from compiling correctly on watch event. We continued making improvements to our internal DX to the point where our entire deployment workflow can be understood and executed very quickly. We automated lots of tasks, set up alerts, and even upped our CI plan so that we have builds faster. I’m planning a whole write-up on the topic but the gist of it is that both produciton and consumption of software is done by humans.
Project Management and Self Management
Probably the most impactful thing I learned this year was the impact of proper and improper project management as well as self management. What I mean by self-management is being able to organize your own time the right way and that includes more than just looking at the next task on the to do list. That includes meetings, pair programming, emails, responding to notifications and so much more. Beyond that, it also includes the ability to focus on work and how to do that. There’s a delicate balance one has to keep with all of the incoming information sources and all of the requests for information from you.
For instance, a message that shows up in my Heroku Slack channel. Do I check what it is? Do I let someone else do it? It might be nothing (just another deployment) but what if it’s a runtime exception? What if it’s an application crash? And bam! I already lost focus and I haven’t even checked what happened. I can’t mute it either because there might be time-sensitive errors.
There are other things as well. I might get an email from a prospective employee and while I don’t check my email often, I do have to carve time out for it.
I wrote tons about PM in a previous article but the gist is that PM can make or break a development cycle. Self-organized teams are a great idea but I’ve yet to see one that works really well on a feature-by-feature basis.
Basically, individual productivity management makes a huge difference on the overall productivity and the overall productivity makes an impact on individual productivity as well.
Technologies come out faster than the speed of light (maybe not that fast). There are so many things hyped right now and for a full-stack developer, it’s more than a handful trying to keep up with every single thing. I also have a kid now and my time has to be appropriated correctly which means that I had to learn to be selective. Selective about my front-end frameworks, about the blog posts I read, selective about the books and even the youtube videos I watch. Being selective gave me a much clearer path in my career and life though. We’re constantly overwhelmed by information and it does us no good unless we sort out the (currently) irrelevant from the pure gold.
I recently posted a Vlog about this on my youtube channel and quickly touched on this topic. Generally speaking, I realized that I don’t need to try out every single thing out there. Sometimes, knowing what that technology does and what problem it solves is enough. Often times, frameworks share paradigms which means that jumping from Angular and React to Vue is the matter of hours rather than days or weeks which also means that learning that specific framework isn’t important until necessary.
I’m hoping to continue to be more selective with how I spend my time outside of work and cut down on the clutter. I honestly did not need to watch a two hour video on SQL Alchemy…especially since I don’t even use Python.
What about 2017?
Usually, I discuss how I want to further my skills in my review section but I wanted to bypass that and just look at the next year as a clean slate.
More app development
One thing I did this year was focus on building more apps for myself. The electron applications are a prime example of that effort but I’ve been tinkering with libraries and with building various products for a good while and I love it. It’s one thing to start a new project to learn a new technology, and it’s a completely different thing trying to push that technology to its limits by building something you want to see happen.
I’ll definitely come back to what I already have because those apps are useful to me. I use OMEN occasionally and I fire up hRPG when I really don’t want to deal with Habitica’s website (or when I really want to have my Habitica tasks on hand). Those edge-cases are what give me a good idea why the new technologies exist in the first place.
I love building apps and I really love buildings stuff I use.
More libraries, more support
I’ve written a handful of libraries and those libraries are used in a handful of other projects. Some of them are still chugging along in past workplaces while others I use for hobby-projects only. My goal for the year is to update these libraries with what I’ve learned. I have a library that I use called JSON Structure Validator which I use for API testing in whatever project I work on. I wrote the original three years ago and over time, I realized that I could improve the experience tremendously and make it do more work for me.
I often create “bags of functions” for work and outside of work and it really baffles me why I never open source them, test them, and outright support them since that would make my life easier.
So for next year, I whole-heartedly want to spend time making my life easier by putting these small modules up on NPM and be able to reuse them wherever I move. I feel like it’ll remove that friction from getting into a new focus.
Last year, I abandoned the notion of learning Go or learning C++ and this year, I did not make much headway in any language really other than Typescript and C. And while those are fine languages, I figured that I would look into something I could use immediately like Elixir. I also looked at Rust especially now that Rocket came out. I do intend to look back into Go as well mainly because I feel like the confusion surrounding the process of building web applications is gone and there are established frameworks that I can look into.
One of the most intriguing things I find about learning new languages is the avenues it opens up. Elixir is similar to Ruby and there are quite a few languages that are Ruby-like, for instance. And Elixir itself is pretty damned powerful. Rust is the new kid on the block and it can be effectively summarized as “the language you’re itching to try but have no idea what to build with it” and that really connects with me.
I’ve been enjoying making videos on Youtube and recording stuff on Twitch. Obviously, I gave up on Twitch at some point but I’m still excited about making Youtube videos. My goal for next year is to figure out a good cadence in releases and find a quick flow to get my thoughts out there.
Less Social Media
As much fun as Twitter is, it’s a time sink and most of the stuff on there eventually trickles down to me in some form or fashion. I enjoyed following the top developers out there and opening discussions but it’s not the type of socializing.
More Selectiveness and Less Delay
Just like this year, I’d like to get more into the habit of filtering out crap I don’t want to read or watch or learn. It’s incredibly easy to fall into the pit and being overwhelmed by everything around me. I mean, my reading list has 70+ books, my netflix list has 30+ movies, and my TV show backlog has hundreds of episodes to watch.
The other part of it is having less delay between “queueing” and action. I’ve gotten into a good habit on Pocket to delete an item if I haven’t gotten around to reading it within a couple of weeks.
How come I plan to spend so much more time on development? I’m not planning to do that. I’m planning to stop wasting time. Being more selective means that I spend my time on development with a purpose. This year, it really taught me a lesson when I got my 300+ list of articles to read down to about 10. On average, I’d spend about an hour reading pointless stuff almost every day (cumulatively). I don’t plan to stop reading but I do plan to use my time more wisely. Less social media is a part of that, too.
At some point this year, I received a comment criticizing me for having a picture with my daughter in my “about me” section and for discussing achievements unrelated to tech. I’d like to emphasize here that this blog is for me and it’s a personal blog with tech focus. That means that: I write about whatever I want, I get personal, and I post a ton of tech stuff while all of that happens.
- My daughter’s first birthday party
- Just about every single thing my daughter did this year 🙂
- Finding out I’m going to have a second child and it’s going to be a boy!
TV Shows and Movies
- Star Wars: Rogue One
- Dark Matter
- Star Wars: Rebels tv show
- Yu-Gi-Oh! (I had a fun time rewatching the entire series)
- Bad History
- Career Day
- Front-end Happy Hour
- Full Stack Radio
- Myths and Legends
- New Game Plus
- Party of One
- Soft Skills Engineering
- The Changelog
- Writing Excuses
I didn’t read many books this year but here’s what I did read:
- Firebird by Jack McDevitt
- Harry Potter and the Philosopher’s Stone (in Czech)
Yeah, that’s it. Seriously. At least according to my Goodreads. That’s part of the reason why I want to focus on reading more in 2017.
- Working For It by Zhu x Skrillex x They
- Only Getting Younger by Elliphant ft Skrillex
- Pacify Her by Melanie Martinez
- pretty much everything that Grimes posts
- Mind by Skrillex & Duplo feat Kai
- Take U There – Jack U feat Kiesza
- Final Song by MO
- Puzzles by Lenx & Denx vs Andy Bianchini
- Faded by ZHU
As you can tell, I’m a huge Skrillex fan. I should also mention that I gave Dido a revisit and absolutely fell in love with her music all over again.
- Learn more Russian
- Read more books
- Be a great parent
- Write another NaNoWriMo book
- Edit my 2014 NaNoWriMo book
- More Youtube Vlogs
- Less phone
- Better finance management
- Diablo II
- Pokemon Sun
- Kirby’s Dreamland
- Mega man 2
- Final Fantasy XIII (not done yet!)
- Counter Strike: Global Offense
And here’s my continuously updated Throwback Thursday article