4 ms·

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

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.

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.