Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It Takes 6 Days to Change 1 Line of Code

edweissman.com

Post reply on HN
Print view View original

121–130 of 237 posts

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

#121

Post by mahyarm »

jrs235 wrote: post #113
badclient wrote: post #101

Earlier quoted context omitted.

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.

My place of employment is similar to yours, I've moved myself up the ladder in order to start isolating and enabling my dev team the peace and quiet they need to be most productive. What if, while you code, you think out loud, like really out loud... louder than you would talk in conversation? Perhaps if YOU bothered EVERYONE then maybe they'd put you in a private office? It's worth a try while you are looking for ot…

That kind of passive aggressiveness will make your coworkers hate you and could get you fired because they know you don't have to do that.

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

#122

Post by bceagle »

ajross wrote: post #72
badclient wrote: post #52

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…

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…

> Learn to prioritize for yourself instead of expecting your slag pile of a management structure to do it for you

What you are suggesting is easier said than done. I think that most good developers have the mentality you are describing...at first. When you work in an environment like this, however, you get worn down. You can only put up a fight for so long before you start getting all sorts of mixed up and you don't know what the f to do. If you took the best prioritizer in the world and put them in a corrosive environment like this one, the environment would eventually win out. I really feel for guys like the one that posted this original article and some of the subsequent commenters. I have been in that boat before and it is not fun.

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

#123

Post by Dove »

ojbyrne wrote: post #110
Dove wrote: post #54

If you want a change request processed quickly, you should get someone in upper management to help you herd it through the system. Literally, take your VIP with you, and walk up to the desk of each admin in turn. Say, "Don't wait for Tuesday's meeting--approve this right now." And then walk to the next admin and do it again. And then walk to the test guys and say, "Drop everything and test this now." And then gather…

That works once. Then the next time you go to each desk, the person there has already checked with their boss, and says "my boss says you need to go through the correct channels and if you don't like it, you need to talk to him."

That's why you have a VIP with you. If he's not her boss's boss, the whole thing is a lot less likely to work.

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

#125

Post by smackfu »

Dove wrote: post #54

If you want a change request processed quickly, you should get someone in upper management to help you herd it through the system. Literally, take your VIP with you, and walk up to the desk of each admin in turn. Say, "Don't wait for Tuesday's meeting--approve this right now." And then walk to the next admin and do it again. And then walk to the test guys and say, "Drop everything and test this now." And then gather…

The tricky bit is that if there is a bug in the change, the VIP might suddenly be busy with other work.

And as you said, a smart VIP is there in the room, suggesting things get done. Explicitly not writing things down in emails.

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

#126

Post by njharman »

fleitz wrote: post #34
lmkg wrote: 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…

> Or you could just hire responsible people and ask them to use their judgement,

Or, just as easily, you could sprinkle magic fairy dust over your servers to solve provlems.

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

#127

Post by pikewood »

badclient wrote: post #105
pikewood wrote: post #83

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"

Then you either demand dedicated "anti-office hours" or you tell them that it's not feasible that project B will get done with the way things have been recently. They're not technical, and all they can do is take your word on when you think you can finish it. They're not going to pick up on the caveats you've laced in your estimate. Also, you should let them know ahead of time that things are slipping instead of them finding it "behind schedule" on their own.

Honestly, don't take this as an insult, but it just doesn't sound like you're the right person for the position. If you have trouble pushing back when you need to, then you should find a spot where there is someone pushing back for you.

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

#129

Post by re_todd »

badclient wrote: post #105
pikewood wrote: post #83

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"

One day I had an epiphany. I realized as I was programming at my computer that nobody had a freaking clue what I was actually working on. If someone asks how their low-priority project is going, I just say that I'm still working on it. They have no way of knowing if I'm actually working on it right now. In the real world, saying "no" a lot will get you enemies. It's much more diplomatic to only work on some low-priority project an hour or two a day (you don't have to tell them your are only spending an hour or two a day), or say you'll get to their project immediately after you finish this thing your are working on (which can be a small component of your large important project). It's important to know how to say "no", but in practice it is important to minimize the number of times you say "no".

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

#130

Post by Mc_Big_G »

jrs235 wrote: post #113
badclient wrote: post #101

Earlier quoted context omitted.

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.

My place of employment is similar to yours, I've moved myself up the ladder in order to start isolating and enabling my dev team the peace and quiet they need to be most productive. What if, while you code, you think out loud, like really out loud... louder than you would talk in conversation? Perhaps if YOU bothered EVERYONE then maybe they'd put you in a private office? It's worth a try while you are looking for ot…

Often, when we are pairing at work, the person driving is thinking out loud or the pair are in discussion with 8 other pairs in their row of tables.
Post reply on HN