DEV Community: Alira Coffman

Cross Training On Teams

Alira Coffman — Fri, 31 Jul 2020 05:22:30 +0000

Like a sports team...

Most teams that I have interacted with or been a part of include a lot of moving parts and specialized individuals. Like a sports team, each person had a role to play. Teams that I have worked with/on have been comprised of the following:

QA Analyst
UI/UX Designer
Team Lead Engineer
Front End Engineer
Full Stack Engineer

Now, this is not always the make up of a product team, but it will give us a start to explain my point.

Explanation of individuals roles.

Lets introduce our fictional team!
Ana - is the QA Analyst. Their role is to make sure products that are moving to production are tested and functional.
Will - is the UI/UX Designer. Their role is to handle the design and user interaction of the product.
Ronan- is the team lead engineer. Their role is to assign and plan work, as well as assist in full stack engineering tasks
Christy - is the Front End Engineer. Their role is to implement the UI/UX design, and anything the user can see and interact with.
Eden - is the Full Stack Engineer. Their role is to assist with the front end implementation, but also the any back end technologies that are needed. They may create database structures, or write APIs.

What is cross-training?

Cross-training is training an individual on another individuals tasks. Our fictional team above lists each individuals brief specialty. An example of Cross Training would be if Will knew how to do Ana user testing task.

Why should we cross-train on our engineering teams?

Just like athletes should be well rounded, and cross train through a couple of different sports. Through cross training, engineering teams can benefit in efficiency, collaboration, agility, and even employee sustainability. Now, cross training does not automatically mean mastery, and an individuals skill set and career goals should be kept in mind.

A good example of cross training is the following:
Will, our UI/UX designer, has a functional understanding of the front end development limitations. Will may not be able to code out their wonderful layouts to the extent that Christy can, but they should understand what can and cannot be done, and technology standards.

Christy, Eden, and Ronan could have an understanding of process Ana does to test the product. This can help Ana during the testing process, if the engineers know what and how Ana is testing, limiting the amount of bugs and change cycles the product needs to go through.

Ronan, our lead engineer, knows that Christy is hoping to become a team lead one day. To help them reach their goals, Ronan may train Christy on leading scrums or managing peoples work load.

How to cross train your team?

There are many ways to cross train your team, it can happen naturally through constant team work, or it can happen through organized interactions.
Suggestions:

Brown Bag Presentations - Have one of your team members show something they have found or created. Give space for team members to ask questions or give feedback.
Training Sessions - They are great for team members trying to take on more responsibility within the team. Have them plan and lead a team training session that introduces the basics of something within their specialty.
Encourage individuals to learn new skills, and learn from each other.

It is not as !important as you think

Alira Coffman — Fri, 03 Jul 2020 01:38:57 +0000

A couple of weeks ago, I was handed a pre-existing project to handle its maintenance and continued support, which has thus become a bigger issue than its worth. A developer on my team came to me and had said "We have to rewrite this. I cannot fix anything without breaking 20 other things." From my experience, developers first desire is to rewrite code that is foreign, old to them, or overcomplicated. So, we had to find the root of the problem in order to find out if we truly needed to go through all that trouble of refactoring a major project for a couple stylistic changes? The developers main reason to complain and want to refactor was justified, at least from an operations perspective: the site used !important 2,033 times. Yes, you read that right.

What is !important?

In short, !important overrides CSS natural specificity, overruling the other possible style selections for that element, making the web pay attention and ignore the others.

Why should I care about CSS Specificity? If it works, it works.

Welll........ does it really work?
In the project I described in the beginning, sales was very happy the project got out in a timely manner, as they were unaware of what was truly happening in the code. One could argue, the site worked. Whats the big deal? Which, they would be right in a way. But months later when developers who did not originally support the code had to make adjustments, it became overly complicated. Specificity gives code consistency by maintaining a standard of weight that is applied to the CSS declaration. When that standard is ignored constantly, the code is no longer consistent, making it hard to maintain, scale, and control. By using !important everywhere, you are pulling the blinds down and ignoring the fire. Eventually, the room you are in will succumb to the fire.

So I should never use !important then?

In tech, I try to avoid the use of the term never. There is possible good done with !important, when applied carefully and sparingly. Some examples of cases where it might be applicable to use:

Overriding style changes that created from JS
Overriding those annoying third-party libraries styles
When it may break multiple things on the website by not using it.

These are just some examples I have seen in my day-to-day job, and it is not a catch-all example listing, each situation is unique. When deciding to use !important, its best to go through all your other options first. Can the structure be adjusted to be reusable? Would it be easier for this element to have its own unique identifier? Can I write this better to be more explanatory and robust? By going down your self imposed list of checkboxes before taking the easy way out, you are sparing future developers from having to put out your fires.

Keep in mind next time you are going to use !important, it is probably not as !important as you think!

To The Young Female Software Engineer With Her First Job Offer

Alira Coffman — Mon, 29 Jun 2020 14:34:53 +0000

First and most important: Congratulations! You have put in the effort, struggled through terrible professors, long nights, and might have a slight addiction to coffee. But you made it!
While in my sophomore year of college, I had the opportunity to become a QA Analyst at a small up and coming Mobile Application Company. Now, as a senior in college, I am now a Lead Software Engineer at the same company. I transitioned to a lead development position very quickly which is not always the case, but I have been forced to learn how to adapt. Here is some unsolicited advice you may not have seen while nervously awaiting your big first day:

1. It is okay to be feminine.

Looking feminine is not for everyone, but if it is something that makes you comfortable, confident, and most important happy: GO FOR IT! There is a preconceived notion in this industry on how engineers, especially female engineers should look. But if wearing a skirt or doing your make up makes you happy, do it! If you are more of a band t-shirt and jeans, rock it! Be yourself, even if it challenges the ‘status quo’ (Look into the campaign #ilooklikeanengineer)

2. You should be heard

Software engineering is a team sport. A team should be based in mutual respect, where people are comfortable sharing their well thought out opinions and they know the others will actively listen. But during many social experiments, researchers still find that women are interrupted more than their male counterparts. From my experience, this is still the case in Engineering, from classrooms to meeting rooms. Remember, you should be heard. Your opinion has value.

3. Take risks

Risk is everywhere in this industry: Risks in deploying code, to making certain calls on storage levels, to choosing if you work for a start up or an already successful and large company. Be impressive.

4. Don’t weaken your own ideas.

Ditch the filler language! It does nothing to strengthen our ideas, in fact it starts to weaken them. If I tell you “I think xyz idea will maybe work better that ABC”, it shows hesitation and that I have not convinced myself of my idea. But if I say “XYZ will work better than ABC because….”. It shows confidence and assurance that will make it easier for you to keep peoples attention and persuade them to your ideas easier.

I wish I could give you all the advice you would possibly need in your career. But I will leave you with those main important four, because if you are anything like me, this is one of ten articles on the subject you will be looking at tonight! Good Luck!