DEV Community: Scott Yeatts

The Hireable Unhireables: A Response

Scott Yeatts — Fri, 12 Jul 2019 04:31:37 +0000

This is in response to an excellent post by @vorahsa about how the industry treats people, and how he has even heard his coworkers referencing these beliefs that, if true, would mean they wouldn't hire HIM. He's most definitely NOT unhireable and sounds like an asset to his team.

I Am Unhireable

Jaakko Kangasharju ・ Jul 9 '19

#career #hiring #developer

This was originally a comment on his article, but seeing as my comments tend to be long-form, AND I tend to be shy about making my own posts, I figured this was a great opportunity for a standalone article so I have to start off by thanking him for his.

Much of this is opinion. There will be at least one link to a supporting resource. I can't promise any more than that!

Not all corporations are malicious, just as not all coders are job-hoppers, not all engineers over 40 are stuck in COBOL and not all PhD holders will design a Rube Goldberg machine if left unsupervised. There's also something to be said of the sub-industries in software engineering like medical equipment, banking, insurance and others where many of these negative stereotypes are inverted, but the ones mentioned in the original article are some of the most prevalent that you will hear today.

The headings will reference some of the biases he has seen or heard others talking about. Hopefully it's a solid companion to that article, analyzing some of the reasons for these negative memes in the industry, and why you should never, ever listen to them. Evaluate the person, not the stereotype!

On NOT Staying in the Same Company for Longer Than 2 Years

Working at the same place for a long time is fine, but I think the reason for this particular piece of bad advice is that if you work in one place for a long time and that place is settled into a particular way of doing things, then it limits the variety of approaches you're exposed to.

I can't let this point go by without also mentioning that it is easier to get a raise by moving companies... but I wouldn't suggest that money is all there is to any given company either.

You can also consider if you've done all you can at the company. A friend of mine used this car mechanic analogy:

You're the headlight guy in the shop and you work on one specific car in one specific garage. You've bought the shop all the equipment, you've put in a lot of work. That car is probably as optimized for headlights as it is going to get with you in the shop. It's probably time to move on to a shop that has never had a headlights guy, and let a guy that is into radiators come in behind you to move the project/team forward.

These are valid reasons to leave after a couple of years, but if that shop has new cars coming in everyday, money isn't the primary motivator for you (those people DO exist), you're getting a good variety of experiences, and you feel like you're expanding your skillset in a worthwhile way, then there's no reason for it to be a requirement.

I think a good pattern for a young engineer (for both experience and advancement) would be to move jobs every few years. After you feel very comfortable in your specialization, either start looking for new things to learn and specialize in or start looking for a long-term position. You may never find it, but there does come a time when the revolving door of new jobs starts to wear thin.

If someone reading this has NOT done that, it's definitely not a career-killer, and to disqualify someone on this basis doesn't make any real business sense. New hires are expensive. Having someone in it with you for the long haul is a huge benefit to a company, but make sure you push your workplace to keep finding better solutions and don't fall into the trap of "the way we've always done it".

On Passion... The Greater of Two Evils

When it comes to the general topic of "passion" (Github, when you learned to program, how much you program in your off-time) there are two possibilities I've found when faced with a company or hiring manager that actually believes in this, and neither makes me want to work for them.

Either it's a dog-whistle that they are looking for someone who will work after-hours for no additional pay because they are "so interested in the problem" OR they haven't really thought about what that line of inquiry really means. It's just parroting what they've heard other people say in interviews because it's the "right" question. Neither is a very attractive look, and this approach is a signpost for me as the interviewee that I need to start looking for other red-flags (Though, in fairness to interviewers everywhere, it's not a disqualifier by itself).

Specifically with Github, my immediate response is "I was writing code with a wife, son, and a lawn to mow before Github existed, and none of my jobs have required me to commit in an open-source repo", and I've never had trouble with that answer in an interview. For a younger person, that can easily be modified to "I've never really worked in an open-source job, so I haven't built a lot on Github." If you're being really cheeky, try adding a "Will we be building open-source software on this team?" to the end of it, if it isn't too obvious what the answer is!

On Ageism... The Greater of Two... wait... they're both Evil, OK?

Ageism is another place where it's a real issue for the victims, and not even the actual problem it's perpetrators would have you believe. It's more about how much the company can push you to give them more work for less money than it is your age.

