7 ms·

What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing? The current trend o

• kerbalspacepro 8y ago
  1. Agile is not personally great for programmers. 2. Agile is good for managers. 3. Managers run the business and make sure it exists. 4. Programmers need the business in order to have a job. 5. Agile is therefore good for the business, 6. And therefore Agile is good for Programmers, though not personally.
  • crazypyro 8y ago
    I would disagree with almost every claim on this list.
    • kerbalspacepro 8y ago
      I don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much). The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.
    • nottorp 8y ago
      Agile is good for managers who are unable to evaluate their programmers otherwise.
  • UnpossibleJim 8y ago
    My, how very Douglas Adams of you =)
  • j4kp07 8y ago
    Unfortunately, you have been taught and are executing Agile in the completely wrong fashion. My first guess would be, you are actually working in Waterfall, but your managers have labeled it Agile and cherry-picked the parts they liked.
    • paulmooreparks 8y ago
      Agile has a remarkable resemblance to both communism and faith healing: Every time I say it doesn't work, a true believer replies and says I wasn't doing it right or I didn't believe in it enough.
  • windows_tips 8y ago
    4. Managers need the Programmers, to make sure the business exists. 5. Agile may or may not be good for Programmers. 6. Agile may or may not be good for the business.
  • Scarblac 8y ago
    Agile is good for managers in that it gives them a feeling of being in control. Agile is not actually for managers, in that productivity suffers a lot, less software with real value is produced. But software productivity is notoriously hard to measure, so it is ignored.
• Chyzwar 8y ago
  Because you work in the team.
  • hinkley 8y ago
    A boss used to say to us, you haven't proven you know how to do it until you've done it twice. This is, as I recall, also the guy who would pigeonhole people who built things that they couldn't hand off to others. He fed us some bullshit line about being 'too important' to work on the new cool stuff. It was a hard lesson but I learned pretty quick to put extra time in to make my code obvious to others instead of just me. Boost your truck number if you ever want new scenery. (Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)
• ben509 8y ago
  I'm not sure how much that micro-managing aspect is peculiar to agile and how much is just inherent to working on a team. > It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable. That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo. Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit. [1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.
  • mohdmasd 8y ago
    Unfortunately, we do not live in Utopia. In reality, politics, competition and self-interest play huge role in the workplace. In some companies, admitting a mistake or showing vulnerability in front of the wrong crowd can be very damaging for your career there.
  • closeparen 8y ago
    That sounds like hell. The sense of ownership, achievement, and subject matter expertise when driving projects from ideation to completion is everything I like about my job. Working on scattershot, atomized tickets from an assembly line would be awful.
• nawgszy 8y ago
  >What if I don't want a team mate to look at something I'm working on? >What if I just want to focus on building, not explaining and sharing? >it makes them share if they are thinking incorrectly about something >it makes them easily replaceable I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable. Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......
  • Benjammer 8y ago
    This mentality is the root of the problem (from the dev perspective). The GP commenter is saying "these processes don't help me to feel that I've done my job better." And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."
• tnolet 8y ago
  If you don’t want to explain or share, I don’t want you on my team.
  • closeparen 8y ago
    I’m confident I can identify some interval at which you don’t want to explain or share, either. For example, every 30 seconds. Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.
• majormajor 8y ago
  Do you care how useful the thing you're building is for the people you're building it for? How well it fits in with what other people on the team are building? If any of your teammates have ideas that could be helpful, or have learned things that might be of interest to you? I've often been the guy who comes in to help untangle a messy code base, and an entrenched "just let me build shit" attitude appears to be a chief predictor of unextensible and inflexible design. Even when not in a managerial role, I don't like to see people working in silos because experience has taught me that I'm gonna have to deal - as a fellow dev - with repercussions of poor design sooner or later.
  • closeparen 8y ago
    If daily standup has any role whatsoever in those questions, your process is horrifically broken.
• brown9-2 8y ago
  are you really on a team then?
  • closeparen 8y ago
    A manager usually has several distinct projects in the air, with ICs working on them in groups of 1-3. Someone's work isn't relevant to you just because you report to the same manager. The "team" for standup, sprint planing, etc. is really several teams, each tuning out while the others speak. And because small groups can communicate fine informally, the relevant-seeming part of the team-level ritual is always a rehash of what the project staff already know.
    • brown9-2 8y ago
      That sounds like a bad structure then. Standups ought to be for the teams of small groups, not the convenience of the manager.
• dudeofea 8y ago
  Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view. Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well. What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback. A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?
  • KZeillmann 8y ago
    It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.
    • pwm 8y ago
      I'm not GP, but let me try to explain. The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution. On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
• fouc 8y ago
  There's still code review right? And if you're off building something more involved, then hopefully that code review is happening on a weekly basis with at least 2 people reviewing it so that there's input and ideas and corrections happening. It's brutal to see someone waste time on building out unnecessary parts, etc. Plus it's also useful to reduce bus factor, have other people in the loop to pick up the work if necessary.
• mvindahl 8y ago
  > it makes them easily replaceable I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective. Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn. Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented. I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.
• IOT_Apprentice 8y ago
  ah the black hole programming movement! We've been there with "waterfall", which was a disaster. Not explaining and sharing is counter to working on a team. If you are a one man army, and no one knows what your code does, or if it can be compiled or deployed without errors, then that is bad for your company.
• Scarblac 8y ago
  It's a crime that Scrum is allowed to call itself "Agile". Look at the Agile Manifesto again, then look at Scrum. Almost complete opposties.
  • collinmanderson 8y ago
    Yes, it's a little disappointing that the term "Agile" pretty much now refers to Scrum.