Live data from Hacker News

It Takes 6 Days to Change 1 Line of Code

edweissman.com

191–200 of 237 posts

Re: It Takes 6 Days to Change 1 Line of Code

#191
post #93

I seriously don't see the problem. The author seems to be assuming that taking 6 days to have a change made is objectively bad. Does the company run? Does it make money? Do the systems work and stuff? Well, if whatever you're doing now to keep the systems working and the company running and making money obviously works so I'd say it's objectively good. The experience may feel bad subjectively but how you feel is of t…

I don't see the problem either. The article is extremely self-centred, and doesn't deconstruct why this is bad for their business. The programmer's job is to help the business achieve its ends. If she feels stymied by process she needs to discuss it with the business. If she's criticised for taking too long she needs to lay out where the time went. Imagine if lawyers wrote articles about how it took months to convict…

The business wanted to s/3/4/ on a single line. The reality is that President, CEO, CIO, etc. don't really care about whether this parameter is configurable, if there are specific test plans, if the test team is happy with the variable name, etc. They don't want to do a layoff. So they asked the developer to perform the s/3/4/.

The developer did so, reasonably. Then it sounds like the self-righteous testing and security people stepped in and basically said "well, this might be delayed because it doesn't follow our standards and we don't have all the sign-offs. This might mean layoffs, lost profits and so on, but damn it we have to follow our policies!"

Sounds like the IT dept. is not enabling the business. They are, instead, hijacking it, substituting their own priorities for those of the whole enterprise.

Re: It Takes 6 Days to Change 1 Line of Code

#192

Earlier quoted context omitted.

> Or you could just hire responsible people and ask them to use their judgement If you know a fail-safe way of only hiring responsible people who always have good judgment... then I hope you're being paid millions of dollars in consulting fees, because nobody has really figured that one out in a general way yet!! :) Also, those people tend to be expensive... sometimes it's far more cost-efficient to hire less-perfect…

In this case, there was someone with basically good judgement, but they were operating from high within their hierarchical framework, which inherently induces delays. In retrospect, Philip, David, or both, should have been copied on the ticket and directly overseen the policy violation that they deliberately set in motion. Simply ordering policy violations from the throne doesn't work in practice. Either the person w…

I think the reason this fails to happen(philip/davic overseeing the ticket till production) is because of this (Heads I win Tails you lose)principle http://www.ribbonfarm.com/2011/10/14/the-gervais-principle-v...

Re: It Takes 6 Days to Change 1 Line of Code

#193

Earlier quoted context omitted.

That is why I insist on communication via chat clients when I'm busy. I'm not immediately interrupted as I would be if someone walks up or shouts out as I can ignore the little flash of the chat window on the task tray for a few minutes, sometimes tens of minutes, while I bring my train of thought to a more orderly stop. If people start with "Hi, I have a problem" and don't state what the problem is I just respond wi…

> If people start with "Hi, I have a problem" and don't state what the problem is I just respond with "drop me the details and I'll have a quick think" and get back to my work. If people start with "Hi, I have a problem" and don't state what the problem is I close the chat window . My work IM's status clearly states "if you have a question, ask it, don't ask if you can ask", time wasters simply get ignored. > Some pr…

> If people start with "Hi, I have a problem" and don't state what the problem is I close the chat window.

In the past I've found that leads to people reporting "I asked him several times over a few hours and got no response" which, if the person being complained to does not know the situation, could look bad for me.

If I feel like being more terse, I just give a one-word response: "Details?".

Re: It Takes 6 Days to Change 1 Line of Code

#194

Earlier quoted context omitted.

2038 is going to be a fun one, isn't it? :)

Dr. Peter Venkman: This city is headed for a disaster of biblical proportions. Mayor: What do you mean, "biblical"? Dr Ray Stantz: What he means is Old Testament, Mr. Mayor, real wrath of God type stuff. Dr. Peter Venkman: Exactly. Dr Ray Stantz: Fire and brimstone coming down from the skies! Rivers and seas boiling! Dr. Egon Spengler: Forty years of darkness! Earthquakes, volcanoes... Winston Zeddemore: The dead ris…

Funny quote. I love that dogs and cats living together came after the dead rising from the grave. Not sure I'd put them in this order. :)

Re: It Takes 6 Days to Change 1 Line of Code

#195

Earlier quoted context omitted.

I don't see the problem either. The article is extremely self-centred, and doesn't deconstruct why this is bad for their business. The programmer's job is to help the business achieve its ends. If she feels stymied by process she needs to discuss it with the business. If she's criticised for taking too long she needs to lay out where the time went. Imagine if lawyers wrote articles about how it took months to convict…

The business wanted to s/3/4/ on a single line. The reality is that President, CEO, CIO, etc. don't really care about whether this parameter is configurable, if there are specific test plans, if the test team is happy with the variable name, etc. They don't want to do a layoff. So they asked the developer to perform the s/3/4/. The developer did so, reasonably. Then it sounds like the self-righteous testing and secur…

IME process doesn't spring fully-formed from the head of Zeus.

You get test plans when somebody goes cowboy on live code and breaks tangentially related processes. You get security reviews when somebody goes cowboy on live code, everything looks great, and then a month down the line you lose days of work when someone changes a password. You get mandates to create parameter files when someone gets burned having to run through this entire process over and over again when business rule changes back and forth.

The reality is that once this change is done the proper way and the business parameter is moved to a file, the company will never lose time over this issue again. It will be configurable just as fast and responsive as we all feel it should be, without any concerns about breaking things down the line.

