Live data from Hacker News

It Takes 6 Days to Change 1 Line of Code

edweissman.com

211–220 of 237 posts

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

#211

This shit happens at my job and leaves me feeling depressed and at times questioning my own skills because I know and my bosses know that on my part, I just had to make a tiny, tiny change. But when you have a dozen such experiences, I feel like something is wrong with me because when the dust settles, this was a one line code change that took me a week to push to production. It also makes my bosses question my estim…

As much as this sounds counterintuitive, say no, and stop being a team player. Petty requests for emails that someone should have are their responsibility. If you think about it, why should your resourcefulness help them complete their job while it blocks your own progress? Your boss is doling out reviews, he's #1 priority. Everyone else gets "no" and no access to your time without talking to him first. "Being a team…

One of the main reasons I took a FT job was to become a better team player so in the long scheme of things, I always wanted to make this work out. Obviously it hasn't worked out too well but I think I have learned some critical lessons for my next gig!

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

#212
post #199

Earlier quoted context omitted.

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

Have you heard of these things called sentences? You don't need to hit return between each one. "Hi Dude, I've got this thing I need help with. Here is the description of what it is and what I am having a problem with." It's not an issue if they put it in the same chat message, it's the "Hi", send message, "I have a problem", send message, "This is what the problem is", send message that drives me up a wall. And if y…

At that point it's not really a chat, is it? It's an email.

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

#213
post #148
post #89

Earlier quoted context omitted.

Er... great chefs do need cookery books. They may not refer to them as often, but you won't find many chefs out there without a collection of cookery books. They still use recipes for things they're not familiar with. Besides, skill may beget product , but it doesn't necessarily beget process .

>> Besides, skill may beget product, but it doesn't necessarily beget process. Oh boy, talk about not seeing the forest for the trees. For skill to beget a successful product, you must follow a process to get from nothing to product. So in the course of creating a successful product you have automatically created a process -- the process to build the product. That process may be used one time, or multiple times -- bu…

Not seeing the forest for the trees? Hell, if we're going to use that loose a definition, everything is a process, regardless of skill level. Even if you end up without a product, to get the steaming pile of crap you abandoned, you went through a process.

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

#214
post #34
post #29

Earlier quoted context omitted.

"Changing one line of code took 6 days!" is a pretty common WTF story. It comes up every so often, and we all get a chuckle at the ponderous rate of change in large organizations. However, "Changing one line of code broke everything for 6 days!" is also a common WTF story. As a rule of thumb, you can't avoid both of them, because avoiding one entails the other. I wouldn't fault a company that chooses the first story…

Or you could just hire responsible people and ask them to use their judgement, you don't have to choose one or the other you can instead apply judgement as to whether this is going to screw shit up or not. Honestly, though the best way to handle this situation is with a phone call to the CEO/IT Director getting him to write you an email allowing you to override all the checks to get this in ASAP. Once you're known fo…

Just because they're smart doesn't mean they don't make mistakes. If you allow one line changes to pass without review, eventually someone's going to make a breaking one-line change.

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

#215

Earlier quoted context omitted.

> 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 slo…

Agree completely.

Step One is "Act Intelligently."

No process is going to help you skip Step One.

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

#216
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?

This is what I'm guarding against. I haven't been a programmer long, but it seems inhuman to not try and be polite or have a tiny lead up to the question. Ironically, it's the exact same thing that makes me impolite.

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

#217

Earlier quoted context omitted.

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

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

As I noted, my conditions are clearly spelled out as my IM status text, if they can't bother following simple instructions I can't bother with them.

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

#218
I have to opposite problem, almost no process at all.

I'm not sure which is worse, having to wait 6 days to do a change or having people request (often trivial) changes to be deployed the same day they specified them and having people going round editing .php files directly on the production server.

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

#219

This shit happens at my job and leaves me feeling depressed and at times questioning my own skills because I know and my bosses know that on my part, I just had to make a tiny, tiny change. But when you have a dozen such experiences, I feel like something is wrong with me because when the dust settles, this was a one line code change that took me a week to push to production. It also makes my bosses question my estim…

At my previous company we had the same problem, where people from all over the company would come up to us developers constantly asking us to do things which were great, but not really what we were supposed to be doing. Like you, we never got around to doing something that we said would only take a day.

One week we all decided to keep a notepad and paper next to our desks and keep a log of every time we were interrupted and asked to context switch and do something random. It was so bad, before the end of Monday our boss was so dumbfounded he completely re-jigged everything so it wouldn't happen like that again.

We ended up calling one developer pair the "consulting developers" each week, and only that pair could be interrupted. There was a huge sign above their desk advertising them for the week. We sacrificed one for the good of all, and it worked really, really well. AFAIK, they are still doing that.

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

#220

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…

He may have changed only a single line, but making the queue 4 months instead of 3 could break other parts of the system. Perhaps the "save data" and "backup" functions assume 3 as well, so you'd lose data. Perhaps other assumptions are made in the code, so with a 4 you'll end up with buffer overflows. Those test and security people are in the process to catch these issues before there are problems. It may seem a trivial change, but people make assumptions all the time.
Post reply on HN