11 ms·

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping a

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" Seniority has nothing to do with this. Communication/coordination/knowledge-sharing matter at all levels.

H8crilA 6y ago
It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.
- austincheney 6y ago
  There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.
  - Twisell 6y ago
    You are totally right but probably assuming you have a top notch and easily discoverable documentation that can guarantee that newbies won't spend 15 days reimplementing "that bash script you need once a year or so" that do the job in 2 minutes. However even if this case you might get lucky and end up with a new script that do the job in 30 seconds and everybody in the team have learn that documentation is very important.
    - H8crilA 6y ago
      It's a matter of balance. No simple rule of thumb exists. Sometimes it results in a much better solution, great! Sometimes it's a new wheel but with more awkward square-ish corners. Sometimes (and this is the worst because it's hard to explain) it is actually better but still likely has been a waste of the engineer's time - high cost vs low benefit, also often cooccurs with lack of team's capacity to maintain the new thing.
  - joatmon-snoo 6y ago
    Re-inventing the wheel can be useful for learning, but can have very real costs, often in the form of production outages. * "You can usually use user metadata field X for billing" - except for those users for whom field X actually maps to something else, for tech debt reasons. (Is it stupid and bad? Yes. Is anyone going to be able to fix it this year? No. Is this going to result in Very Big Customer TM getting mad? You Betcha.) * "Oh, I'll just roll my own fake of Foo" - congratulations, now anyone looking for a fake needs too decide between yours and the other one. (Yes, this is highly context dependent, but the moment you have multiple fakes in common/util libraries this usually starts being a problem.) * "I can just use raw DB writes for this, because I don't want to learn how to use this API" - except the abstraction exists because it guarantees you can do safe incremental, gradual pushes and roll back the change, whereas your home-rolled implementation had a small bug and now the oncaller needs to do manual, error-prone surgery on the backup instead of the usual undo button built into the API. (Oh, and legal is going to have a field day because there's no audit record of the raw writes' content.) Cargo-culting is bad, yes, but reusing existing abstractions is often important because they handle (or force you to handle) the various edge cases that someone learned about the hard way. And of course, if you find a bug in the existing abstraction, well, congratulations- you just found a repro and root cause for that infamous support case that's been giving everyone data integrity nightmares for months.
    - austincheney 6y ago
      > often in the form of production outages Completely unrelated. If you have production outages resulting from new code you have serious gaps in your certification process, especially so if the new code covers existing process/requirements. You are probably insecurely reliant upon dependencies to fill gaps you haven’t bothered to investigate, which is extremely fragile. The benefit of code reuse is simplification. If a new problem emerges with requirements that exceed to current simple solution you have three choices: 1. Refactor the current solution, which introduces risk. 2. Roll an alternative for this edge cases and refactor after. This increases expenses but is safer and keeps tech debt low. 3. Roll an alternative for this edge case and never refactor. This is safe in the short term and the cheapest option. It is also the worst and most commonly applied option.
- mark-r 6y ago
  We decided early on that a daily scrum was just too frequent to be effective for our team, so went to 2x per week. When we started working from home, we added a "keep in touch" meeting for the other 3 days of the week just to stay connected.
  - mixologic 6y ago
    Our standups (for a team of four) are about 15 minutes. Then we just leave the zoom on and co-work together out loud for an hour or two. It's pretty priceless the stuff that comes up during that time.
    - lydon 6y ago
      Always thought this will be useful, but never had a chance to experience it. What kind of stuffs come up?
  - GordonS 6y ago
    Yep, not being dogmatic about standups having to be daily, or indeed about any process, is invariably a win - do what works for the team! I'm working in a small team just now, just 5 of us, and a short, daily standup is working well for us - and it's usually finished in 7 minutes or so. In my last project (where I wasn't leading the standups), the teams were bigger, 10 people in each, and they went.on.forever. Neither the scrum master or PM were strict at curtailing them or keeping them relevant. Everyone hated it.
- avereveard 6y ago
  I'm glad I've reinvented the wheel that many time as a junior, it let me learn why some framework and some solutions are the way they are, and made it extremely easy to pick up third party solutions later on
  - throwaway2245 6y ago
    We'll never know the counterfactual, but in my opinion: You could have learned the same thing more efficiently, with more support for why you didn't need to reinvent the wheel.
    - paledot 6y ago
      I've been a professional software developer for ten years, and I'm on a hiatus right now. One thing I've been doing with my time is reinvent a bunch of wheels, implementing broken clones of this library or that algorithm, and I've gained a tremendous amount of understanding of what's going on behind the scenes of tools I'd been using for years. So yeah, it's a valuable learning tool to build with your own hands. Also, a valuable guide when deciding whether to write code yourself or introduce yet another library to your dependencies.
      - datavirtue 6y ago
        Before getting sucked into the enterprise world, I reinvented a bunch of wheels and this indeed gave me a deeper understanding of the inner workings of various frameworks and technologies. I noticed that my colleagues who had ten years or more on their resume rarely had any idea what I was rambling on about or the basis for the things they were using. Their were so busy trying to get stuff done that they never had time to explore. I don't mean blog post or tutorial explore, I mean weeks and weeks of implementation and testing of patterns and low level engineering. Building database engines from scratch or writing a compiler or a distributed message broker, for instance.
jimbob45 6y ago
Agreed. It’s a deliberate inefficiency to make sure you at least have a chance to communicate with your team on a regular basis. Otherwise you might go days or weeks without the chance to have a critical two minute conversation.
- crdrost 6y ago
  That sounds suspiciously like your team is not communicating enough in the first place though. I mean, I guess the profession does get its fair share of introverts, but I would have expected enough teamwork that everyone knows what everyone else is doing, at least roughly. At my last gig I remember we had three backenders and four frontenders on a game we were building and the stand-ups seemed superfluous, Ryan on the frontend knew all of the frontend tasks and their exact states, I on the backend knew all of the backend tasks and all of their states, stand-ups were more of a means to celebrate what folks had done and coordinate that info with our QA team. My silver rule of meetings is “to make a meeting matter, make a decision.” If we were assigning new tickets and/or backlog, deciding who would own each of them, that meeting is valuable. Progress updates can be delivered asynchronously and consumed asynchronously, unless, say, one wants group applause. Of course now covid exists and I changed jobs to a team that barely talks with me and daily stand-ups are kind of my only social contact with them, so that's less fun. But yeah, 100% the original vision of agile with the “developers should be meeting daily with the product users to clarify the underlying model and mold the software to their hands” should cause people to work together so much that stand-ups become something of an afterthought.
  - closeparen 6y ago
    It sounds like you and your team are working on the same artifact and that your tasks are interrelated. That’s kind of a special case. At any given time our 3 engineers have maintenance tasks in flight on 4 or 5 distinct products.
    - tikhonj 6y ago
      If people are working on completely unrelated things, what do you get from a stand-up other than a group status update?
axaxs 6y ago
Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.
- eyelidlessness 6y ago
  Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They shouldn't be too hard to trigger, or you're never going to get one (or results from one). The best process for this is "shit goes down and you should make appropriate dedicated space for it". Edit to add: I want to emphatically contradict my metaphor in one way, which is that retros should be exactly the opposite of a recall election in terms of identifying/naming/assigning fault. They should be about identifying good/bad outcomes and good/bad patterns, but not about pointing fingers at or casting aspersions on people.
  - pseudalopex 6y ago
    It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.
    - axaxs 6y ago
      Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.
      - arbalist 6y ago
temporallobe 6y ago
Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their work. The best kind of standups are those where you can feel free to discuss your blockers and simply state what you’re doing so the team has a general awareness if what’s going on and how/if it impacts them.
- deleted 6y ago
  [deleted]
- crescentfresh 6y ago
  > not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.
  - projectileboy 6y ago
    In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.
    - dragontamer 6y ago
      > In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors. As someone who did sales early in my career... acting off of a script correctly feels like a casual conversation to the one you're selling to. If your script-reading is bad, that's because you haven't practiced enough. Having a script isn't necessarily a bad thing, and is in fact very useful in keeping focus.
      - emteycz 6y ago
systemvoltage 6y ago
Let’s be honest, stand ups are there so we can get together as a team. Otherwise, engineers would be heads down working on their own things. Benefits of “Oh I yea I’ve worked on the same thing before” are usually realized outside of stand ups in over the shoulder chats or slack. Stands ups are a waste of time. There, I said it. But, I like them, especially if you have a fun team.
- Clubber 6y ago
  For our team, we just do a weekly biz/dev meeting, then break into a pure dev meeting every Tuesday morning. The process takes about 30min - 60min a week and we can go into depth when needed. Plan the week and go do what we do. It works great for our small 5 man team. Daily meetings seem excessive to me, even if they only last 5 minutes.
- ffhhj 6y ago
  Agreed! Stand ups are a teather play to make the client believe a project is moving forward, while team members use their own private channels to talk about the real work.
tikhonj 6y ago
A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up. If something is important, why would you wait for tomorrow's standup? If something isn't important, why are you dedicating an inflexible daily meeting to talking about it? If your team is having the sort of communication problems standups are supposed to solve, it's a symptom of a deeper issue and standups are a bandaid solution. If your team already works collaboratively, standups are pure overhead at best and actively counterproductive at worst. It's easy to get into the bad habit of waiting for a standup to bring up important issues, which loses time and context. Worse yet, chances are the standup has too many people and not enough time to discuss anything in detail—I've seen so many standups where any actually useful conversation would be caught, stopped and moved to a different venue. You end up with a pro forma meeting where most of the information isn't useful to most of the attendees, but still breaks up people's schedules and focus. In my experience, an emphasis on standups goes hand-in-hand with a view of engineering work as a ticket factory: individuals get a ticket off the queue, work just on that, get it done as soon as possible and pick up another ticket. I think that correlation is not a coincidence.
- ncann 6y ago
  While you have a point, it's not that rare for someone to be blocked on a hard issue for a day or two, even having talked to someone, then bring that up at the stand-up. The one you talk to may not always have the solution, and it may be someone else in the team at large.
  - pseudalopex 6y ago
    Email works great for that.
- Chris_Newton 6y ago
  That seems like a reasonable concern to me, and something that could apply to almost any communications that are on a regular schedule, whether it’s a daily team meeting or an annual review with your boss. My father said something to me when I was nervous before my first annual review in my first job, and it has stuck with me ever since: nothing anyone says in that review should ever be a surprise. Whether it’s good or bad, if your management are doing their job, everyone who needs to know about it should have known when it became relevant, not on the anniversary of your employment. I suspect there is more value in some types of regular but short technical meeting at the moment, when many colleagues aren’t in close proximity at work and ad-hoc informal discussions are less likely to serve the same purpose. But as someone who’s primarily worked from home for years, I’d usually still prefer to arrange a group call or physical meeting with whoever actually needs to be there when there’s something specific to discuss, rather than assuming in advance that any particular tempo will be the right one.
Shorel 6y ago
Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.
- zbobet2012 6y ago
  I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).
  - kettro 6y ago
    To this end, I have a small, paper-sized whiteboard that I can scrawl onto on hands at all times. I bought a couple packs of the ultra-fine expo markers, and it’s been a boon. Great for quickly noting things down that don’t need to last. Having both is important, though: you need to be able to preserve the things that matter, that you may need later on.
    - mark-r 6y ago
      That's why phones have cameras.
    - Shorel 6y ago
      You can use the rocketbook app. No need to buy the notebook. https://getrocketbook.com/ https://getrocketbook.com/
  - Shorel 6y ago
    And I find a whiteboard a bit more intimidating. It kind of implies performing your writings in public. A notebook is a very personal thing. =)
    - tribaal 6y ago
      I recently switched from a very whiteboard/paper heavy workflow to using a reMarkable tablet. Holy shit this thing is good. It's like an infinite notepad/whiteboard that auto syncs to the cloud, lets you define page layout templates, and renders PDFs and ebooks. I've had it for just a few weeks and it's already the favorite pice of tech I own.
