
Engineer Anti-Patterns - deathtrader666
http://dtrace.org/blogs/eschrock/2012/08/14/engineer-anti-patterns/
======
Retra
Is Anti-pattern obsession an anti-pattern? Does making lists like this solve
any problems in a verifiable way, or is it just The Talker hard at work?

It's great to put people into boxes and clean up by saying "these boxes aren't
real; we're all a little bit of each", but what is the effectiveness of doing
that? We give people little stories about these unsavory archetypes (and their
brains love it,) but if the moral of the story is not to fall in love with
archetypal simplifications... it just sounds very hypocritical to me. "Don't
be like The Talker: he's a Capricorn, and we all know how dumb Capricorns are:
they tend to believe in astrology." Maybe we should add The Listmaker to the
end of that list...

Pardon my rant. I get tired of seeing the word 'anti-pattern' bandied about
like it's the hottest new thing. Stupidity has many names, but it was never
really cool. Maybe we should be jumping on solutions instead of band wagons?

~~~
Arwill
The list of anti-patterns is good when you don't want to argue with a
colleague, you can just send him the link. There are no hard-set rules in
higher level software design, the compiler will not normally warn you of these
issue. Having the potential pitfalls nicely documented is useful.

And this list in particular might be useful when you don't want to hurt the
feelings of a colleague, when you want to point out their lack of
productivity. If you pass them this list, they might discover some similarity
to themselves. And the source is a third person (the blogs author), so its an
impartial source.

~~~
hyperpape
I think if you send someone that list as a suggestion, your likely results
range from nothing to simmering resentment.

------
debacle
These aren't anti-patterns. These are the realities of people being people and
not cogs - people have desires and goals that extend beyond the realm of "Make
this for me fast and don't screw up."

> Titles should be a reflection of the impact already achieved through hard
> work, not a license granted by a benevolent management.

I don't even really know what this means. It implies that titles are laurels
without responsibility. I think what it really means is that titles are a tool
for management to hold on a stick in front of employees.

> Leadership is something earned by gaining the respect of your peers through
> execution

I would say this has not been the case in any company I have worked at with
more than 10 employees. I have never worked in an environment where at least
one coworker (or manager) wasn't more qualified and deserving of leadership
than someone above them. In fact, to the contrary, I have observed poor
leadership as the greatest mitigable contributor to failure.

This article, in my opinion, is a bunch of feel-good management bullshit about
workaholics and culture fit. The reality is that society produces a lot of
bright, young, wide-eyed engineers and then browbeats them into doing really
immensely boring things. The reality is that work is called work because it's
not play, and you need to be sympathetic with your employees (because everyone
wants to solve hard problems, be respected and admired, do cool things, make
fat stacks, etc) but also guide them in balancing their personal desires with
the responsibility to their salaried employment.

Every one of the behaviors that Eric outlines are natural behaviors. The job
of a manager is to channel those desires into positive business outcomes, not
sift through stacks of resumes for drones.

~~~
scott_s
_I don 't even really know what this means. It implies that titles are laurels
without responsibility. I think what it really means is that titles are a tool
for management to hold on a stick in front of employees._

I understood it to be something different. If someone gets the title "Senior
Engineer", that means they have been acting like a senior engineer. The
alternative would be not acting like a senior engineer until promoted to
Senior Engineer.

This is part of the author's larger point: your title does not limit your
contributions. You don't need permission (a title) to act a certain way.
Titles, then, are an acknowledgement, not a license.

~~~
vonmoltke
Not at my last employer. Titles were frequently used as a reason to increase
or discount the value of opinions or authority on matters. You didn't get the
moral authority to act like a senior engineer until promoted to such.

The only real exception to this was when the person with the title was The
Outsider. Being a defense contractor, we had many long-running programs and
people fairly regularly spent a decade or more on a single program. Among
other things this led ti cliques of "old-timers" on programs who would be
automatically suspicious of high-level people from outside who were brought in
to "help".

~~~
spacecowboy_lon
And very common and a lot stronger in some cultures than others.

