8 ms·

Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive i

Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :) My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc). Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it. Next year the damage will probably be worse given the rapid outflow of talent.

ironmagma 4y ago
As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
- silon42 4y ago
  Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...
- whydid 4y ago
  Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
  - bosie 4y ago
    > If someone hasn't taken the time to learn the tools their team uses, How does your company handle this? How do you give the people the time/resources to learn those tools?
    - ratww 4y ago
      My company handles this by allowing them to study on the dime. I just ask how much time they want and ask them to do it, and if they need some material or help devising a study plan. Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).
  - ironmagma 4y ago
    I've never seen documentation on Git that was good and accurate. Pretty much every explainer out there commits major errors, claiming things like: commits are changesets, branches are sets of commits, claiming that any Git operation can be undone, implying merge is a symmetrical operation, or saying to never force push. Being a beginner in Git is probably hell.
- dghf 4y ago
  But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.
  - kevinventullo 4y ago
    Don’t forget the most important operation: rm -rf the whole directory and re-clone the main repo.
    - cyberge99 4y ago
      git reset HEAD —hard
    - bluefirebrand 4y ago
      Yep and if that doesn't work? Sudo rm -rf
- lazide 4y ago
  If someone has no idea what ‘git add’ is, the criticism is still on point.
- dbwjxufh7373 4y ago
  I don't think they were. Software devs hitting the job without understanding git means your hiring team is sleeping on the job.
romanovcode 4y ago
> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!
- marginalia_nu 4y ago
  If we move to a microservices architecture, we can use 100 developers to solve same the same problem in with ten times the hardware! With growth like that, we'll be unstoppable!
  - speedgoose 4y ago
    Make sure to deploy your micro services in Microsoft Azure AKS to improve the reliability on the long term, thanks to the included and frequent network issues.
  - devoutsalsa 4y ago
    How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.
    - torginus 4y ago
      That has more downtime during upgrades than my college dorm Counter-Strike server built from leftover PC components ever had.
- threatripper 4y ago
  It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.
sokoloff 4y ago
It’s hilarious to me to think “let’s put all the managers on one team…”
- dreamcompiler 4y ago
  Reminds me of the B Ark. https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...
JonChesterfield 4y ago
Manager (or possibly his boss) needs a leaving present of the mythical man month
- intelVISA 4y ago
  They'd probably fail to see the correlation in having their senior ICs occupied re-explaining Git to a constantly rotating offshore roster -- they're getting 10 engineers for the price of 1 after all.
sascha_sl 4y ago
There hasn't been a single job where I didn't have to explain Git to someone. Or that Git is not GitHub. Wherever I was somehow in charge of some authentication / account management (never been my primary responsibility, but "people who know cloud" teams often get that honor anyway) I have always had someone who didn't understand MFA. Either they assumed because MS Authenticator sends them a push, AWS should send them a push or they would have a clock desynced so hard that the most generous TOTP grace windows couldn't save them. My partner is in a place right now that had to be introduced to python dependency management. Really. No containers or anything like that either. Just alternate runing the script and installing the latest of a package until the import errors disappear. I really don't mind tutoring, but many of these people also would rather wait 20 minutes for you to respond than 5 minutes on Google. Or even your internal documentation. That's linked in the Slack channel they're asking. It drives me nuts people value their peers time so little.
pmontra 4y ago
Some managers do that kind of things to prepare the next step of their career or because they worked for the company they are hiring (which is a variation of the first point.)
steveBK123 4y ago
Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO. Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year.. The median senior now has 1 year on the team versus previous median of 3 years. There's basically no institutional knowledge on the team anymore. Managers have now convinced themselves that all these green engineers are going to build v2.0.. however they are basically recommitting all the mistakes and suffering all the pitfalls that v1.0 did because.. no one is left to ask..
- uwuemu 4y ago
  I just want to know how do you keep a job as a manager when you fuck up so badly. The vast majority of what seniors bring to the table is experience. That is also what you pay for. That experience is not like gold, it's like a gold mine - you have to mine it first, then bring it to the surface and only then you can profit off it. The fact that there are software houses out there that do not understand this is amazing (in a bad way). I mean I guess there is some value in a senior dev coding menial tasks (generally more mature, less error prone code with the right amount of abstractions), but that like saying there is some value in a rocket engine pulling a plough... technically true, but not really economical and there's a pretty good chance of most of your rocket engines going away rather quickly.
  - steveBK123 4y ago
    Larger cultural issues: Bad engineering - product relationship Inability to set priorities Zero roadmaps No annual/quarterly objectives The only thing that mattered was the thing someone was screaming about right that minute Manager walked rather than deal with it anymore as well..
BeetleB 4y ago
> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are willing to read. Be it for learning or for understanding specs. I'm not one of those people who gets upset at people coming to my cube to ask questions - I actually enjoy it (far more than them IM'ing me). But if it's something easy to find on the Internet, or clearly documented in a local wiki/manual, they should have at least tried to read it. Similarly, I'll take the time to document very well how a tool I built works. Almost always someone will then come to me and ask "Hey, can you tell me what the tool does and show me how to use the tool?" Over 90% of the times it's not because my documentation is bad (which I admit it very well could be), but because they didn't even try to read it.
- no-s 4y ago
  > Hire people who can and are willing to read. Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)
  - ratww 4y ago
    Reading is a huge problem with certain developers. It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation. (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
    - BeetleB 4y ago
      > (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it) Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who have no idea they're getting errors: "I just hit Enter so I can get to the program."
jnwatson 4y ago
An interesting sociological question arises about how knowledge is passed down through generations. One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago. If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?
- ratww 4y ago
  I knew a CEO that claimed that Mythical Man Month was his favourite book. As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book. People just don't read. Or admit THEY are at fault.

ironmagma 4y ago

As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.

silon42 4y ago
Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...
whydid 4y ago
Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
- bosie 4y ago
  > If someone hasn't taken the time to learn the tools their team uses, How does your company handle this? How do you give the people the time/resources to learn those tools?
  - ratww 4y ago
    My company handles this by allowing them to study on the dime. I just ask how much time they want and ask them to do it, and if they need some material or help devising a study plan. Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).