While I have run into a few older engineers who learned to program one way many years ago and don't want to learn more (which is the reason ageists give to justify why they want younger engineers, if they even own up to it, instead of hiding behind phrases like "overqualified" for legal reasons) I've met FAR more who are still keeping their skills up-to-date and have decades of experience that would be an asset to any team.

Unfortunately (according to the companies who do this) those "overqualified" engineers have also built lives and interests outside of work (the aforementioned "partner/children/lawn/insert hobby here" issue) and are far more likely to work the hours they are paid to work and go about their lives in their free time. An employer that uses this logic compares that to a new grad right out of University who has fewer home responsibilities, more free time, and an eagerness to "prove" themselves, and chooses the more (seemingly) profitable option, ignoring the benefit that experience brings in favor of the more immediate perceived cost/benefit.

On the Combination of the Two (Two Bad Tastes That Taste Terrible Together)

This employer believes that weeks of crunch time are met with fewer complaints if the person has fewer responsibilities outside of work and the employee thinks they "owe" the extra time to the company that "gave them their shot". This is terribly unfair to the younger engineers. It trains them that this is just "how it is" in the industry, and that their free time is unimportant. You have to have downtime, and you have to have time to build the life that a more nefarious company will resent you having once you get to a "certain age".

Crunch time all the time is a failure of the organization. Not your skill or the skill of those around you.

This is also where I have to mention a personal pet-peeve. Take-home coding tests. I put this under a combination of the two, because while I do feel it disproportionately impacts older workers (Again with the "partner/children/chores" issue), it's just as much a test to find out how much of your free time you will spend on work tasks as it is a test of your ability.

I don't do well on them, and I refuse to take them anymore.

That has less to do with my ability as an engineer and more to do with this ("You just black-holed me" is a joke in our house).

My "free time" isn't really mine and hasn't been for over a decade. It's my wife's. It's my son's. If you don't have equivalent relationships, your free time belongs to your comic books, or your mountain climbing, or your volunteering, or your video games. Your free time does not belong to a company that isn't even going to compensate you for the "two hour" test that actually takes two days of every spare moment you can scrape together.

According to some sources, I'm one of the oldest Millennials. Or the youngest Gen-X'er. Or the Oregon Trail Generation... it doesn't matter, with this beard I've been asked if I have grandkids before, and I've felt like the "old man" in a LOT of shops (it's even in my profile). "Passion"-bias and ageism haven't started impacting the majority of us in tandem... but pretty soon many of us will start facing it in the workplace, and Gen Z (who are a bigger cohort than any other generation, and starting to graduate college) will be calling us the olds.

Full Disclosure... I never finished the last 12 credits on my Bachelor's

Finally, the anti-academia movement. This one has a lot of roots. Again, the seed of truth in this is rooted in a few negative experiences and plays on some existing biases. The seed is that, while I have worked with some great coders with postgraduate degrees, I've also met a (very) few who were more concerned with extremely complex (one might say complicated, or even accidentally complex) solutions to very simple problems. In these situations, many in this small set hadn't actually spent as much time writing code as they had writing theses, and it shows in their ability. This is not all, or even a majority of the academic population (I currently work with some highly educated engineers who are great, and this post was inspired by a PhD!), but it's where this bias comes from.

On the business-side, higher qualifications means higher compensation. The VAST majority of programming work out there doesn't deal with optimizing compilers, programming gates in the processor, or require a detailed knowledge of how data packets are sent across networks. It's generally code-plumbing. Plumbing is a very hard field, it takes a lot of skill and knowledge of things like building codes, local ordinances, technical knowledge about how fluid dynamics in a system work and a million other things I wouldn't pretend to know, but it is a skilled trade and is well compensated for that skill. That skill comes from hands-on experience over years of practice, not from studying advanced fluid dynamics to understand how supernovae in a vacuum spread or how the atmosphere moves to create various weather patterns. As a business, I wouldn't hire a Physics PhD with a specialization in Fluid Mechanics to build the plumbing in my building, and the same can be said for implementing a code-base.

If that PhD holder had written their thesis on plumbing, spent a career designing and implementing plumbing and had demonstrable skill in that field it's absolutely not a disqualifying criteria either. If the intrinsic complexity of my problem requires someone with a PhD to solve it then I need someone with a PhD. NASA can't hire plumbers for the work they do. In these situations this is an attractive and beneficial trait to have on your team, worth every penny of premium paid for the advanced degree. But very few companies are NASA.