rektide 6y ago
> Standups are useful for communication between a team in general, if kept brief. Just once I'd like to work for a company that tries to stay in communication without so many explicit/manual/sync check-in gates. * No stand-up, engineers required to write a 250-words or less blog post 2+ times a week. * No announcing PRs, reviews &c to each other. Make watching the board a habit, one you "pull" rather than that is pushed to you. Or use a company provided chat-bot/tool to help surface changes as they happen, if you need that. The issue tracker should better dashboard whatever activity is happening, in general- indicate branch updates, pr changes, &c, clearly, across the board. There's some value to using social processes to radiate all the changes happening, but I'd really like to see some camp out there that makes a go at mechanizing themselves. I think there are a lot of interesting possibilities, more enduring & valuable forms of communication that we have failed to even begin to explore.
- jbay808 6y ago
  A place I used to work had engineers documenting their work essentially in the form of a blog. It was actually really a useful habit, and reviewing the project blogs once each week made it really easy for me to find cases when I could help a colleague who was working on something I'd had experience with before.
  - anaerobicover 6y ago
    I'd venture that the parent was talking about engineers "documenting" their work for managers, whereas I think you mean documentation for other engineers. Very different audiences and thus different things to say. (And widely different lifespans for the information.) The latter no doubt is hugely useful (I'm on a long slow effort myself to get my co-workers to document their work more robustly). But writing status reports for managers/PMs on a weekly basis is, in my not so humble opinion, a complete waste of time for the company, and a sign of poor organization.
    - rektide 6y ago
      I was hoping both purposes would be served, at this mandatory level. I would adore any engineer who writes more blog posts walking through what they're up to more technically. How do you feel about every-day stand ups as a means for managers/PMs to check in on employees? My own impression has been that this is at least 50%+ of the reason for stand up, and to me, I'd far prefer periodic write-ins, rather than ephemeral, undetailed, synchronous communication.
