web development

Senior engineers might not be so bad

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.

Advertisements

Certainty is a fickle friend

Later on my life, when I look back on this time of starting my job, I imagine I’ll remember a long period of mental haze.  Every day, the rug gets pulled out from under me in a new way, forcing me to adapt my working style to a new variable.  When I think I’ve found the last thing that could break, I inevitably discover a new ‘weakest link’, thus blowing all my earlier assumptions out of the water.

Before I got into software, I worked as a program manager at a mentoring program.  Part of my job was training team members into their roles.  Most of my team members were doing their first job out of college, so I got to play expert, not only teaching them best practices about mentorship, but also how to organize and schedule themselves.  I knew things, and I relished the opportunity to share them with colleagues.  I was a super-hero of information synthesis!

Those days are gone.  Now I only fantasize about knowing things as I dive headfirst into a bottomless pit of bug-wrangling uncertainty.

First it was string disappointment.  Of all of the JavaScript data types, I felt I could most depend on strings, because they were just chstick-man-with-capearacters between quotes.  Then I started writing keyboard shortcuts for a web app, and the browser threw an error because “a” != “a”.  WTF?!!  I had no idea where to go from there, until my colleague suggested that i might be dealing with unloggable unicode characters, wicked invisible entities that live to screw your validations over.  I left that experience feeling that my trust in strings had been misplaced indeed.

Next, my libraries let me down.  Although I painstakingly followed the exact directions of a d3 library, nothing happened on the canvas.  No error thrown either.  Just a whole lot of nothing.  I debugged, tried variations, checked the github issues to see if anyone else had this problem.  Then finally, on inspecting an object, I found that one of the methods in the library’s initialize instructions didn’t actually exist.  Library FAIL.

Finally, Chrome let me down.  After I pushed a big commit, I felt like an engineering superheo until my colleagues informed me that the commit had broken their apps in Chrome.  There was  no small amount of embarrassment on my part as I perused the code, trying to figure out how the changes I made could possibly be causing these errors.

As it turns out, Chrome had saved a JSON draft in local storage that was not compatible with my changes.  A quick localStorage.clear() was all we needed.  (Shouldn’t local storage be cleared automatically when one pulls from a github repo?)  From a new JavaScripter’s perspective, it seems that no good deed goes unpunished: tiny half-assed changes have tiny repercussions, but hard work results in big changes that lead to big, embarrassing errors.

But I’ve got to keep trucking.  I may not be a superhero of information-synthesis anymore, but I have Tom-Haverford-inspired hopes of donning a new cape: the superhero of information-FAILURE-synthesis.  Knowing why something is failing is the first step toward better understanding, which beats blind certainty by a long shot.

Fail early, fail often, fail purposefully: that’s the developer’s credo.

**CAUTION: Approaching Max Frustration**

My day coding today was terrible. Think Alexander and the Terrible, Horrible, No-good, Very Bad Day, but substitute a recurring ‘CANNOT PERFORM FUNCTION ON UNDEFINED’ for the lima beans.

We’ve been working on mongo.db (databases built through objects instead of columns) and using it to build our own wikis. In the course of the day today, I broke everything I worked on: the database, the wiki, another page I worked on.  My breaking streak spanned the entire day, includiError Messagesng sharing an idea during the lecture that ‘broke’ the document we were learning from, hence lecture = over.

And that, my friends, is the coding profession in a nutshell.  The goal is to get a program to work once, then to not ever have to touch it again, because in editing it you will invariably break it AND the 100 other scripts attached to it.  And, as in life, it is important to be able to accept a failure, walk away, and come back with new ideas.  Again.  And again.  And again.  And a-… Can someone throw me a loop function?