Hacker Newsnew | past | comments | ask | show | jobs | submit | throwaway9191aa's commentslogin

I very much recommend this book as well. Great read. Thanks for writing it!


Why are these comments saying that not doing a small part of a job that your boss doesn't want you to do is means for dismissal?

If something you are doing is being thrown away, you should change focus (like pulling back on quality of life arrests, and focus on real crimes).

If your boss is destroying all your work, you're going to get fired for not producing anything. I'd recommend you figure out what your boss cares about.


But that isn't what appears to be happening. Their "boss" (the DA) is the one saying "I don't want to". When your boss gives you clear incentives, like not prosecuting (throwing out) portions of your work, you are going to stop that work and focus on other things.


The DA is not their boss. Cops are supposed to enforce laws. The DA is supposed to prosecute them. The cops are just using the DA as an excuse to not do their jobs. And once you normalize the cops not arresting people, now the DA has an excuse for prosecuting fewer criminals - at that point how do you decide who's to blame? Now you have two dysfunctional organizations, each pointing the finger at the other, and you've already normalized at least one of them. Even if you think the cops shouldn't be arresting people because of the DA, at the very least this skews data on crime as police are making fewer arrests independent of crime levels.

This is like me saying I don't want to do my job because those other guys in the other department aren't going to do anything with it, so I'm just not going to bother. I think almost everyone can relate to lazy/incompetent coworkers - does that mean you should also be lazy/incompetent? The way to fight laziness is with hard work, and the way to fight incompetence is with competence. What you're advocating for just normalizes dysfunction.


This is why I joined AWS 9 years ago, and left the startup world. I own (still?) 15% of a company as a founding engineer (with no voting rights). As part of a raise, the company sold its IP to another company for a 0.5% stake in that company. So now I own 15% of 0.5%....... I just didn't understand the business side of all this at the start. As I understand it, the raise wouldn't have happened and the original company would have folded if the deal wasn't done, so you can't really argue fraud.

Since then, I have seen similar things happen more than once to other friends. I can only imagine that as the number get larger, the problems become more complex.


15% of 0.5% of a billion dollar company is just over $700,000. That's not FU money, but that's a down payment on a 3.5MM home.


My other option was AWS though. That $700k is like 4 years of effort, and I get vacations. Actually realizing a sale on a billion dollar company after 4 years is just incomprehensibly low. TBH Amazon is also less work than running a startup. If you think AWS oncall is bad, think about having even less people on your team to handle the load, or to build the product durably in the first place :)

Also, I have no way of knowing if the same ownership thing is going to happen again. Giving me another 0.5% of the above calculation. Sure, lots of people make millions in a startup. Way more people make millions, although over a longer time span, in tech companies and index funds.


I agree this is a great question. Maybe more for managers, but it let's people think "This is day 2 of that blocker, I need to step in". Sometimes junior devs will let external asks sit too long and write it off as "blocked on another team". Managers can manage this.


These three questions are intended to keep standups short. I haven't, personally, been on a team that sticks to this format. It always ends up with individuals talking about their individual implementation thoughts on whatever they are working on. During this time, others zone out, missing anything that could be important. Nobody learns anything, and nobody is able to fully concentrate on their tasks.

I purposefully schedule meetings after our standup to make sure I cut it off after 30 minutes. Our team of 11 will go for almost an hour if nobody cuts people off.


I had 8 people in standup today, the whole meeting took 4 minutes - mostly because of 2 people who had some after meeting news to share. As the team tech lead I need to keep track of what everyone is doing and just looking at stories in progress isn't enough to know if they are making progress or I need to jump in. (most of the time they are or they ask questions after the meeting). There is value in everyone knowing how the current story is progressing, but it should only be a few minutes. I run my standup 3x week as I don't need this daily, but I need to keep track that things are happening.


This is the way.

If a standup goes longer than 2 ish minutes a person, it's no longer a "stand up". Pull up a chair, sit down and chat, you're having a meeting.

The 3 questions could be answered in 1 to 2 sentences... the check in is for every one to see everyone else's face to inform secondary meetings.


There's many reasons I have my team do our standup in a designated chat room rather than in person.

One reason is because it eliminates facilitation on my part. I don't have to cut people off and make them stay on topic.


Ouch. 15 minutes is the rule. 30 minutes is way too long. I was in only one team that followed the rule, and after 15 minutes people would start leaving the room regardless of whether others are talking. If someone had a habit of speaking too much, he was coached.

When we were on site, we would try to schedule the room such that someone else had a booking at the 15 minute mark - so you had no choice but to keep it in that window.


This is easily solved by just having a facilitator who actually facilitates. Whether that's a scrum master, a manager, a team lead, or just a member of the team who isn't afraid to cut people off, it really is not that hard to keep standups to 15 minutes, maybe 20 for a team that big.


I started doing the listen-only as well! By this, I mean I just don't look at the screen, I'd love to know if there is a way to setup a listen-only option.

I've also used Jumpspeak, which is an AI conversation partner. It works ok, but the speech recognition is... not great. But you can have a conversation and practice listening and responding. I was able to treat the AI as an uber driver and ask about places to go in Peru, and how to get there, and why they were nice.


Our team had so many planning poker sessions where we spent 12 people * 2 dev hours trying to figure out whether stories were a 2 or a 3, management finally said it is always a 3. We were literally spending more aggregate time trying to decide effort, than the actual effort it took to complete these tasks.

2 and 3 are equal. 5 and 8 are equal. The question is simply "Is this a couple days, the whole week, or the whole sprint?".


The only reasonable estimates, ever:

+ That's trivial, it will be ready for testing before lunch.

+ I know how to do that, should be ready tomorrow/next day.

+ I can see how to do that but there are lots of other constraints - at least a week, might be more.

+ It's a big project, needs more planning and specification before it becomes a series of estimable tasks. Let's do that.

+ That breaks other things we care about. We need to prioritize and be ready for rework.

If you want, you can call these small, medium and large.


I completely agree with these levels, but disagree with mapping them to “small, medium, and large.” That’s a lossy compression if you will, and the heart of the problem. A shorthand might start with good intentions, but rapidly is muddied by conflicting interests.


Almost 25 years ago I worked at a little startup. I started to build a network management system using ..... tcl/tk some open source HP Openview, what was the name?

Anyway, I had a neat display showing live nodes as green. I was redirected to enhance that display with graphs and charts and linking the nodes, we bought a TV to display it on... long story short, it was more important to show this awesome graphic tool to potential investors then to know whether our systems were actually down.

Some things never change.


I think it was from the movie industry - just something in the background shot with lots of blinking lights and occasional beeps was known as an EBG, or "electronic bullshit grinder". They do tend to impress investors as well as audiences.


Most Thinking Machines CM-1/CM-2 were sold to just sit there and blink away.


Was it MIMIC simulator by any chance?


This is something my company's internal RTO channels seem to have missed. What if large corporations really *did* collect enough data during covid to justify working from home? Now faang can justify outsourcing the rest of US based jobs.

Force RTO in the US, replace those who leave with less expensive resources.


This is actually a brilliant bit of insight/tinfoil that I'd totally missed, largely because all the things that FAANGs have been saying to justify RTO have been so daft.

You're totally right, though. If the data shows that RTO has negligible benefit — or even, say, just a marginal 5-10% benefit — then the logical move is to force RTO for the most expensive headcount (since a 5% boost there will be the most valuable) and then hire globally-remote headcount for all the rest.

That... really feels quite grim, the more I think about it. Time to go stare at my early-retirement spreadsheets and see where I can squeeze out some more velocity for myself, I suppose.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: