5 ms·

I'm a Magpie. And I've left two other teams where it was hard to persuade managers to learn shiny new stuff on the job. Couple of points OP missed: 1. To prov

I'm a Magpie. And I've left two other teams where it was hard to persuade managers to learn shiny new stuff on the job. Couple of points OP missed: 1. To prove that the new Rust service working fine, Magpie will stay extremely motivated, put 2x hours into it. You have to literally tear them off a keyboard. Now you got a devoted Owner, who is willing to take more responsibility of a project, isn't that wonderful? 2. Every rewrite serves as a good security review. Old unnecessary permissions will get abandoned, and only required accesses will be migrated. If Magpie is experienced and responsible, they will make it more secure than it was. 3. Every time I've seen a project rewritten (regardless of technologies) -- it became better. But only big companies can afford it. Magpie did it for you for free. 4. Motivation (aka pay less). If you see your team is bored, and updating their resume -- allow them to rewrite something on a tech stack they choose (and you can postpone promos till next year).

deleted 5y ago
[deleted]
InsomniacL 5y ago
1. 2x hours booked against a project with a cost code. 2. There is no security review if only one person knows that language. As well as that one person being new to that language. 3. mostly agree but as you state, not relevant to new technology decided upon by someone on a whim. 4. Do you really believe creating sections of the tech stack that only a single person is able to maintain will result in you not having to pay these staff as much? Those staff who you now have a critical dependency on and they know it?
- inetknght 5y ago
  To your point #4: Do you really think that developers shouldn't be paid what they're worth? Or that developers should hold down their worth so that you can pay them that much less?
  - Cthulhu_ 5y ago
    But migrating to a more niche technology where the existing one was fine is artificial inflation.
  - InsomniacL 5y ago
    I do think they should be paid what they're worth... and if they're the only person in the whole company that can fix the code they wrote in a language nobody else knows, then they're indispensable and can charge any salary they want. which is why they shouldn't be allowed to artificially make themselves indispensable without bringing any additional benefit to the business
nhinck 5y ago
Sure any rewrite has those benefits, but it's also become a huge liability with a truck factor of 1.
- deepsun 5y ago
  Rewrites don't have to be done by sole Magpies. I've seen a semi-large project been rewritten 4 times at G, by the whole team. When I came I literally couldn't propose a single thing to improve (there were only things that could be traded off for something else). It was very self-respecting to work on that project (though I didn't do any of those rewrites). And I respected managers there for giving resources for it to happen.
tartoran 5y ago
> 2x hours into it Yeah, that includes a lot of time learning. For that reason it is also exciting, because you’re having fun learning what you chose to and additionally fattens the resume.. that releases extra dopamine.
codingdave 5y ago
5. Nobody else on the team knows the tech, so you are committing everyone to that same learning curve in order not not have a huge bus factor for this product. I'm not at all opposed to learning new shiny tech on the job. But it has to be a team effort, not one developer just deciding to forge their own path. FWIW, I work with a team who has greatly modernized their skill sets together over the last few years. But they did so by choosing when to start with a new tech, and putting time in their sprints towards the learning efforts, training, tutorials, etc.
xxs 5y ago
>1. ...put 2x hours into it. isn't that wonderful? That's what horrors are made of. You absolutely do not wish your people overworked for any extended period of time. And if there is an drawback, hurdle down the road, instability, etc...
- Cthulhu_ 5y ago
  Yup; 2x hours is not sustainable and there will be burn-out down the line. Bus factor is the phrase to consider here.
- deepsun 5y ago
  No, overworking only comes if you're not motivated with what you're doing, forcing your brain to overwork. But if your brain is simply tired of doing motivating job, then it just reduces a level of motivation, until it gets enough rest. So it's a self-regulated system.