- ironmagma 4y ago
  I've never seen documentation on Git that was good and accurate. Pretty much every explainer out there commits major errors, claiming things like: commits are changesets, branches are sets of commits, claiming that any Git operation can be undone, implying merge is a symmetrical operation, or saying to never force push. Being a beginner in Git is probably hell.
dghf 4y ago
But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.
- kevinventullo 4y ago
  Don’t forget the most important operation: rm -rf the whole directory and re-clone the main repo.
  - cyberge99 4y ago
    git reset HEAD —hard
  - bluefirebrand 4y ago
    Yep and if that doesn't work? Sudo rm -rf
lazide 4y ago
If someone has no idea what ‘git add’ is, the criticism is still on point.
dbwjxufh7373 4y ago
I don't think they were. Software devs hitting the job without understanding git means your hiring team is sleeping on the job.

romanovcode 4y ago

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!

marginalia_nu 4y ago
If we move to a microservices architecture, we can use 100 developers to solve same the same problem in with ten times the hardware! With growth like that, we'll be unstoppable!
- speedgoose 4y ago
  Make sure to deploy your micro services in Microsoft Azure AKS to improve the reliability on the long term, thanks to the included and frequent network issues.
- devoutsalsa 4y ago
  How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.
  - torginus 4y ago
    That has more downtime during upgrades than my college dorm Counter-Strike server built from leftover PC components ever had.
threatripper 4y ago
It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

sokoloff 4y ago

It’s hilarious to me to think “let’s put all the managers on one team…”

dreamcompiler 4y ago
Reminds me of the B Ark. https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...

JonChesterfield 4y ago

Manager (or possibly his boss) needs a leaving present of the mythical man month

intelVISA 4y ago
They'd probably fail to see the correlation in having their senior ICs occupied re-explaining Git to a constantly rotating offshore roster -- they're getting 10 engineers for the price of 1 after all.

sascha_sl 4y ago

There hasn't been a single job where I didn't have to explain Git to someone. Or that Git is not GitHub. Wherever I was somehow in charge of some authentication / account management (never been my primary responsibility, but "people who know cloud" teams often get that honor anyway) I have always had someone who didn't understand MFA. Either they assumed because MS Authenticator sends them a push, AWS should send them a push or they would have a clock desynced so hard that the most generous TOTP grace windows couldn't save them. My partner is in a place right now that had to be introduced to python dependency management. Really. No containers or anything like that either. Just alternate runing the script and installing the latest of a package until the import errors disappear. I really don't mind tutoring, but many of these people also would rather wait 20 minutes for you to respond than 5 minutes on Google. Or even your internal documentation. That's linked in the Slack channel they're asking. It drives me nuts people value their peers time so little.

pmontra 4y ago

Some managers do that kind of things to prepare the next step of their career or because they worked for the company they are hiring (which is a variation of the first point.)

steveBK123 4y ago

Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO. Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year.. The median senior now has 1 year on the team versus previous median of 3 years. There's basically no institutional knowledge on the team anymore. Managers have now convinced themselves that all these green engineers are going to build v2.0.. however they are basically recommitting all the mistakes and suffering all the pitfalls that v1.0 did because.. no one is left to ask..

uwuemu 4y ago
I just want to know how do you keep a job as a manager when you fuck up so badly. The vast majority of what seniors bring to the table is experience. That is also what you pay for. That experience is not like gold, it's like a gold mine - you have to mine it first, then bring it to the surface and only then you can profit off it. The fact that there are software houses out there that do not understand this is amazing (in a bad way). I mean I guess there is some value in a senior dev coding menial tasks (generally more mature, less error prone code with the right amount of abstractions), but that like saying there is some value in a rocket engine pulling a plough... technically true, but not really economical and there's a pretty good chance of most of your rocket engines going away rather quickly.
- steveBK123 4y ago
  Larger cultural issues: Bad engineering - product relationship Inability to set priorities Zero roadmaps No annual/quarterly objectives The only thing that mattered was the thing someone was screaming about right that minute Manager walked rather than deal with it anymore as well..

BeetleB 4y ago

> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are willing to read. Be it for learning or for understanding specs. I'm not one of those people who gets upset at people coming to my cube to ask questions - I actually enjoy it (far more than them IM'ing me). But if it's something easy to find on the Internet, or clearly documented in a local wiki/manual, they should have at least tried to read it. Similarly, I'll take the time to document very well how a tool I built works. Almost always someone will then come to me and ask "Hey, can you tell me what the tool does and show me how to use the tool?" Over 90% of the times it's not because my documentation is bad (which I admit it very well could be), but because they didn't even try to read it.

no-s 4y ago
> Hire people who can and are willing to read. Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)
- ratww 4y ago
  Reading is a huge problem with certain developers. It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation. (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
  - BeetleB 4y ago
    > (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it) Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who have no idea they're getting errors: "I just hit Enter so I can get to the program."

jnwatson 4y ago

An interesting sociological question arises about how knowledge is passed down through generations. One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago. If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?

ratww 4y ago
I knew a CEO that claimed that Mythical Man Month was his favourite book. As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book. People just don't read. Or admit THEY are at fault.