[HN Gopher] Magpie Driven Development (MDD)
___________________________________________________________________
Magpie Driven Development (MDD)
Author : DeathArrow
Score : 32 points
Date : 2021-10-12 11:45 UTC (11 hours ago)
(HTM) web link (www.nichesoftware.co.nz)
(TXT) w3m dump (www.nichesoftware.co.nz)
| konschubert wrote:
| If your senior dev manages builds a whole service in another
| language and you learn about it _after_ they 're about done, I
| think there are bigger problems than just the choice of the
| language.
| nottorp wrote:
| Can't blame someone who tries something else instead of .net.
|
| Going back to my current legacy .net project that i hate. Except
| there's no way I can stealth port it to rust or anything else so
| i'll just try to get the changes over with.
| DeathArrow wrote:
| Legacy .NET is crap. New .NET is pretty nice on the other hand.
| darkmatterrat wrote:
| However the people building stuff in new .NET are the same
| people building stuff in old .NET for the most part and you
| get all the same wonkyness just in .NET core.
| nottorp wrote:
| I believe mine was started in VB pre .net :)
| jaywalk wrote:
| Oh. Oh no.
|
| I hope you've at least had exposure to recent, proper .NET
| code. Don't judge the platform based on that project.
| whizzter wrote:
| While old VB was fun for whacking together things it's not
| really stuff one would want to maintain in the long haul.
|
| Right now I'm sometimes spending time maintaining something
| for a DCOM based semi-monstrosity and that does suck even
| if I've managed to clean out some old warts, luckily I'm
| also doing some more modern .NET stuff and that isn't too
| bad at all actually.
| fmajid wrote:
| I stopped reading when the author wrote with a straight face
| that .NET would help with their migration to Linux.
|
| That said, new technology proof of concepts should always be
| done on non-critical systems first, and certainly not sprung as
| surprises.
| littlecranky67 wrote:
| Can you ellaborate? .NET runs on Linux very well just a
| couple of years MS officially supported it, and if you have a
| decade worth of .NET code in your company, porting it to .NET
| 5 might be orders of magnitude easier than to rewrite into
| something else.
| clncy wrote:
| I also like the term Resume Driven Development (RDD) to describe
| this. Choose whichever technologies improve the developers resume
| the most.
| loulouxiv wrote:
| The technology most suited to improve one's resume will be the
| one most in demand on the job market, and therefore also the
| most difficult skill to hire for...
| llimos wrote:
| Guilty of this. And I encourage my team to do it too. You need to
| align incentives.
|
| The doing it in secret part is a far bigger problem.
| tlackemann wrote:
| "Let's use GraphQL"
| can16358p wrote:
| Literally happened to me. Our backend guys decided to switch to
| GraphQL from perfectly functioning REST. Result: release
| postponed by 4 months and 30% of the client side had to be
| rewritten. The whole client logic relies on Redux state as the
| single source of truth and I always fetch objects fully anyway,
| so it even makes less sense to switch.
|
| But again, backend guys being backend.
| jarcane wrote:
| I've begun to recognize "unnecessary GraphQL" as a code
| smell, and one usually indicative of wider architectural
| problems in a project.
|
| I have yet to be wrong in immediately steeling myself for the
| worst the second I see the word.
| corpdronejuly wrote:
| What would you consider to be "necessary GraphQL"
| dgb23 wrote:
| Nothing. But the utility it provides is a unification
| layer for heterogeneous data sources to enable ad-hoc
| queries on the consumer side.
| jarcane wrote:
| Are you Facebook?
| Chris2048 wrote:
| > backend guys being backend
|
| I've found backend devs to be more conservative than front.
| handrous wrote:
| Backend devs--who've been at it for any amount of time--
| know they're gonna have a really bad night followed by a
| really bad week and, quite possibly, a really bad month, if
| the wrong sort of stuff gets written to the production DB.
| Or someone accidentally deploys redirect or routing code
| that's effectively an open proxy and kills your IP block's
| reputation. Or _et c., et c._
| littlecranky67 wrote:
| Great example, I contract in FE space and GraphQL is very often
| brought up - 100% in project context where it didn't really
| make sense and most of the time I got the feeling they will
| bring it up to have it on the CV or out of FOMO.
|
| I personally see good use in GraphQL for 2 usecases:
|
| - Aggregator over existing (!) microservices backend arch that
| has REST (plus maybe gRPC) in place, to allow FE people to move
| fast with their UI. In no way should new services be written in
| GraphQL, BE should still use REST (+gRPC)
|
| - Prototyping/Fast clickdummy implementation; ideally a
| Snapshopt of an existing DB is used, and graphQL adapter for
| 1:1 entity mapping to allow 1-2 FE devs to quickly toss
| together a new FE (this should under no circumstances be used
| for anything even close to production)
|
| Cases where it has been pitched to me where I see no increased
| value:
|
| - BE team is too slow/lazy/defensive for new features (just
| have a GraphQL adapter and 1:1 map db entities to GraphQL
| entities -> please don't do that)
|
| - having "typed" queries (you should just use typescript to
| strictly type your REST DTOs instead and optionally use a VM
| mapping)
| Netcob wrote:
| Communication issues aside, good luck finding developers who
| aquired all the necessary skills to work in software development
| without this mindset.
|
| Of course it would be great for a company to be able to hire
| people who only learn new things on weekends and then 100% commit
| to and derive all their motivation from delivering the product,
| but I think that's quite rare...
| what_is_orcas wrote:
| I've sort of been dealing with this at my day job, except it
| doesn't come from other developers, it comes from management.
|
| Every few years, a new Head of Engineering comes in and says
| something like "let's use $TECHNOLOGY for this project" with the
| expectation that it will make the company more effective, I
| think. It's been GraphQL, microservices, clouds ("can we do this
| with Lambdas on AWS?" when we don't have any other significant
| infrastructure on AWS), and a bunch of other things.
|
| On one hand, it's good for me to dabble in a lot of this stuff
| (learning the basics of GraphQL on company time helps my resume,
| after all), but I end up pushing back most of the time ("I don't
| think this is a great use-case for GraphQL. From what I
| understand, $X and $Y would be reasons to use it, but for this
| project, REST makes more sense because of $Z"). Meanwhile I'm
| just trying to get my work done and not make it a hassle.
|
| If we had a good reason to use GraphQL (or any of the other
| things management suggests), I'd be into it, but I don't want to
| be wrestling with fitting square pegs into round holes for no
| benefit.
| mywittyname wrote:
| This manager might be optimizing for the environment they work
| in. If the expectations are the Head of Engineering introduces
| Cool New Technology to the company, then that's what they will
| push to do.
|
| If you report directly to them, it might be worth a
| conversation to frame your team's work in a way that sells it
| as Cool New Technology that is being built.
| what_is_orcas wrote:
| Oh certainly.
|
| I have a pretty good relationship with that manager,
| actually, and that's more or less the framework we use to
| sort of compromise. He gets his buzzwords and I get to get my
| work done.
|
| I enjoy learning new things, don't get me wrong, but
| sometimes a CRUD app is just a CRUD app and trying to
| shoehorn other stuff into it makes it more of a pain in the
| long run.
|
| I guess I just wanted to illustrate that this isn't only an
| IC issue; management can engage in MDD too.
| can16358p wrote:
| Not to advocate any of it, but if trying out that new shiny
| language creates real motivation for the developer (and of
| course, suitable from a business/maintainabity etc perspective
| too), let them.
|
| Of course you should have communicated more with the developer
| though to see what they've been working on.
| xyzal wrote:
| I am guilty. Also, I very much enjoy it.
| nivertech wrote:
| MDD - Migpie Driven Development HDD - Hype-Driven
| Development BWDD - BuzzWords-Driven Development HNDD
| - Hacker News-Driven Development RDD - Resume-Driven
| Development CVDD - CV-Driven Development
| osigurdson wrote:
| EDD - Epoch Driven Development
|
| To use precisely the tools and technologies that the project
| started with until the end of time.
| oqbrya wrote:
| There is nothing wrong with learning new technologies and trying
| new stuff. If your organization prohibits this I don't think it
| is a good place to work. What you call "MDD" sound to me more
| like a planning or communication issue between the project
| manager and the developer.
| littlecranky67 wrote:
| Learning is one thing, putting a production service into place
| in a language no one else is familar with and without
| permission, is not okay.
| dhruvmittal wrote:
| I think a slight improvement over this model is to have a
| forward-looking CTO/Lead Developer/etc. who incorporates new
| technologies into the overall plan with sane fail states. This
| allows the overall technology stack to remain fresh, the
| developers to stay motivated and current, manages the overall
| amount of legacy code, while also managing incurred risk
| effectively. It can also lead to company investment in those new
| technologies, i.e. training time/budget or conference tickets
| (depending on what's relevant).
|
| Tl;dr: put your magpies on the top!
| bovermyer wrote:
| I see several comments here defending new-shiny syndrome in the
| context of improving the developer.
|
| From a business standpoint, that doesn't make a ton of sense.
| Development is meant to complete the business's objective of
| solving a problem for humans. It's not meant to make the
| developers enjoy their work more (though that's a nice bonus when
| it happens).
|
| Chasing the new shiny puts the team in a perpetual state of re-
| learning how to do a known process. Maintaining and extending
| existing code in a known way is more predictable and more cost-
| effective.
| handrous wrote:
| Yet, if the developers who successfully mislead their employers
| into misguided tech choices have notably better careers, on
| average, it's exactly what we should do. And we shouldn't feel
| a bit bad about it unless we're in one of those rare roles
| where lives are on the line.
|
| > Development is meant to complete the business's objective of
| solving a problem for humans.
|
| Sure, but every layer of management is making decisions
| constantly, including about what to direct development to do,
| that are in their own personal interest rather than the
| business' interest. If they can do that, the peons can (and
| should) too.
| beardyw wrote:
| The larger and less well managed (from the top) a business
| becomes the more likely that becomes. If you haven't
| experienced the converse I would advise you to seek it out.
| Working in an environment where the goal is understood and
| (mostly) everyone is working toward it because that is how
| they will be measured, is a joy.
| handrous wrote:
| I mostly have, which is the only reason I haven't taken my
| own (implicit) advice and become parasitic, like everyone
| else who's (personally) successful in large enterprises.
| That would have been a better move for my finances, for
| sure, but I don't really have the stomach for it.
|
| OTOH I still think that complaining that people at or near
| the bottom of the org chart _follow incentives_ to achieve
| better personal outcomes, because it might hurt the company
| a little, is naive at best--at worst, it 's propaganda in
| the class war. "Workers, please limit your own career
| trajectory to help out the company. Here, let me
| (deliberately?) misunderstand your motivations and, as is
| typical, present developers as akin to children, not like
| the fully-formed adults in management".
|
| Haha. No.
| bovermyer wrote:
| I feel like you're reading more into my comments than you
| should. I'm a developer, too.
|
| Your second paragraph... what is that in response to? How
| is saying that forcing other developers to follow the
| tech whims of some wannabe 10X is a bad thing "propaganda
| in the class war?"
| handrous wrote:
| > Your second paragraph... what is that in response to?
| How is saying that forcing other developers to follow the
| tech whims of some wannabe 10X is a bad thing "propaganda
| in the class war?"
|
| The article, mainly, which reads _very much_ like it 's
| from the perspective of a project manager or engineering
| manager or something like that--as in "This morning you
| found out to your surprise that one of _your senior
| developers_ " (emphasis mine), which seemingly-not-a-
| developer voice and POV it continues throughout. The
| (inevitable) infantilizing is here:
|
| "Magpie Driven Development is when you have developers
| who want to use something new for no better reason than
| it's shiny and fun."
|
| Sure--except when developers do it because it's how you
| get ahead in this career. But that's something a rational
| person, not a toddler, might do, so we can't allow that
| that might be the reason. This sneering "oh, those
| childlike developers" tone is typical of management most
| places, when they talk/write about developers. I've even
| seen it in places that are pretty damn developer-friendly
| and tech-driven--it's subtle, but "oh, you know how
| software developers are" is _deeply_ ingrained in
| management vernacular. I think it 's a defense mechanism,
| mainly--and a very successful one, from what I've seen--
| because devs are _paid_ like we 're upper-middle-class
| but managers are, unconsciously or otherwise, very
| uncomfortable with us being in the same (or higher,
| maybe) _social_ class as them, so take care that we do
| not rise in status on that front. I think that 's how you
| end up with that kind of language being the norm, when
| managers treat of developers. "Well OK they make a lot of
| money but aren't they so _immature_ and _flighty_ and
| _distractible_? And god knows they can 't be good at
| talking to people, or understanding how business works,
| or anything else that's _our_ job. Now hold on, I 've got
| _really strong_ bad opinions about how this button should
| look and I expect to have my thoughts treated with
| _deference_ and close attention. Why? Well, look at the
| org chart! That 's why."
|
| Anticipation and avoidance of this dynamic is why lawyers
| and doctors tend to resist having non-doctor and non-
| lawyer managers--and it's part of why those professions
| still, on average, carry significantly more social value
| than "software engineer". Pay's only part of the
| equation.
| bovermyer wrote:
| This strikes me as very cynical.
|
| In my own life experience, the majority of my employers have
| genuinely wanted to work together to improve things for a
| large group of people.
|
| I have never worked for an employer where it was obvious that
| everyone was only out for themselves.
| inetknght wrote:
| > _I have never worked for an employer where it was obvious
| that everyone was only out for themselves._
|
| I guess you mustn't have worked for very many employers. Or
| at least not in the USA. The sentiment is endemic where I
| am in Houston, TX and previously in CA
| [deleted]
| Chris2048 wrote:
| > defending new-shiny syndrome
|
| this is itself a negative phrasing for the phenomenon. For one
| thing, Rust isn't just shiny and new - it has actual benefits.
|
| Depicting "a perpetual state of re-learning" as
| negative/positive omits whether or not the process is actually
| improving or not.
|
| > Maintaining and extending existing code in a known way
|
| depends how debt-inflicted it is. In any case, this article
| describes a new service, so there wouldn't be the same issue as
| extending existing services.
| bovermyer wrote:
| There are cases - like a brand new service - where a new
| language or framework is a good idea.
|
| In some very rare cases, rewrites can also be a good idea.
|
| But choosing a new technology just because it's new and
| popular? Almost never a good idea.
| littlecranky67 wrote:
| Exactly. Remembering Scala? It had a lot of drag around
| 2010-2015 and everybody was like "this is going to replace
| Java everywhere". Now it is still alive, you will find some
| jobs, but career wise Java devs are in higher demand, and I
| don't think that'll change again.
| TeMPOraL wrote:
| Don't confuse popularity with hotness. The latter is the
| first derivative of the former. Rust is hot, but not
| popular. Scala is somewhat hot (was truly hot a couple
| years ago) and somewhat popular. Java is lame, but very
| popular. JavaScript is... a goddamn black hole.
| Chris2048 wrote:
| > But choosing a new technology just because it's new and
| popular?
|
| Sure, but the given example states that as assumption. IRL
| how is that determined. The article states:
|
| > Investigating, you find out that there's no compelling
| business reason for the component to be written in Rust.
| Not much of a technical reason either
|
| but doesn't detail if that was based on (or in agreement
| with) the opinion of the senior engineer who implemented
| the service, or the opinion of the author (whose role isn't
| that clear).
|
| I'd also state that that while "choosing a new technology
| just because it's new" is bad (although could easily be a
| proxy for the features that the new thing actually brings -
| Rust isn't just a new rehash of existing languages, it
| brings unique features); "choosing a new technology just
| because it's popular" does have merit.
| jfabre wrote:
| A company has multiple stakeholders.
|
| - Investors
|
| - Workers
|
| - Customers
|
| - Community
|
| A delicate balance has to be achieved by the company to meet
| everyone's need. If the company cannot achieve this, it will
| suffer one way or another.
| bovermyer wrote:
| This is true.
|
| However, characterizing workers as only needing to work with
| their latest interest misses out on a world of other (and
| sometimes conflicting) needs.
|
| Not every developer in an organization is going to want to
| change languages and ecosystems every Tuesday.
| nodejs_rulez_1 wrote:
| _> Not every developer in an organization is going to want
| to change languages and ecosystems every Tuesday. _
|
| Not every developer wants to work with whatever Linus,
| Netflix and other Googles have concocted for their unique
| reasons yet here we are.
| bovermyer wrote:
| I don't understand what you're trying to say here.
| nodejs_rulez_1 wrote:
| It's OK.
| TeMPOraL wrote:
| Hah. The author is missing the point of their own example:
|
| > _Investigating, you find out that there's no compelling
| business reason for the component to be written in Rust. Not much
| of a technical reason either. It's just that the developer
| involved really wanted to learn the Rust language and related
| ecosystem of tooling, and they figured this work project was the
| best place to do that learning._
|
| > _Magpie Driven Development is when you have developers who want
| to use something new for no better reason than it's shiny and
| fun._
|
| That developer didn't use Rust because "it's shiny and fun". They
| did it to learn. Couple possible reasons:
|
| 1/ Mental hygiene. They're bored out of their mind with their
| current tech stack, and picked something different to prevent
| burnout.
|
| 2/ Principal-agent problem. They wanted to learn the new
| language, perhaps to use it for a side project, and opted to do
| some of the learning on company time.
|
| 3/ Professional development. They want to "sharpen their saw"
| and/or keep up to date with industry trends, and opted to do it
| on company time.
|
| 4/ CV padding. They consider changing the job, and are trying to
| gain some marketable experience.
|
| 5/ In-house improvements. There's a need for a change of tech
| stack in the company, of which the author of this article isn't
| aware. The developer did a project in new technology as a part of
| moving in this direction.
|
| We can debate professionalism and ethics of any of those reasons
| as applied to a specific case. But I don't think classifying such
| situations as developers chasing shiny things is productive or
| insightful.
| bobthepanda wrote:
| > In-house improvements. There's a need for a change of tech
| stack in the company, of which the author of this article isn't
| aware. The developer did a project in new technology as a part
| of moving in this direction.
|
| Certainly something that would probably get messaged at all
| levels of the company, not something you surprise drop on the
| rest of your coworkers and pull them kicking and screaming
| towards.
| [deleted]
| nodejs_rulez_1 wrote:
| Another one of those articles...
|
| Please tell us how you incentivise your staff to deprioritise
| their skill growth in favour of your business? I hope to hear
| things other than "salary, benefits and bonus" but they have to
| be monetary.
| rocqua wrote:
| Why do they have to be monetary but not based on salary or
| bonuses?
| nodejs_rulez_1 wrote:
| Because you want people to care about business same way as
| the owners do, yet when the firing starts they will simply be
| let go.
|
| Another option is to openly state during hiring that new
| technologies and approaches are not welcome.
| UncleEntity wrote:
| Because the business pays them to do a specific job which
| doesn't include them training for their next job?
|
| Is it really that common that people expect their current
| employer to subsidize their "skill growth" when they know they
| are just going to hop to another company in the near term?
|
| Not judging --- just asking as an outsider looking in.
|
| --edit--
|
| Huh, just downvotes so I assume it is expected to be able to
| train yourself on company time...
| TeMPOraL wrote:
| > _Is it really that common that people expect their current
| employer to subsidize their "skill growth"_
|
| Yes, that's common in professions.
|
| > _when they know they are just going to hop to another
| company in the near term?_
|
| That's a consequence of employers not willing to keep paying
| market rate over time. The only way to get back to that rate
| is to go somewhere else.
|
| Also, most employers are expecting to hire already competent
| proffesionals, and invest nothing into training people in-
| house. So for each person that jumps ship, when they hire a
| replacement, they enjoy a subsidy of said replacement having
| secretly trained themselves on previous employers' dime.
| handrous wrote:
| Capitalists and the c-suite: _Nepotism and self-dealing all day
| every day, constantly directing entire acquisitions to bail out
| a buddy 's or a kid's failing business, or making companies
| they have control of rent buildings they personally own or
| whatever_
|
| Software developers: _Act in their own self interest in a minor
| way that 's not perfectly in line with he company's interests_
|
| Business bloggers: Hey now, cut it out developers! What a bunch
| of low-attention-span babies you are.
| politician wrote:
| It takes a certain culture and way of working for staff to be
| able to safely experiment with new technologies or new product
| ideas. I prefer to build teams where learning and experimentation
| are aligned with business objectives.
|
| However, this approach doesn't work for everyone or for every
| business. There are many successful risk-averse businesses
| staffed by folks working ticket queues.
|
| In the end, it's about the culture. An autodidact will struggle
| in a ticket mill. A ticket puncher will struggle in a skunkworks.
| vaughandroid wrote:
| I'm not a fan of this post as it seems to be pointing the blame
| at the wrong thing: the problem isn't the shiny new thing, it's
| the environment that allowed the situation to develop: people
| working in isolation, key decisions being made by individuals in
| private, lack of oversight.
|
| There are plenty of arguments in favour of allowing teams to use
| shiny new tech. Done responsibly, it can help with engagement,
| job satisfaction, retention, and recruitment.
| mkl95 wrote:
| Magpie Driven Development is imho a symptom of Dead-end Driven
| Development (DDD).
|
| Dead-end Driven Development happens when the majority of a
| developer's time is spent working with technologies that hurt
| their career. The way you end up like this is often because the
| projects you were initially hired for have reached a maintenance
| state.
|
| Instead of rewarding developers who have successfully completed
| the tasks they were initially hired for by assigning them tasks
| that benefit both their career and the company's goals,
| developers who meet management's expectations are often assigned
| to legacy projects that are riddled with obscure bugs, strange
| architecture, and bad choices. The end goal of these tasks is
| often to upgrade a system that uses ancient technologies in order
| to ease some customer's mind.
|
| In this situation burnout eventually creeps in and the engineer
| faces two choices: either they start doing something that puts
| their career back in the right track (MDD) despite the
| consequences, or they find another job that improves their
| situation.
|
| In the previous economy I would expect most people to pick option
| 1. In the current economy I'd expect an overwhelming majority to
| pick option 2.
| mamcx wrote:
| Consider it lucky Magpie is using Rust. Imagine if instead
| rewrite it in JS with they new shinny frameworks...
| grayclhn wrote:
| tbh, the only problem I have with the approach in the article is
| that they're not being strategic about it. I've informally had a,
| "one cool idea per project," rule in the past. So if the project
| itself is cool, stay conservative with implementation choices,
| etc. But if the project is routine, you get to experiment a
| little.
| deepsun wrote:
| 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).
| jmnicolas wrote:
| > 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.
| xxs wrote:
| >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...
| mywittyname wrote:
| > 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.
| tartoran wrote:
| > 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.
| InsomniacL wrote:
| 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 wrote:
| 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?
| femiagbabiaka wrote:
| 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.
| nhinck wrote:
| Sure any rewrite has those benefits, but it's also become a
| huge liability with a truck factor of 1.
| codingdave wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-12 23:01 UTC)