Live data from Hacker News

You've only added two lines – why did that take two days?

mrlacey.com

501–510 of 522 posts

Re: You've only added two lines – why did that take two days?

#501
post #427

Earlier quoted context omitted.

A lot of people are building big systems these days and in many cases we have a guess at what is a reasonable amount if time for all of the steps in the process to take if we want an answer in 600 ms. While your trick makes you look good, setting the times to match the budget might be more honest. And when the app slows down you can blame the people who take 250ms to do their part when we agreed to 100ms.

100ms?! That’s insane, if we set the bar at 1000ms then maybe 25% of our requests will qualify.

Really? Our 95th percentile only goes above 1s when we are having problems, and nobody with any power in the company thinks that's good enough. Think about how much hardware capacity you need for a site getting even 100s of requests per second. If you can halve the p95 you can decommission or re-allocate close to half of your servers.

As several other people on HN have pointed out more eloquently, it's the variability that kills you faster than the average throughput.

The 100ms was not about end-user response times, it's referring to internal response times between servers. To make a page in 1 second you can't have 3 different services taking 700ms to respond, even if you can make all three calls in parallel. And if you have to call a bunch sequentially, you need the 75th or even the 95th percentile for those services to be pretty good otherwise your 95th percentile for the entire interaction will be very spiky.

Re: You've only added two lines – why did that take two days?

#502

Earlier quoted context omitted.

Reading your comment reminds me of how sheltered and lucky I've been in my career. If my manager released something after I said I was 80% done with it I'd go have a talk with him about how "we" can avoid making that mistake again and what process needs to change to prevent similar errors. If he tried to chew me out, I'd just say "That's not how I remember things. I said I was 80% done, and, frankly, it was a mistake…

Yeah, I'd have the same conversation with my manager and she'd apologize. I don't think you have been lucky, such a reaction is just a normal adult civilized reaction.

This kind of thing tends to happen when young and inexperienced. After it happens once or twice we have the experience and clarity to speak up.

Re: You've only added two lines – why did that take two days?

#503

Earlier quoted context omitted.

On the other hand, programmers are very good at wasting weeks creating incredible software architectures to try the latest library they read about or try a design pattern, or in general over engineer something so that it’s “better designed”, more generic, more “flexible”, and so on. In other words, if a project manager sets an expectation that a task is a “task that takes two weeks”, the developer will somehow manage…

Programmers actually hate working on the same thing for longer than necessary. They like new problems and new challenges, as your identifying in your misguided take on always wanting new libs/frameworks. If you are finding that you actually believe this, you've somehow cultivated a very toxic technology environment where your developers are hiding necessary tasks from you and attempting to make up the difference wher…

That's a very broad generalization.

I've been getting paid to write code since 1998. The last few years in management. So I know something about actually being a programmer.

I hired someone who was awesome from a technical knowledge perspective. Friendly, personable, smart, driven, etc. Loved talking tech with him and he had really great ideas.

Anyway, the problem was, I'm running a startup and every single project he was on he tried to model it as "the perfect open source project". So instead of doing something simple in a couple of days he would build this really well abstracted, over engineered (but pretty damn good code!), "beautiful" thing that would take 3 or 4 weeks to deliver.

In the end, it didn't work out for him.

Anyway, my point is that it is not true that programmers hate working on the same thing for longer than necessary. I do. You do. Many others do. But some just love being architecture/purity astronauts and refining that 3 line method into a 7 class inheritance hierarchy.

Re: You've only added two lines – why did that take two days?

#504

Earlier quoted context omitted.

Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk th…

I don't do that. When I demo something I need feedback on, I demo the best version I've got. If it still requires work, I say so. This seems to work quite well for me.

Re: You've only added two lines – why did that take two days?

#505
post #481
post #326

Earlier quoted context omitted.

Look up the 72(t) rule relating to a 401k. You can retire early and start withdrawals at any age without penalty, as long as you continue the withdrawals for sufficient time (the longer of five years or until age 59.5.) This fixes the "too much in the 401k" situation.