christkv 6y ago
We always run standups in the same way. What did I work on yesterday, what am I working on today and finally impediments or help required as well as general organizational stuff that might impact the team.
- Falkon1313 6y ago
  So do we, but generally a quick glance at the kanban board would show that for everyone. Well, it would if we had one unified board. Instead we have stuff scattered across multiple boards. Still it would only take 1-2 minutes to open them all up and glance through them. Information radiators. They work well. Instead we have a 30-60 minute standup/sitdown/try-not-to-doze-off meeting to achieve the same thing. We used to also have additional meetings to review the boards but eventually cut those because people got tired of me saying "the status is still the same as I said an hour ago, because I've been in this meeting since then." The exception is stuff like team announcements, reminders that someone's going to be out, requests for someone to volunteer to take a task. That can all be done async though.
diob 6y ago
Standups aren't always necessary, but you'd need a high functioning (read communicative) team. In other words, they serve primarily as a forcing function to make sure teams are acting like teams (communicating). I find the most useful standups are asynchronous though. It's much easier for others to follow along (and ask follow up questions), and avoids statuses devoid of usefulness (or at least makes them very apparent).
js8 6y ago
> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so that everybody knows about him being an expert and consults with him on a regular basis. Is it really better to have everybody a shallow experience with everything rather than have a few individuals with a deep expertise with a particular thing? And to have a meeting every day to "solve" this non-problem (somebody not knowing who the expert is, or supposed to be) seems really inefficient.
- Scea91 6y ago
  Reason why I don’t want my team to overspecialize: I don’t want them to isolate and develop tunnel-vision. I want everyone to be aware of the project goals and understand the work that needs to be done to deliver value. My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected.
  - js8 6y ago
    > My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected. I doubt it isn't the case either way. If you neglect understanding and development of expertise, you will still end up with some people having more expertise than others, and possible blind spots. Except now you have no idea what those blind spots are. (https://news.ycombinator.com/item?id=10970937 https://news.ycombinator.com/item?id=10970937)
