Live data from Hacker News

It Takes 6 Days to Change 1 Line of Code

edweissman.com

171–180 of 237 posts

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

#171
post #94
post #88

Earlier quoted context omitted.

Tim Schafer, of http://www.kickstarter.com/projects/doublefine/double-fine-a... fame, has a note on his door until 11am in the morning saying, don't knock, writing. Could you make progress on projectY if you made a deal to not work on projectX until 11am? To not even open your office door? (FWIW, this is a classic Quality of Service (QoS) algorithm, where traffic on ProjectY is given dedicated bandwidth (2 hours in t…

Door? Who has those anymore? In the interest of collaboration open-plan offices have become the norm, to the detriment of productivity everywhere.

I'll frequently work from home in the morning or evening if I want to get stuff done; no coworkers there. Or if I need to concentrate, I'll leave my office and go find a massage chair or cozy nook and curl up with my laptop, or even go to a different building and work alongside a team where nobody knows who I am.

Only thing I miss is my 3 24" monitors.

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

#172

Earlier quoted context omitted.

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…

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 applaud this post.

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

#173

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.

If you have a single (actually) business critical incident that cannot be resolved, the company will fail. It's called risk management. You spend minutes per day arguing with idiots to not have the company fail in an emergency.

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

#174
post #94
post #88

Earlier quoted context omitted.

Tim Schafer, of http://www.kickstarter.com/projects/doublefine/double-fine-a... fame, has a note on his door until 11am in the morning saying, don't knock, writing. Could you make progress on projectY if you made a deal to not work on projectX until 11am? To not even open your office door? (FWIW, this is a classic Quality of Service (QoS) algorithm, where traffic on ProjectY is given dedicated bandwidth (2 hours in t…

Door? Who has those anymore? In the interest of collaboration open-plan offices have become the norm, to the detriment of productivity everywhere.

Wear some sort of ridiculous Productivity Hat with a door on it somewhere and an 'Occupied' sign.

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

#175
post #34

Earlier quoted context omitted.

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…

> 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 who made the decision or a trusted lieutenant who understands what's going on has to see it through to the end, otherwise the bureaucracy in the middle will simply continue on its preprogrammed course.

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

#176

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…

This is why I stopped using all chat clients.

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 with "drop me the details and I'll have a quick think" and get back to my work. Even if they respond immediately to that it might take me ten or fifteen minutes to get look at their message again - that is their time wasted, not mine.

Some problems require a more urgent response so I'll accept a walk-up or a shout for those, and some problems are best illustrated by showing them than describing them, I just have to trust people to know what they are and what is less urgent. And of course a message will come in at a time when I am eminently interruptible, in which case people get an immediate response anyway.

I find it works except for people who insist on not following the process, but they soon learn I'm far more helpful if they don't irritate me!

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

#177
This thread reminds me of two lessons that I'm thankful I've learned young:

1. Processes exist for a reason. They're often annoying and sometimes overkill and unnecessary, but they're often there as a result of a past problem.

2. The whole top thread about communicating and literally ignoring people reminds me of my roommate who bragged that he was a good leader, meanwhile telling me that he would simply ignore his teammates because they annoy him. This is why "geeks" get the stereotype that they can't interact with people and it's why programmers with business and communication skills are so valuable and sought after.

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

#178

Earlier quoted context omitted.

This will keep happening if you keep saying OK. Try something like, "Can I get back to you in an hour? Boss wants me to finish this top priority item for him." And if Boss asks you if you can finish it next week, say no. You're being asked to give an estimate, and it doesn't help to say "Yes, if [this thing doesn't happen which I know it will]". If they want you to be the startup guy, then act like you're the one in…

That works until they goto the boss and the boss comes to me... "So I know your project is important but projectX is still our #1 priority so to the extent Jenny needs you please prioritize her work"

I found keeping a timesheet helped me there. When it came to "it is getting to the point where X is not going to be ready on time, and I've got personal things on this week so I really can't work significant overtime", and the question came back "well, what have you been doing for the last week", I could give them a full list of "2 hours helping X with Y", "an hour doing Z", "four hours on that high priority fix client C that no one else was willing to touch" and so forth. Don't play the blame game and point out that person X was being thick on an occasion or otherwise dwell on who is interrupting your key work, just lay it out as matter-of-fact as you can: "This is where my time is being used".

Make damn sure though that people understand a short interruption "for a quick meeting" when you are at the time "powering through" stuff sometimes kills as much as a full hour of development time if you are working on something complex as it can completely break your train of thought (especially if you are tired due to recent overtime!), or worse if you are coordinating with other people and/or are working on something timing sensitive (so the interruption might mean a key coordination point is delayed).

If you can show what the demands on your time are, a good manager will try rearrange things so that you are interrupted less often. Sometimes simply merging those small interruptions into a scheduled period or two each day is enough to make all the difference to your mid/long term work: problems that didn't really need you magically go away (as the person who was going to interrupt you does that 30 seconds of extra thinking/research that was needed to give them the clue) and the others "interrupt" you a few times a day rather than several times over an hours or two.

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

#179
post #94

Earlier quoted context omitted.

Door? Who has those anymore? In the interest of collaboration open-plan offices have become the norm, to the detriment of productivity everywhere.

Funny enough I didn't get a private office but we got walls built for a private office when the sales guy joined because he was disturbing everyone . If my non developer coworkers realized how disturbing it is to be in flow writing code to have someone tap your shoulder and start discussing a totally unrelated issue to what you've been coding.

If you only you could talk to them?

Seriously, most of these problems are due to lack of communication, set up a ticketing system, teach people how to use it.

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

#180
post #45
post #4

Honestly, for code that controls millions of dollars worth of business and could seriously screw over a lot of people if a subtle flaw was introduced, I don't see a problem with doing it this way. Might be overkill for one line of code, but where do you set the threshold? If you say any change longer than four lines is subject to this process, then people will work on trickling in new stuff in increments of four line…

Agreed. I think the main problem in this story however is the the red-tape between people and not so much the process itself. Ask Homer, well Homer is not in so ask Marge, well I don't have access to Marge. Delays like this that come from artificial communication barriers can be easily avoided if they worked on improving communication throughout the organization. It would probably have saved them 1-2 days, if not mor…

As mentioned above, Homer and Marge are servers rather than people.
Post reply on HN