My Beef with Angular Conf 2017

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.

Scrapping my work — again

I discovered a new emoji this week: the volcano.  

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.

 

 

How many Jr Engineers does it take to change a lightbulb?

It’s been said that a senior engineer is worth 10 junior engineers, and some days that idea haunts me.

Three months into my first engineering job, it’s tempting to feel no-good when I get stuck on another jasmine test, or screw something up in my git branch yet again.  My more experienced colleagues are faster and better at coding than I am, able to get to the root of a problem in seconds while I’m still desperately console-logging everything in sight.

But lately, I’ve been thinking about things in my job that I’m good at.  Even as the most junior person in the office, and partly because I’m the most junior person, some areas come naturally to me.  Here are a few examples of the things I’ve excelled at so far:

Being an intelligent test user. This is the one skill I’m most proud of.  As a detail-oriented person, I can sniff out a bug like a hound on the trail of a ferret.  As a detail-oriented person, I see technology from the target user’s perspective and easily find areas where s/he might get tripped up.  Over the last three months, I’ve made hundreds of github issues for features and refactors to make our app easier to use.

One recent example: Our ‘dirty’ input text color — dark orange — is so close to red that I kept thinking that my input values were invalid.  Like me, our users won’t realize that the dark orange is for a ‘dirty’ input (with dark orange color mimicking our logo); they will just wonder what they’ve done wrong.

Explaining technical concepts.  I may only know a small fraction of the information that a senior engineer knows, but I can explain that fractional amount in great detail.  This comes in handy when someone on staff needs to learn jasmine or angular.  In fact, I wrote a set of exercises to folks get their sea legs in our angular code base!

Research.  Writing new features is challenging, but a great deal of work happens before the writing starts, in the form of research.  Engineers often put off creating new features because they don’t want to stop everything in order to look up and vet libraries and methods.  With an English / history background, I jump at the chance to do a little research.  By explaining pros and cons of each option to my team, as well as answering their questions, I get our new features off the back burner and into our next release.

Pulse.  As a fairly new JavaScripter, I know all the best engineering podcasts and meetups around the city.  I know the latest information on the MIT Open Courseware and other course offerings.  I make it a point to keep a beat on the cutting-edge libraries so that I can offer these when our team is looking for new solutions.

Back to the original question: Is a senior engineer faster than 10 junior engineers?  Maybe.  But is a senior engineer worth 10 junior engineers?  I’m skeptical.  A senior person brings speed and knowledge, but also brings the baggage of comfort and a single perspective, often overlooking reasons why someone else might get tripped up on her/his UX, or spending hours on tired recruiting methods when s/he could simply contact a couple of key meetup organizers with the job announcement.

Junior engineers may be slow and overly methodical, but we’ve got grit and eagerness on our side.  When it comes down to it, I guess the only thing as good as 10 junior engineers is… well… 10 junior engineers.