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…
It Takes 6 Days to Change 1 Line of Code
211–220 of 237 posts
Re: It Takes 6 Days to Change 1 Line of Code
#212Earlier 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…
Re: It Takes 6 Days to Change 1 Line of Code
#213Earlier 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…
Re: It Takes 6 Days to Change 1 Line of Code
#214Earlier 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…
Re: It Takes 6 Days to Change 1 Line of Code
#215Earlier 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…
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
#216Earlier 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?
Re: It Takes 6 Days to Change 1 Line of Code
#217Earlier 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?".
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
#218I'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
#219This 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…
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
#220Earlier 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…