We hear stories about engineers being taken advantage of. Surely they aren't the only people to receive such treatment.  There is an impression, however, that this has been the case for some engineers.  Why is that?  Here are some possible reasons why this might be a thing in software engineering.



## Flexible Medium

One of the best parts about software is the flexibility of the medium.  You are programming electrons.  You can make up whatever you can imagine.  This flexibility can also be a liability.

You wouldn't cover a physical bridge with gold, the cost would be too high.  But you can't see the cost as easily in something invisible like software.  Perhaps this is why software engineers are asked to eek out a few more features at the very end of a production cycle.

You wouldn't build a bridge and then open it without a deck on it.  What poor motorists!  James Bond might be ok with his car sub, but everyone else is toast.  But with software, it's easy to cut corners and still deliver something that looks fine on the outside.  Perhaps this is why software engineers are asked to deliver anyway, even if important features are lacking.

## History

It seems there are some markets that are more stereotypical in taking advantage of engineers.  The games industry seems especially wont to burn out its engineers in death marches marking the end of products -- and sometimes the end of relationships.  This might be something related to the publishing cycle of games, a particularly bad ability to estimate complex projects, or just a bad habit of not changing this aspect of this industry.

## Always On

The things that software engineers build are often always on.  The software might be a part of the Internet.  Something on the Internet has global reach.  There will be many users' fingers on the software long after the engineer has gone home for the evening.  Perhaps this is why engineers have their personal lives interrupted by work.  

However, sometimes engineers do this to themselves, forgetting the operational value of what they do.  Their own bad code leads to their own bad experience in production.

## Culture and Demographics

Perhaps there are cultural factors leading to taking advantage of engineers.  Much of this might be reality or falsly based on stereotypes.  If an engineer is a night owl, we can ask him to stay up and finish a task.  Or perhaps we train him to be a nigh owl by just such requests.  

Maybe there's a real or perceived picture of an engineer that is young, single, or a loner.  This might lead to unreasonable asks of engineers to stay in the office working beyond reason, keeping them alone and single, aging under the flourescent lamps of corporate America.  How bleak!

I'm not actually sure why engineers are taken advantage of.  Maybe they aren't any more than anyone else.  Perhaps I just know more engineers than nurses.  Some engineers actually throw themselves under the bus in fits of false heroism.

What do you think?  Are engineers taken advantage of?  Or are we past this?  Or did it ever happen?  What kind of specific environments does it persist in?

Do software engineers get taken advantage of? Why might this be?

Why Engineers Get Taken Advantage Of

We have limits to our learning.  These limits might include mental capacity, emotional readiness, time, or interest.  We have thresholds for how much learning we can handle at a time and quotas for how much we feel we need.  Find your optimal zone for learning and thrive there.



## Learning Thresholds

We can only learn so much at a time.  We have certain capacity and availability.  We require time to digest things.  We need to respect our sleep cycle and absorb learning into long-term memory.  We need to have experiences that occur over time.  We need to be able to focus our interests.

An software engineering organization realizes that it has a threshold when it tries to keep a finite number of technologies in its stack.  It doesn't want endless tech stacks.  There can be a wide spread and a lot to learn.  Given contextual constraints, it might be difficult to learn so many things in tandem.  There are mitigations for this, such as specialization.  There's another which is to learn things serially.  For example, if an org were to get its ops stack well-understood by a dev team, that dev team might have extra capacity below its threshold to then be amenible to learning a new dev stack.  We make learning new things easier when there aren't as many other required things to learn at the same time.  We stay within our threshold.

## Learning Quotas

Have you ever noticed that when you're not really pushed to learn much new at work that you come up with the most in-depth, interesting, and new projects at home?  Some might describe this as scratching an itch.  There's something inside us that wants to experience growth and movement toward our potential.  If we don't get it one place, we make it in another.  We want to feel like we're getting better.  We want the rush and satisfaction of new life experiences.  We have a learning quota that we want to fill.  Anything less than the quota, and it feels like we need to learn more -- either quickly, deeply, or broadly.

## Optimal Learning Zone

In the realm where we're being pushed just beyond our limits, we'll maximize our learning.  We'll be uncomfortable but not overly so as to feel discouraged, finding insurmountable problems before us.  We can keep our quota filled.  We can push our personal threshold higher.  Life is short and there's so much to experience.  Yes, take a break when needed.  Humans have a rhythm and are not machines.  But make growth and challenge the norm in your life and learning, and you'll find greater satisfaction.

## Different Thresholds & Quotas

Different people have different learning thresholds and quotas.  Some want to focus on fewer things, have a smaller span of control.  Some want to focus longer on a thing, having a more in-depth experience.  We value learning -- for ourselves and for others.  When you perceive someone else's learning quota or threshold are different than yours, be slow to judge their own value of learning.  If their threshold is lower, don't assume they don't like to learn and are stuck in their old ways.  If their quota is higher and timeline on a subject shorter, don't assume they're always distracted by the new and shiney.  We have different learning metrics that are suited well for us.

Thinking about yourself, how can you tell when you're making your learning quota or approaching your learning threshold?

We have limits to our learning -- thresholds for how much we can take and quotas for how much we need.  Find your zone and thrive in it.

Learning Quotas and Thresholds

When we are exposed to a new thing, we might not at first see its full grandeur.  After a bit of context and perspective, our appreciation for that thing may increase substantially.