How Does This Impact the Real World (Not Google)?

Most of these biases are specifically geared to get the maximum benefit for the company at all costs. Unfortunately these ideas have been seeded into the community from interviews and experiences with very large companies and the cargo-cult following people have about emulating them. That community includes hiring managers who want to build their engineering team into a Google-like powerhouse (but only have the headcount for five people).

These gigantic companies have more applicants than they can hire and are able to pick and choose who to hire and not hire. They are also a very large source of jobs, but a very small percentage in the total number of companies looking to hire engineers. Trying to emulate them at a startup or smaller company unnaturally limits your hiring pool and those are the places where I want to work (so it works out well for me if those places are less discriminatory).

There are fewer engineers than jobs worldwide, and certain markets are starved for talent while others are flooded. If you have good interviewing and social skills, combined with good technical ability, then no one is unhireable right now. Maybe you won't end up at Google... but you might be able to build something great.

IE 11, the Modern Web, and You (Featuring StencilJS)

Scott Yeatts — Sat, 15 Sep 2018 21:24:13 +0000

This article has an alternate title: How I learned that enterprise users are people too.

IE11 Is the Worst

So. IE11 is the worst. No one should support it any more and it should be shunned from existence (except for those specific apps that depend on it and are critical to your operations. Your company should have started the process of getting out of that mess 3 years ago... but we all know how that goes).

I've been really excited about my project at work because I was trying out web components with Stenciljs from the Ionic team. It works well in every browser I've tested... except IE11 (No, I am not surprised by this.... more surprised by the support requirement that I discovered after I started working on POCs and said "Let's try it... I'm sure we can write/use polyfills where needed").

Bring the Ruckus

Yesterday I found one issue where IE11 doesn't know what CSS.supports() is. I fixed that (with a little pain) and moved on. It was actually in a dependency so I could have just pulled out the dependency, written it myself and moved on, but I'm only about a week into the project, so I'm still in learning mode.

Playing around with it today I found Symbol being referenced in my ES5 build. Symbol is ES6. TypeScript hasn't fully implemented it, but every single browser HAS except IE11 which is, of course, 0% implementation. It will never be implemented because IE11 is a dead browser save for some security updates.

As an aside, the error that was thrown? It came from a polyfill. Let that sink in. IE11 is starting to break when you try to polyfill it. It hasn't received a new feature in more than 3 years. That's the situation we've created by using IE11 in 2018... it's the equivalent of using Netscape Navigator in 2011)

I'm thinking about rolling back to using a framework, because I know I'm just going to keep finding these problems as I build more and more. This is.... frustrating to say the least.

Seriously, try Stencil.

Full disclosure, Stencil is in pre-1.0 mode and has only been out for a little over a year. It's a tool, not something that will be deployed to end-users, so I'm personally OK with this. You'll need to consult your own conscience and your mileage may vary.

I looked at Polymer, Skate and Svelte... but all of them were more abstracted than I wanted and all of them are essentially frameworks of some kind. I wanted to get as close to building actual Vanilla JS web components (And I actually tried a POC of exactly that) with the smallest framework-style coupling I could get. Stencil won the day.

In Stencil, I can build a search component that has an endpoint property and is invoked in HTML like:

<search-component api="/some/url/string"></search-component>

