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 Screen Shot 2014-03-06 at 9.13.36 PMtarget 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.

Rethinking the Traditional Topbar Menu

I posted recently about my efforts to convert a quiz app project from class into my own MEAN-stack REST-ful website.  A big part of this project was adding features common to a website but not to a class project, like navigation to get from one view to another.

I started the app with a traditional black topbar with my five main views written across it in text.  But my page content is fairly sparse, with lots of white space and minimalist lines.  The topbar felt incredibly heavy, distracting from the content and weighing down the aesthetic.  I started to think about other options.

A number of liabilities present themselves with topbar navigation, including:

  •  The topbar effectively cuts off the viewing space of the screen by 1/2 inch, which is particularly problematic since height is desktop screens’ smaller dimension.
  • In a day of flat ui, a solid topbar competes with the solid content blocks.
  • As the first thing the site visitor sees reading from the top-down, the topbar menu can take away from the wow moment you want someone to have when they visit your site.
  • When the mouse is spending a lot of time on the scrollbar, the topbar navigation system is not always quick to get to.

By contrast, the nav system I settled on — the right-hand vertical bar — allowed me to put the navbar close to the scrollbar and out of the way of the content, so no need to maneuver around the navigation (see screenshot below)!  I chose common icons with tooltips on hover to explain each one.  The hidden tooltip feature allowed me to cover a lot of information with minimal permanent space usage.  When I compared their pixel footprints, my topbar used NINE TIMES as much screen space as my vertical bar — +1 for the vertical bar!  Finally, my vertical bar complemented the overall aesthetic instead of competing with it.

I’d like to see the design dialog re-opened to look at non-traditional options for the navigation that are easy to hide and easy to access.  Here’s my idea.  What’s yours?