I suspect that some recent SV hiring trends will have incresed this tendancy -
this could cause problems as a comapny coudl turn into a civil serivce
orgaiastion but with out the flexability that has developed over the centurys
in the british civil service

Charlie Stoss's descriptions of the laundy are only a slight exageration and
he only worked in local govenment :-)

------
analog31
A cautionary note: Make sure the patterns you're observing aren't rational
adaptations to the work environment that you've fostered. At one employer, I
retreated to the "thinker" mode because I was sick of dealing with a
profoundly constipated and political development process.

~~~
thirdtruck
Very true. I'm constantly running into code that wasn't refactored because my
predecessors were too scared of introducing regressive errors in the process.

~~~
debacle
"I would optimize this algorithm but I don't want to bother with 4 rounds of
code review."

~~~
thirdtruck
If only. More of a "I don't want a dressing down from my internal customer"
situation.

~~~
debacle
I was speaking from my own experiences. At my first real programming job I was
lucky enough to work with a handful of obscenely talented programmers and they
very commonly would implement incredibly stupid or lazy solutions because they
were easier to get through code review.

~~~
thirdtruck
Ah, I see and empathize. I've had some very long code reviews on account of
writing code above my reviewers' skill levels.

------
santacluster
Job title has in my experience strongly affected my ability to influence
entrenched company and engineering cultures.

Titles affect how you are perceived by others, including engineers, no matter
how often we like the repeat the "but we're a meritocracy" BS. People don't
work that way, not even engineers. There are a lot more variables that go into
how we perceive and treat people than just their technical output.

So the question "how will my job title affect my ability to do X?" is a
perfectly valid one, and meritocracy buzzword bingo is not a valid answer.

~~~
samastur
I agree.

Another way of looking at it is if title is not defining scope of something,
then what is its purpose?

~~~
radmuzom
It's purpose is to keep wages low. One might be so good that their ideas and
subsequent execution is better than the "lead" or "chief" engineer, but the
same person will be paid much lesser because of their title.

~~~
nissimk
In a similar context, title is often used by management as something that
incurs little or zero cost to give to employees to make them feel better.

Beware of "I didn't get (much of) a raise but I got a promotion"

------
greenyoda
See also: "The 7 Habits of Highly Overrated People":

