6 ms·

3.4. The Procrastinator 3.5. The Lone Wolf 3.6. The Negative Nancy 3.7. The Over-Promiser 3.8. The Know-It-All 3.9. The Silent Type 3.10. The Perfectionist 3.11

by danwee 3y ago

3.4. The Procrastinator 3.5. The Lone Wolf 3.6. The Negative Nancy 3.7. The Over-Promiser 3.8. The Know-It-All 3.9. The Silent Type 3.10. The Perfectionist 3.11. The Unreliable One 3.12. The Conflict Instigator 3.13. The Burned-Out Employee I have experienced myself being one of each type of "difficult" software engineer during my career. Not every day, not every month, but from time to time. Sometimes because of the environment (e.g., type of company I worked for), sometimes because of internal issues (e.g., family issues), and sometimes because I really felt like that (e.g., when I was in my mid 20s). I haven't met any engineer who's never shown any traits of the thirteen "personas" listed in the post. If you're looking for an engineer that has zero traits like the ones listed above, you are perhaps looking for a robot.

glimshe 3y ago
Expand your last paragraph to apply to almost all human beings in any industry. There are burned-out doctors, know-it all priests, negative nancy teachers, perfectionist lawyers and silent type librarians. Perhaps what's special for Software Engineers is that it's a profession with a skew towards younger workers, so you might see larger groups of people who are still emotionally immature, and thus displaying these traits, than in other industries.
flir 3y ago
> e.g., when I was in my mid 20s Lone Wolf?
- LeoNatan25 3y ago
  I’ve become more of a lone wolf in my 30s, actually. A combination of gained knowledge and experience, teams not familiar with my tech stack, remote hours (both because of timezone difference and also my crazy work hours) and also, yes, less trust in other people’s opinions. This also happens. It’s not just teenagers that feel sometimes they have the most experienced opinion. After listening to bad discussion for long enough, one becomes burned out and cynical of the “team discussions” and just looks inward to find solutions for the most difficult problems.
  - diarrhea 3y ago
    > teams not familiar with my tech stack Not the other way around?
    - LeoNatan25 3y ago
      It’s all about perspective. In two companies now, I’ve been in teams that don’t really care about my tech stack. It was mutual, of course. You can blame the company for making these teams up (I did/do), but that how things are.
      - ohyes 3y ago
        Normally the technology stack refers to the languages and frameworks underpinning the project. It is very weird to be in a situation where (for example) we’re working on a project in python and one person refuses to use python. Weird enough that I’ve never seen anyone with a personal tech stack, most people just try to adopt the local custom of the team they’re hired into.
        LeoNatan25 3y ago
        In my previous job, I was hired into a team of tech leads, each in their own field. In the current job, I was hired into a product team that was about a macOS app. After several reorgs, mergers and downsizing, the team is mostly web devs, backend devs (Go) and me, still developing the macOS app. Why should I care about the teams’ other tech stacks (and vice versa)?
        flir 3y ago
        I understand now. In my terms, you're a team of one who happens to be sitting next to another team, maybe under the same manager. That sucks, I feel for you.
        ohyes 3y ago
        Do they not care about what happens if you decide you want more money, want to do something else, or just get frustrated and quit?
