|
Best to do it without writing it to disk at all though, read from one database and write to the other.
CSV is evil. Particularly in the absence of a standard. I try to avoid it.
My boss was on a JSON kick for a while, he'd read a blog post. It seems that he is incapable saying "no".
|
|
|
|
|
Is there a solution to this? Seems this is the case everywhere (maybe almost!) and don't see getting it changed.
Think, it's just live with the reaction for saying No.
And the best option probably would be to provide best guesstimate and take whatever comes on the way as much possible.
|
|
|
|
|
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. 
|
|
|
|
|
SteakhouseLuke wrote: I often work with people from other cultures (programmers, customers, etc) where NO is forbidden.
I thought the same thing when I read that a dev actually said no to someone.
Most places there is no possible way to say no. They want an estimate and you give them one.
Completely meaningless, but very polite. 
|
|
|
|
|
SteakhouseLuke wrote: I often work with people from other cultures
I've had that experience - it definitely requires learning how to phrase questions differently, like "tell me what you understand from all this?"
|
|
|
|
|
Working with the Japanese can be soooo frustrating. I built an entire solution based on their response only to find out it was completely wrong. We had to send an interpreter to Japan to get straight answers.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
In English we have "The customer is always right."
In Japanese they say "The customer is God."
|
|
|
|
|
Marc Clifton wrote: The irony is that this project manager went from being a bull in a China shop to a mouse - no facilitation, no responses to our emails when we actually need some information from the client that he could "facilitate", in fact, no communication at all except an hour before the scheduled weekly meetings "Are you guys ready?"
Decades ago I worked with a QA lead who very much felt that he needed to have some visible authority and that he was constantly getting his hands tied behind his back. He stopped caring and only showed up to collect his regular paycheck. Then he was accused of "not being a team player".
I saw him a few years after he was laid off, and was making the claim that "[Company Name] put an end to my IT career". I'm pretty sure he did that himself. As much as I don't like office politics, you have to learn what the rules are, and play by them. Don't sulk for months until you get fired just because you're not getting things your way.
|
|
|
|
|
The more I worked in the field, the more I understood the wisdom of two year olds.
When I was green I was asked to move a deadline on a 3 month project, up a month. I said maybe. My mistake.
Since then I have not been afraid of "no."
I realized part of my job was to protect management from themselves. Not in the job description, but when the project fails, who gets blamed? It is my responsibility, because it's my behind if it gets behind.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I realized part of my job was to protect management from themselves.
Yeah, so often the sad truth. Especially when the manager explicitly says "my boss is breathing down MY neck."
Oi. Talk about roll reversal, which it should be the manager's job to protect you!
|
|
|
|
|
I agree. It was one of things I really didn't like about the field.
Real programmers use butterflies
|
|
|
|
|
Quote: ...I was asked to move a deadline on a 3 month project, up a month...
I've been asked that recently in a similar timeline.
I said "OK" 
Then I said "Which bits do you want me to leave out?"
I got some funny looks at that point, and the "nothing should be left out" response.
I then wasted another 15 minutes of my life explaining that the work they required would take 4 months, so they could either have all of the work after 4 months or some of the work after 3 months.
Now they've got me in overly frequent, regular meetings to review how we are against plan. The irony that these meetings are eating into my available dev time is completely lost on them 
|
|
|
|
|
And people wonder where Scott Adams gets his material. The man must have worked in development.
Real programmers use butterflies
|
|
|
|
|
That's when you tell them things have slipped a week because of all the time wasted in meetings.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I ran my own schedule using scheduling software and told the (user) PM that they had their schedule and I would use mine. Of course, they could look at mine. I had projected finish dates. If there was a "due date", I made them take out "requirements" until my forecast matched their due date (year-end). And, no (I said), "more people" won't help after a certain point. I was never "popular", but never late.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I had to jump in a project that was already way behind schedule. My first week there was almost only letting people explain me what it should be done and where we were. I tried to analyze what the previous guy was doing and then I called my boss, because repairing that mess would take me more time than starting over again. He let me do it.
2 weeks later, I was already moving the machine in semi-automatic. Then an appointment with the customer was done.
When they came the project manager was trying to explain things where I was internally hitting my head against the desk. Then the customer started asking for things and the project manager would open his mouth. At some moment I got tired and said... NO.
All quiet, staring at me...
Customer: Pardon? What do you mean?
Me: Because blah blah blah
Next day he was speaking with me using "Du" instead of "Sie" (the formal form in Germany) the other team members were  and asked me if he knew him from before...
ME: No, I met him yesterday, why?
They: Because the project manager had been working for him as extern for 4 or 5 years and was still being spoken with "Sie"
I suppose I got his respect exactly when I said "No" and then I gave him technical reasons to support my "No" some of them even protecting the machine or the ergonomy of the future operators of his company. I gave him even an alternative (that he payed extra, because was against was written in the contract)
So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
Very 
|
|
|
|
|
A long time ago I read somewhere that when writing software it takes 95% of the forecast time to do 95% of the work and another 95% of the forecast time to do the remaining 5% work. Whenever the PM insists for estimates on task duration I make a generous estimate and double it.
|
|
|
|
|
Back in the day I did mine with factor 1,5 if I had a really good project description and I did my own chats with the customers. A 2,5 or even a 3 when I had bad specs or no first hand information.
My boss still added a 50% more, so he could bargain with the customer up to 25% down and still have his own buffer.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Male ego? I think it would be better to write "ego" without a qualifier.
Sorry for my bad English
|
|
|
|
|
I've always been a fan of saying "no" when it's needed. As long as it's done the proper way, I find it only helps with planning and actually improves your professional image in the eye of your counterpart.
Well, managers are often an exception to that rule, alas!
A few years ago I had a particularly funny (though it was NOT funny for me at the time!) eexperience: a big client's PM called me to discuss the schedule of a rather big project. She sent me the whole planning and we went through all the deadlines and discussed in detail all activities. In the end, it was a demanding schedule, but not impossible. I was positively surprised, and agreed that it was doable.
That's when I commented on a date for a meeting: I was not available on that specific day. She told me to ignore the dates on the schedule... I said "what?". She said yeah of course the schedule was about the time it would take to complete the project, but the date on the schedule were all off: the project would start the next day instead of the next month...
Let's just say that I answered with something more... articulate than a simple "no"
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
I never understood why people are so tied up in dates. Understanding dependencies is better for everyone, and just simpler.
"Here are the things we need to happen before X. Whenever those things are in line, we can start work on X."
You know, the basics of iterative development.
It's even o.k. to give a rough timeframe for X (assuming it's reasonably well-defined, or the business people understand and buy into it being rough). But that doesn't define a date from now, it (roughly) defines a date from start of X.
Good luck, Marc.
|
|
|
|
|
After 42+ years of working in corporate development both as an employee and a consultant, I retired.
It wasn't the changing technologies but simply the fact that I couldn't work for assholes any longer...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outklook.com
|
|
|
|
|
Same here. we had a PM pushed on us recently, and wanted break downs for every step on every project with completion dates for each step. That was a solid no from us also. there are just two of us devs at our community college, not only do we have daily tickets, a backlog of apps to fix, upgrade, or create we also now have a new data store/schema coming from the state that we have to migrate to in the next year.
With everyone working from home, i understand they want some sort of metric on our day to day to make sure things are getting done, but this is not the way. things change too much from day to day. like the other day I got everything cleared away to get back to working on an upgraded app; 2 hours in everything got derailed when an emergency came in that used up the rest of the day.
I've been told in the past (different PM), if you know how long it takes to put a button on the screen you can estimate how long to do everything else.  everyone who has actually done software development, can give educated guesses like that feature might take 3-4 days, but actually takes 1 day or 1 week, but don't hold me to the educated guesses especially when other things popup. Same PM told me all programming is simple; it's just 'click,click,click'
I've been doing Dev work for over 20 years now and have not missed a deadline yet, and all without any PM. PM's should be there to organize information and keep all parties updated, and a source to dig up information needed, but please putting a measurement on dev's productivity with dates is dumb, might as well go back to KLOC measurements, absolutely meaningless, since I could say that feature will be done in 6 months finish it off in 3 hours and take the rest of the time off.
|
|
|
|
|
Aaaand another developer is labelled a Prima Donna that is hard to work with. Heavy sigh.
Ok, yes, you should say, "No" sometimes. As a developer that wants to be helpful and driven by a sense of purpose, it is hard to say, "No". I've erred more on the optimistic side by saying, "Yes" and then having to work heroically (ie late nights and weekends) to meet my commitments. Chalk that up to experience.
Instead of simply a one word answer that is perfectly realistic but not helpful, why not follow up with what you CAN do? Then list all your risks and unknowns so that the PM and the rest of the team can track them, revisit them each week until the risk is dealt with or the unknowns become known. If your worst fears are realized then you look like a prescient genius. If not, no one will bother to remember.
A good PM will not simply manage the schedule but will also manage the risks and unknowns. The PM will help to develop contingency plans, re-negotiate the schedule and resources, and escalate issues that are blocking you or other team members to keep the project on track so you can focus on the technical issues. The PM can only succeed if he/she has good info to manage the project and depends on the technical folks for that information.
A bad PM will only manage the schedule and hold everyone to the earliest date ever uttered by anyone at any time based on any assumptions. So, document your risks and unknowns along the way for the post mortem, err, uhh, retrospective.
Keep your friends close and your PM closer. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