- Jestar342 6y ago
  That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck. Natural siloing happens, but you (team) should be striving to reduce it, not encourage it. *More accurately: work can only proceed on that something when X is available*
skohan 6y ago
I agree the list is very good list in general. My point of disagreement is: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions. The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"? After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.
- otijhuis 6y ago
  I consider software architecture to be extremely important and based on the other opinions of the author he probably agrees with you that it should be "just-in-time", as do I. Useless abstractions just get in the way and make things complex and hard to understand. Yes, if a program doesn't function the way it's supposed to, it's useless. Unfortunately I've seen many developers take shortcuts and not even think about the software architecture (because "hey, it works doesn't it"). Good software architecture not only makes it much easier to build functioning software, it also makes the team function much better. The ability to maintain the software and quickly add new features depends on it. Even little things you do can contribute to a good software architecture. Overengineering leads to a terrible mess, so does the "hey it works, I don't care about anyone who has to maintain it" mentality. Ideally you'd be somewhere in the middle. You shouldn't design everything up front and you shouldn't ignore things that are right around the corner either.
jrib 6y ago
> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I personally hate stand-ups. We do get benefit out of them, but I think it also leads to people waiting for the next standup to communicate instead of fostering a culture of communicating more pro-actively. In your example: why wait for a standup? Why not just drop a message in slack saying "working on Y and not sure how to proceed; any ideas?" Personally, I don't see the need for standups as long as the team is open about sharing blockers as they come up instead of waiting for the next standup cycle.
warrenm 6y ago
That's exactly how Opsware Support worked when I was there: https://antipaucity.com/2011/09/15/the-ticket-smash-raw-metrics-and-communication-how-to-have-a-successful-support-organization/#.YBgNPuBOmc4 https://antipaucity.com/2011/09/15/the-ticket-smash-raw-metr...

