5 ms·

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC projec

I've been working with one junior and one not so junior programmer on a hobby project recently, and they are both "Right Way Guys". For a roughly 300 LOC project with a discord bot and some rust code that only we will be running for now, they insisted on complete documentation, separate VMs for QA and "prod", systemd deployments, a templating system for a few strings, an ORM layer for four (4) SQL queries.. this is a project that maybe 10 people would use. These are only half the requirements for the "0.3" release with much more over engineering planned for the future. I have stopped working on that project :) It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.

Verdex 3y ago
In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they could try to fix the existing router. The suggestions are all half spoken before being answered: "Did you try the ..." : "yes"; "well , how about resetting the ..." : "I tried that too". Clearly they're basically reading each other's minds because of how well they know each other and how much time they spend with each other. But then comes the 'punchline'. One character says 'yes' to buying the new router. The other response with "I need an 'aye'". Their side business apparently has very strict rules about what words they need to use for voting on decisions. It doesn't matter that they all know each other so well that they're finishing each other's sentences. It doesn't matter that this is a $50 router. And it doesn't matter that their income from this side business is inconsequential. The rules say that they need an 'aye'. My own theory with "Right Way Guys" is that some people have been able to find a lot of success by leveraging the knowledge that's stored in the hivemind of society. They don't really know what they're doing when you consider what's going on inside their skull. But they have successfully copied success up till now. The plus side is that they're able to inherit successful methodologies that have survived over time without having to do all the hard work themselves. The down side is that they literally don't understand when they're in a scenario where it will lead to failure. [2] [1] - I didn't think much of this until I watched the director commentary. Where they explicitly talk about how they intentionally setup this interaction to showcase how certain characters took the rules too seriously and which ones didn't take them seriously enough. [2] - My theory on my theory is that this is also why so many people encourage others to join in their favored cargo cult practice (be it software development or anything else). Social behaviors may or may not work, but the more people you can convince to follow them the greater the chance that when they fail catastrophically and/or fatally they're failing for someone who isn't you.
- hinkley 3y ago
  I over-analyze everything and if I actually explained all the reasons the screwdriver should be put away, you would be bored, possibly to death. If you persist in arguing you might hear half of it. And yet my toolbox is still full of things I do because someone I respect did them, or someone I disrespect didn’t, and the outcomes were dramatic. I know the expected outcomes, I have half an idea how they actually work, I just know it’s a magic spell that gets me into or out of problems. We don’t know why asking dad for ice cream works more often than mom, but empirically it does. There are areas dictated by human factors like errors, or overconfidence. There are areas I will sweat blood to do a mindful task to avoid a mindless one, and vice versa. And there are things I do because it improves outcomes with neurodivergent people, and sometimes neurotypical ones. There’s a concept in chronic illness circles called spoons. It is a metaphor that acknowledges that it’s not time that’s the constrained resource, it’s energy. A wake up call that software desperately needs. When you have used all your physical or emotional energy you are “out of spoons” for the day. You can’t do anything but veg. This is slowly being replaced in psychology circles with metaphors that are more like deck building card games, because they speak also to many other groups of non-extroverts. If you aren’t prepared for a task like calling tech support or dealing with a toxic relative, being forced to do it now burns all the other tasks you might have done cheaply today. These people want to know they have a dentist appointment or a date in two days because they need to psych themselves up. Spend energy today and tomorrow making sure they have that card available. And if there’s a cancellation, they are out all that energy and have to spend it again. There’s a lot of this in our work too. The old joke aphorism about, “why spend a day doing something you can spend a week automating?” falls under this umbrella.
  - jiggawatts 3y ago
    I call this effect “sand in the gears”. Some things are low friction and effortless, others less so. Too much friction and the “machine” seizes. Psychological aspects are a big part of this. My pet peeve is overzealous security trolls making IT staff use four layers of VPNs and remote access solutions with multiple glacially slow MFA authentication prompts. I watched one guy typing into a console with a two second lag on each key press. That’s the round trip time to the Moon and back! I felt bad every time I had to ask him to do something for me, because his shoulders would slump and he’d have this depressed look on his face as he forced himself to jump through the hoops… again.
gosub100 3y ago
Remember juniors have it tough in the employment market, so some of this could be due to RDD, so they can tack on SQL, ORM, managed vm infrastructure, on their resumes.
jorisd 3y ago
I'd argue that they're not completely wrong in doing those things. Many of those things you list really don't take too much time to do, like writing systemd units or using an ORM. But they really help when anyone needs to take a look at things in the future or someone else wants to contribute as well later on. Besides, they're easier to do when things are still fresh in the mind, and these kinds of chores rarely get done later on when a project has grown. This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way!
- Rayhem 3y ago
  > This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way! Exactly my thought. Hobby projects are great opportunities to practice those skills since, if you don't, they don't manifest.
motoxpro 3y ago
I had to realize that for people like this the "Right Way" is the hobby, not the Discord bot.
- bsdpufferfish 3y ago
  This is exactly it. It's fun to try out the new tools and how "effortless" they make it. It's a kind of tinkering.
yodsanklai 3y ago
> I was myself a "Right Way Guy" at the beginning of my programming for a few years Maybe it's a case of known the rules so you can break them.
akshatpradhan 3y ago
The situation you described doesn’t sound like “Right Way Guys”. It actually sounds like “Bikeshedding” [1]. This means giving a disproportionate amount of attention or importance to the trivial details while neglecting or giving less attention to the significant issues. Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bike shed that they want built nearby. In your case, their focus on separate VMs for QA/Production, systemd deployments, templating system for a few strings, and an ORM for a few SQL queries, especially for a project with a limited user base (10 people) really exemplifies Bike-shedding. They’re emphasizing minor, arguably unnecessary details rather than the core functionality or purpose of the project [2]. This usually occurs because these trivial aspects are easier to understand and discuss, especially for junior devs, which leads to increased involvement on minor details while the more meaningful parts of a project (which might be more challenging to address), are overlooked or given less attention. IMO, a good leader knows how to strike a balance between the “Right Way” and avoiding the pitfalls of “Bike-shedding”. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality [2] I would argue complete documentation of the meaningful parts of the project is not bike-shedding.
- randomdata 3y ago
  It sounds more like a case of "Use the tools you know". Like, the stated ORM toolkit may be complete overkill, but if they don't have experience doing object relational mapping by hand that's one more thing to learn to get the job done. The asserted goal is to deliver something for a group of people to use, so it's not a hobby of trying to find as many new lessons to learn as possible.
- howenterprisey 3y ago
  Bikeshedding is the act of debating trivial details. They're just overcomplicating something that should be simple, but it doesn't seem like there was much of a debate about it at the time, so it's not bikeshedding.
- mcmoor 3y ago
  I see it funny when this behavior is assigned as one of symptoms of quite quitting, and Allies advice to rebellious German workers in WW2.
hardwaregeek 3y ago
What's tricky is that in a different context, those people would be excellent contributors. Like in a mature product, who wouldn't love a developer who works on documentation, builds out a staging environment, and makes the codebase more scalable? But it just doesn't make sense when you haven't shipped anything yet.
- staunton 3y ago
  What's even more tricky is that almost all (successful) projects start out small and it takes immense discipline and foresight to catch up on "maturity" at the right stage in the project. Chances are, you'll get bogged down with these "maturity" things from the start and never build anything successful, or you'll go fast (perhaps catching a glimpse of success) until nobody can keep working on the project once those "maturity" things start to matter.
- arp242 3y ago
  I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature products, which almost always have some history behind them: shifting requirements, "seemed like a good idea at the time, but with the experience we have now it probably wasn't", shifting trends in the industry, constraints in terms of dev time or budget, etc. Often this is sub-optimal, but it works well enough, so it's fine. And never mind that opinions on "the right way" differ. Previous poster mentioned ORM: some people think "the right way" is to never use an ORM, some think "the right way" is to always use it. Right Way Guys will insist that your codebase will always needs to be scalable, whether it makes sense or not. You've got a B2B product that will only have a few hundred customers? Doesn't matter. It needs to be scalable. It's the Right Way. Right Way Guys will insist that this kind of ugly module that hardly sees any changes and is basically bug-free will need to be rewritten to The Right Way once they add a minor trivial feature. It doesn't mater it works fine. It's The Right Way. Right Way Guys make things worse. Always. In the case of juniors: they can be taught. They're just juniors. That's okay. In the case of seniors: good luck... I'd argue these are among the worst people you can hire. And you really don't need to be a Right Way Guy to write a few docs or set up a staging environment.
deleted 3y ago
[deleted]
Buttons840 3y ago
I initially was expecting you to make excuses like "yeah, our code has undefined behavior, but it works, and only 10 people will use it". This is how I've seen the "but it works, just get shit done" attitude employed among my programming peers. People use "but it works" to excuse things don't don't actually work. In the end, I think you're right though. As long as the code is reliable, then the shortest code is the best code (within reason, don't start playing code golf). It takes an awfully good abstraction to beat simply having less code.
- potatopatch 3y ago
  I kind of assume the opposite problem. If you start with code and then add testing and documentation you may never committed to leave broken things to maintain otherwise inconsistent alternative sources of truth. If you try to maintain these things from the start you probably have a lot of errors that no one is authorized/competent to fix without leaving behind references to incorrect truths, even if it is only in a less frequent contributor's mind.
tdeck 3y ago
When you're a junior engineer overdoing it like this on a small project can be a good way to practice new skills and see how they apply through a project's whole lifecycle.
saiya-jin 3y ago
Ha, reading first part I got incorrect feeling you are actually proud of that approach, I thought 'geez not again this'. Luckily I read till the end :) I see it all the time, well most of the time these days. I call those folks smart juniors, and it literally doesn't matter if they have 1 or 20 years of experience. Smart juniors know most if not all design patterns, read Mythical man month, and so on, and... is super eager to try new technologies, languages, frameworks and is literally running around with shiny new hammers desperately looking for anything resembling nails. And then they do some stupid decisions because they don't grok the power an optimized boring old DB can bring in. Then comes a guy like me with 20 years of experience who has seen damn well how such projects end up 5-10 years down the line with half if not most of the original team gone, and cuts half of that crap out while keeping genuine added value, because we are not running kindergarten for devs who want to have fun at all costs all the time, we work for our business who pays us and expects good, stable and relatively quick deliveries, rest are details on our side. You can't be taken seriously by business if you behave like that, no matter how good your intentions are. IMHE bleeding edge stuff and trying new things for the sake or avoiding boredom will consistently break more down the road than it will help fixing. We incorporate technologies which whole team can grok and be proficient in, not just some bored superstar. Build your CV elsewhere if you desperately want as many technology entries as possible, there are companies like that, and good for them. IMHO these folks anyway don't stay around for too long so full added value is even questionable, the grass is always greener elsewhere, at least till they get there. Could be boring for some, I call it seasoned (yet still endless amount of stuff to learn, but that's fine this won't change till my retirement).
Arainach 3y ago
Building things the right way is a chance for people to learn tools and have fun. They're more impressive if your goal with a side project is for companies to look at your GitHub page. Documentation is crucial. I have some fairly basic <300LOC projects including a bot and a web scraper that I currently cannot run because I didn't document them. The Raspberry Pi they were running on died and I need to do....something....to fix my headless virtual framebuffer and debug some cryptic errors that do not find productive search results. If I had containerized or, at a minimum, documented my setup steps, I would not have this problem.
taneq 3y ago
Are you sure that all this infrastructure is not, to them, the actual point of the project? Sometimes it’s fun to go way overboard on engineering for its own sake. I saw one guy who’d built an entire PLC-based control cabinet to automate a cat door. Necessary? No but that’s beside the point. :D
devwastaken 3y ago
The reason they're doing that is because theyre going to be tested on that knowledge when finding employment. It's harder than ever to be full stack, but there's plenty of competition.
deleted 3y ago
[deleted]
rewmie 3y ago
[dead]

Verdex 3y ago

In the movie Primer, a group of four friends start a small computer business on the side. Two of them later invent a sci-fi box and then dramatic shenanigans ensue. Something I missed at first [1] was the significance of an event that happens early in the movie. They need to buy a $50 router because their existing one is broken. They have an impromptu meeting where one of the characters gives suggestions on how they could try to fix the existing router. The suggestions are all half spoken before being answered: "Did you try the ..." : "yes"; "well , how about resetting the ..." : "I tried that too". Clearly they're basically reading each other's minds because of how well they know each other and how much time they spend with each other. But then comes the 'punchline'. One character says 'yes' to buying the new router. The other response with "I need an 'aye'". Their side business apparently has very strict rules about what words they need to use for voting on decisions. It doesn't matter that they all know each other so well that they're finishing each other's sentences. It doesn't matter that this is a $50 router. And it doesn't matter that their income from this side business is inconsequential. The rules say that they need an 'aye'. My own theory with "Right Way Guys" is that some people have been able to find a lot of success by leveraging the knowledge that's stored in the hivemind of society. They don't really know what they're doing when you consider what's going on inside their skull. But they have successfully copied success up till now. The plus side is that they're able to inherit successful methodologies that have survived over time without having to do all the hard work themselves. The down side is that they literally don't understand when they're in a scenario where it will lead to failure. [2] [1] - I didn't think much of this until I watched the director commentary. Where they explicitly talk about how they intentionally setup this interaction to showcase how certain characters took the rules too seriously and which ones didn't take them seriously enough. [2] - My theory on my theory is that this is also why so many people encourage others to join in their favored cargo cult practice (be it software development or anything else). Social behaviors may or may not work, but the more people you can convince to follow them the greater the chance that when they fail catastrophically and/or fatally they're failing for someone who isn't you.

hinkley 3y ago
I over-analyze everything and if I actually explained all the reasons the screwdriver should be put away, you would be bored, possibly to death. If you persist in arguing you might hear half of it. And yet my toolbox is still full of things I do because someone I respect did them, or someone I disrespect didn’t, and the outcomes were dramatic. I know the expected outcomes, I have half an idea how they actually work, I just know it’s a magic spell that gets me into or out of problems. We don’t know why asking dad for ice cream works more often than mom, but empirically it does. There are areas dictated by human factors like errors, or overconfidence. There are areas I will sweat blood to do a mindful task to avoid a mindless one, and vice versa. And there are things I do because it improves outcomes with neurodivergent people, and sometimes neurotypical ones. There’s a concept in chronic illness circles called spoons. It is a metaphor that acknowledges that it’s not time that’s the constrained resource, it’s energy. A wake up call that software desperately needs. When you have used all your physical or emotional energy you are “out of spoons” for the day. You can’t do anything but veg. This is slowly being replaced in psychology circles with metaphors that are more like deck building card games, because they speak also to many other groups of non-extroverts. If you aren’t prepared for a task like calling tech support or dealing with a toxic relative, being forced to do it now burns all the other tasks you might have done cheaply today. These people want to know they have a dentist appointment or a date in two days because they need to psych themselves up. Spend energy today and tomorrow making sure they have that card available. And if there’s a cancellation, they are out all that energy and have to spend it again. There’s a lot of this in our work too. The old joke aphorism about, “why spend a day doing something you can spend a week automating?” falls under this umbrella.
- jiggawatts 3y ago
  I call this effect “sand in the gears”. Some things are low friction and effortless, others less so. Too much friction and the “machine” seizes. Psychological aspects are a big part of this. My pet peeve is overzealous security trolls making IT staff use four layers of VPNs and remote access solutions with multiple glacially slow MFA authentication prompts. I watched one guy typing into a console with a two second lag on each key press. That’s the round trip time to the Moon and back! I felt bad every time I had to ask him to do something for me, because his shoulders would slump and he’d have this depressed look on his face as he forced himself to jump through the hoops… again.

gosub100 3y ago

Remember juniors have it tough in the employment market, so some of this could be due to RDD, so they can tack on SQL, ORM, managed vm infrastructure, on their resumes.

jorisd 3y ago

I'd argue that they're not completely wrong in doing those things. Many of those things you list really don't take too much time to do, like writing systemd units or using an ORM. But they really help when anyone needs to take a look at things in the future or someone else wants to contribute as well later on. Besides, they're easier to do when things are still fresh in the mind, and these kinds of chores rarely get done later on when a project has grown. This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way!

Rayhem 3y ago
> This being a hobby project may also be a reason why the other programmers want to do things right; they may get satisfaction and learn new things by doing it this way! Exactly my thought. Hobby projects are great opportunities to practice those skills since, if you don't, they don't manifest.

motoxpro 3y ago

I had to realize that for people like this the "Right Way" is the hobby, not the Discord bot.

bsdpufferfish 3y ago
This is exactly it. It's fun to try out the new tools and how "effortless" they make it. It's a kind of tinkering.

yodsanklai 3y ago

> I was myself a "Right Way Guy" at the beginning of my programming for a few years Maybe it's a case of known the rules so you can break them.

akshatpradhan 3y ago

The situation you described doesn’t sound like “Right Way Guys”. It actually sounds like “Bikeshedding” [1]. This means giving a disproportionate amount of attention or importance to the trivial details while neglecting or giving less attention to the significant issues. Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bike shed that they want built nearby. In your case, their focus on separate VMs for QA/Production, systemd deployments, templating system for a few strings, and an ORM for a few SQL queries, especially for a project with a limited user base (10 people) really exemplifies Bike-shedding. They’re emphasizing minor, arguably unnecessary details rather than the core functionality or purpose of the project [2]. This usually occurs because these trivial aspects are easier to understand and discuss, especially for junior devs, which leads to increased involvement on minor details while the more meaningful parts of a project (which might be more challenging to address), are overlooked or given less attention. IMO, a good leader knows how to strike a balance between the “Right Way” and avoiding the pitfalls of “Bike-shedding”. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality [2] I would argue complete documentation of the meaningful parts of the project is not bike-shedding.

randomdata 3y ago
It sounds more like a case of "Use the tools you know". Like, the stated ORM toolkit may be complete overkill, but if they don't have experience doing object relational mapping by hand that's one more thing to learn to get the job done. The asserted goal is to deliver something for a group of people to use, so it's not a hobby of trying to find as many new lessons to learn as possible.
howenterprisey 3y ago
Bikeshedding is the act of debating trivial details. They're just overcomplicating something that should be simple, but it doesn't seem like there was much of a debate about it at the time, so it's not bikeshedding.
mcmoor 3y ago
I see it funny when this behavior is assigned as one of symptoms of quite quitting, and Allies advice to rebellious German workers in WW2.

hardwaregeek 3y ago

What's tricky is that in a different context, those people would be excellent contributors. Like in a mature product, who wouldn't love a developer who works on documentation, builds out a staging environment, and makes the codebase more scalable? But it just doesn't make sense when you haven't shipped anything yet.

staunton 3y ago
What's even more tricky is that almost all (successful) projects start out small and it takes immense discipline and foresight to catch up on "maturity" at the right stage in the project. Chances are, you'll get bogged down with these "maturity" things from the start and never build anything successful, or you'll go fast (perhaps catching a glimpse of success) until nobody can keep working on the project once those "maturity" things start to matter.
arp242 3y ago
I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature products, which almost always have some history behind them: shifting requirements, "seemed like a good idea at the time, but with the experience we have now it probably wasn't", shifting trends in the industry, constraints in terms of dev time or budget, etc. Often this is sub-optimal, but it works well enough, so it's fine. And never mind that opinions on "the right way" differ. Previous poster mentioned ORM: some people think "the right way" is to never use an ORM, some think "the right way" is to always use it. Right Way Guys will insist that your codebase will always needs to be scalable, whether it makes sense or not. You've got a B2B product that will only have a few hundred customers? Doesn't matter. It needs to be scalable. It's the Right Way. Right Way Guys will insist that this kind of ugly module that hardly sees any changes and is basically bug-free will need to be rewritten to The Right Way once they add a minor trivial feature. It doesn't mater it works fine. It's The Right Way. Right Way Guys make things worse. Always. In the case of juniors: they can be taught. They're just juniors. That's okay. In the case of seniors: good luck... I'd argue these are among the worst people you can hire. And you really don't need to be a Right Way Guy to write a few docs or set up a staging environment.

deleted 3y ago

[deleted]

Buttons840 3y ago

I initially was expecting you to make excuses like "yeah, our code has undefined behavior, but it works, and only 10 people will use it". This is how I've seen the "but it works, just get shit done" attitude employed among my programming peers. People use "but it works" to excuse things don't don't actually work. In the end, I think you're right though. As long as the code is reliable, then the shortest code is the best code (within reason, don't start playing code golf). It takes an awfully good abstraction to beat simply having less code.

potatopatch 3y ago
I kind of assume the opposite problem. If you start with code and then add testing and documentation you may never committed to leave broken things to maintain otherwise inconsistent alternative sources of truth. If you try to maintain these things from the start you probably have a lot of errors that no one is authorized/competent to fix without leaving behind references to incorrect truths, even if it is only in a less frequent contributor's mind.

tdeck 3y ago

When you're a junior engineer overdoing it like this on a small project can be a good way to practice new skills and see how they apply through a project's whole lifecycle.

saiya-jin 3y ago

Ha, reading first part I got incorrect feeling you are actually proud of that approach, I thought 'geez not again this'. Luckily I read till the end :) I see it all the time, well most of the time these days. I call those folks smart juniors, and it literally doesn't matter if they have 1 or 20 years of experience. Smart juniors know most if not all design patterns, read Mythical man month, and so on, and... is super eager to try new technologies, languages, frameworks and is literally running around with shiny new hammers desperately looking for anything resembling nails. And then they do some stupid decisions because they don't grok the power an optimized boring old DB can bring in. Then comes a guy like me with 20 years of experience who has seen damn well how such projects end up 5-10 years down the line with half if not most of the original team gone, and cuts half of that crap out while keeping genuine added value, because we are not running kindergarten for devs who want to have fun at all costs all the time, we work for our business who pays us and expects good, stable and relatively quick deliveries, rest are details on our side. You can't be taken seriously by business if you behave like that, no matter how good your intentions are. IMHE bleeding edge stuff and trying new things for the sake or avoiding boredom will consistently break more down the road than it will help fixing. We incorporate technologies which whole team can grok and be proficient in, not just some bored superstar. Build your CV elsewhere if you desperately want as many technology entries as possible, there are companies like that, and good for them. IMHO these folks anyway don't stay around for too long so full added value is even questionable, the grass is always greener elsewhere, at least till they get there. Could be boring for some, I call it seasoned (yet still endless amount of stuff to learn, but that's fine this won't change till my retirement).

Arainach 3y ago

Building things the right way is a chance for people to learn tools and have fun. They're more impressive if your goal with a side project is for companies to look at your GitHub page. Documentation is crucial. I have some fairly basic <300LOC projects including a bot and a web scraper that I currently cannot run because I didn't document them. The Raspberry Pi they were running on died and I need to do....something....to fix my headless virtual framebuffer and debug some cryptic errors that do not find productive search results. If I had containerized or, at a minimum, documented my setup steps, I would not have this problem.

taneq 3y ago

Are you sure that all this infrastructure is not, to them, the actual point of the project? Sometimes it’s fun to go way overboard on engineering for its own sake. I saw one guy who’d built an entire PLC-based control cabinet to automate a cat door. Necessary? No but that’s beside the point. :D

devwastaken 3y ago

The reason they're doing that is because theyre going to be tested on that knowledge when finding employment. It's harder than ever to be full stack, but there's plenty of competition.

deleted 3y ago

[deleted]

rewmie 3y ago

[dead]