Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sunny side of firing someone

madned.substack.com

Post reply on HN
Print view View original

71–80 of 113 posts

Re: The sunny side of firing someone

#71

Post by sjg007 »

fired_but_ok wrote: post #29

I was fired from my first industry job. I had been thrilled to find my first role as a software developer, was making more money than I had ever made in my life, and my relationship with teammates started out super-pleasant. The team, and company-at-large, seemed similarly thrilled to be bringing me on-board. I was woefully unprepared, having worked mostly meaningless jobs up until then. I was complacent and lazy and…

It's good to see that you took the situation as an opportunity for personal growth.

Re: The sunny side of firing someone

#72

Post by itronitron »

mgomez wrote: post #9

> Bob did well on our interviews and was hired as a software developer in charge of infrastructure components. But it soon became apparent that his development habits were very heavily biased towards the hacking end of the spectrum. I'm primarily a self-taught developer. Can anyone recommend some resources (e.g., books about professional software engineering practices) so that I don't end up like Bob?

Regardless of whether you're self taught or minted from a program, the lesson to learn here is that your colleagues can get rid of you if your work doesn't conform to their expectations.

It's just as possible that Bob's colleagues were anally retentive simpletons that couldn't handle the truth of his code, as it is that Bob is a loosy-goosy house of cards coder whose results were always C- material (I've worked with both.)

Point being, if you want to keep your job you should aspire to be a good 'culture fit' and if you want to be a good developer then work with great people and read more source code than you write.

Re: The sunny side of firing someone

#73

Post by chiefalchemist »

higeorge13 wrote: post #63
deltaoneseven wrote: post #48

Earlier quoted context omitted.

This is done because when employees are let go they could become potentially hostile to the company. That's why they don't inform people beforehand of the firing. What should absolutely be done is inform him of the exact performance problem and steps to improve. An actual well intended PIP and not just a way to throw someone out.

I guess he means that they didn’t have any negative feedback until then.

Thank you.

Re: The sunny side of firing someone

#75

Post by armchairhacker »

worker767424 wrote: post #61
andy_ppp wrote: post #30

Earlier quoted context omitted.

Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a while you get fired…

> Smart...pleasant to work with Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.

if you want to enforce higher standards than your colleagues, you have to put in most of the work to reach those standards. For instance, if you think a section of a code needs unit tests, maybe write some of the tests yourself or at least suggest how to.

also be modest, and make sure to frame your standards as cooperating to improve the company’s code, not competing to show you’re a better programmer

the ultimate goal is to make your high standards more of an asset (“he’s improving the code”) then a burden (“he’s criticizing us and making us do more work”)

Re: The sunny side of firing someone

#76

Post by [deleted] »

sjg007 wrote: post #71
fired_but_ok wrote: post #29

I was fired from my first industry job. I had been thrilled to find my first role as a software developer, was making more money than I had ever made in my life, and my relationship with teammates started out super-pleasant. The team, and company-at-large, seemed similarly thrilled to be bringing me on-board. I was woefully unprepared, having worked mostly meaningless jobs up until then. I was complacent and lazy and…

It's good to see that you took the situation as an opportunity for personal growth.

[deleted]

Re: The sunny side of firing someone

#77

Post by dehrmann »

cyberpunk wrote: post #55
philovivero wrote: post #6

I've been in the unfortunate position of having had to fire about 5 people over my career. I take it as a very solemn responsibility that requires full attention and compassion for the person being fired. I make it a real conversation, where I try to make them fully understand the position of their teammates. What is interesting is that most of the time (4 of the 5 times) the person understands fully, gets their shit…

Literally the first day I got made head of engineering for the first time (so, running a group of dev teams, instead of just one) I was tasked with firing 20 engineers I had worked with for about 2 years. I helped about 60% of them find new jobs, and one entire team I managed to actually get hired together as a team (and they all got a pay raise), but baptism of fire or what. I got through a lot of whisky that week.…

> Literally the first day I got made head of engineering for the first time (so, running a group of dev teams, instead of just one) I was tasked with firing 20 engineers I had worked with for about 2 years.

I assume this was part of the deal? You can't say "hey, would you like to head-up engineering" without knowing this would be your first big assignment.

Re: The sunny side of firing someone

#78

Post by axiolite »

mkl95 wrote: post #22

Back when I was a junior developer I used to think tech companies -even the smallest ones- generally had some kind of reasonably accurate performance review process, where engineers who were underperforming for a while were eventually weeded out. In my experience ever since, that's simply not true. There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get aw…

> There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years.

That would be Wally from the Dilbert comic strips...

I have seen that when the employee in question has much lower salary requirements than others, appearing to provide a sort of false economy to management, even as their actual value is entirely negative.

I accidentally solved one of those problems, myself... having stumbled upon evidence a very poorly performing employee was reading articles on the web most of the day, only doing a few minutes of coding and taking some steps to hide logging of this fact (which was actually the part that caught my attention). Setting up screen recording and running it for several days hammered the point home. Said employee at the end of this period conveniently reported running into technical difficulties with their project, necessitating more time to work on it. That nicely drove the point home, putting the final nail in and effectively catapulting them out the door...

Re: The sunny side of firing someone

#79

Post by dehrmann »

mgomez wrote: post #9

> Bob did well on our interviews and was hired as a software developer in charge of infrastructure components. But it soon became apparent that his development habits were very heavily biased towards the hacking end of the spectrum. I'm primarily a self-taught developer. Can anyone recommend some resources (e.g., books about professional software engineering practices) so that I don't end up like Bob?

Build a medium-sized project on your own, especially one with evolving requirements. Bonus: come back to it 6 months later. You'll learn about scaling a codebase past 1000 lines (and maybe 10,000 lines), weigh the pros and cons of hacky workarounds, go through the pain of refactoring, and gain perspective about how projects evolve.

Re: The sunny side of firing someone

#80

Post by exdsq »

axiolite wrote: post #78
mkl95 wrote: post #22

Back when I was a junior developer I used to think tech companies -even the smallest ones- generally had some kind of reasonably accurate performance review process, where engineers who were underperforming for a while were eventually weeded out. In my experience ever since, that's simply not true. There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get aw…

> There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years. That would be Wally from the Dilbert comic strips... I have seen that when the employee in question has much lower salary requirements than others, appearing to provide a sort of false economy to management, even as their actual value is entirely negative. I accidentally solv…

A company secretly screen recording me makes me shiver
Post reply on HN