diarrhea 3y ago
Exactly what I wanted to say! Out of the list, I can identify with most things. Almost scary... I think what's most important is to be aware. If traits aren't too pronounced, betterment is possible, and awareness helps eventually taming them. There's no need to eradicate: as you put it, the end game of that is a robot.
ukj 3y ago
I can identify with every one of the items on that list. I can also identify that about 60-80% of the time I've been called a "procrastinator"; or a lone wolf; or a negative nancy (or any one of the pejoratives) it's because I've been fed bad incomplete or incorrect information about what's expected from me or from the team. >"you are perhaps looking for a robot." It's clear from the definition... I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required. Everything's always going smoothly with my computers they do exactly as I tell them. It's just humans that constantly misunderstand my managerial instructions.
rollcat 3y ago
Second that, reading through the article felt like looking in a mirror. It's helpful to be more self-conscious about one's flaws, at least you can spot yourself doing the thing and get a chance at reversing course. To people who also see themselves here, but weren't fortunate enough to be working with a smart and compassionate manager: - Listen to the feedback from your peers. Go have after-work beers if a more formal setting doesn't work. - Figure out if you can move horizontally within your org, to a position where either your flaws won't be getting as much in your or someone else's way, or - if you're brave - to a less comfortable position, where you need to face and fix them. - Show the article to your manager! Understanding is an acquired thing.
intelVISA 3y ago
> you are perhaps looking for a robot Ah yes, the LLM persona: the Hallucinator.
- js8 3y ago
  My former boss had an employee like that. He was prolific, but his code was extremely convoluted and had complicated solutions to simple problems.
  - StackOverlord 3y ago
    I've been categorized as such for having the audacity of writing a tree traversal function.
    - SkyPuncher 3y ago
      Was it strictly necessary? I’ve worked on a code base where someone implemented the core data structure as a tree instead of a simpler data structure. It was completely unnecessary for performance and killed productivity on the project.
      - StackOverlord 3y ago
        You will be the judge. I was tasked of enabling us to backtrack on our decision of building a microservice rather than a library. The service was using postgres, and was connected to multiple website, one of which was targeted to use the service as a library. The challenge lied in the fact we used JSON to store some metadata as a shallow tree of depth 2-3, and the targeted website used mysql (which did not support JSON data at the time). Concretely it required to introduce edits in more than 300 files and manually take care of parsing a couple datetimes. Maybe there were other gotchas I have forgotten but it was hard enough with respect to the test suite I decided to write an ORM adapter to add support for json in mysql (dump it as a string, retrieve it, parse the string as native datastructures, walk the tree to convert datetime strings). I know this sounds crude, but it was enough for these tiny JSON data we only looked at when investigating problems at the command line. I took the steps to isolate this adapter as an independent library so that we could take the same decision of transforming the microservice as a library dependency on other websites we maintained ... basically at the cost of adding a library dependency in the project config. After a code review that astutely pointed out my adapter ran at every loading of an object from the database (which I corrected by running it lazily upon accessing specific fields), it was decided my code was a gas factory and the CTO proceeded to do the right thing, get rid of that perky – but working and ready to go in production ! – library (took me 2 days to write) and just update the damn code. 3 days later he still wasn't finished with the 300 files edits, and he ended up abandoning and splitting the library in two. One would be used by the microservice, and the other as a library on the website. He traded treewalking our datastructures with treewalking our codebases, program efficiency with programmers efficiency (we were 15 on the team while our competitors had 50 devs). This way any modification brought to that service/library: - is not transferred to the other version, leading to organizational complexity - is transferred and the time it takes to dev a features is multiplied by a number between 1 and 2. - or there are complex surprises under the surface and this factor is greater than 2.
vasco 3y ago
Whenever you see someone describe "types of people" you should have the understanding that nobody has a type. People behave in complex ways and display traits that can be attributed to several types. Like a scientific model that has limits, putting fictional people into types allows us to describe patterns of behavior and their caracteritics in better ways than just going "ahhh chuck everyone is different there's nothing I can learn". You can apply this thinking to "archetypes of staff engineers" or any sort of personality trait quiz that purports to find your "type". I'm always surprised when people think that other people actually fit into a box while obviously seeing that themselves could fit into many boxes at different times.
- uoaei 3y ago
  You can think of archetypes as "principal components" if it helps to assuage the reaction to being unfairly labeled or pigeonholed. People are more or less of one thing or another and the loadings change over time and depending on circumstances. The goal is not to build a set of discrete categories but to build a vector space of sorts.
  - ukj 3y ago
    There's no such thing as "principal component" to a human. To quote Walt Whitman - I am large, I contain multitudes. There's only the particular behaviour that's getting in your way within a given context. The bug you have to patch to make me line up with your expectations. What the author describes as "procrastination" (focusing on less important tasks while ignoring the critical ones.) in one context is "attention to detail" in another.
    - thfuran 3y ago
      They mean principal component as in principal component analysis. There can be a multitude of principal components.
      - ukj 3y ago
        I know what they mean and we aren't disagereing. Given that we are a complex multitude of principle components the single principle component in focus and of interest to a manager is that which the manager has (mis?)identified as the minimum viable change in behaviour necessary to get the employee back on track. They've already done the analysis - the employee's behaviour is the problem now all the manager just has to correct it. Even if the behaviour is intentional and rational given the employee's (mis?)understanding of the situation; or a systemic organizational failure of sorts. But hey, pointing out systemic issues which are making it difficult to deliver in accordance with expectations is confirming what the manager already believes - that the engineer is difficult to manage. It would be so much easier if the engineer just shuts up and does what they are told... All these strong opinons aren't necessary from people with zero autonomy.