femiagbabiaka 5y ago
Every behavior here sounds great for you and terrible for your team and org. I’m noticing that you didn’t mention skill transfer back to the rest of your team during or after the project.
- deepsun 5y ago
  Thanks, that's a pretty good note. It let me think of how it works in my current team, where I enjoy being. Basically, we are all Magpies here, and the implicit agreement here is that every project is combination of code and experience (in form of utilized best practices, like writing README-s, leaving scripts for everything etc). Everyone wanting to dive into another project is expected to be somewhat experienced in software engineering to know the best practices without asking (e.g. read the README, read the scripts), and everyone is expected to just read the code, it's all there. After those two actions, there are little left for communicating, really. But I understand that probably doesn't work for most teams, as we accept only senior devs to our team. PS: Also, I just noticed we never re-written a project here so far, mostly because older Magpies can explain why it's ideal for how it is, without resorting to "it works, so don't touch it" and "for historical reasons". It's written well enough so that even if I started rewriting, I would end up with the same thing.
jmnicolas 5y ago
> Now you got a devoted Owner, who is willing to take more responsibility of a project, isn't that wonderful? Yeah and since the Magpie won't be around long (since it will soon find a new shiny job) someone will have to learn rust just to maintain this project.
- DeathArrow 5y ago
  >Yeah and since the Magpie won't be around long (since it will soon find a new shiny job) someone will have to learn rust just to maintain this project. Maybe the new maintainer will rewrite it in Zig or Haskell if they don't know Rust.
  - jmnicolas 5y ago
    It's all fun and games until someone rewrites it in Brainfuck!
- AussieWog93 5y ago
  Oh God, I was on the receiving end of that. Whoever decided to make the build system dependent on Jinja wasted so much of my time and caused a lot of grey hair!
  - unmole 5y ago
    Wait, build system dependent on Jinja, the templating engine and not Ninja?
    - AussieWog93 5y ago
      Yep. Part of the build process involved spitting out some auto-generated documentation. We had these short Jinja templates that relied on long Python scripts to do the actual work of performing the substitutions, as the logic was too complex to handle otherwise.
- jamesfinlayson 5y ago
  I've seen a business-critical system written in Cache ObjectScript and running on an InterSystems database - big liability and a struggle to get anyone who knows how to work with it.
mywittyname 5y ago
> Every time I've seen a project rewritten (regardless of technologies) -- it became better. I've seen the opposite happen, a lot. In the late 00s, the trend in the industry was to rewrite all the things. Everyone was trying to move away from PHP-based solutions to something "modern." Old code is battle-tested. That's valuable. Sometimes people reach for rewriting something that really just needs the plumbing updated.
- deepsun 5y ago
  I'm still hearing the opposite opinion from one older programmer I know, who's supporting a Cobol system right now. They get headaches just opening the Cobol editor. But extremely eager to jump off that project and move to a shiny new Java project. They don't care what will happen to that Cobol system, for all they care it may just burn in flames (taking a big bank with it).
everyone 5y ago
Maybe cuckoo is a better bird analogy than magpie. They leave their 'eggs' in other birds nests for them to take care of.
theshrike79 5y ago
Joel Spolsky on rewriting: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... > The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive
- deepsun 5y ago
  I'd argue that code does rot. 1. Cobol. Seems like most crowd here on HN thinks of it as a problem, contrary to what Joel says. 2. Security -- old code that's not being updated is often insecure. E.g. it requires old environment, that's not being supported anymore, so no security patches for you. 3. Motivation -- the older a project gets, the more you need to pay for its maintenance.
