DEV Community: Aaron Eiche

Taking counter-questions to interviews

Aaron Eiche — Mon, 05 Aug 2019 17:50:18 +0000

I've been interviewing recently and I'm having typical interview questions thrown at me - mostly not brainteaser type stuff, but the sort of 'Do you know your Javascript?' type questions. I had this thought about bringing my own set of questions to the interview, to see if the interviewing developer could likewise answer questions on the spot.

I was reminded recently that interviews are as much an opportunity to evaluate the company, as it is for the company to evaluate you. While I certainly wouldn't want to make anyone uncomfortable, interviews tend to be lopsided in favor of the interviewer seeking specific answers, and being able to evaluate the knowledge of the interviewer to see how you'd fit into the team is interesting.

Thoughts?

Jack of All Trades, or Master of one?

Aaron Eiche — Fri, 23 Mar 2018 19:30:50 +0000

I got into my current career sort of accidentally. I took over building some web pages for a friend who'd left on a mission for our church, and I kept running into problems I couldn't solve with HTML. So I started to learn PHP. After a few freelance gigs, I realized I could probably do this full time. I found a job with a small company that wasn't just PHP. There was HTML/CSS, and Javascript, and a weird language I can't remember the name of. I learned MySQL interaction. I learned some Apache configuration, and I christened myself a "Full-stack developer".

Over the course of my career, I found myself having to learn more and more technologies, and trying to pick the winners. In my current position I sometimes build web apps, and sometimes am working on embedded system prototypes. I've been with my current company for 4 years now (a bit of an oddity in web development) and as a result my skill set has gotten wider, but shallower. I often wonder if I'm doing myself a disservice in this.

Narrow but deep

A few times in my career, I've tried to really narrow down the work that I do. Sometimes it's been in pursuit of avoiding certain annoyances: There was a time when I wanted to work exclusively in the back-end because I was so sick of dealing with CSS issues between IE and other browsers. At other points I've wanted to spend all my time in the front end because I was so excited about dynamic front-end experiences - like when I first did AJAX loading of data with jQuery, or when I started experimenting with Angular and React.

It can be rewarding to be the specialist in the room regarding a technology, or a practice, and be able to contribute meaningfully to the community regarding that technology. For instance, if you deeply know and understand the way that React works, you're in a position to potentially contribute to the code in a way that a casual user can't.

Going narrow on a technology stack can be a double-edged sword though. I spent many days and nights in Prototype before finding that it had been superseded by JQuery. And I spent many years in jQuery before realizing that it was no longer in-vogue, favoring frameworks like React and Angular.

Wide but shallow

As I mentioned above, in my current job I work all over the place. I've gotten to write Web Applications, low-level C firmware for micro-controllers, skills for the Amazon Echo, C++ for Infotainment applications in vehicles. This was a departure from my previous positions where I was working exclusively on web sites and web apps. I've very much enjoyed the additional opportunities, especially in the realm of embedded work because I enjoy electronics so much. It's also helped with this nagging (but silly) fear that I'm somehow not a "real" developer, because I wasn't writing software in a compiled language*.

Wide but shallow gives you the opportunity to explore ideas and concepts you have in your work environment. This is not available to everyone. I've turned away a number of job opportunities because I was being sought after to work on a company shopping cart, or a shipping technologies. My current job gives me the chance to do a lot of blue-sky exploration. So the more I know, the more likely it is I get to work on something new and interesting.

This of course, also has its downsides. Not being an expert or a "ninja" in a single technology means you might get overlooked when employers are looking for candidates. In my experience working at a job in a particular technology is the best opportunity to go deeper into that technology, because you're otherwise stuck in the position of spending your off-hours time in it. If you don't specialize, you might find yourself switching modes so often that you can't do the deep-dive you want it.

Go with your gut

So what's a developer to do? I think many web developers of old became "Full Stack" developers because there was a need at the time. Web developers weren't as plentiful as they are now, and it was a great way to get yourself on someone's radar. That landscape has changed with a flood of new developers into the industry. I have coworkers who are still early in their software development career, and have expressed to me trepidation in spreading their skill set too thin. The best advice I can give to you is: Don't do anything out of fear. Do your best to stay on top of where you're working, and explore your interests.

*This is a form of impostor syndrome, by the way, and it's important to know that many many people feel it, even those of us who have been in our careers for more than a decade.

Start holding a domain knowledge meeting

Aaron Eiche — Tue, 18 Apr 2017 16:50:24 +0000

Sharing knowledge is important. It's the reason we gather on sites like this. To Try to get a better grasp on the technology that we use, and the concepts that we work with.

This can be really important in terms of our jobs as well. We do a lot of interesting work at the JLR OSTC. As developers we get to work on a wide variety of projects. One week we might be working on server systems, the next we're building websites, prototype UIs, or interface integrations. Because we've got lots of projects going on, it can be hard to share knowledge across a particular domain.