jacquesm 3y ago
Those are symptoms, not causes...
antonvs 3y ago
I think I have about seven of those simultaneously. But the classification instinct is strong in some people, which is how we end up with systems like MBTI and, worse, why people buy into them.
jansan 3y ago
Moreover, you can be multiple types of software engineer at the same time. I am currently working on two projects. On one I am unfortunately the "Over-Promiser", because I frequently underestimate how bad the legacy code is that we are working on (and how litte we are motivated on this project). On the other project, that is actually quite awesome, I am the "Lone Wolf", because I actually know how to do things best for parts of the project. I hate being the Over-Promiser and love being the Lone Wolf.
hobofan 3y ago
It's okay to have some of those traits, but I've also experienced colleagues which were basically comic book versions of some those types to the point that they ended up being impossible to work with. While I think that the author could have done a better job at humanizing the engineers, I think the post in general offers some quite reasonable suggestions on how to help the engineers help themselves (rather than traditional micromanagement suggestions).
StackOverlord 3y ago
3.14 the one you call back one full year after he left because otherwise you're fired as a manager.
chasd00 3y ago
“Pobody’s nerfect”. The ones who refuse to acknowledge their shortcomings, refuse to adapt and learn, to try something new, those are the difficult ones.
p0nce 3y ago
Now I imagine a list of similar personnalities for codebases: 1. The Sand Tower. 2. The Sacred Pile of Poo 3. The closed Clue Shop. 4. For the Family 5. The Spreadsheet 6. The Silent Trainwreck. 7. The Warden 8. Gilga-mesh

by danwee 3y ago

glimshe 3y ago

Expand your last paragraph to apply to almost all human beings in any industry. There are burned-out doctors, know-it all priests, negative nancy teachers, perfectionist lawyers and silent type librarians. Perhaps what's special for Software Engineers is that it's a profession with a skew towards younger workers, so you might see larger groups of people who are still emotionally immature, and thus displaying these traits, than in other industries.

flir 3y ago

> e.g., when I was in my mid 20s Lone Wolf?

LeoNatan25 3y ago
I’ve become more of a lone wolf in my 30s, actually. A combination of gained knowledge and experience, teams not familiar with my tech stack, remote hours (both because of timezone difference and also my crazy work hours) and also, yes, less trust in other people’s opinions. This also happens. It’s not just teenagers that feel sometimes they have the most experienced opinion. After listening to bad discussion for long enough, one becomes burned out and cynical of the “team discussions” and just looks inward to find solutions for the most difficult problems.
- diarrhea 3y ago
  > teams not familiar with my tech stack Not the other way around?
  - LeoNatan25 3y ago
    It’s all about perspective. In two companies now, I’ve been in teams that don’t really care about my tech stack. It was mutual, of course. You can blame the company for making these teams up (I did/do), but that how things are.
    - ohyes 3y ago
      Normally the technology stack refers to the languages and frameworks underpinning the project. It is very weird to be in a situation where (for example) we’re working on a project in python and one person refuses to use python. Weird enough that I’ve never seen anyone with a personal tech stack, most people just try to adopt the local custom of the team they’re hired into.
      - LeoNatan25 3y ago
        In my previous job, I was hired into a team of tech leads, each in their own field. In the current job, I was hired into a product team that was about a macOS app. After several reorgs, mergers and downsizing, the team is mostly web devs, backend devs (Go) and me, still developing the macOS app. Why should I care about the teams’ other tech stacks (and vice versa)?
        flir 3y ago
        I understand now. In my terms, you're a team of one who happens to be sitting next to another team, maybe under the same manager. That sucks, I feel for you.
        ohyes 3y ago
        Do they not care about what happens if you decide you want more money, want to do something else, or just get frustrated and quit?