Cthulhu_ 5y ago
The hours invested count for NOTHING if the developer doesn't take anyone else with him. Nobody should be a solo developer, especially if they're being paid. I've had to work with a few prima donna's like that, the one guy basically went offline for six months (and he was the CTO!) to build his "it's full of stars" CQRS framework in C#, then he (and the manager that enabled him) quit and were re-hired as highly paid consultants. The manager was ousted or toned down a peg later on by a new, more willful manager. I'll concede that a rewrite CAN improve a software and pull it into the new decade, but it's a big risk, a lot of effort, and a lot of re-discovery - always consider, if that amount of effort and money was invested in the existing codebase, wouldn't it have the same effect? Another phrase that comes to mind is hype-driven development.
- deepsun 5y ago
  I knew a prima donna, who went offline for a year. They quit their previous job and were extremely motivated skip salary for 12 months to rewrite a project on a new shiny tech stack. That how the prima donna started my current company. If not for the Magpie, I'd be working somewhere else now.

deleted 5y ago

[deleted]

InsomniacL 5y ago

1. 2x hours booked against a project with a cost code. 2. There is no security review if only one person knows that language. As well as that one person being new to that language. 3. mostly agree but as you state, not relevant to new technology decided upon by someone on a whim. 4. Do you really believe creating sections of the tech stack that only a single person is able to maintain will result in you not having to pay these staff as much? Those staff who you now have a critical dependency on and they know it?

inetknght 5y ago
To your point #4: Do you really think that developers shouldn't be paid what they're worth? Or that developers should hold down their worth so that you can pay them that much less?
- Cthulhu_ 5y ago
  But migrating to a more niche technology where the existing one was fine is artificial inflation.
- InsomniacL 5y ago
  I do think they should be paid what they're worth... and if they're the only person in the whole company that can fix the code they wrote in a language nobody else knows, then they're indispensable and can charge any salary they want. which is why they shouldn't be allowed to artificially make themselves indispensable without bringing any additional benefit to the business

nhinck 5y ago

Sure any rewrite has those benefits, but it's also become a huge liability with a truck factor of 1.

deepsun 5y ago
Rewrites don't have to be done by sole Magpies. I've seen a semi-large project been rewritten 4 times at G, by the whole team. When I came I literally couldn't propose a single thing to improve (there were only things that could be traded off for something else). It was very self-respecting to work on that project (though I didn't do any of those rewrites). And I respected managers there for giving resources for it to happen.

tartoran 5y ago

> 2x hours into it Yeah, that includes a lot of time learning. For that reason it is also exciting, because you’re having fun learning what you chose to and additionally fattens the resume.. that releases extra dopamine.

codingdave 5y ago

5. Nobody else on the team knows the tech, so you are committing everyone to that same learning curve in order not not have a huge bus factor for this product. I'm not at all opposed to learning new shiny tech on the job. But it has to be a team effort, not one developer just deciding to forge their own path. FWIW, I work with a team who has greatly modernized their skill sets together over the last few years. But they did so by choosing when to start with a new tech, and putting time in their sprints towards the learning efforts, training, tutorials, etc.

xxs 5y ago

>1. ...put 2x hours into it. isn't that wonderful? That's what horrors are made of. You absolutely do not wish your people overworked for any extended period of time. And if there is an drawback, hurdle down the road, instability, etc...

Cthulhu_ 5y ago
Yup; 2x hours is not sustainable and there will be burn-out down the line. Bus factor is the phrase to consider here.
deepsun 5y ago
No, overworking only comes if you're not motivated with what you're doing, forcing your brain to overwork. But if your brain is simply tired of doing motivating job, then it just reduces a level of motivation, until it gets enough rest. So it's a self-regulated system.

femiagbabiaka 5y ago

Every behavior here sounds great for you and terrible for your team and org. I’m noticing that you didn’t mention skill transfer back to the rest of your team during or after the project.

deepsun 5y ago
Thanks, that's a pretty good note. It let me think of how it works in my current team, where I enjoy being. Basically, we are all Magpies here, and the implicit agreement here is that every project is combination of code and experience (in form of utilized best practices, like writing README-s, leaving scripts for everything etc). Everyone wanting to dive into another project is expected to be somewhat experienced in software engineering to know the best practices without asking (e.g. read the README, read the scripts), and everyone is expected to just read the code, it's all there. After those two actions, there are little left for communicating, really. But I understand that probably doesn't work for most teams, as we accept only senior devs to our team. PS: Also, I just noticed we never re-written a project here so far, mostly because older Magpies can explain why it's ideal for how it is, without resorting to "it works, so don't touch it" and "for historical reasons". It's written well enough so that even if I started rewriting, I would end up with the same thing.