[http://www.daedtech.com/the-7-habits-of-highly-overrated-
peo...](http://www.daedtech.com/the-7-habits-of-highly-overrated-people)

HN discussion:
[https://news.ycombinator.com/item?id=6965295](https://news.ycombinator.com/item?id=6965295)

------
agentultra
Maybe we should add, _The Absolver_ : the "engineer" who likes to pigeonhole
people into simple categories and absolve eirself from the responsibility of
treating those people as complete human beings. The Absolver likes to blame
the weaknesses in other people before their own.

It goes both ways. Many of us have been guilty of some of these behaviors from
time to time. The better of us learn to change and adapt. The important thing
to remember when using generalizations like this is that they are simplistic
and not representative -- it's not _wrong_ to be a software developer who is
concerned primarily with the intricacies of the kernel scheduler; it's a
complex topic and specialization is useful in some organizations. It's rather
useful to be someone who is articulate and able to stick to their opinions
when they have the confidence and factual evidence to know they're right.

I wouldn't really consider this a list of "anti-patterns." Patterns, yes, but
people can change their behaviors with a little helpful prompting.

------
serve_yay
If titles don't matter, then give everyone the title "King/Queen of
Engineering Mountain". Oh, you don't want to do that eh? I wonder why...

In all seriousness, if I asked about job titles and got this trifle as a
response that would be a negative signal for me. Politics function whether
engineers choose to believe it, or not.

~~~
mlieberman85
Agreed. I was told to lead a team in all but title, but without the title I
was consistently told that I didn't have the seniority nor have I proved
myself. Maybe it's different at Delphix, doubt it, but if it is different at
Delphix is there just the "Engineer" title and that's it? If so, that's great.
If there are titles like Infrastructure Engineer and Front-End Engineer and
Chief Architect, etc. then thats on the company culture for being
contradictory.

------
angrybits
After reading that, I cannot help but think that this person/company would be
positively horrible to work for. I find myself wondering what his goal was
when publishing that, because it didn't read (to me) as positive or helpful.

~~~
ExpiredLink
Me too. I wouldn't want to work for Eric. He _is_ a management anti-pattern.

~~~
spacecowboy_lon
And one that hassn't heard of Belbin and his work on team roles.My top 3 where
Plant, Resource Investiagtor and Chair

------
zirkonit
In the end, management is just like engineering – getting the outcome you need
despite all the constraints.

Negative personality traits of the team is a constraint just like anything
else – a smart leader will be able to foster thinkers into coming up with
really actionable ideas, soothe entitleds' egos, calm down the talkers etc.

------
ChuckMcM
The combination of this article and this HN discussion is pretty interesting
to me.

I recognize the whole 'management is evil' thing which I have found is a
pretty common component. That tends to go away with experience (or at least
get tempered into something more along the lines of it being a necessary
evil.) but the title one is something I related to in the post and thought I
would comment on.

The titles people have set expectations in the company and in their peers of
what someone will be able to do or get done. Generally if the pay is
sufficient, I've found you benefit from the lowest possible title because it
allows work you do to be contextualized within the expectations of the title.
If you're much 'better' than the title gives you credit for, then you will
"exceed expectations" and get maximum rewards. One's ability to "move the
needle" as it were, is really related to who you connect with at the company.
And it is hard for introverts to connect with a lot of people so this is
particularly challenging. But to put that in context, a junior person who has
the respect and friendship of the CEO can have a huge impact, whereas a junior
person who has nobody's respect and doesn't know anyone, will not have nearly
as much ability to impact things. The key here is to not let your "title" to
self edit you from interacting with everyone.

Pay grades however are a different story. An interesting conversation to have
is how is pay decided and how is it influenced by contribution.

------
eschrock
As the author, clarifying some misinterpretations:

First, the act of identifying patterns (anti or not) is not equivalent to
labeling human beings with the same terms, nor does it imply that one takes
action (management or otherwise) against people as a result. Rather, it's a
way to extract and summarize similar behaviors in a way that others can
interpret and apply in their own situations. The post intros this as a set of
negative pathologies (not people) I had encountered as an engineer (not
manager) in the previous decade, and closes with observation that we all can
suffer from these in some form or another. In the end it proposes that
avoiding them at scale is a cultural problem, hard fought by continually
embodying, supporting, and rewarding the positive aspects of the culture, not
a management problem won by platitudes.

Second, it is speaking from the viewpoint of someone building the foundation
of an engineering culture at a startup. These are not observations of our
culture at the time, but rather a set of pathologies we sought to avoid as we
grew. It is true that many other companies do not eschew these pathologies,
and for example, result in the title abuse referenced in many comments.

Finally, with respect to titles in particular, we absolutely do embrace
engineering titles at Delphix. Promotions are a visible and meaningful
mechanism for recognizing (through titles that persist beyond these walls) and
rewarding (through compensation) our best engineers. The point is that
promotions reflect _actual_ impact, not the result of political scheming. As a
result, people don't listen to you differently, you don't get fed different
opportunities, and you don't get to do more impactful things. Maybe that's not
how it works elsewhere, or the audience doesn't believe me that it's possible
to achieve, but it's very important to me that it work that way here.

------
rab_oof
By contrast, "T-shaped" people are a delight to work with... Centroid of some
deep domain knowledge and/or ownership of specific process/es but able to get
out their comfort zone and don't really care what the title says... Get it
done, make customers smile, and keep the company profitable.

Move fast, break a few things and

~~~
debacle
What does 'T-shaped' mean in this context?

~~~
sp332
The vertical stroke represents deep knowledge in a small area, and the
horizontal stroke means they have some understanding of many other areas.

------
Vaskivo
> The Entitled > being a Senior Staff Engineer _enables_ her to do something
> that cannot be accomplished as a Staff Engineer

I think it is not an issue with being able to do something. I believe the
reasoning is something of the sorts of "Being just a Staff Engineer, I'm not
doing X because I'm not payed enough to do it" or "it is not my
responsability", while being a Senior Staff Engineer has a bigger pay and more
responsabilities. In my opinion, it is a perfectly valid stance. Someone
should just talk to this engineer to clear up any ambiguities.

And I totally agree with santacluster's comment.

------
UhUhUhUh
Just as in psychology, you can assign as many pathologies as you like, the
bottom line will always be that "health" is but the ability to switch among
various aspects depending on the circumstances. Every single aspect can be
adaptive and productive depending on the circumstances. We hallucinate
(dreams), we are depressed (when we lose something), we are manic (when we
need a boost), we are anxious (when something needs to be feared), we are OCD
(when we need to get deep into the details) and so on so forth. The only anti-
pattern is rigidity and bosses are certainly not immune to that.

------
douche
The talker kills me. Those that can, do, those that can't, run their mouths
and make it harder for those of us who have to actually do the work to
actually get it done.

~~~
michaelcampbell
The counter to that is The Recluse, which tech industries seem to have far too
many of.

~~~
debacle
That's because the recluse + the owner = job security

------
indymike
The words used to describe three of the anti-patterns (thinker, talker and
owner) were not chosen very well if you want people to think, communicate and
take responsibility.

------
metaphorm
well, this seems to have badly backfired in the author's face. while there are
certainly people that are unpleasant to work with, they aren't merely
"patterns" or "categories". they are humans. humans aren't defined by code and
are not unchanging objects.

in fact, humans are deep, complex, multi-faceted beings who may have many
strengths and weaknesses at the same time, and thinking of people only by
which "anti-pattern" one of their flaws resembles is insulting and limiting.
most of the time a person's flaws are not fatal, and in fact they are almost
always a reflection of a poor environment more than any essential
characteristic of the person.

my take away from this article is that a hiring process needs to look for a
more holistic picture of the candidate and not try to eliminate people because
they match a contrived "anti-pattern", as if humans could be fitted to
patterns in the first place.

------
wrikl
I know this is petty and on a slight tangent, but for some reason I get a bit
irritated by the constant use of software development-specific terminology
(e.g. Anti-Pattern) in articles talking about psychology, human nature, and
other general topics. In this case the author could have simply used
'stereotype' or 'personality type' which would have been perfectly fine.

It provokes a similar reaction to when I see people using 'grok' unironically
in general conversation: it just feels a bit awkward and almost forced.

Commenting on the actual article, I agree with others who have pointed out
that this article isn't particular helpful. It's a gross simplification of
human behaviour and makes me wonder what the working culture is like at an
organisation that would be 'disheartened' by a newhire asking questions like
that.

~~~
pionar
(I'm not commenting on the actual article's contents, as I think we agree on
the value of it).

I think it is useful to use development-related terms when discussing non-
development processes and concepts. Analogies are a great way to communicate
subject matter that the audience may not be familiar with, especially when
that intended audience is a narrow band (e.g., developers).

My girlfriend is a flutist (or, flautist for European readers), and
oftentimes, when we're discussing something like octatonic scales, it helps
for me to think of these concepts in a way that I feel comfortable (set
theory).

~~~
wrikl
I do understand where you're coming from, and I also find myself using such
analogies as often they are the quickest way to communicate a concept to an
audience of developers. However, I think it's often worth considering if there
are other ways to communicate the same ideas using methods more accessible to
non-technical people, or those who might be new developers. I think my gut
reaction to the (over)use of such terms is more of a reaction towards a
potentially exclusionary culture which I dislike strongly.

------
Rainymood
I, personally, feel like this could be solved by a 'good' team. I work in a
team of 2. I usually come up with the ideas while my partner executes them. I
usually hang over his shoulder while he codes, he does most of the coding,
70/30\. For us, this works, for others, it might not.

~~~
collyw
I wonder if that is how my relatively incompetent team leader would describe
our working relationship?

He usually comes up with some half thought through suggestion, and I flesh out
the real details of what needs done and implement it properly, trying to avoid
all the pitfalls he didn't even bother to think about.

------
deedubaya
Titles determine pay scale and hold weight when changing jobs. They may not be
important to the employer, but they should be very important to the employee,
even if they plan on sticking around for 5-10 years.

------
CmonDev
Would be more sympathetic if he described a path for growing from a developer
to a board member in their company.

------
michaelochurch
This sounds more like entitled whining from a management PoV than anything
constructive.

Let me just take one shot, and then I'll go away.

 _In this case, after hours of discussions, I couldn’t shake this engineer’s
fixation with understanding how his title would affect his ability to have
impact at Delphix. After deciding that it was not a good cultural fit..._

Something I've learned the hard way is that people are insecure. I don't mean
that they're always emotionally insecure (but that can be a part of it) so
much as they're also positionally insecure. People care about titles
because... (wait for it) titles matter.

A title is a starting point. It's a formal statement of trust in a person. If
my competence is a 7.3 and yours is a 7.6, people are going to listen to the
person with the higher title, whether that's you or me. In fact, there are
many organizations (even Google) where decisions are made primarily on title
and formal job description, and that doesn't mean that they're bad
organizations. It just means that they're big. Chain of command is a reality
of life. Not a pretty one, but it's what your up against, and I have no
problem with someone wanting to know where he's going to stand before he risks
his career by stepping into a new company.

~~~
le_architect
completely agree. It's more like Spock calling humans weak, stupid and
illogical and not realizing that spock would have created windows and humans
would create apple. I've worked with the people sited in the original blog.
Early on in this engineering department there were no titles. It was like a
pack of dogs with no alpha dog. Wonder if you have ever seen that. All the
dogs are yapping and nipping because no one knows who is the alpha dog. Later
they enforced a full hierarchy. CTO, VP, 5 levels of engineers. After the
imposition of titles things ran smoothly and quietly. Everyone fell in line.
No more yapping or nipping (for better or worse - there was a lot of fear and
lost lines of communication, lost design ideas from engineers who were too
afraid to voice their insights) The original lack of titles IMO came from the
fact that the main engineers (ie senior, ie architects) , coming from Sun
DTrace and Fishworks, had felt that stupid execs at Sun and stupid product
managers told them, the gods of engineering, what to do and those people were
stupidly wrong and they were always right. Now that they were out of Sun and
in control of a brand new engineering team they were hell bent on keeping
control since they were clearly the smartest beings around. They as the gods
of coding should be the only product managers. They as the gods of coding
should be the only architects. Yes, titles make a difference for better or
worse. Worse when they are not deserved and better when they point out that
the senior person has more proven experience. When super smart junior engineer
says you should use Mongo for your Bitcoin banking site and the senior
engineer with 20 years of experience says you should use an ACID compliant
database, you should use your senior engineers advice. Super smart junior
people can often talk dangerously misguided intelligent circles around more
senior calmer senior engineers. Titles can, in the best of cases, help direct
the discussion. Just ask [http://hackingdistributed.com/2014/04/06/another-
one-bites-t...](http://hackingdistributed.com/2014/04/06/another-one-bites-
the-dust-flexcoin/)

~~~
bcantrill
I came from Sun Fishworks as well, and still have an engineering team without
titles (everyone is a "Software Engineer"). This is deliberate[1], and I don't
think it's been an impediment -- there is certainly not a problem with
"yapping and nipping." Of course, every organization is different, and what
works for one group of people may not work for another -- but I can't
personally imagine working in an organization that insisted on hierarchical
titles among its engineers.

[1]
[http://www.slideshare.net/bcantrill/surge2013](http://www.slideshare.net/bcantrill/surge2013)

------
stefantalpalaru
tl;dr: labels I assign to people I don't like