## Subjects are Deep and Broad 

There are so many fields of study in this world.  Many of them have been around for a long time (eg, any study of our natural world)!  When we are first exposed to a new field of study or a new idea, we see the surface.  We don't know what the expert of many dedicated years knows.  Similarly, subjects are broad.  We may not even know what another human being has discovered in this field of study during his cursory investigations of the same.  He may have found something new and foreign to us that we have not experienced ourselves.

## Code You Didn't Write

One of the most fascinating and fantastic things about software is the extreme malleability of the medium.  You can make something out of nothing.  The somethings that we make can take any shape.  Thus the method of problem solving varies much from craftsman to craftsman.

Given the size and lifespan of many software projects today, you'll see and get to work with code that you didn't originally write.  You may open a file, run through the code, and remark, "what was he thinking when he wrote this?!" -- as if he wasn't thinking what you're thinking.  And he wasn't.  But he was thinking.  In his implementation he had a perspective -- a context consisting of many things.  The combined forces of his knowledge, experience, the team, the timeline, the leadership, the company culture, company growth stage, tool availability, operational environment, customer expectations, clarity of requirements, evolutionary stage of the product, and on.  We don't see things now as that original craftsman did.  We have a new context through which we're interpreting things and making decisions.  Were we to see more clearly the context under which this software was created, our appreciation for the person and the product would likely grow.

## Crossing Disciplines 

In software teams, and any large endeavor, we employ the specialties of many people to make something larger and more interesting.  A cross functional team may consist of a software developer, ui/ux designer, product manager, operations engineer, data scientist, and more.   

The thing that we create together, we can generally all appreciate.  But do we see as clearly the expertise brought to the team from each of these disciplines?  Sometimes we may feel that one of these disciplines is lacking and letting the project down.  A bit more context into the depth and breadth of the subject may increase our appreciation of that discipline and the people attempting to perform it.  It's hard, it's deep, it has taken time, effort, and focus to get to the current level of performance -- just like your own discipline.  If performance is really lacking, help that person. But before judging too harshly, try to gain some context, and it might assist your own appreciation.

What is something that you once didn't have much appreciation for but after some investigation and added context grew in your appreciation?

When you have the background of context, you're able to better see the value of things.

Context Assists Appreciation

Ideas happen all the time.  Statistically, we'll hear some bad ones.  At least we think they're bad.  How can we best hear and react to these bad ideas?



## Ideas Have Value

First, a basic foundation for ideas:  Ideas come from people's thoughts.  People's ideas are the catalyst for innovation -- things to try, explore, and from which real progress can spring.  Progress is important.  People are even more important.  There is value in each.

## Hearing and Learning

Some ideas elicit a strong response from us.  Let's talk about the negative type of response.  Perhaps there's something in our background or perspective that may make us revile at just hearing certain ideas.  If we revile, the conversation will be over.  That one idea will die.  That may be what we want in the end.  But focusing on just the short term consequence of disposing of a bad idea may blind us to other side effects we may cause in immediately, strongly, or without tact opposing a bad idea.  

Let's explore some alternatives:  Listen.  Just take it in.  Keep your composure.  Don't even hint at your dislike of this idea.  Ask clarifying questions.  Ask about how this person got this idea.  Ask about how this idea and any implementations so far have helped them.  Here we're trying to get basic understanding, background information, and gathering any evidence of good that might exist.

Ask about any pitfalls they've experienced.  You don't have any specific lines of thinking at this point but are just inquiring generally.  Now ask about pitfalls that you see.  Don't state that these are fact.  Just ask if the person thinks these one or two pitfalls might apply.  Ask if there are any adjustments they'd make to the idea or implementation to account for these.  Here we're trying to expose in a non-threatening way the real drawbacks that may exist in the idea.

Now if you're feeling composed and generous enough, go a step further in your learning.  Congratulate them on the good things happening to them relative to this idea.  Then ask this person to describe how he thinks this idea might potentially be helpful to you.  Is it a generally useful idea?  Or in what contexts?  You may be surprised with some thoughts this person shares with you that you have not yet thought of.  You may be surprised at their generosity and desire to help you.

## Graceful Disagreement

Even after hearing and learning, you may be unmoved in your opinion.  Or maybe you want to give yourself time to consider what you've heard and learned.  But in the end, you don't have to accept what you think is a bad idea.  It's essential to realize that your hearing and learning do not imply your acceptance.  You are not forced to agree.  By listening you are not stating or even intimating that you agree.

You can give your own opinion or perspective on the idea.  You should be honest to the opinion you hold in your expression.  You also don't have to shove it in this person's face that you think the idea is terrible.  You may not mean to make your disagreement personal.  Do one better than that, and try not to let it be *perceived* as personal.

Remember that what you share as a counter-idea or fresh alternative is another idea in itself.  If you're down-voting an idea, it's good to have an alternative anyway.  You can state plainly that you'd rather not use this idea for you, your context, or your team.  State the specific pitfalls that you don't want to happen to you.  Remember that your relationship with people is more important than a problem to be solved or a task to be finished.  Keep the channels of collaboration and communication open.

The next time you hear an idea you think is bad: hear, learn, be graceful, be honest.

Is this hard for you sometimes?  What helps you avoid the initial bad reaction and inquire more honestly about what you're hearing?

The next time you hear an idea you think is bad: hear, learn, be graceful, be honest.

empathy