It should never happen in the first place. The specification should be crystal clear. Any ambiguities would have been worked out at the outset where I confirm that he really wants X.
If you feel that way, then maybe software development isn't for you. I don't see it much differently that writing a book (in terms of the actual working environment). Presumably book authors do it because they love to write. The fact that it's a solitary job is irrelevant. I write code because I love to write code. I don't need my work environment to be a place for friends to socialize.
[H]ow does he do his job when you don't wish to attend the very short and brief meetings he's set up to find out how you're doing?
If he needs to know that, it means he doesn't trust me. If, however, he does trust me, he assigns a block of work X to be done by date Y and he can then essentially completely forget about me knowing I'll have it done by Y.
But normally you actually take some time to explain the problem and tell him when you'll pick it up or need it back by. You don't just leave him guessing.
Well, of course.... just like when the project is laid out at its inception. But, once laid out, there don't need to be daily meetings about it any more than I have to call my mechanic every hour. I think you're missing my point.
Because it's good to know how well the project is progressing? It's good to know if you're on target? It's good if something happens to someone or multiple people that you all know what has and hasn't been done and is left to do?
That's the project manager's job. I shouldn't have to care if he's doing his job. It's a matter of trust and competence.
If I have a good auto-mechanic that I trust, I know I can drop off my car, he'll diagnose and repair the problem, do good quality work, and not rip me off. That enables me to have the peace-of-mind to not have to care about his work or how he gets it done.
I should have that same level of trust in everybody I work with so I don't have to care. I think part of the problem here is that the phrase "I don't care" is seen negatively in common use. I don't mean it that way. If I don't care about your work, it's because I know you'll do a good job (just like with my auto-mechanic). That frees my time up to work on what I need to work on.
If I have to care about your work, it implies I need to baby-sit you because I don't trust your quality of work or that you'll get it done on time.
[Good developers] are able to leverage the power of a good team to boost their own performance and their coworkers to new heights they couldn't achieve on their own.
You make it sound like a team is some kind of social program (no developer left behind). It's not. A team is a part of a company whose goal is to make money -- with any luck, enough of it to retire early.
In what toy projects do you work that others people code does not affect yours?
It seems you've got it backwards: only in toy projects would everybody's code affect everybody else's (because the code-base is small). In most of the projects I've worked on, the code-base is fairly large. As long as the interfaces don't change often, what they do under the covers doesn't affect my code.
And if the interfaces do need to change, well that's not the kind of pervasive change you suddenly bring up in a daily stand-up. That would require a more formal design meeting.
So why don't you like talking to your team to help them improve to your level?
You can't make a silk purse out of a sow's ear. I'd rather simply hire better people.
I don't see anything magical, it looks like bog standard code. From your arrogance I was expecting some really stand out stuff.
Then you're letting your personal feeling influence your objectivity. It's much better than 99% of the crap out there for the formatting, comments, variable-names alone. And most code is mundane in its purpose -- but it can still be done well.
You're some kind of super-coder yet you can't pick up another team member's work in say a SCRUM and carry on with it? If you're any good at coding then reading code and understanding algorithms isn't something you should be struggling with.
The problem is their code is often terribly formatted, not commented, and is often 3 times as long as it needs to be. Bad developers always write far more code than necessary because they don't know how to do things concisely. Code reviews are supposed to catch this, but not everybody can review everybody else's code. (What usually happens is that they get their buddy -- who writes equally crappy code -- to review it.) So no, I often can't make heads nor tails of somebody else's crappy code. I often throw it out and rewrite it from scratch in about a third the space (including comments).
I finished class X yesterday, today I'll be doing class Y, but I had a few issues with problem Z.
Why does anybody care what you did yesterday? It's in the past. What's done is done. The only part of that that has any potential value is the problems. The yesterday/today stuff -- what problem does anybody else know that solve?
You still seem to have this idea that the standup is some long meeting full of detail. It's not, it's an extremely brief summary of where everyone is at.
Which is why it's pointless. It gives project leads warm-fuzzies that they think they know what's going on.
Code reviews are only part of it. If that's truly all your involvement with your co-workers, that's sad.
No, it means I'm spending most of my work time actually working on the things assigned to me, i.e., what you're paying me for. It makes me maximally productive and either on-time or ahead of schedule.
You can get the same result with a daily email, but you usually won't. Daily emails usually don't get the same results and involvement.
If you've already drank the Agile Kool-Aid, how do you actually know you won't get the same results? And if you don't get them, why not figure out how to solve that problem (while still using e-mail).
The stand up meeting with 10 people takes like 3 minutes. Perhaps 5...
How?? If you limit every person to 1 minute, that's 10 minutes right there.
And why don't you care what your coworkers do?
Because it doesn't affect the code I'm working on and I simply don't have the luxury of time to care. I don't care any more than the local baker down the street has to care what the local butcher does. Division of labor is a good thing.
How can you possibly not care about what the rest of your team is doing to the code that you're working on?!
That's what code reviews are for.
But sometimes somebody is trying to figure something out on his own because he's sure he can do it and doesn't want to disturb others with it, when actually someone else can solve his problem much faster. Standups are for detecting that issue.
One justification for stand-ups I've heard is to prevent slacking off; now this one to mitigate stubborn and/or prideful people. It sounds like Agile is a way to baby-sit people with work-ethic or personality defects. You can get the same result with a daily e-mail -- that I can glance at much more quickly than having to hear someone speak it and either delete it (because I know nothing about their problem or how to help) or answer it.
You're not a team player, you're not an effective developer, it's that simple.
I'm a team player in that we're all working towards the same goal. As for effective developer, modesty aside, I write the best (correct, concise, efficient, well-commented, and even well-formatted) code in the project (or, in all my years, in any project I've even been part of). Go Google me and download some of my open-source code for a look.
1) If someone falls ill, everyone else knows where he was upto so someone can take over
That's a complete fantasy. Even if I know what you're doing, that doesn't mean I'm familiar with your code, your algorithms, your data-structures, etc. If I have to be sufficiently familiar so I can take over (and I have to be able to do this for everybody on the entire team), when am I supposed to find time to work on my own stuff? Your fantasy could only possibly work for very small teams. It simply doesn't scale.
2) Talk about problems can cause others to offer solutions, or if the problem was already solved, to share solutions so others don't encountered similar problems
That can be done via e-mail.
3) Raising more general problems such as "It was too hot in here to concentrate yesterday" so that the product owner/SCRUM master can go do something about that, like buy some fans
That also can be done by e-mail, or simply walk into that person's office. The same is true for the rest of your reasons.
If your standups are rolling on for more than 5 - 15 mins then yes, you're doing it wrong.
Most of my teams have been about a dozen people. If you limit every person to 1 minute, that's still 12 minutes. Again, Agile doesn't scale.
With regards to solving problems when they happen, yes, if you can do that do that, but don't just arbitrarily interrupt the whole dev team to ask if they know anything about it and ruin their concentration.
I'm not suggesting you stand up on your desk and shout out to the entire office -- send a group e-mail. If I'm deep in concentration, I can ignore your e-mail for a while.
... you don't care what anyone else is doing because you have no intention of carrying on their work if something happens to them, I guess that's "someone else's problem"
It is someone else's problem: the project lead's. That's what he gets paid (usually paid more) for. If I spend my finite time staying informed about everybody else's work and nothing happens to them, then it was a waste of my time. If, however, my project lead comes to me and says, "Jim was hit by a bus and I need you to take over his work," then I can become familiar with his work in a focused way. The time it would take is probably better than conserved because it's a focused effort rather than 1 minute a day.
Agile places a high value communication, especially face to face communication. You can pick up things face to face that you can't in an email.
And yet, somehow, projects like, oh, the Linux kernel, the Apache HTTPD server, and just about every other open-source project out there seem to be able to muddle along without face-to-face communication.
Besides projects are supposed to be a team effort and as a member of the team you should care what other people are doing and what issues they may be running into.
That's your job as project lead.
... and no need to put added pressure on any dev by suddenly making daily inquiries about their progress.
Then you explain to them why you are making such inquiries and, if they'd like them to stop, what they should do about it.
If you are downstream from me you better care what I have done, because eventually it get merged into the build. And just because it builds properly and passes unit tests does not mean it is correct.
Which is why you should have implemented the specification we mutually agreed upon at the outset. As long as you do that, I shouldn't have to care what you do on a daily basis.
Ditto for what is happening today. You better know what is going on so you can be agile and adjust.
That can happen by you walking over and talking to me or sending me an e-mail at any time (but only when necessary) and doesn't (nor shouldn't) have to wait until the next daily stand-up.
...if you are blocked you bring it up in the next standup...
No, you send e-mail about it immediately. If you get blocked 10 minutes after the day's stand-up has ended, you're doing to wait 23+ hours to bring it up? Seriously?
Man people must love working with you. I like taking an interest in what my colleagues are doing day to day.
I like coworkers who are motivated and talented such that if I know (from some initial communication) they're working on X that's due on date Y, I can rest easy knowing they'll deliver quality code on time. I have plenty of my own stuff to think about. I'd rather not have to concern myself with everybody else's stuff on a daily basis. If I'm working with such people, I shouldn't have to care either.
If they've spent 2 days on something that should have taken a few hours, you as the project lead know there's trouble.
Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?
Just the fact that a developer on a daily basis has to stand up in front of their peers identify what they did and what they are currently working on helps them stay on task...
In other words, it's a way to keep people from slacking off. Surely as a project lead, you know who your good, self-motivated developers are and who your slackers (or potential slackers) are. If that's the case, then simply fire the slackers or, slightly less drastic, require daily e-mails from only the slackers and leave the better developers alone.
You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.
I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.
Wrong: those things don't solve transportation problems, because they're all 19th-century technology.
That's not an argument. "New" doesn't always mean "better."
Light rail sucks; it's slow and very expensive...
It's only slow if done wrong (and several municipalities do it wrong, either out of ignorance or because doing it right would cost more -- which gets back to my point that it's chiefly a money problem, not a technology problem). If you give light rail its own right-of-way, then it's certainly faster than both busses and private autos that have to sit in traffic. Throw in signal-priority for trains (assuming there are at-grade intersections) and it gets even faster. Add pre-boarding fare-payment and it gets faster still.
That's why 20th-century technology like PRT is the solution: use automated cars to move people between points of their choosing, on demand (rather than according to a fixed schedule).
For starters, the technology isn't there yet for real-world deployment, especially if they're on roads shared with private cars, pedestrians, and bicycles. Move it to a closed-track system and it too becomes hugely expensive, not to mention where to find the right-of-way since you can't simply phase out conventional modes of transit over night.
... with SkyTran, you hang the rails from simple utility poles.
I don't know about other places, but that probably wouldn't fly at least here in SF since there are many who find anything elevated to be ugly.
... or even to put it on the ground.
See 2 comments up.
Who the hell wants to walk 2 miles from the nearest stop to their destination?
Who said anything about 2 miles? All I said was that stops were too close. Decent spacing for stops is 2 blocks: you'll never have to walk more than 1 block to a stop. That's perfectly reasonable.
You're right, there are a lot of problems that could be helped by new tech. Just look at transportation for instance: we spend a ton of money on it in the US, and it sucks: it's slow, we spend lots of time idling in traffic or at stoplights, our cars are driven by oil-burning, pollution-spewing horrifically inefficient engines, and 50,000 people die every year in auto accidents.
New tech isn't going to solve transportation problems. We already know how to solve transportation problems and it comes down to money for building new infrastructure, e.g, subways, light rail, high-speed heavy-rail, and transit-only lanes. All that is hugely expensive.
Then there's the NIMBYs. Take San Francisco: people complain about Muni (the city transit agency), but they simultaneously fight tooth-and-nail against any improvements because they don't want their neighborhoods or businesses temporarily disrupted for a couple of years for the construction. Cases in point: the new Central Subway that's being built and a Geary line that's been fought for decades by one man who heads the Richmond district's neighborhood association.
Also, Muni also has way too many stops on lines, sometimes less than 1 block apart (thus slowing them down). The agency wants to remove stops, but people don't want their closest stop removed.
People's attitudes have to change to make sacrifices for the greater good rather than it being about me, me, me.
Yes I know this contradicts the conventional wisdom that HFCS is bad, while sucrose (which your body breaks down into 50% fructose / 50% glucose) is good.
... cancelling all remote working while the rest of the word is learning how to adapt to and benefit from it.
I talked to someone who works for Yahoo who told me that, out of the roughly 11K employees, this affects only around a couple of hundred. Of those, many will simply get a desk/cubicle at the office (thereby meeting the "on site" requirement), but actually still work at home most of the time. The reality is that this is basically a non-change.
That being the case, it still makes you wonder (if it's as much or a non-change as claimed by the Yahoo employee I spoke to) why bother? The Yahoo employee has no answer to that.
Slashdot Mirror
It should never happen in the first place. The specification should be crystal clear. Any ambiguities would have been worked out at the outset where I confirm that he really wants X.
If you feel that way, then maybe software development isn't for you. I don't see it much differently that writing a book (in terms of the actual working environment). Presumably book authors do it because they love to write. The fact that it's a solitary job is irrelevant. I write code because I love to write code. I don't need my work environment to be a place for friends to socialize.
If he needs to know that, it means he doesn't trust me. If, however, he does trust me, he assigns a block of work X to be done by date Y and he can then essentially completely forget about me knowing I'll have it done by Y.
Well, of course.... just like when the project is laid out at its inception. But, once laid out, there don't need to be daily meetings about it any more than I have to call my mechanic every hour. I think you're missing my point.
That's the project manager's job. I shouldn't have to care if he's doing his job. It's a matter of trust and competence.
If I have a good auto-mechanic that I trust, I know I can drop off my car, he'll diagnose and repair the problem, do good quality work, and not rip me off. That enables me to have the peace-of-mind to not have to care about his work or how he gets it done.
I should have that same level of trust in everybody I work with so I don't have to care. I think part of the problem here is that the phrase "I don't care" is seen negatively in common use. I don't mean it that way. If I don't care about your work, it's because I know you'll do a good job (just like with my auto-mechanic). That frees my time up to work on what I need to work on.
If I have to care about your work, it implies I need to baby-sit you because I don't trust your quality of work or that you'll get it done on time.
You make it sound like a team is some kind of social program (no developer left behind). It's not. A team is a part of a company whose goal is to make money -- with any luck, enough of it to retire early.
That should have been worked out during the design phase.
It seems you've got it backwards: only in toy projects would everybody's code affect everybody else's (because the code-base is small). In most of the projects I've worked on, the code-base is fairly large. As long as the interfaces don't change often, what they do under the covers doesn't affect my code.
And if the interfaces do need to change, well that's not the kind of pervasive change you suddenly bring up in a daily stand-up. That would require a more formal design meeting.
You can't make a silk purse out of a sow's ear. I'd rather simply hire better people.
Then you're letting your personal feeling influence your objectivity. It's much better than 99% of the crap out there for the formatting, comments, variable-names alone. And most code is mundane in its purpose -- but it can still be done well.
The problem is their code is often terribly formatted, not commented, and is often 3 times as long as it needs to be. Bad developers always write far more code than necessary because they don't know how to do things concisely. Code reviews are supposed to catch this, but not everybody can review everybody else's code. (What usually happens is that they get their buddy -- who writes equally crappy code -- to review it.) So no, I often can't make heads nor tails of somebody else's crappy code. I often throw it out and rewrite it from scratch in about a third the space (including comments).
Why does anybody care what you did yesterday? It's in the past. What's done is done. The only part of that that has any potential value is the problems. The yesterday/today stuff -- what problem does anybody else know that solve?
Which is why it's pointless. It gives project leads warm-fuzzies that they think they know what's going on.
No, it means I'm spending most of my work time actually working on the things assigned to me, i.e., what you're paying me for. It makes me maximally productive and either on-time or ahead of schedule.
If you've already drank the Agile Kool-Aid, how do you actually know you won't get the same results? And if you don't get them, why not figure out how to solve that problem (while still using e-mail).
How?? If you limit every person to 1 minute, that's 10 minutes right there.
Because it doesn't affect the code I'm working on and I simply don't have the luxury of time to care. I don't care any more than the local baker down the street has to care what the local butcher does. Division of labor is a good thing.
That's what code reviews are for.
One justification for stand-ups I've heard is to prevent slacking off; now this one to mitigate stubborn and/or prideful people. It sounds like Agile is a way to baby-sit people with work-ethic or personality defects. You can get the same result with a daily e-mail -- that I can glance at much more quickly than having to hear someone speak it and either delete it (because I know nothing about their problem or how to help) or answer it.
I'm a team player in that we're all working towards the same goal. As for effective developer, modesty aside, I write the best (correct, concise, efficient, well-commented, and even well-formatted) code in the project (or, in all my years, in any project I've even been part of). Go Google me and download some of my open-source code for a look.
That's a complete fantasy. Even if I know what you're doing, that doesn't mean I'm familiar with your code, your algorithms, your data-structures, etc. If I have to be sufficiently familiar so I can take over (and I have to be able to do this for everybody on the entire team), when am I supposed to find time to work on my own stuff? Your fantasy could only possibly work for very small teams. It simply doesn't scale.
That can be done via e-mail.
That also can be done by e-mail, or simply walk into that person's office. The same is true for the rest of your reasons.
Most of my teams have been about a dozen people. If you limit every person to 1 minute, that's still 12 minutes. Again, Agile doesn't scale.
I'm not suggesting you stand up on your desk and shout out to the entire office -- send a group e-mail. If I'm deep in concentration, I can ignore your e-mail for a while.
It is someone else's problem: the project lead's. That's what he gets paid (usually paid more) for. If I spend my finite time staying informed about everybody else's work and nothing happens to them, then it was a waste of my time. If, however, my project lead comes to me and says, "Jim was hit by a bus and I need you to take over his work," then I can become familiar with his work in a focused way. The time it would take is probably better than conserved because it's a focused effort rather than 1 minute a day.
And yet, somehow, projects like, oh, the Linux kernel, the Apache HTTPD server, and just about every other open-source project out there seem to be able to muddle along without face-to-face communication.
That's your job as project lead.
Then you explain to them why you are making such inquiries and, if they'd like them to stop, what they should do about it.
Which is why you should have implemented the specification we mutually agreed upon at the outset. As long as you do that, I shouldn't have to care what you do on a daily basis.
That can happen by you walking over and talking to me or sending me an e-mail at any time (but only when necessary) and doesn't (nor shouldn't) have to wait until the next daily stand-up.
No, you send e-mail about it immediately. If you get blocked 10 minutes after the day's stand-up has ended, you're doing to wait 23+ hours to bring it up? Seriously?
I like coworkers who are motivated and talented such that if I know (from some initial communication) they're working on X that's due on date Y, I can rest easy knowing they'll deliver quality code on time. I have plenty of my own stuff to think about. I'd rather not have to concern myself with everybody else's stuff on a daily basis. If I'm working with such people, I shouldn't have to care either.
Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?
In other words, it's a way to keep people from slacking off. Surely as a project lead, you know who your good, self-motivated developers are and who your slackers (or potential slackers) are. If that's the case, then simply fire the slackers or, slightly less drastic, require daily e-mails from only the slackers and leave the better developers alone.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.
I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.
That's not an argument. "New" doesn't always mean "better."
It's only slow if done wrong (and several municipalities do it wrong, either out of ignorance or because doing it right would cost more -- which gets back to my point that it's chiefly a money problem, not a technology problem). If you give light rail its own right-of-way, then it's certainly faster than both busses and private autos that have to sit in traffic. Throw in signal-priority for trains (assuming there are at-grade intersections) and it gets even faster. Add pre-boarding fare-payment and it gets faster still.
For starters, the technology isn't there yet for real-world deployment, especially if they're on roads shared with private cars, pedestrians, and bicycles. Move it to a closed-track system and it too becomes hugely expensive, not to mention where to find the right-of-way since you can't simply phase out conventional modes of transit over night.
I don't know about other places, but that probably wouldn't fly at least here in SF since there are many who find anything elevated to be ugly.
See 2 comments up.
Who said anything about 2 miles? All I said was that stops were too close. Decent spacing for stops is 2 blocks: you'll never have to walk more than 1 block to a stop. That's perfectly reasonable.
New tech isn't going to solve transportation problems. We already know how to solve transportation problems and it comes down to money for building new infrastructure, e.g, subways, light rail, high-speed heavy-rail, and transit-only lanes. All that is hugely expensive.
Then there's the NIMBYs. Take San Francisco: people complain about Muni (the city transit agency), but they simultaneously fight tooth-and-nail against any improvements because they don't want their neighborhoods or businesses temporarily disrupted for a couple of years for the construction. Cases in point: the new Central Subway that's being built and a Geary line that's been fought for decades by one man who heads the Richmond district's neighborhood association.
Also, Muni also has way too many stops on lines, sometimes less than 1 block apart (thus slowing them down). The agency wants to remove stops, but people don't want their closest stop removed.
People's attitudes have to change to make sacrifices for the greater good rather than it being about me, me, me.
True.
False. You can tell the me combination to your safe, but the safe is still yours.
False. Lack of evidence is not evidence. The 5th Amendment is not a tool for the guilty, but for the innocent.
The reality, however, is that while, yes, HFCS is bad, sucrose is equally bad.
But it's bad PR.
I talked to someone who works for Yahoo who told me that, out of the roughly 11K employees, this affects only around a couple of hundred. Of those, many will simply get a desk/cubicle at the office (thereby meeting the "on site" requirement), but actually still work at home most of the time. The reality is that this is basically a non-change.
That being the case, it still makes you wonder (if it's as much or a non-change as claimed by the Yahoo employee I spoke to) why bother? The Yahoo employee has no answer to that.
How is this news for nerds?