Menu

javascript

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.

To date, the crocodile has been my go-to emoji for expressing rage. For example:

This lady with weird pants almost hit me with her bike this morning on Broadway.

My coworker called a meeting and didn’t even bother to show up.

Someone else took the last swedish fish from the snack jar.

But this week, my emoji needs reached a whole new level. I was trying to get final specs on a new feature, into which I had already poured a number of hours. After a lot of unhelpful answers over slack from the people who were supposed to be planning the feature, I got a final message:

“Hey don’t worry about this feature too much. Once you make it we can have people try it out and then we can always just roll it back.”

Irritating exchanges aside, this is one of the things that has been hard to get used to in software — the idea that everything I do can and will be scrapped, sometimes by me, sometimes the next day, often without a trace of my original labors.

In past jobs for government contractors, nonprofits, and universities, everything I did led somewhere. My edits were incorporated, my proposals submitted. Redoing something from scratch was a rarity– if it was bad enough to need redoing, the boss would probably give it to someone else anyway.

Fast-forward to today: rewriting code galls me. It says to me that I’m just a code monkey who is that much closer to death, that if people respected my time this wouldn’t happen — even though I’m just as often to blame for mistakes. Every minute I spend redoing something feels like further confirmation of my own worthlessness. “I may as well not even be here,” I think to myself bitterly as I start cherry-picking commits.

And yet. My boss offered some encouraging feedback in my annual review last month. After telling me how happy they are to have me as part of the team for 2016, he offered some constructive feedback. He encouraged me to be patient and flexible around redoing things. (He knows how bent out of shape I get about this stuff, having received his fair share of.) He reminded me that reworking is part of the software development process, part of life, and it’s not really a sign of personal shortcoming. In fact, refusing to rework a feature or to improve it would be the shortcoming.

I still hate redoing things — that hasn’t changed — but I’m starting to see this struggle as an opportunity to practice patience with my sometimes frustrating reality. No software, not even my own AHEM flawless code, lasts forever. Heck, in a few years, we’ll scrap this entire code base and rewrite from scratch using the fad JS framework of 2020. Moreover, even a task as mundane as refactoring can offer the opportunity to for reflection and even — dare I say — innovation.

I’ve talked before about my ambivalence toward senior engineers. As members of the department with 4+ years’ experience, senior engineers often come across as know-it-alls, eager to criticize whatever you do before you’ve even had time to explain it. No matter how hard you work, how many annoying little bugs you fix, how many features you contribute of your own initiative, in the end nothing you do impresses or surprises them, because they could do your job better and faster anyway.

It’s easy to resent senior engineers — people who are significantly younger and less organized than I am but make significantly more $$ (because, let’s face it, they are significantly more skilled than I am) — but I’ve seen some great sides of senior engineers over the past few months that have softened my critiques.

One of these glimpses happened a few weeks ago. I was having a conversation with my senior engineer friend Brent about how overwhelmed I feel about next steps in learning computer science — I want to take a couple of classes, but all of them seem to require Python. After the year-long slog that was learning JS basics, I lamented, how could I commit the time to learn Python?

At this point, my stereotypical senior engineer would have been like, “Yeah, it’s probably out of your reach. I program fluently in all languages, and 99% of them are so much more better than Python anyway. Let me further offer some choice critiques of OOP that only I have thought of.” And then I would have gone back to my downtrodden and discouraged state.

But Brent is not your stereotypical senior engineer. He took a breath, and said, “Yeah, but you know, once you’ve learned one language, they’re really not that hard to pick up. I wouldn’t let that stop you.”

In that moment, I felt a newfound capability as the whole world of programming opened up to me. My thoughts raced: Is it possible that learning Python — learning any language — might not be such a big deal? What if I can do it without much fuss? What if I can learn anything I need to learn?

…

Since that conversation, I’ve been devouring the Python.org tutorial and even started a Python-based Data Structures course! Brent was right — it’s really not that difficult to learn a new language, and the time investment is so much lower than it was for my first language.

But my bigger takeaway from this experience is about reserving judgement until I’ve really given something a good try. Python terrified me at first because I had it in my head that learning it would be a huge time sink. It continued to loom over me until I tried it out. Likewise, senior engineers — who I’d all but written off after a few terrible experiences — turned out to be not all bad and maybe even a little bit good. It’s all a matter of being open to new experiences and not letting pre-conceived notions get the better of me.