Then I can npm run build a dist folder with NO framework code, only Vanilla JavaScript. I cannpm pack that into a tarball, publish it to npm, keep it in a local registry, or go the low-tech, bad practice, unscalable, get-it-off-the-ground route and just store those in a directory in the repo and npm install <tarball location> (Seriously, don't do that for production code... please?).

After that it's a simple import 'search-component' or appropriate syntax, and I can start using it anywhere else. I could just put a script tag on index.html and call it with no other JavaScript on the page.

The best part? These are composable components. Do you need to write 3 components to make up one feature? You can pack them all together and only have one import.

What Do We Have to Lose?

What are we losing because of support for IE11?

Vanilla Shadow DOM v1 and Custom Elements v1 which gives us total encapsulation of every single component
Access to the ionic v4 library of web-components (Also in Beta), built with Stencil (Even though I'm a long-time AngularJS/Angular guy I've never used or thought about using Ionic, but they've gotten me super excited about this one... prebuilt components and/or examples of how to build them? Yes, please.)
Vanilla JS implementation that can live forever in a tarball or on npm until W3C deprecates it. No more versioning of dependencies at pipeline build time, no more worrying about breaking changes in a dependency of a dependency, no more feeling like I need to proxy npm just in case a package is removed from the registry and my build breaks. None of that. I can use that same artifact for YEARS until I see a need to work on it again. Then I can update JUST that one component and NOTHING else will be impacted. This gets so granular that in Ionic, their grid system is down to the col level.... they have a component for columns in a responsive grid. That's just cool.
The ability to get ahead of the technology curve instead of chasing Angular/Vue/React updates every 6 months.
Easy PWA creation (Literally they have a PWA builder, or you can just define the Service Worker file in the config)
Easy-ish Native conversion with (again) Ionic, whether I initially build in Ionic or not. Routes and Layouts are components. Just spin up an ionic or insert web to native framework here instance and plug and play.(Warning: I have never done this, so this could be mindless marketing propoganda that I'm parroting.... but it looks easy...ish... but we all know what happens when someone says "It should be easy, right?")
Built-in polyfills for the things that don't work per browser. Most of this is supported in 80% of all browsers. Unfortunately the POLYFILL is what broke IE11. Firefox will have support for Shadow DOM and Custom Elements v1 in 63 which is the next release at the time of this writing, but I don't want to manage the polyfills for all the other browsers myself.
Using a COMPILER vs a FRAMEWORK. No more downloading tons of code just to use 1/10 of the functionality. No Stencil code is sent to the browser in any way. This makes me very happy. With IE11 in the picture, this is not an option.
The ability to get rid of Stencil two months or two years from now once Web Components are fully supported. All that it takes is for Firefox to release 63 and Edge to take it out of 'Consideration' and implement it... notice a pattern there? Take a look at the canIuse page for Custom Elements v1 and Shadow DOM v1. Once those are supported we can just directly write custom components in Vanilla JS. Now I'm going to take a second and point out that this next sentence is very important, having been through the AngularJS to Angular upgrade on a very large application. WE DON'T HAVE TO GO BACK AND CONVERT THE OLD STENCIL COMPONENTS. They will always be there and we can do lazy upgrades whenever we want, or just continue using Stencil for those components only. We give up this flexibility in order to support IE11.
Anywhere from 10-30% of our development time (stat is pulled from thin air and anecdotal experience) because no matter what tech we use other than (maybe) JQuery, we WILL run into 'doesn't work on IE11' problems.

What Did I Just Do?

I think I just wrote the argument convincing ME to fight for dropping IE11 support and telling anyone still using it to use a modern browser... we'll see. I started this post in despair, but I think these are the arguments that I'm bringing to the team on Monday. We're making the assumption that our employees are using browsers in a different ratio from the worldwide average... Why? Do we think our employees are less intelligent or less tech-savvy than the average and haven't downloaded Chrome or Firefox, happily chugging away using an application that probably throws more and more strange errors every day? Nope. There's at least 2.66% of people still on IE generally. I'd guess it could go as high as 15% inside a company if we account for people that don't like to download outside applications to their work computer, as well as the technically inept. I have NO problem telling those users to go download a real browser. Hell, I'll do it for them!

But hey, If it doesn't work out and I start spinning up a Vue application instead, at least I'm not being forced to use TypeScript, amirite?

Another engineer asked me for feedback...

Scott Yeatts — Tue, 26 Jun 2018 05:21:50 +0000

Another engineer asked me for feedback on their performance. I wrote a few things down and then re-read it and realized this could apply to almost anyone. What follows is the advice I gave them. Names and technologies have been changed for their own protection...

What am I doing wrong?

I tend to think positively, which means I can’t tell you what you're doing "wrong" necessarily, but I can tell you some things I’d like you to look at and think about as you work on our application. These are just things I’ve noticed that I think could help make you an even better software engineer.

I know you’ve been writing code for X years, but always be learning!

Where we're going, we don't need ROADS...

Think about the future of the code you’re writing. Don’t just go with the first idea that you have! The worst way to write code is to sit down and start writing and trying to get it done as fast as possible. Think about what the simplest solution would be, and try to implement that. Here are a few things that help me:

1) Be open to refactoring.

2) How can we make sure another engineer (especially an inexperienced one) will understand it, even years from now?

3) What is the least you could do? This isn't 'Code Golf' where the person with the lowest number of changes or lines of code wins, rather it's deciding "what is the easiest solution that will satisfy the requirements to the current problem, but doesn't add technical debt to be fixed later?"

Study (and do it on company time, too!)