H8crilA 6y ago

It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.

austincheney 6y ago
There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.
- Twisell 6y ago
  You are totally right but probably assuming you have a top notch and easily discoverable documentation that can guarantee that newbies won't spend 15 days reimplementing "that bash script you need once a year or so" that do the job in 2 minutes. However even if this case you might get lucky and end up with a new script that do the job in 30 seconds and everybody in the team have learn that documentation is very important.
  - H8crilA 6y ago
    It's a matter of balance. No simple rule of thumb exists. Sometimes it results in a much better solution, great! Sometimes it's a new wheel but with more awkward square-ish corners. Sometimes (and this is the worst because it's hard to explain) it is actually better but still likely has been a waste of the engineer's time - high cost vs low benefit, also often cooccurs with lack of team's capacity to maintain the new thing.
- joatmon-snoo 6y ago
  Re-inventing the wheel can be useful for learning, but can have very real costs, often in the form of production outages. * "You can usually use user metadata field X for billing" - except for those users for whom field X actually maps to something else, for tech debt reasons. (Is it stupid and bad? Yes. Is anyone going to be able to fix it this year? No. Is this going to result in Very Big Customer TM getting mad? You Betcha.) * "Oh, I'll just roll my own fake of Foo" - congratulations, now anyone looking for a fake needs too decide between yours and the other one. (Yes, this is highly context dependent, but the moment you have multiple fakes in common/util libraries this usually starts being a problem.) * "I can just use raw DB writes for this, because I don't want to learn how to use this API" - except the abstraction exists because it guarantees you can do safe incremental, gradual pushes and roll back the change, whereas your home-rolled implementation had a small bug and now the oncaller needs to do manual, error-prone surgery on the backup instead of the usual undo button built into the API. (Oh, and legal is going to have a field day because there's no audit record of the raw writes' content.) Cargo-culting is bad, yes, but reusing existing abstractions is often important because they handle (or force you to handle) the various edge cases that someone learned about the hard way. And of course, if you find a bug in the existing abstraction, well, congratulations- you just found a repro and root cause for that infamous support case that's been giving everyone data integrity nightmares for months.
  - austincheney 6y ago
    > often in the form of production outages Completely unrelated. If you have production outages resulting from new code you have serious gaps in your certification process, especially so if the new code covers existing process/requirements. You are probably insecurely reliant upon dependencies to fill gaps you haven’t bothered to investigate, which is extremely fragile. The benefit of code reuse is simplification. If a new problem emerges with requirements that exceed to current simple solution you have three choices: 1. Refactor the current solution, which introduces risk. 2. Roll an alternative for this edge cases and refactor after. This increases expenses but is safer and keeps tech debt low. 3. Roll an alternative for this edge case and never refactor. This is safe in the short term and the cheapest option. It is also the worst and most commonly applied option.
mark-r 6y ago
We decided early on that a daily scrum was just too frequent to be effective for our team, so went to 2x per week. When we started working from home, we added a "keep in touch" meeting for the other 3 days of the week just to stay connected.
- mixologic 6y ago
  Our standups (for a team of four) are about 15 minutes. Then we just leave the zoom on and co-work together out loud for an hour or two. It's pretty priceless the stuff that comes up during that time.
  - lydon 6y ago
    Always thought this will be useful, but never had a chance to experience it. What kind of stuffs come up?
- GordonS 6y ago
  Yep, not being dogmatic about standups having to be daily, or indeed about any process, is invariably a win - do what works for the team! I'm working in a small team just now, just 5 of us, and a short, daily standup is working well for us - and it's usually finished in 7 minutes or so. In my last project (where I wasn't leading the standups), the teams were bigger, 10 people in each, and they went.on.forever. Neither the scrum master or PM were strict at curtailing them or keeping them relevant. Everyone hated it.
avereveard 6y ago
I'm glad I've reinvented the wheel that many time as a junior, it let me learn why some framework and some solutions are the way they are, and made it extremely easy to pick up third party solutions later on
- throwaway2245 6y ago
  We'll never know the counterfactual, but in my opinion: You could have learned the same thing more efficiently, with more support for why you didn't need to reinvent the wheel.
  - paledot 6y ago
    I've been a professional software developer for ten years, and I'm on a hiatus right now. One thing I've been doing with my time is reinvent a bunch of wheels, implementing broken clones of this library or that algorithm, and I've gained a tremendous amount of understanding of what's going on behind the scenes of tools I'd been using for years. So yeah, it's a valuable learning tool to build with your own hands. Also, a valuable guide when deciding whether to write code yourself or introduce yet another library to your dependencies.
    - datavirtue 6y ago
      Before getting sucked into the enterprise world, I reinvented a bunch of wheels and this indeed gave me a deeper understanding of the inner workings of various frameworks and technologies. I noticed that my colleagues who had ten years or more on their resume rarely had any idea what I was rambling on about or the basis for the things they were using. Their were so busy trying to get stuff done that they never had time to explore. I don't mean blog post or tutorial explore, I mean weeks and weeks of implementation and testing of patterns and low level engineering. Building database engines from scratch or writing a compiler or a distributed message broker, for instance.

jimbob45 6y ago

Agreed. It’s a deliberate inefficiency to make sure you at least have a chance to communicate with your team on a regular basis. Otherwise you might go days or weeks without the chance to have a critical two minute conversation.

crdrost 6y ago
That sounds suspiciously like your team is not communicating enough in the first place though. I mean, I guess the profession does get its fair share of introverts, but I would have expected enough teamwork that everyone knows what everyone else is doing, at least roughly. At my last gig I remember we had three backenders and four frontenders on a game we were building and the stand-ups seemed superfluous, Ryan on the frontend knew all of the frontend tasks and their exact states, I on the backend knew all of the backend tasks and all of their states, stand-ups were more of a means to celebrate what folks had done and coordinate that info with our QA team. My silver rule of meetings is “to make a meeting matter, make a decision.” If we were assigning new tickets and/or backlog, deciding who would own each of them, that meeting is valuable. Progress updates can be delivered asynchronously and consumed asynchronously, unless, say, one wants group applause. Of course now covid exists and I changed jobs to a team that barely talks with me and daily stand-ups are kind of my only social contact with them, so that's less fun. But yeah, 100% the original vision of agile with the “developers should be meeting daily with the product users to clarify the underlying model and mold the software to their hands” should cause people to work together so much that stand-ups become something of an afterthought.
- closeparen 6y ago
  It sounds like you and your team are working on the same artifact and that your tasks are interrelated. That’s kind of a special case. At any given time our 3 engineers have maintenance tasks in flight on 4 or 5 distinct products.
  - tikhonj 6y ago
    If people are working on completely unrelated things, what do you get from a stand-up other than a group status update?

axaxs 6y ago

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

eyelidlessness 6y ago
Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They shouldn't be too hard to trigger, or you're never going to get one (or results from one). The best process for this is "shit goes down and you should make appropriate dedicated space for it". Edit to add: I want to emphatically contradict my metaphor in one way, which is that retros should be exactly the opposite of a recall election in terms of identifying/naming/assigning fault. They should be about identifying good/bad outcomes and good/bad patterns, but not about pointing fingers at or casting aspersions on people.
- pseudalopex 6y ago
  It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.
  - axaxs 6y ago
    Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.
    - arbalist 6y ago

temporallobe 6y ago

Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their work. The best kind of standups are those where you can feel free to discuss your blockers and simply state what you’re doing so the team has a general awareness if what’s going on and how/if it impacts them.

deleted 6y ago
[deleted]
crescentfresh 6y ago
> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.
- projectileboy 6y ago
  In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.
  - dragontamer 6y ago
    > In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors. As someone who did sales early in my career... acting off of a script correctly feels like a casual conversation to the one you're selling to. If your script-reading is bad, that's because you haven't practiced enough. Having a script isn't necessarily a bad thing, and is in fact very useful in keeping focus.
    - emteycz 6y ago

systemvoltage 6y ago

Let’s be honest, stand ups are there so we can get together as a team. Otherwise, engineers would be heads down working on their own things. Benefits of “Oh I yea I’ve worked on the same thing before” are usually realized outside of stand ups in over the shoulder chats or slack. Stands ups are a waste of time. There, I said it. But, I like them, especially if you have a fun team.

Clubber 6y ago
For our team, we just do a weekly biz/dev meeting, then break into a pure dev meeting every Tuesday morning. The process takes about 30min - 60min a week and we can go into depth when needed. Plan the week and go do what we do. It works great for our small 5 man team. Daily meetings seem excessive to me, even if they only last 5 minutes.
ffhhj 6y ago
Agreed! Stand ups are a teather play to make the client believe a project is moving forward, while team members use their own private channels to talk about the real work.

tikhonj 6y ago

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up. If something is important, why would you wait for tomorrow's standup? If something isn't important, why are you dedicating an inflexible daily meeting to talking about it? If your team is having the sort of communication problems standups are supposed to solve, it's a symptom of a deeper issue and standups are a bandaid solution. If your team already works collaboratively, standups are pure overhead at best and actively counterproductive at worst. It's easy to get into the bad habit of waiting for a standup to bring up important issues, which loses time and context. Worse yet, chances are the standup has too many people and not enough time to discuss anything in detail—I've seen so many standups where any actually useful conversation would be caught, stopped and moved to a different venue. You end up with a pro forma meeting where most of the information isn't useful to most of the attendees, but still breaks up people's schedules and focus. In my experience, an emphasis on standups goes hand-in-hand with a view of engineering work as a ticket factory: individuals get a ticket off the queue, work just on that, get it done as soon as possible and pick up another ticket. I think that correlation is not a coincidence.

ncann 6y ago
While you have a point, it's not that rare for someone to be blocked on a hard issue for a day or two, even having talked to someone, then bring that up at the stand-up. The one you talk to may not always have the solution, and it may be someone else in the team at large.
- pseudalopex 6y ago
  Email works great for that.
Chris_Newton 6y ago
That seems like a reasonable concern to me, and something that could apply to almost any communications that are on a regular schedule, whether it’s a daily team meeting or an annual review with your boss. My father said something to me when I was nervous before my first annual review in my first job, and it has stuck with me ever since: nothing anyone says in that review should ever be a surprise. Whether it’s good or bad, if your management are doing their job, everyone who needs to know about it should have known when it became relevant, not on the anniversary of your employment. I suspect there is more value in some types of regular but short technical meeting at the moment, when many colleagues aren’t in close proximity at work and ad-hoc informal discussions are less likely to serve the same purpose. But as someone who’s primarily worked from home for years, I’d usually still prefer to arrange a group call or physical meeting with whoever actually needs to be there when there’s something specific to discuss, rather than assuming in advance that any particular tempo will be the right one.

Shorel 6y ago

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.

zbobet2012 6y ago
I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).
- kettro 6y ago
  To this end, I have a small, paper-sized whiteboard that I can scrawl onto on hands at all times. I bought a couple packs of the ultra-fine expo markers, and it’s been a boon. Great for quickly noting things down that don’t need to last. Having both is important, though: you need to be able to preserve the things that matter, that you may need later on.
  - mark-r 6y ago
    That's why phones have cameras.
  - Shorel 6y ago
    You can use the rocketbook app. No need to buy the notebook. https://getrocketbook.com/ https://getrocketbook.com/
- Shorel 6y ago
  And I find a whiteboard a bit more intimidating. It kind of implies performing your writings in public. A notebook is a very personal thing. =)
  - tribaal 6y ago
    I recently switched from a very whiteboard/paper heavy workflow to using a reMarkable tablet. Holy shit this thing is good. It's like an infinite notepad/whiteboard that auto syncs to the cloud, lets you define page layout templates, and renders PDFs and ebooks. I've had it for just a few weeks and it's already the favorite pice of tech I own.

