Live data from Hacker News

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

mrlacey.com

511–520 of 522 posts

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

#511
post #506

Earlier quoted context omitted.

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.

You should follow your own plan, a Nobel prize in physics awaits.

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

#512

Earlier quoted context omitted.

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.

We also had to take care of the few folks who signed up with wrong password(in the sense that they never intended the password to start with a capital letter.). Changing the field value was a part of it - applicable for all new users. The complication was the people who already went through the flow and would have trouble logging in now.

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

#513

Earlier quoted context omitted.

Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all. In 2014 I worked at a company that switched to Git and then started measuring LoC to assess performance/involvement. Engineers took to committing/removing things like node_modules directories to mak…

This reminds me of a story from my first job. The business I worked at was a typical office, like the one you saw in Office Space. Departments had their own TV screens on the wall that showed performance of individuals in a department; the sales department had a screen that showed who was making the most sales that day. After we'd pretty much finished working on the web apps that supported these TV screens, the CEO m…

Why not simply explain that LOC is not a good performance measure?

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

#514

Earlier quoted context omitted.

I like to use two principles: * smoke means fire * a contained smokey fire is sufficient to hide the start of a wildfire This means: * keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly. * user complaints are errors. Just because they aren't clear doesn't make them any less so. There is a perception that users go out of their way to make unfounded comp…

> If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly. Okay, how do you handle a network failure, a full disk or a faulty RAM stick? I see your overall argument, but at some point you've got to accept that you can't handle everything.

keeping errors at zero does not mean errors don't happen, it just means you resolve them all, you don't ignore any. Perhaps it should be 'keep errors at 0 or 1'.

So if you're small, a RAM issue is something you deal with manually and rarely. As you get bigger you'll transition to automated failovers that still get looked at individually. Then you'll scale up to the point where these aren't freak occurrences. Now its important for you to have a strategy to identify the issue and its follow on issues, and resolve them. Its also past time you think deeply enough about your setup to be able to contain them so you can stop surfacing them as errors - they are now part of a normal business process. You want to make sure that too many are surfaced as an error (and too few), and any effects you can't currently recover from automatically are also errors.

Its perfectly possible to "keep errors at 0" without ignoring any output.

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

#515
post #495

Earlier quoted context omitted.

I like to use two principles: * smoke means fire * a contained smokey fire is sufficient to hide the start of a wildfire This means: * keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly. * user complaints are errors. Just because they aren't clear doesn't make them any less so. There is a perception that users go out of their way to make unfounded comp…

I think that, but then our feedback report include things like "How do I change my outlook password?". I don't work at Microsoft.

Sounds like you aren't being clear about your role to the user.

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

#516
post #222

The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week. It always gives me a pause, and then I would double the schedu…

I'd always prefer the honest path. You could try to explain the problem and why it might seem easier than it is in simplified terms.

Also, fast and slow, hard and easy - those terms don't always correlate. Easy tasks can require a lot of time while hard problems might result in a quick solution after careful consideration. Furthermore getting hard tasks done quickly might be exactly why you're billing that much. Maybe you've dealt with a similar problem before - in that case your experience and competence in that particular subject shouldn't devalue your work.

What I'm trying to say is: Don't base your price on time spent alone.

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

#517
post #423

> You've only added two lines – why did that take two days? If this is hard for them to understand, the confused look when you reveal a change was a net removal of lines/statements must be amusing! > Because the issue was reported with a vague description of how to recreate it This is something my current management fully understands, but I wish we could get through to our clients. Short of being actively rude about…

Decent logging of all changes and error happening on the platform I work on usually lead me to pretty much the following dialog : " - I have a problem, the platform is broken" " - Sure, do you have any rough idea when that happened " (I discovered that weirdly, people are very good to report a bug a day or even more after it actually happened) " - Around [some hours range]" (Get the logs for this time and this user)…

> Since users indeed never learn, stop expecting them to !

I don't expect them to. That doesn't mean I can't be irritated that they don't!

We have various logs and audits too, that can usually be used to work out what has happened. Sometimes alerts based on those logs mean we are already fixing the issue before any user reports it. Even with full audits and other logs, it is usually still quicker to locate and diagnose a problem if given what useful information we know the user has access to (the standard set: approximate time (at least the date if not today), what were you asking it to do, what did it do instead, any error messages they were displayed).

If the user is give a message with a code that explicitly says "report this number when you report the issue" and they don't bother (they just say "I got an error") and that information would save me time, you bet your arse I'm pushing the issue back onto the queue and getting on with some interesting dev/infrastructure work until a better report arrives, or looking at another issue where there is decent information.

Want to be at the head of my TODO list? Then make at least a minute amount of effort to help me help you.

It particularly bothers me when clients who negotiate a discount because they won't need first-line support as they are "big enough to have a department that triages that sort of thing", still send through terrible reports because their idea of triage is just hitting the forward button whenever an email comes in. I've got better things to be getting on with than providing free outsourced work for a bad IT department!

I'm not very customer facing these days, since we have grown to the point where I have a bit of a shield provided by our support/PS/BA teams, which is good for both my irritation levels and the clients!

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

#518

Earlier quoted context omitted.

Well, that gets to my other lesson: Save money aggressively so I'm not beholden to any employer. It's harder when you're taking care of a family on one income (and not making FAANG money), but I saved aggressively when I was young and single. I never actually had to use that option, but I was in a position where I could have lived (as a single healthy guy with no debt) for 4-5 years without needing a paycheck. I woul…

> My main mistake was putting too much in my 401k Can you expand on this? I recently moved to the US and people keep telling me to get a 401k, but I haven't yet.

  At a minimum, you should save enough to your 401K to get the company matching.
  Let's say the company match 50% on the first 6% you save.
  So if you put 6% of your salary to 401k, the company will add another 3% in addition to what you did. That's a free 3% raise. 
  Tell me another way that you can get guaranteed 50% return of your money.

 
  In addition, there is the tax advantage where you do not get taxed on your money until you retire. So you money grow without taxes until you actually need them.

  Are there bad 401k? yes, but I think very few. Check the rules of your company. But most of them are very good deals and you should take advantage of them if you can.

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

#519
The real reasons: depressed due to the current world situation, browsing reddit, HN, youtube, doing housework, checking stock portfolio, chatting with friends. In between all these distractions, one does manage to get some work done, at least 2 or 3 days a week.

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

#520
post #506

Earlier quoted context omitted.

> 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.

You should follow your own plan, a Nobel prize in physics awaits.

There's no money in doing useful incremental pieces of physics (and precious little even for the big milestones), unfortunately.
Post reply on HN