Study everyone’s code and every pull request. You have a little bit of a disadvantage coming from X years of Technology J into a Technology K environment. Things that are written a certain way in Tech J are very different in Tech K.

Take a look at our primary programming paradigm. It’s what we TRY to do, and we fail at it.... a lot. Our code tends to be more Functional in the front-end, but we tend to mix in more Object Oriented concepts in the back-end (which you're probably familiar with from Tech J). We use all three paradigms in the application, and it's best to understand them all. I promise you, in the real world you will find and write Procedural code. You might not realize it, and something or someone might even tell you that you should feel bad for doing it, but if you understand why you use each paradigm, and can justify your code, then there's no problem (usually)!

Be familiar with modular code and separation of concerns. We want to make sure that we don’t introduce dependencies between parents and children. Sometimes it’s unavoidable, but we tend to try and avoid it (If it's going to take three days to add that next level of abstraction, the cost/benefit might not be there!). We want every front-end component and every back-end service to be able to live on its own anywhere, inside or out of the application.

Be innovative. I know it seems like I’m trying to get you to write code in a certain way (and in some cases I am!) but if you see a better way to do something, bring it up! If you want to talk about something, send us an email, schedule a meeting or catch us when we’re all online at the same time. Be open to the fact that we MIGHT not use your suggestion, but know that it’s appreciated!

Teamwork Makes the Dream Work

Study some more! We’re using some older frameworks, so it might be harder to make sure you’re using the right online resources. Ask your co-workers if there’s something you don’t understand or you think there might be a better way. If you work near to each other, try out ideas on them before you put it in the code (They should do this with you, too).

Our QA Engineer and I Skype each-other all day long. Even though he doesn’t write a lot of application code, he helps me to talk out a solution before I try and implement it, so I can avoid realizing after three or four hours of work that my solution might have an odd edge-case, and it helps him to understand my thinking when he goes to test it.

Check Yourself Before You Wreck... nothing, because that's what source control is for.

Depend on your teammates (me included) and question everything (especially the code you write). Make sure that you have reviewed and tested your code more than anyone else, and code-review your own code immediately after you open a Pull Request. It can help you to put clarifying comments where you think we might have questions AND I have caught more bugs than I can count in my own work by code reviewing it myself! If you don’t think you would have understood the code when you first started as a developer, then it might be worth looking at for a refactor. I refactor my code many times before I say it’s done.

But this one goes up to 11... OR They've Gone PLAID

Speed is not the goal, it’s the result. When I was in the Army we had a saying: "Slow is smooth and smooth is fast". It means that if you take your time, practice, and make sure that you do something the right way every time, eventually it will become an easy thing to do. Once it becomes easy to do it the right way every time, then you will automatically get faster at it.

The same applies for writing code. Don’t try and rush to get to the end of a story just so you can say you finished it. That will cause a lot of code review, bugs might be found and you’ll end up doing rewrites. Take your time to make sure it’s right and test it over and over again. Question your solution over and over again, as you write it and before you say it’s done. That way, when it goes to code review and testing it will fly right through.

Code Review: It's What's for Breakfast... Lunch... and Dinner

Last note: Code review! I want you (and everyone else in the team!) to be more active in code review. One of the most important things to know about this team is that no one "owns" the code. The TEAM owns the code.

If you tell me you see a problem with my code, I will discuss it with you. If you don’t understand the context of my code, I’ll see if I can simplify it. If you think another engineer could have written a better variable name, or a simpler function, tell them, and don’t feel like anyone will be offended or upset by your comments!

Code review is the time for the whole team to make what one developer wrote better before it goes into production, and no one writes perfect code!

Insert Agile framework name here's biggest benefit is that it brings conflict to the surface so we can address it early. Conflict doesn’t mean we get angry at each other, it just means we can discuss differing opinions to make the code better. I don’t mind having different opinions. Occasionally we won’t agree, and that’s why we bring the whole team to the issue. Because everything we do in the code is a team effort! Without a team, we're each just individual developers, trying to write more code than we have time for, and probably creating more technical debt than we could ever fix.

If you don't know who Martin Fowler is, find out. Design patterns and Code smells are good to know, but don't memorize them. Knowing they exist, and where to look them up will serve you well.

If you don't know who Fred Brooks is, find out. "The Mythical Man Month" may not apply as much to the average software development team of today, but the lessons he learned in the 1970's are just as relevant today.