Is it frustrating? Sure. But that doesn't mean it's wrong.

Going cowboy on live code, even for something as trivial as changing a 3 to a 4, can and has created large problems.

Re: It Takes 6 Days to Change 1 Line of Code

#196

Earlier quoted context omitted.

On this subject: Whenever someone chats me in the following manner, I want to kill them. Straight up. Just fucking take an ice pick and jab it right through their skull: Other Dude: Hi. Me: Hello A minute elapses Other Dude: I'm having a problem Me: How can I help A minute elapses Other Dude: ACTUAL PROBLEM THAT THEY NEEDED HELP WITH Me: Oh, here is your resolution which took all of 15 seconds to give to you. WHAT TH…

I'm really bad on IRC with this kind of thing. Need to get to the point faster. Thanks for pointing that out.

Not "faster", immediately. Say absolutely nothing until you've typed out your question.

Would you send an email that says "Hi", then another that says "I have a question", then another with your question?

Re: It Takes 6 Days to Change 1 Line of Code

#197
post #72

Earlier quoted context omitted.

This doesn't sound like a process problem at all, actually. Really it's the reverse: your work environment is a mess, no one has the ability to do their own job except to bug you to do things they need. And that's a disaster too, but it would be helped by adding process, not hurt. Also, dude: learn to say no. Learn to prioritize for yourself instead of expecting your slag pile of a management structure to do it for y…

And if your workplace environment really doesn't permit that, move on. Doing just that :) It's basically a startup with 10 of us where I am the only in house developer. I've tried many things like asking folks to Skype me instead of walking over to my desk or calling my name. I've gone to great lengths to get em to understand why skyping to get my attention is different than other ways. None of these guidelines reall…

It can piss people off and so work negatively (so, evaluate your individual circumstances), but you can begin insisting upon written requests. Amongst other things, this documents the requests. (And you can tell people the written request is e.g. for your email-based "todo" list.)

If/when people start getting into your face (perhaps even formally) about performance, you have documentation to back up your argument. (Although, ultimately, most arguments are kind of moot, unless they end up in court or perhaps before an unemployment insurance evaluation -- not something you really want, anyway).

As for the overall experience. While negative, emotionally, you can still view it as a learning experience. Keep in mind that when you are in a better position, with more control, 90 % of the world with which you are competing is / will be what you are now experiencing. So... if you can cut out that bullsh-t, you will have a very significant competitive advantage.

It can be useful, to get a good, hard, close-up look at what you don't want. Just don't let it go on too long.

P.S. A trick I'll occasionally use, in problematic verbal situations, is to summarize the conversation/request in an email to the other party(s). 'We met. Here's what you asked me to do / how I understand it, what I'm going to do, and my anticipated schedule and potential conflicts / other overriding priorities. Let me know if I've misunderstood or you disagree.'

If no one responds, I proceed accordingly. If they bitch, hey, I laid out my approach and circumstances up front and asked for feedback.

It can put people on the defensive and create a negative vibe. But hey, when people tell you / manipulate you with statements of "We're losing confidence", things are not too positive, to start with. (P.S. That's already the sign/signal to bail. "Bail, bail, bail!")

Re: It Takes 6 Days to Change 1 Line of Code

#198

Earlier quoted context omitted.

Did you miss this part: > It [sic] we don't do this right away, we'll have to have a layoff. As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes. You're a phone company, and adding a new feature should take months. I get that. You're a phone company, and because of an unforeseen Cinderella problem, 10% of your customers can't make phone calls.…

> As a company, it's great to have a process for incremental changes, but you also need to have a process for critical hot-fixes. And as soon as you do, everyone thinks that their problem is a good candidate for the critical hot-fix path. At the very least, you now have to sink minutes per day into arguing them down from using it. Worth it? Possibly. But not always.

You need a good operations team with the authority and willingness to say "no" with overrides coming only from senior management, the authority to say "yes" for the obvious stuff, and a direct line to senior management for grey areas they're not comfortable making a call on by themselves.

The operations team will spend a few months saying "no" a lot and justifying their decisions to management. Eventually it will slow to a trickle except for a few really stupid people who lack reading comprehension and any sense of pattern detection. Management will eventually get tired of it and forbid the stupid ones from making hot-fix requests.

Re: It Takes 6 Days to Change 1 Line of Code

#199

Earlier quoted context omitted.

I'm really bad on IRC with this kind of thing. Need to get to the point faster. Thanks for pointing that out.

Not "faster", immediately . Say absolutely nothing until you've typed out your question. Would you send an email that says "Hi", then another that says "I have a question", then another with your question?

Would you burst into someone's office and start telling them all the problems you expect them to fix without even saying hi?

Re: It Takes 6 Days to Change 1 Line of Code

#200
post #199

Earlier quoted context omitted.

Not "faster", immediately . Say absolutely nothing until you've typed out your question. Would you send an email that says "Hi", then another that says "I have a question", then another with your question?

Would you burst into someone's office and start telling them all the problems you expect them to fix without even saying hi?

First of all, you're not bursting into someone's office. Second of all, if you burst into my office while I'm working and start making smalltalk, I will, depending on my mood and whether or not I've previously judged you to be a useless person, either immediately ask you to get to the point, or throw you out.

Stop wasting my time. If sending "Hi" makes you feel better, fine, but the substance had better be on my screen by the time I look at the window, or you've wasted my time.

Post reply on HN