101–110 of 514 posts
Earlier quoted context omitted.
Rust may still be a bit too pragmatic, perhaps you could use a language you wrote yourself?
"Aaaand that's the container address orchestrator -- it's written in Haskell by that one guy a few years ago."
Earlier quoted context omitted.
Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to rem…
You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?
If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes:
"You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?"
When said this way, doesn't seem like "waste" to me, rather a regular part of the job. If the person working the bug doesn't know how bad it is, then who does?
You forgot the most crucial part to making a career in big corps: After you fucked everything up "rescue" the project with witnesses.
TLDR: customers don't pay for beautiful, elegant code dealing with the happy path only.
A friend of mine accidentally wiped out over 100k hours of other researcher's computing operations the other day, does that make him a -100,000x engineer?
The person who wiped out the data should be thanked for uncovering the serious problem.
A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
Author here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?
Earlier quoted context omitted.
The article is good at making a point of what is bad and for the fun of it. However, it is not successful at compassionately explaining what one should strive to instead as there is no simple negation of the points being made.
It is not the responsibility of a person pointing out problems to also solve them. Granted, pointing out problems is generally much easier than solving them, and correspondingly less valuable. As I like to say, stand up, spin around, and point at something randomly. You're pointing at a problem of some sort. But that still does not incur a responsibility to someone pointing out a problem to also solve it. It's a popu…
The problem with the article is even though it’s right it makes no attempt to explain why, and blames bad people for the problems instead of understanding why they might be acting like they are.
A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
Author here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?
If you're offended, this article is probably for you.
> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
Yeah, in my experience writing complete tickets forces people to actually think through designs and trade-offs. It also has the nice benefit of exposing their thinking to others in the organization, who can weigh in and go, "Oh, if you're doing that , we have to do this on our project."
Do you spend more time wrangling over the ticket content or the format? Do you spend more time discussing context & requirements, or story points? Etc