rektide 6y ago

> Standups are useful for communication between a team in general, if kept brief. Just once I'd like to work for a company that tries to stay in communication without so many explicit/manual/sync check-in gates. * No stand-up, engineers required to write a 250-words or less blog post 2+ times a week. * No announcing PRs, reviews &c to each other. Make watching the board a habit, one you "pull" rather than that is pushed to you. Or use a company provided chat-bot/tool to help surface changes as they happen, if you need that. The issue tracker should better dashboard whatever activity is happening, in general- indicate branch updates, pr changes, &c, clearly, across the board. There's some value to using social processes to radiate all the changes happening, but I'd really like to see some camp out there that makes a go at mechanizing themselves. I think there are a lot of interesting possibilities, more enduring & valuable forms of communication that we have failed to even begin to explore.

jbay808 6y ago
A place I used to work had engineers documenting their work essentially in the form of a blog. It was actually really a useful habit, and reviewing the project blogs once each week made it really easy for me to find cases when I could help a colleague who was working on something I'd had experience with before.
- anaerobicover 6y ago
  I'd venture that the parent was talking about engineers "documenting" their work for managers, whereas I think you mean documentation for other engineers. Very different audiences and thus different things to say. (And widely different lifespans for the information.) The latter no doubt is hugely useful (I'm on a long slow effort myself to get my co-workers to document their work more robustly). But writing status reports for managers/PMs on a weekly basis is, in my not so humble opinion, a complete waste of time for the company, and a sign of poor organization.
  - rektide 6y ago
    I was hoping both purposes would be served, at this mandatory level. I would adore any engineer who writes more blog posts walking through what they're up to more technically. How do you feel about every-day stand ups as a means for managers/PMs to check in on employees? My own impression has been that this is at least 50%+ of the reason for stand up, and to me, I'd far prefer periodic write-ins, rather than ephemeral, undetailed, synchronous communication.

