Engineer Anti-Patterns(dtrace.org)
dtrace.org
Engineer Anti-Patterns
http://dtrace.org/blogs/eschrock/2012/08/14/engineer-anti-patterns/
25 comments
I sympathise with your point but I think there is a role for patterns of all forms; the advisable and the inadvisable. Essentially they attempt to encapsulate and share experience in a form that can help guide the less experienced. Obviously, a characteristic of an expert is someone who knows when to buck conventions and patterns but what is 'stupid' isn't necessarily always obvious to everyone.
You should flesh that out and make a blog post "Anti-patterns considered harmful".
or just "blogging anti-patterns"
Lambda the ultimate antipattern. The next 700 antipatterns. Why antipatterns matter.
> Is Anti-pattern obsession an anti-pattern?
No. It's precisely because the world is so complicated and the broad generalizations don't work that I think patterns and anti-patterns (ideally with stories behind them that explain the context in which the author discovered them) are so much more useful than, say, the rule format that so much of our industry's content is wrapped in ("stop doing X", "you should be doing Y", and so on).
No. It's precisely because the world is so complicated and the broad generalizations don't work that I think patterns and anti-patterns (ideally with stories behind them that explain the context in which the author discovered them) are so much more useful than, say, the rule format that so much of our industry's content is wrapped in ("stop doing X", "you should be doing Y", and so on).
I've always believed that it's better to be aware of values or behaviors that you should aim for, rather than be given a list of things not to do.
I think these anti-pattern posts are primarily therapeutic for the writer, and I suppose useful to people who oversee or supervise.
I think these anti-pattern posts are primarily therapeutic for the writer, and I suppose useful to people who oversee or supervise.
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.
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.
I think if you send someone that list as a suggestion, your likely results range from nothing to simmering resentment.
If you had beef with me, and instead of saying it to my face, you sent me some dumb list, as if it was indisputable proof that you were right, I'd hate hate hate you.
Don't ever do this.
Don't ever do this.
I would just call these archetypes, not anti-patterns. Anti-pattern is a fairly specific domain of poor decision-making.
Real people aren't like this, and these aren't problem solving methods, just kind of unhelpful behaviors. There's nothing wrong with them in certain contexts, and the author doesn't say when or where they work. It's just kind of "look at this list of extremes I want to make fun of."
I had fun reading it. I could relate to some of that stuff. But I just don't see it as the 'doing better' that the author is trying to advocate. Which kind of makes it a greater contribution to confusion and noise than to reliable progress. You could just accuse any thought you don't agree with to be a manifestation one of these archetypes and then you're back at square one, aren't you? Bottom line: you'll always need to think. The fact that the author has to say "we're all a little of all of this" is a big clue that maybe it isn't any more useful than astrology. Hence my comparison.
Real people aren't like this, and these aren't problem solving methods, just kind of unhelpful behaviors. There's nothing wrong with them in certain contexts, and the author doesn't say when or where they work. It's just kind of "look at this list of extremes I want to make fun of."
I had fun reading it. I could relate to some of that stuff. But I just don't see it as the 'doing better' that the author is trying to advocate. Which kind of makes it a greater contribution to confusion and noise than to reliable progress. You could just accuse any thought you don't agree with to be a manifestation one of these archetypes and then you're back at square one, aren't you? Bottom line: you'll always need to think. The fact that the author has to say "we're all a little of all of this" is a big clue that maybe it isn't any more useful than astrology. Hence my comparison.
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.
> 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.
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.
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.
This is a slight twist on "dress for the job you want." I've been living by this rule my entire life. Do the job you want. Don't be restricted by what you're told and don't go looking for permission, approval, and especially kudos.
This doesn't always work of course, but why would you want to be where you are pigeonholed? I find most people don't stop you from doing more and assuming more responsibility. You do the job you want or believe needs doing and in many cases it's handed to you.
I showed up at my last job in a support role and started doing engineer work. Got promoted to engineer. Started doing architect work and then got promoted to architect.
I've been doing a lot more people management lately, so who knows.
This doesn't always work of course, but why would you want to be where you are pigeonholed? I find most people don't stop you from doing more and assuming more responsibility. You do the job you want or believe needs doing and in many cases it's handed to you.
I showed up at my last job in a support role and started doing engineer work. Got promoted to engineer. Started doing architect work and then got promoted to architect.
I've been doing a lot more people management lately, so who knows.
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".
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".
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 :-)
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 :-)
I am not stating "this is how it is, everywhere." I am stating "this is how the author thinks it is at his company."
> 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.
While it's true you can do whatever you want, titling generally functions as a way to control or punish the output of a worker. I have seen folks with lesser titles do something that a manager doesn't agree with and then been censured for it being outside of their job duties. I have seen people with high titles be chided for doing small work that someone felt was below them. I have seen managers become untouchable by anyone below them because the manager title became a shield against any other non-manager's criticism or input.
Titles service to reinforce the employee hierarchy that most business utilize. All the usual problems with that hierarchy are expressed through titles.
While it's true you can do whatever you want, titling generally functions as a way to control or punish the output of a worker. I have seen folks with lesser titles do something that a manager doesn't agree with and then been censured for it being outside of their job duties. I have seen people with high titles be chided for doing small work that someone felt was below them. I have seen managers become untouchable by anyone below them because the manager title became a shield against any other non-manager's criticism or input.
Titles service to reinforce the employee hierarchy that most business utilize. All the usual problems with that hierarchy are expressed through titles.
> 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.
Oh man, I wish that were true. Reality is, if the company needs someone to take responsibility, they'll promote the person they like the most and hope they rise up to that challenge. Most of the time, the person making the decision doesn't know much about what it really takes to do the job. They're managers, not engineers. The engineer-manager is a rare breed, indeed.
Promotions are driven by company needs, not by merit. If there's someone available that actually merits the promotion, wow, great. If not, lets roll the dice and hope we get sixes.
Oh man, I wish that were true. Reality is, if the company needs someone to take responsibility, they'll promote the person they like the most and hope they rise up to that challenge. Most of the time, the person making the decision doesn't know much about what it really takes to do the job. They're managers, not engineers. The engineer-manager is a rare breed, indeed.
Promotions are driven by company needs, not by merit. If there's someone available that actually merits the promotion, wow, great. If not, lets roll the dice and hope we get sixes.
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.
One of the reasons why engineers get dicked relative to executives is that engineers tend to be promoted "confirmationally" (i.e. you're promoted to X once you're an X already) while executives are promoted aspirationally. At least, that's how it's sold to the engineers. In truth, it's standard-issue corporate stinginess.
The problems with that are multiple. The first is that you can't just ditch your X-1 (and, typically, X-2 and X-3) work while you're still an X-1 in title. Standing up and taking on X work is a way to make yourself a McNulty: you're likely to be perceived as neglecting your assigned work or poking your nose where it doesn't belong. The second is that companies will often give better projects in lieu of the title bump and the raise that typically comes with it, which is why you often have to job hop to get genuine career progress. Google has a lot of SWE 3's and Sr. SWEs who were underpromoted but work on important projects, and ends up handing out $500k+ retention packages when it realizes its mistake (usually because the underpromoted engineer now has a Facebook offer).
One of the reasons why engineers get dicked relative to executives is that engineers tend to be promoted "confirmationally" (i.e. you're promoted to X once you're an X already) while executives are promoted aspirationally. At least, that's how it's sold to the engineers. In truth, it's standard-issue corporate stinginess.
The problems with that are multiple. The first is that you can't just ditch your X-1 (and, typically, X-2 and X-3) work while you're still an X-1 in title. Standing up and taking on X work is a way to make yourself a McNulty: you're likely to be perceived as neglecting your assigned work or poking your nose where it doesn't belong. The second is that companies will often give better projects in lieu of the title bump and the raise that typically comes with it, which is why you often have to job hop to get genuine career progress. Google has a lot of SWE 3's and Sr. SWEs who were underpromoted but work on important projects, and ends up handing out $500k+ retention packages when it realizes its mistake (usually because the underpromoted engineer now has a Facebook offer).
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.
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.
"I would optimize this algorithm but I don't want to bother with 4 rounds of code review."
If only. More of a "I don't want a dressing down from my internal customer" situation.
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.
Ah, I see and empathize. I've had some very long code reviews on account of writing code above my reviewers' skill levels.
"Code review? What code review?"
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.
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.
Exactly.
Has the author never worked for a different employer? It's very common in a lot of companies for developers to be excluded from (hearing about / learning about / have input on) something, simply because they don't have (specific job title). That's a legitimate concern. Even tiny 10-ish person companies often fall into this trap.
The companies that promise candidates not to worry about job titles because "we're a flat organization", "we're agile", "we're a meritocracy" tend to fall into this trap even more than the older ones do -- knowing and using the right buzzwords is almost a red flag in itself.
So, completely hypothetically, these are all problems that would be bad and should be avoided, as the author writes.
But in practice, it sounds like a candidate was concerned about making sure they'd have enough authority to actually make improvements and not just shoved onto busywork at random.
And instead of addressing that concern in any meaningful way, the company took that as an opportunity to respond with a bunch of buzzwords and ad-hominems, and then pat themselves on the back about it.
Has the author never worked for a different employer? It's very common in a lot of companies for developers to be excluded from (hearing about / learning about / have input on) something, simply because they don't have (specific job title). That's a legitimate concern. Even tiny 10-ish person companies often fall into this trap.
The companies that promise candidates not to worry about job titles because "we're a flat organization", "we're agile", "we're a meritocracy" tend to fall into this trap even more than the older ones do -- knowing and using the right buzzwords is almost a red flag in itself.
So, completely hypothetically, these are all problems that would be bad and should be avoided, as the author writes.
But in practice, it sounds like a candidate was concerned about making sure they'd have enough authority to actually make improvements and not just shoved onto busywork at random.
And instead of addressing that concern in any meaningful way, the company took that as an opportunity to respond with a bunch of buzzwords and ad-hominems, and then pat themselves on the back about it.
It's been my experience that people who are quickest to say "Titles don't matter here" are the ones with the nicest titles. :)
In fairness, I don't think most founders set out to create political organizations. (Politics is more of an emergent phenomenon -- a "god of the gaps" that arises to fill informational voids and power vacuums.) But saying titles don't matter is either being very naive, or being intentionally misleading. Naive: when someone high up in an organization (a founder or VP, say) isn't aware of the extent to which titles matter, because his title has ensured that people always listen to him. Misleading: when a boss or hiring manager tells a prospective employee that titles don't matter, in order to get that employee to accept a title below his expectations.
That having been said, I do occasionally encounter the "Entitled" anti-pattern the blog post talks about. You see it in employees who feel marginalized. Sometimes you see it in new employees, especially those who have recently come from a much bigger organization, and who are used to formalized hierarchies. Sometimes you see it because your organization really does care a great deal about title, and you've been blinded to the extent to which it does. In any of these cases, I tend to think the burden is on the organization/boss to try to understand the source of any title hangups. Sure, some people are just wildly insecure, and they'll never be content with any given title. I tend to think these people are the minority of most "Entitled" scenarios. And at any rate, it's more productive to assume that the person feels marginalized in some way, and to attempt to diagnose why -- rather than to blame his fundamental psychology.
In fairness, I don't think most founders set out to create political organizations. (Politics is more of an emergent phenomenon -- a "god of the gaps" that arises to fill informational voids and power vacuums.) But saying titles don't matter is either being very naive, or being intentionally misleading. Naive: when someone high up in an organization (a founder or VP, say) isn't aware of the extent to which titles matter, because his title has ensured that people always listen to him. Misleading: when a boss or hiring manager tells a prospective employee that titles don't matter, in order to get that employee to accept a title below his expectations.
That having been said, I do occasionally encounter the "Entitled" anti-pattern the blog post talks about. You see it in employees who feel marginalized. Sometimes you see it in new employees, especially those who have recently come from a much bigger organization, and who are used to formalized hierarchies. Sometimes you see it because your organization really does care a great deal about title, and you've been blinded to the extent to which it does. In any of these cases, I tend to think the burden is on the organization/boss to try to understand the source of any title hangups. Sure, some people are just wildly insecure, and they'll never be content with any given title. I tend to think these people are the minority of most "Entitled" scenarios. And at any rate, it's more productive to assume that the person feels marginalized in some way, and to attempt to diagnose why -- rather than to blame his fundamental psychology.
For sake of argument, have you considered selection bias or cause/effect reversal as another explanation?
What I mean is, perhaps the people who are able to clearly and concisely explain their ideas are the ones who are most likely to become senior engineers, managers, etc? As they proficiently share their ideas, they tend to have a lot of influence, which in turn leads to them getting promotions. Communication and interpersonal skills are a huge part of being a good engineer working on a team.
There was a guy I worked with when I was a new grad, let's call him Bill. Bill himself was also pretty fresh, had a few years under his belt maybe. But Bill can communicate with a level of clarity that I am still in awe of. Of course he became a senior engineer while he was very still fairly young, and of course he has a lot of influence. The technical skills to become a Senior Engineer are only half of the equation.
I say this all as a (non-senior) engineer who finds he often has a hard time with communication and interpersonal skills. I'm growing technically, but I've got to work way harder to grow those soft skills at the same rate.
What I mean is, perhaps the people who are able to clearly and concisely explain their ideas are the ones who are most likely to become senior engineers, managers, etc? As they proficiently share their ideas, they tend to have a lot of influence, which in turn leads to them getting promotions. Communication and interpersonal skills are a huge part of being a good engineer working on a team.
There was a guy I worked with when I was a new grad, let's call him Bill. Bill himself was also pretty fresh, had a few years under his belt maybe. But Bill can communicate with a level of clarity that I am still in awe of. Of course he became a senior engineer while he was very still fairly young, and of course he has a lot of influence. The technical skills to become a Senior Engineer are only half of the equation.
I say this all as a (non-senior) engineer who finds he often has a hard time with communication and interpersonal skills. I'm growing technically, but I've got to work way harder to grow those soft skills at the same rate.
Absolutely. Maybe this can work if you only work around other engineers who are able to (somewhat) accurately judge the quality of your work and opinions based on their own knowledge. As soon as you're dealing with other departments or clients who do not have the ability to correctly judge your competence they latch on to other methods of ranking you, which will be word of mouth, and failing that, title.
I have a similar experience, although so far it is only with one company so far. The company claimed to be flat, but it ended up being the loudest/most obstinate that ended up influencing the technical decisions.
I prefer more structure now to avoid running into that sort of situation.
I prefer more structure now to avoid running into that sort of situation.
I agree.
Another way of looking at it is if title is not defining scope of something, then what is its purpose?
Another way of looking at it is if title is not defining scope of something, then what is its purpose?
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.
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"
Beware of "I didn't get (much of) a raise but I got a promotion"
See also: "The 7 Habits of Highly Overrated People":
http://www.daedtech.com/the-7-habits-of-highly-overrated-peo...
HN discussion: https://news.ycombinator.com/item?id=6965295
http://www.daedtech.com/the-7-habits-of-highly-overrated-peo...
HN discussion: https://news.ycombinator.com/item?id=6965295
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.
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.
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.
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.
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.
I was once offered a job where I got to choose my own title, so I chose Sales Engineer. My response, when the contract said "Senior Engineer" was predictable enough, met with "you were serious about that? Titles don't matter here." They appear to matter quite a lot to the people making statements like that -- I made my employment conditional on being able to choose responsibilities and role, and ended up walking away.
See the top comment, about whether or not this article is just Talkers with their sound and fury, signifying nothing.
See the top comment, about whether or not this article is just Talkers with their sound and fury, signifying nothing.
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.
Personally, I found it exceptionally well summarized. For me, the usefulness is in striving to not fall into one of these categories (as the conclusion hints, I certainly have the potential to end up that way from time to time). I could translate these anti-patterns to a list of advice (though I think it's better to read the original post):
Thinker: Design, but also don't hesitate to execute.
Talker: Discuss, but make sure the the discussion is fruitful, succinct and to the point.
The Entitled: Don't care too much about my title or titles of others - we are all working together to achieve some goal.
The Owner: Be open to suggestions and changes by others to ideas and code that originated with me.
The Recluse: No matter my specialization, I have to be able to pick up new technologies and processes, instead of blindly delegating every item I feel is not part of my expertise.
Thinker: Design, but also don't hesitate to execute.
Talker: Discuss, but make sure the the discussion is fruitful, succinct and to the point.
The Entitled: Don't care too much about my title or titles of others - we are all working together to achieve some goal.
The Owner: Be open to suggestions and changes by others to ideas and code that originated with me.
The Recluse: No matter my specialization, I have to be able to pick up new technologies and processes, instead of blindly delegating every item I feel is not part of my expertise.
Me too. I wouldn't want to work for Eric. He is a management anti-pattern.
Ditto.
And one that hassn't heard of Belbin and his work on team roles.My top 3 where Plant, Resource Investiagtor and Chair
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.
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.
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.
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.
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.
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.
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
Move fast, break a few things and
What does 'T-shaped' mean in this context?
[deleted]
The vertical stroke represents deep knowledge in a small area, and the horizontal stroke means they have some understanding of many other areas.
It means deep knowledge/mastery of a specific skill, plus broad knowledge of many other skills. Kind of like a jack of all trades and master of one.
> 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.
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.
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.
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.
[deleted]
The counter to that is The Recluse, which tech industries seem to have far too many of.
That's because the recluse + the owner = job security
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.
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.
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.
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.
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.
(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).
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).
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.
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.
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.
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.
[deleted](1)
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.
Would be more sympathetic if he described a path for growing from a developer to a board member in their company.
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.
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.
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...
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
[1] http://www.slideshare.net/bcantrill/surge2013
tl;dr: labels I assign to people I don't like
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?