diarrhea 3y ago

Exactly what I wanted to say! Out of the list, I can identify with most things. Almost scary... I think what's most important is to be aware. If traits aren't too pronounced, betterment is possible, and awareness helps eventually taming them. There's no need to eradicate: as you put it, the end game of that is a robot.

ukj 3y ago

I can identify with every one of the items on that list. I can also identify that about 60-80% of the time I've been called a "procrastinator"; or a lone wolf; or a negative nancy (or any one of the pejoratives) it's because I've been fed bad incomplete or incorrect information about what's expected from me or from the team. >"you are perhaps looking for a robot." It's clear from the definition... I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required. Everything's always going smoothly with my computers they do exactly as I tell them. It's just humans that constantly misunderstand my managerial instructions.

rollcat 3y ago

Second that, reading through the article felt like looking in a mirror. It's helpful to be more self-conscious about one's flaws, at least you can spot yourself doing the thing and get a chance at reversing course. To people who also see themselves here, but weren't fortunate enough to be working with a smart and compassionate manager: - Listen to the feedback from your peers. Go have after-work beers if a more formal setting doesn't work. - Figure out if you can move horizontally within your org, to a position where either your flaws won't be getting as much in your or someone else's way, or - if you're brave - to a less comfortable position, where you need to face and fix them. - Show the article to your manager! Understanding is an acquired thing.

intelVISA 3y ago

> you are perhaps looking for a robot Ah yes, the LLM persona: the Hallucinator.

js8 3y ago
My former boss had an employee like that. He was prolific, but his code was extremely convoluted and had complicated solutions to simple problems.
- StackOverlord 3y ago
  I've been categorized as such for having the audacity of writing a tree traversal function.
  - SkyPuncher 3y ago
    Was it strictly necessary? I’ve worked on a code base where someone implemented the core data structure as a tree instead of a simpler data structure. It was completely unnecessary for performance and killed productivity on the project.
    - StackOverlord 3y ago
      You will be the judge. I was tasked of enabling us to backtrack on our decision of building a microservice rather than a library. The service was using postgres, and was connected to multiple website, one of which was targeted to use the service as a library. The challenge lied in the fact we used JSON to store some metadata as a shallow tree of depth 2-3, and the targeted website used mysql (which did not support JSON data at the time). Concretely it required to introduce edits in more than 300 files and manually take care of parsing a couple datetimes. Maybe there were other gotchas I have forgotten but it was hard enough with respect to the test suite I decided to write an ORM adapter to add support for json in mysql (dump it as a string, retrieve it, parse the string as native datastructures, walk the tree to convert datetime strings). I know this sounds crude, but it was enough for these tiny JSON data we only looked at when investigating problems at the command line. I took the steps to isolate this adapter as an independent library so that we could take the same decision of transforming the microservice as a library dependency on other websites we maintained ... basically at the cost of adding a library dependency in the project config. After a code review that astutely pointed out my adapter ran at every loading of an object from the database (which I corrected by running it lazily upon accessing specific fields), it was decided my code was a gas factory and the CTO proceeded to do the right thing, get rid of that perky – but working and ready to go in production ! – library (took me 2 days to write) and just update the damn code. 3 days later he still wasn't finished with the 300 files edits, and he ended up abandoning and splitting the library in two. One would be used by the microservice, and the other as a library on the website. He traded treewalking our datastructures with treewalking our codebases, program efficiency with programmers efficiency (we were 15 on the team while our competitors had 50 devs). This way any modification brought to that service/library: - is not transferred to the other version, leading to organizational complexity - is transferred and the time it takes to dev a features is multiplied by a number between 1 and 2. - or there are complex surprises under the surface and this factor is greater than 2.