christkv 6y ago

We always run standups in the same way. What did I work on yesterday, what am I working on today and finally impediments or help required as well as general organizational stuff that might impact the team.

Falkon1313 6y ago
So do we, but generally a quick glance at the kanban board would show that for everyone. Well, it would if we had one unified board. Instead we have stuff scattered across multiple boards. Still it would only take 1-2 minutes to open them all up and glance through them. Information radiators. They work well. Instead we have a 30-60 minute standup/sitdown/try-not-to-doze-off meeting to achieve the same thing. We used to also have additional meetings to review the boards but eventually cut those because people got tired of me saying "the status is still the same as I said an hour ago, because I've been in this meeting since then." The exception is stuff like team announcements, reminders that someone's going to be out, requests for someone to volunteer to take a task. That can all be done async though.

diob 6y ago

Standups aren't always necessary, but you'd need a high functioning (read communicative) team. In other words, they serve primarily as a forcing function to make sure teams are acting like teams (communicating). I find the most useful standups are asynchronous though. It's much easier for others to follow along (and ask follow up questions), and avoids statuses devoid of usefulness (or at least makes them very apparent).

js8 6y ago

> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so that everybody knows about him being an expert and consults with him on a regular basis. Is it really better to have everybody a shallow experience with everything rather than have a few individuals with a deep expertise with a particular thing? And to have a meeting every day to "solve" this non-problem (somebody not knowing who the expert is, or supposed to be) seems really inefficient.

