Menu

I recently returned from Angular Conf 2017, an annual event that takes place in Salt Lake City. It was well-organized and incredibly exciting. There was angular swag, custom-designed angular graphics and banners, an angular rap with nerds onstage doing *terrible* attempts at dancing! All in all, it was an A+ experience.

My favorite workshop covered the Angular 4 compiler. In an hour, we picked the compilation process apart to see exactly how it works, and even turned the compiler off while we manually compiled some simple examples.

One thing that was missing from the conference was any mention whatsoever of angular 1. Those familiar with the background of angularJS know that the switch to angular 2.0 eight months ago ushered in a whole new paradigm that is not backwards compatible. And while angular 2 is absolutely a better, faster framework, early adopters of angular are stuck in a state of limbo. Many of us have just finished writing entire production applications using Angular 1.x with thousands of LOC. And while there are tools to help teams upgrade, most teams end up having to rewrite large portions of their applications. It is a costly process.

I wanted some mention of us, the invisible people stuck in a very difficult position due to the angular development team’s lack of foresight. Based on the people I talked to at the conference, I’d guess at least 40% of us are in exactly that position. Yes, we want to see the newest, latest, and greatest updates, but we also want some excitement around what we’re building every day, and some acknowledgement of the bind we’re in for the future. Yet there was not even one talk or workshop acknowledging that angular 1 even still exists.

Taking this up with the angular team during a Q&A yielded the condescending answer: “Well, you just need to upgrade.” They forget that not every company has unlimited resources like google does. It seems they are developing for the most elite teams that have developer time to spare.

(Relatedly, another piece of advice from the angular team: update your angular package every 2 weeks to get every miniscule versioning change. It’s a good idea in theory, but most startups don’t have engineers just sitting around waiting to read release notes and dependency changes every two weeks.)

I feel invisible to them, like my work doesn’t matter. As an early adopter and early angular evangelist, I feel almost punished for adopting early, as our eager Angular 1 development landed my company in the legacy code position we are now in. I love angular, but I’d love to work on a framework where I feel respected and acknowledged by the team developing it, instead of being ignored like last week’s lemonade.

I wanted to do a quick check-in to log what I learned in my second year of full-time work as an engineer.

My first year was mostly focused around JavaScript, CSS (SASS), HTML5, and getting familiar with some of the tools that support my work (transpiling, compiling, uglifying, module building, browser dev tools, github, Sublime Text).

This year has brought major changes. As my company moves into a microservice architecture and doubles our engineering team, I’ve needed to grow as well. This year I became a part-time nodeJS developer, learning a bunch of the tools that come with that — docker, async unit testing (jasmine), MYSQL queries. I also dabble in PHP when the need arises.

Instead of being a front-end person on a large team, I’m now the only front-end person on a team of 2 engineers, so if I don’t know how to do something, I have to figure it out.

The biggest change is just this feeling of confidence. The number of unknowns has gone down so much that there is no longer a nebulous cloud of questions around every bug. Now I can systematically check through every possibility (environment, settings, versioning, error in current application, error in outside application) to hunt down the root cause.

Interested to see where I’ll be a year from now. I’m reading up to become much proficient with the shell and to keep growing my SQL ninja skills. I’m creating a list for my team of some best practices we can adopt that will make our microservices less cumbersome to test.

I just realized that this month is the 2-year anniversary of starting school at Fullstack. I’ve been programming full-time ever since, and knock on wood, haven’t gotten sick of it yet!

The reason I haven’t posted in a while is because I have been using every spare brain-watt on new work projects. Like most dev shops, we are crazy under-staffed. The plus-side of this is that I’ve gotten to get my hands into so many new projects. Earlier this spring, we decided to build nodeJS microservices for some 3rd-party integrations, and I got to build one of them!

And when our in-house d3 wrapper needed to be expanded to include a new kind of chart, as well as adapted to some new data, guess who got tapped?

Needless to say, my emotions have been all over the place. I spent a few weeks out of my mind with the overload of learning new things that felt way over my head. Async unit testing? SVG re-rendering? Some nights I went home thinking, “At what point are they going to realize that I am not capable of doing this and should just be left doing HTML forms for the rest of my days?” And then somehow, impossibly, I would figure out the next step.

Other nights I went home and thought, “Wow. I am really doing this.” But usually it was just trying to figure out what to spread on my toast before numbing my mind with 30 Rock and crawling into bed. (Literal crawling, because my room barely fits my full-size bed.) And now, the wonderful knowledge that my microservice will be deployed to production next week.

All these back-and-forths, these crushing doubts followed by breakthroughs (most of the time) or the mundane humiliation of needing help (also pretty often) — this is all part of the package you sign on for when you get into software. Or you are a cyborg who has no need to waste time on doubts (or blogs) as you are finishing up your cure for cancer app as we speak.

If I could go back 2 years and decide whether to take this stressful, sleep-stealing, mind-altering journey again, would I? Hell yes! And maybe with a little less ‘can I even do this?’ angst next time. But you know, probably still a lot of angst.