vasco 3y ago

Whenever you see someone describe "types of people" you should have the understanding that nobody has a type. People behave in complex ways and display traits that can be attributed to several types. Like a scientific model that has limits, putting fictional people into types allows us to describe patterns of behavior and their caracteritics in better ways than just going "ahhh chuck everyone is different there's nothing I can learn". You can apply this thinking to "archetypes of staff engineers" or any sort of personality trait quiz that purports to find your "type". I'm always surprised when people think that other people actually fit into a box while obviously seeing that themselves could fit into many boxes at different times.

uoaei 3y ago
You can think of archetypes as "principal components" if it helps to assuage the reaction to being unfairly labeled or pigeonholed. People are more or less of one thing or another and the loadings change over time and depending on circumstances. The goal is not to build a set of discrete categories but to build a vector space of sorts.
- ukj 3y ago
  There's no such thing as "principal component" to a human. To quote Walt Whitman - I am large, I contain multitudes. There's only the particular behaviour that's getting in your way within a given context. The bug you have to patch to make me line up with your expectations. What the author describes as "procrastination" (focusing on less important tasks while ignoring the critical ones.) in one context is "attention to detail" in another.
  - thfuran 3y ago
    They mean principal component as in principal component analysis. There can be a multitude of principal components.
    - ukj 3y ago
      I know what they mean and we aren't disagereing. Given that we are a complex multitude of principle components the single principle component in focus and of interest to a manager is that which the manager has (mis?)identified as the minimum viable change in behaviour necessary to get the employee back on track. They've already done the analysis - the employee's behaviour is the problem now all the manager just has to correct it. Even if the behaviour is intentional and rational given the employee's (mis?)understanding of the situation; or a systemic organizational failure of sorts. But hey, pointing out systemic issues which are making it difficult to deliver in accordance with expectations is confirming what the manager already believes - that the engineer is difficult to manage. It would be so much easier if the engineer just shuts up and does what they are told... All these strong opinons aren't necessary from people with zero autonomy.

jacquesm 3y ago

Those are symptoms, not causes...

antonvs 3y ago

I think I have about seven of those simultaneously. But the classification instinct is strong in some people, which is how we end up with systems like MBTI and, worse, why people buy into them.

jansan 3y ago

Moreover, you can be multiple types of software engineer at the same time. I am currently working on two projects. On one I am unfortunately the "Over-Promiser", because I frequently underestimate how bad the legacy code is that we are working on (and how litte we are motivated on this project). On the other project, that is actually quite awesome, I am the "Lone Wolf", because I actually know how to do things best for parts of the project. I hate being the Over-Promiser and love being the Lone Wolf.

hobofan 3y ago

It's okay to have some of those traits, but I've also experienced colleagues which were basically comic book versions of some those types to the point that they ended up being impossible to work with. While I think that the author could have done a better job at humanizing the engineers, I think the post in general offers some quite reasonable suggestions on how to help the engineers help themselves (rather than traditional micromanagement suggestions).

StackOverlord 3y ago

3.14 the one you call back one full year after he left because otherwise you're fired as a manager.

chasd00 3y ago

“Pobody’s nerfect”. The ones who refuse to acknowledge their shortcomings, refuse to adapt and learn, to try something new, those are the difficult ones.

p0nce 3y ago

Now I imagine a list of similar personnalities for codebases: 1. The Sand Tower. 2. The Sacred Pile of Poo 3. The closed Clue Shop. 4. For the Family 5. The Spreadsheet 6. The Silent Trainwreck. 7. The Warden 8. Gilga-mesh