Scea91 6y ago
Reason why I don’t want my team to overspecialize: I don’t want them to isolate and develop tunnel-vision. I want everyone to be aware of the project goals and understand the work that needs to be done to deliver value. My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected.
- js8 6y ago
  > My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected. I doubt it isn't the case either way. If you neglect understanding and development of expertise, you will still end up with some people having more expertise than others, and possible blind spots. Except now you have no idea what those blind spots are. (https://news.ycombinator.com/item?id=10970937 https://news.ycombinator.com/item?id=10970937)
Jestar342 6y ago
That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck. Natural siloing happens, but you (team) should be striving to reduce it, not encourage it. *More accurately: work can only proceed on that something when X is available*

skohan 6y ago

I agree the list is very good list in general. My point of disagreement is: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions. The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"? After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.

otijhuis 6y ago
I consider software architecture to be extremely important and based on the other opinions of the author he probably agrees with you that it should be "just-in-time", as do I. Useless abstractions just get in the way and make things complex and hard to understand. Yes, if a program doesn't function the way it's supposed to, it's useless. Unfortunately I've seen many developers take shortcuts and not even think about the software architecture (because "hey, it works doesn't it"). Good software architecture not only makes it much easier to build functioning software, it also makes the team function much better. The ability to maintain the software and quickly add new features depends on it. Even little things you do can contribute to a good software architecture. Overengineering leads to a terrible mess, so does the "hey it works, I don't care about anyone who has to maintain it" mentality. Ideally you'd be somewhere in the middle. You shouldn't design everything up front and you shouldn't ignore things that are right around the corner either.

jrib 6y ago

> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I personally hate stand-ups. We do get benefit out of them, but I think it also leads to people waiting for the next standup to communicate instead of fostering a culture of communicating more pro-actively. In your example: why wait for a standup? Why not just drop a message in slack saying "working on Y and not sure how to proceed; any ideas?" Personally, I don't see the need for standups as long as the team is open about sharing blockers as they come up instead of waiting for the next standup cycle.

warrenm 6y ago

That's exactly how Opsware Support worked when I was there: https://antipaucity.com/2011/09/15/the-ticket-smash-raw-metrics-and-communication-how-to-have-a-successful-support-organization/#.YBgNPuBOmc4 https://antipaucity.com/2011/09/15/the-ticket-smash-raw-metr...