A month or so ago I decided (on a whim) to start a meeting for the JavaScript developers in our office. It's a relatively small group, but I thought it worthwhile to do a little training (which in turn inspired my "JavaScript functions you may have missed" series) and a group code review, just to expose everyone to other people's methods of problem solving, and code interpretation. It also meant we got to have snacks, which is always a welcome treat.

"Please no, not another meeting" is what you might be thinking. I was a little concerned about this sentiment as well, but I found that what this meeting was about made a big difference on how people viewed attending it.

If you don't have something like this, here's my formula: Biweekly (My thinking being that manager won't worry too much about an hour every other week.) hold a meeting for an hour with developers who work in the same domain as you do. Spend 25 minutes on a "learn a thing" segment teaching a programming concept, a language feature, or something else. Spend 25 minutes on a group code review. Talk about what the code does, why it might do that, and how it can be improved. Use your own code, use a team member's (ask permission) or grab some random code from online.
In the last 10 minutes, open the floor to anyone who has questions, or needs help figuring something out.

This kind of meeting accomplishes a few things: It shares knowledge across the team, it builds rapport with team members, and it helps us professionally develop ourselves.

The next time you hold the meeting, give out assignments. Let someone else run the "teach a thing" segment, and ask them to bring something to teach. It doesn't matter much what they teach. This gives them the chance to run a meeting, share their experiences, and learn how to work better with a team. Same with the code review segment. Assign, or ask for volunteers to lead the review portion. This lets people get their code (or someone else's) I'm front of a whole group of people, and from the process in that group atmosphere.

One very important component: this meeting needs to be a comfortable place for folks to share. When you start the meeting, make it very clear that constructive criticism is welcome but mocking, insults, questions of competency, etc are not appropriate - Your office may have an environment of good-humored ribbing or something similar, but I encourage to drop it here. For this meeting to work everyone needs to feel like it's is one worth attending, and that they're going to get something positive out of it.

I hope you find a domain knowledge meeting as valuable as we have. I encourage you to give it a try. If you don't feel senior enough to run it, pop over to your team lead and see if you can get them to organize it. Offer to run one of the segments.

Good luck!

Building systems that don't match your worldview

Aaron Eiche — Fri, 07 Apr 2017 00:35:32 +0000

I wrote a programming article recently that started out describing an example problem: How many girls are in a class? The intention was simply to have a value to filter against. Almost immediately I was struck that, in 2017 there are lots of people who don't identify as male or female.

I tossed this around in my head for a few days, and every time I looked at it I was a little uncomfortable with what I was writing. I'm a straight, middle-class, white man living in America. In a lot of ways things couldn't get much easier for me. Sometimes my world-view paints a picture that we can all have the American dream if we work hard enough. Intellectually, I know that's not true. We don't all get the same opportunities, and we don't all start out the same way. However, in the past I've built systems that better match my worldview.

As developers we wield a tremendous amount of power, usually unbeknownst even to ourselves. We have the power to shape the way the world functions. The way we design our systems can powerfully affect the way that other people can utilize them. Consider the ubiquitous img tag in HTML. Have you ever forgotten to include and alt attribute in it? It can be easy to forget, and you would probably not notice it wasn't there. If you used a screen-reader though, you might be missing an awful lot. According to MDN This attribute defines the alternative text describing the image. This information may provide a screen-reader the ability to describe an image to a sight-impaired individual.

Have you ever thought that you could marginalize an entire group of people? I don't usually feel like I have that kind of power. If you're the one designing the database you might have the power to make that gender field one that has 3 or more enum values, instead of just 2. If you're the one writing the webpage, you might have more power than anyone else to write in the base support for i18n translation. Does your site work for people who have really low bandwidth? What about people who only have mobile devices? What about people who don't have mobile devices?

You may think that in your organization these decisions are made before the project gets to you. "There's no budget for that" or "That hasn't been approved" is an understandable response but as developers I think we have an obligation to take these questions back to "stakeholders", if for no other reason than to ask "have we thought about this?" If they have thought about this, you might be adding your voice to others - strengthening the argument.

Back in 1990 in the US, President Bush(H.W.) signed into law The Americans with Disabilities Act. It made it a legal requirement that buildings accommodate people with disabilities. Buildings had to have wheelchair ramps, and elevators, and braille placards. It didn't affect me as far as I knew (I was quite young), but in 2005 my father suffered a stroke that left him wheelchair bound. Suddenly, I was very grateful for the ADA. My dad was able to get into buildings without someone holding a door, get on a bus without someone having to carry him on, go to the 2nd, 3rd, or 34th floor of a building, without issue. I can say without a doubt that if the ADA hadn't been a law, he could not enjoy the autonomy available to him.

When we sit down to write code, or design systems, if we spend just a little more time considering who might be among our users we can make the world more accessible for more people.

Useful JS functions you aren't using: Array.filter

Aaron Eiche — Tue, 04 Apr 2017 15:53:28 +0000

Suppose you had a list of students in a classroom, and you want to know how many are girls. You might write something like this:

var students = [
  {name:"Davey", gender:"male",age:"10"},
  {name:"Susie", gender:"female",age:"10"}, 
  {name:"Frank", gender:"male", age:"10"},
  {name:"Lindsay", gender:"male", age:"11"},
  {name:"Terry", gender:"female", age:"10"},
  {name:"Melissa", gender:"female", age:"11"}
]

var girlsCount = 0;
for(s = 0; s < students.length; s++){
    if(students[s].gender === "female"){
        girlsCount++;
    }
}

console.log("The Number of girls is: " + girlsCount);
//The Number of girls is: 3

That's a fine, functional way to do it. If you utilize the language features of Javascript, you can save yourself some time. Try Javascript's filter function attached to every array!

var girls = students.filter(function(s){return s.gender === "female" });
console.log("The Number of girls is: " + girls.length);

Filter returns a new array that is a subset of the array you call it on, wherein the callback function returns either true or false. A true value will include that item in the new array. A false value will leave it out. This makes it easy to write filters that can accommodate however simple or complex you need. In our class, lets say we instead want to find all the students that are eleven, and have the letter 'e' in their name. With a filter, we just need to return true if a student object has those two things:

var eAndEleven = students.filter(function(s){return s.name.match(/e/gi) && s.age == 11});
eAndEleven.map(function(s){console.log(s.name)});

We can use the Array.map function to output all those matching students to our console.

Speaking of Array.map, suppose you need to apply some transformations to your array, before you generate a subset of it. Because these methods return new arrays, you can use them chained together:


  students
  .map(function(s){ s.age++; return s})
  .filter(function(s){ return s.age < 12})
  .map(function(s){console.log(s.name)})

This code adds a year to everyone's age, then filters out those who are less than 12, and the final map outputs the filtered array to the console.

Like map, filter allows you to make things more compact and utilizes built-in language features to make your life easier as a developer.

If you're using ES6/ES2015, you can utilize arrow functions to make your code even more compact:

  students
  .map(s=>{ s.age++; return s})
  .filter(s=>{ return s.age < 12})
  .map(s=>{console.log(s.name)})

I got lots of comments on twitter about my first article, Useful JS Functions You Aren't Using: Array.map, which encouraged this as a series, and things to include. Thank you to folks for contributing back, and offering suggestions.

Useful JS functions you aren't using: Array.map

Aaron Eiche — Tue, 28 Mar 2017 22:00:03 +0000

I learned Javascript the hard way: I stumbled into web development and kept on stumbling my way through the stack until I could program competently. Some days I'm still stumbling my way through.

Because of the way I learned, picking up what I needed only when I needed it, I wrote a lot of this kind of thing:

var arr1 = ["Alpha","Beta","Gamma","Delta"];

function aToB(arr){
    for(var i =0 ;i < arr.length; i++) {
        arr2.push(arr[i].replace(/a/gi,"b");
    }
}

var arr2 = aToB(arr1)

The result:

[ 'blphb', 'Betb', 'Gbmmb', 'Deltb' ]

It's fine and it works, but there is a better way. This function takes an array, and replaces


s with

 ```b```

s. Javascript has a built-in method that takes care of the redundant bits for you:

var arr1 = ["Alpha","Beta","Gamma","Delta"];
arr2 = arr1.map(function(a){return a.replace(/a/gi,"b")});






```array.map```

 is a great solution if you need to do some sort of transformation on an array. It can be something like changing all the a's to be b's, or it can be something more useful like parsing sets of data. Consider this function that parses and returns dates :

var dates = ["2017-04-01","2017-04-07","2013-01-22",]

function pDates(a){
for(var i =0; i < a.length; i++){
a[i] = new Date(a[i].split("-"));
}
return a;
}



The results:


```[ Sat Apr 01 2017 00:00:00 GMT-0700 (PDT),
  Fri Apr 07 2017 00:00:00 GMT-0700 (PDT),
  Tue Jan 22 2013 00:00:00 GMT-0800 (PST) ]```




It's a fine function but we can accomplish it more compactly, and without potential pitfalls (like trying to figure out if your iterator is going to miss a key):

dates = dates.map(function(d){
return new Date(d.split("-"))
});



Is it that much of a difference? No, but it gives the same result. If you're familiar with using

 ```map```

 you can save yourself some time and trouble. On top of that it's a lot quicker to _read_ and that's a favor you're doing for the _next_ developer.

If you've not spent the time becoming familiar with some of the native implementations available in the Javascript specification, there's a lot to be gained by perusing and understanding how they work. I recommend spending some time at [MDN](https://developer.mozilla.org/en-US/) perusing the [Javascript reference](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference).

Hi, I'm Aaron Eiche

Aaron Eiche — Wed, 15 Mar 2017 16:23:31 +0000

I have been coding for [number] years.

You can find me on GitHub as aaroneiche

My Blog is at AaronEiche.com

I live in Portland, OR.

I work for Jaguar Land Rover

I mostly program in these languages: Javascript, Python.

I am currently learning more about C++.

Nice to meet you.