101–110 of 113 posts
I had to look at the author's name to find out if I was Bob! Though the latter paragraphs about ignoring the other engineers requirements about reviews, etc don't fit. After a few gigs that didn't go great, I ended up at a research org, where my less than perfect code that would do things in a non-scalable way was actually appreciated and a benefit. This org had amazing engineering capabilities, and amazing research.…
Earlier quoted context omitted.
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.
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.
Have some conversations to build consensus with your team about what standards the codebase should be held to at this phase in its lifecycle, and when that decision should be revisited as the project matures and evolves.
It's fine to personally have high standards, but it's important to keep those distinct from the actual needs of the current development work.
For a given standard X like "always check errors" or whatever "Does this change maintain property X of the code?" is a very different question from "Is it worth maintaining property X in our codebase today".
Justifying that a change you advocate for is better is not enough; you also need to reach consensus on that improvement being worth the cost in time, complexity, maintenance, etc.
Also, don't try to revisit that consensus for small matters. Having consensus about what you're collectively aiming for, and people feeling confident that they're aiming at a stable target, is itself extremely important, and is worth trading off a bit of code quality for.
Something else I find really helpful for building credibility in your proposals being well-calibrated instead of universally "do better" is to look for opportunities to change your mind, to be persuaded by someone's argument, and for opportunities to say "This is great as-is; no need for complication here" or "Thanks for keeping this simple". You might consider aiming for "good taste and well-calibrated standards" as a replacement for "high standards".
Help people feel confident that you will advocate for lower standards when appropriate, and they'll believe you way more when you advocate that higher standards are worth it in a specific situation.
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.
Imposing preferences on others via the mantle of "best practices" is a great way to annoy them.
Earlier quoted context omitted.
> 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.
High code standards or specific preferences? Are your comments more like, "If this receives two requests at once it will result in a race condition" or more of the "you used tabs but I like spaces" sort? Imposing preferences on others via the mantle of "best practices" is a great way to annoy them.
The article fails to address when the firing is actually wrong and incorrect. I work at anduril and I know of a new manager who 6 months into the job fired 2 people and had one person quit because he couldn't handle dealing with him. The manager obviously is blind to see the statistical significance of that many people gone in 6 months. He likely views it as a performance problem of 3 people rather then the more like…
You can't tell from "statistical significance" if a firing is good or not. Maybe those three people have needed to be fitted for a while. Maybe, as the article says, it comes down to job-fit and the three employees are great people in the wrong job.
There are bad managers. But you can't identify them solely based on numerical analysis of turnover.
> 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?
There is no book to teach these parts. Books teach some simple principles but there are many right ways to write code. Ask your manager and coworkers for real feedback. Let them know that you can take anything. It even set up some anonymous feedback method. And no matter what they tell you don't get defensive. Just say thank you for the feedback and reflect on it later. You can even get mad later but still please try…
Either people won't trust it's 100% anonymous, won't see an upside for themselves or maybe bad actors.
Earlier quoted context omitted.
"evidence a very poorly performing employee was reading articles on the web most of the day" Sounds like probable cause for a warrant. Not that employers needs a warrant to use their own property, but to assure employees that they aren't being watched unless there's legitimate suspicion.
I think this is illegal in Europe or parts of Europe! I’d feel differently if you were told this would be happening.
Earlier quoted context omitted.
As a non manager, keeping parasites around is bad for moral.
Firing them is also bad for morale, for different reasons. Only solution is to not hire parasites in the first place.
Earlier quoted context omitted.
I think this is illegal in Europe or parts of Europe! I’d feel differently if you were told this would be happening.
I think the general rule in Europe is that your employer may record your screen as long as you know it's happening.