The problem I see is that if you're 30 and use that rule, you are basically forced to drain your 401k over the next 29.5 years.

Yes, but you don't have to spend it all. You could take just what you need to live on and invest the rest elsewhere. You'd give up some of the tax-deferral advantages of the 401k, of course.

(Perhaps you could roll over part of the 401k into an IRA first, and then take the rest as 72(t)?)

Re: You've only added two lines – why did that take two days?

#506
post #458

Earlier quoted context omitted.

Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.

My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime, first the mathematical models behind it need to be created then implemented in software.

> My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime

Sure, sounds straightforward enough. Start with simple cases (e.g. universe is a unit circle), you can definitely implement useful pieces within two weeks.

> first the mathematical models behind it need to be created then implemented in software.

That's not a real (i.e. user-facing) requirement.

Re: You've only added two lines – why did that take two days?

#507
post #89

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.

I've learned the opposite. If I communicate clearly that what is being shown is little more than a mock-up, executives of all levels and technical skill, all the way down to managers just above myself, all understand that a very thin and scripted demo is not anything close to a finished product.

Describing the demo as a "house of cards" that will collapse with a single misstep gets the point across nicely, while also giving the demo audience an eyeful of what can be accomplished if everything is handled appropriately.

Demos are carefully scripted and rehearsed, values are hard-coded, and absolutely nothing exists that does not prop up the demo for the purposes of the script and the talking points.

It is hard to describe to someone who hasn't written an application demo like this just how little actually exists behind the UI.

Anyway, my point is that if you choose the correct words, anyone can understand that it's like a painting of an application, and not an actual application, just like a painting of your mother is not actually your mother.

Re: You've only added two lines – why did that take two days?

#508
post #231

Earlier quoted context omitted.

We had a hard and fast rule at my last job. ALL demos were either 100% real, or were mock-ups from Balsamiq. If it looked like someone doodled it on paper we didn’t have to worry it would be taken as working. We came to this rule after far too many incidents where some sort of mock up (Photoshop, HTML, whatever) was shown and taken as done. Then we got the questions (possibly unhappily) about where it was and when it…

For mockup images, you can use an unmistakably prominent watermark. Superimpose the word "MOCK-UP" in a gigantic font that takes up nearly entirely the image. Make it translucent and red or make it black outline. And maybe tilt it diagonally to catch attention and to make it easier to visually separate it from the rest of the image. To streamline the process, you can just keep an image like this around to import as a…

Honestly? I’m not sure that would work. As sad as that is.

Re: You've only added two lines – why did that take two days?

#509

Earlier quoted context omitted.

After your suggested fix, how does a user enter the first letter of their password in upper case if that's what they want? Maybe you were expecting the dev to go through all the passwords and fix them so the first letter of all passwords is lower case? Oh but if they were following best practices they don't know the password, they only know its salted hash. Since the app was already shipping without the first letter…

Sorry, it requires more context. The reason this issue wasnt highlighted before was 1/ Many of our users were on laptop and did not use mobile site as much 2/ There was rarely a switch for those who used the mobile site (as in they rarely used desktop, else we would have caught it sooner). The fix was a longer one. We obviously had to have the same convention for a password in desktop and mobile web. For mobile users…

Actually the correct fix is correctly flagging the field as a password field, which fixes the capitalisation problem on iOS and Android.

Re: You've only added two lines – why did that take two days?

#510

Earlier quoted context omitted.

I mean... are they dumb, or just playing dumb to bully you?

The person who promoted them doesn’t care which, as long as they are consistent. I think we spend too much time focused on the trigger man. Whatever person in your org is making your life difficult, there’s a person above them who knows and hasn’t done a goddamn thing about it. Who is the real problem?

I'll gladly blame the entire chain from the immediate supervisor/lead all the way to the top.
Post reply on HN