jmnicolas 5y ago

> Now you got a devoted Owner, who is willing to take more responsibility of a project, isn't that wonderful? Yeah and since the Magpie won't be around long (since it will soon find a new shiny job) someone will have to learn rust just to maintain this project.

DeathArrow 5y ago
>Yeah and since the Magpie won't be around long (since it will soon find a new shiny job) someone will have to learn rust just to maintain this project. Maybe the new maintainer will rewrite it in Zig or Haskell if they don't know Rust.
- jmnicolas 5y ago
  It's all fun and games until someone rewrites it in Brainfuck!
AussieWog93 5y ago
Oh God, I was on the receiving end of that. Whoever decided to make the build system dependent on Jinja wasted so much of my time and caused a lot of grey hair!
- unmole 5y ago
  Wait, build system dependent on Jinja, the templating engine and not Ninja?
  - AussieWog93 5y ago
    Yep. Part of the build process involved spitting out some auto-generated documentation. We had these short Jinja templates that relied on long Python scripts to do the actual work of performing the substitutions, as the logic was too complex to handle otherwise.
jamesfinlayson 5y ago
I've seen a business-critical system written in Cache ObjectScript and running on an InterSystems database - big liability and a struggle to get anyone who knows how to work with it.

mywittyname 5y ago

> Every time I've seen a project rewritten (regardless of technologies) -- it became better. I've seen the opposite happen, a lot. In the late 00s, the trend in the industry was to rewrite all the things. Everyone was trying to move away from PHP-based solutions to something "modern." Old code is battle-tested. That's valuable. Sometimes people reach for rewriting something that really just needs the plumbing updated.

deepsun 5y ago
I'm still hearing the opposite opinion from one older programmer I know, who's supporting a Cobol system right now. They get headaches just opening the Cobol editor. But extremely eager to jump off that project and move to a shiny new Java project. They don't care what will happen to that Cobol system, for all they care it may just burn in flames (taking a big bank with it).

everyone 5y ago

Maybe cuckoo is a better bird analogy than magpie. They leave their 'eggs' in other birds nests for them to take care of.

theshrike79 5y ago

Joel Spolsky on rewriting: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... > The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive

deepsun 5y ago
I'd argue that code does rot. 1. Cobol. Seems like most crowd here on HN thinks of it as a problem, contrary to what Joel says. 2. Security -- old code that's not being updated is often insecure. E.g. it requires old environment, that's not being supported anymore, so no security patches for you. 3. Motivation -- the older a project gets, the more you need to pay for its maintenance.

Cthulhu_ 5y ago

The hours invested count for NOTHING if the developer doesn't take anyone else with him. Nobody should be a solo developer, especially if they're being paid. I've had to work with a few prima donna's like that, the one guy basically went offline for six months (and he was the CTO!) to build his "it's full of stars" CQRS framework in C#, then he (and the manager that enabled him) quit and were re-hired as highly paid consultants. The manager was ousted or toned down a peg later on by a new, more willful manager. I'll concede that a rewrite CAN improve a software and pull it into the new decade, but it's a big risk, a lot of effort, and a lot of re-discovery - always consider, if that amount of effort and money was invested in the existing codebase, wouldn't it have the same effect? Another phrase that comes to mind is hype-driven development.

deepsun 5y ago
I knew a prima donna, who went offline for a year. They quit their previous job and were extremely motivated skip salary for 12 months to rewrite a project on a new shiny tech stack. That how the prima donna started my current company. If not for the Magpie, I'd be working somewhere else now.