13 ms·

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's the

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offers him a chance to climb the ladder. 3. No product manager can put "Made the product more stable and usable" in their resume. It's all the new extra features that they thought out, which will earn them reputation. 4. No manager is rewarded for how lean a team they manage and how they get things done with a tiny & flat team. Managers pride themselves with how many people work under them and how tall in the hierarchy they are. Our industry thrives on producing more solutions than needed. Efforts are rewarded based on conventional measurements, without thinking through- in what directions were the efforts pointed at. Unless the incentives of everyone involved are aligned with what's actually needed, we'll continue solving imaginary problems, I guess.

morning-coffee 3y ago
^ this ^ Until we figure out a nice metric for "removing complexity" and then rewarding for it, it's not likely to change, IMO.
ronnier 3y ago
I really think we have too many people working at most companies. It pushes people to the extremes and edges just to have something to work on. Managers need more people under them to get promotions. And managers want to manage managers to keep moving up. They fill teams of people on products that could really be ran by a fraction of the engineers. But that’s not where we are, we are on large teams working on small areas of the product inventing areas to build in and often ruining the product as a result. We also get slower with so many people. The coordination overhead is killer and losing context as the product is sliced up into small parts that move on without you
- sanderjd 3y ago
  Yeah I dunno, I hear this a lot, but there has universally been way more work to do than people to do it at every company I've worked for. But that doesn't mean the right things are being prioritized.
  - Aeolun 3y ago
    There is a lot of work, but a lot of that work is generated by people doing the wrong thing too often. If we had a smaller and more competent team, the initial build might have been marginally slower, but we wouldn’t have to spend a permanent 50% to just keeping down the technical debt.
    - Denzel 3y ago
      You’re working from a cost-efficiency / cost optimization perspective. That’s a great perspective in some contexts, for example, mature late-stage products, fully saturated markets, etc. Is cost efficiency an effective perspective for innovation or revenue growth? Mostly, no. As long as your risk-of-ruin is low, then you want to fail. Sometimes people misinterpret this as “doing the wrong thing”. But it takes doing a lot of wrong things to do the right thing. The difference between right and wrong, if there ever was such a simple dichotomy, is so marginal and only understood in hindsight.
      - Aeolun 3y ago
        You ask the executive if he wants to get to his goal with a team of 200 after lighting on fire 20M, or with a team of 20 after paying 2M. Ultimately you end up in the same spot, but one choice is fairly suboptimal there.
        sanderjd 3y ago
        The whole point of the comment you replied to is that, if the "goal" is something innovative rather than just sustaining, then no, you don't end up in the same spot in those two scenarios. But this is why some executives are better for some kinds of businesses and others are better for other kinds. Some executives don't understand your parent comment's point (or just don't find it comfortable), and will be very allergic to the "waste" necessary to experiment and iterate on poorly understood projects. Other executives will be uncomfortable just constantly figuring out how to optimize costs without damaging revenues. A very tricky part of the lifecycle of many companies that get gigantic is to figure out when to flip this and start switching out the executive team to focus on a different model.
pavlov 3y ago
> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scientist, an industrial designer, and a product manager with industry experience in the customer domain. The application was Windows native. User research was conducted on site with scientific rigor. Adhering to platform guidelines and conventions was a priority. I think I spent a few weeks redrawing hundreds of toolbar icons so they’d be in line with the Office 97 look (the kind of boring job you give to the junior). If the app stood out on the Windows desktop, that would have been considered problematic. Today a similar design team would only have a graphic designer and a PM, and neither of them would care the slightest about platform guidelines or customer domain. The UI is primarily an extension of the corporate brand. Hiring a cognitive scientist? Forget about it… Everything certainly wasn’t perfect in the Windows/Mac desktop golden era. But the rise of the web wiped out a lot of good industry practices too.
- aldanor 3y ago
  Today they might have a psychologist on the team to research which buttons may serve as dopamine triggers so you're a lot more likely to upgrade to Premium before thinking it over
  - pavlov 3y ago
    Right. Making people click on things they didn’t mean to and buy things they didn’t want — those goals were not even a part of the 1990s UI paradigm.
    - hnlmorg 3y ago
      1990s design was all about preventing people from accidentally doing actions they might not have wanted to. Even down to the “Are you sure you want to quit” dialogues that were all the rage. It’s sad just where we are now compared to the design goals of old.
chillbill 3y ago
I don’t think it’s as easy as you’re making it to seem. The issue is that there are unintended consequences to each one of those points you mentioned. I’m pretty sure a substantial amount of thinking goes into software design from all aspects and it’s a bit reductive to say that it’s just lack of incentive. Humans doing software are not some machine learning algorithm to train with reinforcement learning techniques.
x86x87 3y ago
I call this "the tragedy of software development"
wildekek 3y ago
All of those are absolutely real. There is a lack of economics and a surplus of optics in the game for all players.
voz_ 3y ago
Uber was a massive example of this. The best engineers kept their head down and just tried to keep things afloat, fixing bugs, etc. However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such a way that it only ever encouraged “TL”/“architect”types to grow. This led to constant churn, horrible codebases, and utter bullshit self made problems which could only be solved by digging a deeper hole. There are companies who handle this well. Ultimately it comes down to engineering culture.
- nine_zeros 3y ago
  The career ladder is among the biggest fuck ups of the tech industry. They incentivize bullshittery more than actual innovation. There are more rewards for BS RFCs than in keeping the ship running.
  - gtirloni 3y ago
    I had a completely different view of RFCs before coming into contact with some peers that followed this approach to the letter. RFCs for such small issues would take 10 pages and barely mean anything. Of course they would be praised by upper management (it didn't matter the RFCs would be ignored most of the time).
sirsinsalot 3y ago
> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.
- kylelahnakoski 3y ago
  Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.
  - sirsinsalot 3y ago
    In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/... Like most other engineering in the world really.
    - paulryanrogers 3y ago
      IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies. Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
      - 3y ago
marcus0x62 3y ago
And at least at the “enterprise” level for B2B software, there is intense customer demand for more features and, simultaneously, more stability. From my view, that and pressure from the analyst racket are the main drivers behind feature bloat with self promotion a distant third.
yieldcrv 3y ago
and the re-writes have to be in a trendy language that other companies are using, just for the engineer to stay relevant. everything about engineering group decisions are about creating a reason to use a newer framework in a way other people can vouch for.
bluGill 3y ago
There are exceptions to all the above, but only after the worst case burns from failure to do those things. If you are losing customers to competition that doesn't crash, then suddenly you can be the hero by making yours more stable. Of course only if you can do this before the company dies.
bombolo 3y ago
Coworker of mine wrote a thing in java… it was too slow (intensive locking between threads)… so he rewrote it in C… it was crashing all the time (because he sucks), then he rewrote it in go. Got promoted for this feat.
- ilyt 3y ago
  That's kinda what initally Go was made for IIRC. They noticed people which job is not programming but had to write some code (say some analytics or sth) often did it in Python, and if it was too slow they moved to C or Java and were predictably terrible at it, so that's why Go was made simple and with builtin concurrency primitives.
  - bombolo 3y ago
    But his job is programming. He is very proud of his C skills. If you listen to him, it crashed because C is intrinsically bad (it is difficult yes), but I guess it was also such a bad codebase that rewriting it made sense. He also holds a grudge against me for having dared to rewrite a sacred C library he wrote (that was a constant source of segfault and I rewrote in 1 afternoon).
    - ilyt 3y ago
      Sounds more like his job is producing tech debt. I saw few people like that, basically none of their code was left as most of that needed to be eventually replaced coz it was shit.
deleted 3y ago
[deleted]
joshlemer 3y ago
I don't know, the more I advance in my career, the more I see it as the opposite. Wide eyed developers with big designs, who are obsessed with the technical aspects of a solution, who disregard the practicalities, long term implications at the social level (who is going to maintain this, do we have people that have that skillset, is this worth the effort, does it really matter to be this elegant, or is it more important to ship quickly and economically) come off as a bit immature and the more effective engineers who understand these priorities are given more respect and authority.
- stuckinhell 3y ago
  The problem for a lot of the social level issues is that it is pure pure politics.
- gopalv 3y ago
  > the more effective engineers who understand these priorities are given more respect and authority. The problem with "given more authority" I see is that management plucks these engineers out to make their day job basically "sit in meetings" if you're even slightly effective at simplifying life for everyone else. Because that is the place of most leverage to place those people, but then those people are in a constant tug-of-war with the first group of "fresh ideas". Eventually, the people who are in charge of the "prevention of bad architecture" become the bad guys because they (or me, I'm projecting) get jaded into just finding out what's wrong with something as fast as possible to be able to keep up with that workload. You go from a creative role to a fundamentally sieve role with destructive tendencies, where you are filtering out the good from the bad as fast as possible, be. First of all, not all new ideas are bad and "there's something bad about X" is not a "let's not do X". Secondly, going from making things to shooting down things is intellectual suffering if you have a bit of empathy. Some people on the "committee" with you don't have empathy & literally enjoy it - you're either trying to damage control on a case-by-case or building a "these assholes need to be fired" doc out of the meetings. I realized what I would become if I conflated authority and respect ("respect my authoritah!"). Quitting was really the only way out of it. But it wasn't hard to explain to my spouse that i needed to leave for a job a level down and which paid half as much, because she could see me bringing my "why the hell do we have to do this" attitude home & to family decisions.
Xen9 3y ago
This kind of problem surfaces in a large amount of systems involving humans and roles.
hinkley 3y ago
There’s a couple of woodworking hand tool companies who among other things make replicas of old school Stanley tools, the way Stanley used to make them (materials and tolerances). They also fuse the best elements of several eras or manufacturers to make slightly better versions. Surfaces from this one, handles from that one, adjustment mechanism from a third. I hope that I live to see a time when software applies modern algorithms to classic designs and produce “hand tools” in software.
- Aerbil313 3y ago
  The field of software is maturing as we’re reaching the end of Moore’s Law and time passes. Times of constant innovation is very slowly coming to an end, the curve is slowly flattening. You can already see it with general trends like type-safety, DX features universal in all languages (linting etc.), browsers finally becoming the universal OS (Wasm, WebUSB, GPU), more and more things being standardized every day.
  - hinkley 3y ago
    Proebsting's Law says compilers double code efficiency every 18 years. I wonder what the doubling interval is for algorithmic performance. I expect it would be tough to calculate, like the cost of living, because algorithmic improvements rarel affect all aspects of code performance equally. Incremental improvements in sorting efficiency likely have one of the broadest reaches, followed by concurrency improvements and object lifetime analysis. Then there's a long tail of niche applications that only apply to certain domains. Only the Amdahl's Law parts of the code has a substantial impact on performance.
segh 3y ago
I'm not sure it's just incentives. Inexperienced early stage founders often end up solving imaginary problems, despite having a real incentive to get it right. The Y Combinator moto is "make something people want" because so many people don't.
sh34r 3y ago
I agree with just about everything you've said, except that bit about rewrites. Rewrite projects typically go down in flames, and on the rare occasions that they don't, the business stakeholders are still mad because their precious feature factory was down for maintenance for months.
- Hackbraten 3y ago
  > months Please.
- whstl 3y ago
  I don't think you two disagree, GP is just saying that large-scale rewrites are rewarded, regardless of the result. I've seen that happening even when stakeholders were unsatisfied.
analog31 3y ago
You can still get away with these things if your only user is yourself or maybe a small handful of non-enterprise folks. This could be why the so called "scientific" programmer feels like they can be as productive as a team of 10+ software developers. And also why the most frequent request from the users is: Please don't change anything. The principal-agent problem looms large in software.
- hutzlibu 3y ago
  "And also why the most frequent request from the users is: Please don't change anything." I think it is: "Please don't change anything I did not request" (who does not hate updates that break your workflow?) But they usually very much like changes, that makes life easier for them. Best way to find out, is to watch them using your tool and talk with them.
rapht 3y ago
You can think of it in even broader terms: being/staying lean, re-using tried and tested things, adapting your requirements to widely available solutions rather than developing custom solutions to fit your requirements, making everything work more efficiently, etc -- all those resource-minimization issues are "less" problems: not good problems to be working on when your raison d'être is "more" -- and that's the only raison d'être for a lot of people and actually for all businesses. (Obviously there are also specialists for doing "less" "more": unsurprisingly, they are generally paid a cut of savings.)
AndrewKemendo 3y ago
I’m going to reference this comment in the future when I build my next software product. Thanks
throw10920 3y ago
They're not mutually exclusive. FOSS software has vastly different incentives than commercial software, yet suffers from many of the same problems: bugginess, poor performance, lack of documentation, feature misprioritization, bad UI. That alone indicates that the problem is not merely "misaligned incentives". Actually, you can reduce most problems down to "misaligned incentives" if you're overly reductive enough. That doesn't mean that it's a useful way to think about the world.
- jrockway 3y ago
  I think Free Software suffers from the misaligned incentives. Take documentation for example. Why would I write it? I already know how the system works. I designed it! If I forget in a few years, a quick glance at the code will refresh my memory. One would argue that you should write documentation so that people will use your thing. That's true! But there is almost no incentive to have users; you pay a cost, but they pay nothing in return. (Someone will send a bugfix now and again, of course, but it's very very rare.) Some other incentives are balanced, though. Persistent low performance or bugginess affects the author and end users equally; the more the author uses their own software, the more this will hurt. Sometimes the low performance is a design trade off; Python isn't Rust, and the users seem to be okay with that. It was done on purpose. Sometimes low performance is a factor of the author's needs; you're trying to run the thing on 1 billion machines, they only have 1; something has got to give. But that's not misaligned incentives so much as it is lack of suitability for a particular purpose. A screwdriver is terrible for hammering in nails. That's not the screwdriver's fault.
  - indymike 3y ago
    > I think Free Software suffers from the misaligned incentives. It's really hard to tell what the motivation of any given free software author is. That makes it really hard to even know what incentives matter to any give author, team or community. It's just really diverse. > That's true! But there is almost no incentive to have users; you pay a cost, but they pay nothing in return. It's fascinating to see free software with huge user bases getting on with a tiny number of contributors. It seems like good code + near zero support cost + near zero support expectation seems to work.
xyzelement 3y ago
Maybe I am biased by my background in finance tech but I saw a ton of guys get rewarded for what (at the time) seemed like boring maintenance of systems. In retrospect - it was recognized that they built or took good care of money making systems with little drama and that was well appreciated by the companies. In FAANGs I see now more of "what will get me promoted" versus "what is gonna make the company money" ethos.
- sanderjd 3y ago
  Promotion driven features are definitely not entirely a myth IMO, but on the other hand, anecdotally I saw quite a few people get promoted at Google for doing make-things-work-better work. The trick was figuring out which were the important things to maintain and make small improvements to, rather than just which were the things that seemed fun to tinker with, but weren't as impactful.
- throwaway2037 3y ago
  "finance tech" -- those people maintaining those systems are middle-aged, comfortable, and well-paid. If you were junior under them, you would never want to stay. Fifteen years ago, there were large fresh hire classes each year. Tons of juniors around the office. Plenty of young ones dreaming up unnecessary "upgrades". Most of that is gone as the industry has matured. If anything, the hoards of junior hires have moved from finance to Big Tech.
llanowarelves 3y ago
I like that it's this way so we can easily compete with these dysfunctional companies. Don't fix them :)
tzhenghao 3y ago
"Show me the incentive, I'll show you the outcome." - Charlie Munger
- woah 3y ago
  Isn’t he the guy who tried to get a university to build a giant windowless dormitory cube?
  - zimpenfish 3y ago
    I mean, he's not wrong though - the incentive was "University gets a large amount of cash" and the outcome, predictably, was "University bends over backwards to accommodate insane requests of donor". (The correct solution, obviously, is that universities should be sustainably state-funded and not require mega-donors with their associated insanities, etc. to survive.)
  - pphysch 3y ago
    Still don't understand the opposition to that. Students get affordable, safe, private housing on campus, where there's a million places to hang out beyond your windowless bedroom. Libraries, open spaces, study halls, cafes. The alternative is often paying $1K for some barely maintained triplex basement shared bedroom off of campus, from a negligent landlord.
mattgreenrocks 3y ago
Definitely. I’ll say one thing though: all of those skills you mentioned as not being valued are extremely useful for indie dev/taking ownership. Shipping simple + correct code frequently is extremely possible with sufficient practice and discipline. More to your point, this is why I switched toward being a research engineer. There is a higher barrier of entry, projects are quite technically challenging, and constraints often force thinking of a world of computing beyond the tiny sphere of the web browser. It’s hard work, but I love it. If this resonates, you are in the US, and looking for a change, drop me a note (see profile).
sanderjd 3y ago
I don't think these "No"s are entirely right, though they are directionally right. But there are actually healthy businesses (and healthy divisions within less healthy businesses) out there that do incentive those behaviors, and it's a huge competitive advantage for them.
sheepscreek 3y ago
How do companies keep pushing their quarterly numbers higher and higher? By manufacturing innovations! Welcome to 21st century capitalism.
bbor 3y ago
Just want to throw out a way we could align everyone’s incentives: a robust universal economic safety net. If people were working to make a good product rather than stop their children from starving, our natural inclination to take pride in our work would be allowed to flourish. Not gonna convince anyone but hopefully someone reads this and starts thinking about such options. They are not as impossible as those in power would have us believe.
jongjong 3y ago
With developers, incentive misalignment is just insane at all levels. - There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design). - There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far more important). The costs of this tends to fall on other developers who come in later and act as scapegoats for the 'apparent 10x developer'. - The industry keeps dismantling narratives which would otherwise help to reward talent. For example, many companies dismiss the idea of a '10x developer' - Probably because they are aware of the previous point about the fast developer who cuts corners and creates technical debt for others. 10x developers do exist, but they're not what most people expect because paradoxically, they may be slow coders when it comes to LOC metrics and speed of implementation for new features; their code really only shines in the medium and long run and it improves the productivity of their colleagues too so it's hard to properly allocate credit to 10x devs and they only really matter on greenfield projects.
- zerbinxx 3y ago
  Mega agree with this. It was really bad for my personal/career growth to get a ton of praise for doing things fast: granted, a lot of people doing the praising had precious little experience in tech themselves. I probably have 2-3 whole dead years where I could have been learning/improving a lot more but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned because there was no incentive for anyone but me to maintain it, and who would want to because it was shitty code with hacks and tech-debt, and anything that isn’t writing a fucking mountain of new garbage code gets in the way of shiny star collection.
  - testacct22 3y ago
    > but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned I feel like I've fallen into this hole at my current gig, where I just churn shit out to solve a problem as quickly as possible I get away with it just bc general code quality was already not good to begin with Biggest mistake was going fast the first time, now I'm getting assigned way more shit Word of advice to readers: don't make the same mistake I made. You'll just get taken advantage of
viraptor 3y ago
Just for context for others: This is an extreme description that doesn't match many of the actual jobs. My team/environment is the exact opposite of this, for example. I think parent projected their experience way too far on the whole industry.
siilikuin 3y ago
Reminds me of one of my favorite papers ever: "Nobody Ever Gets Credit for Fixing Problems that Never Happened". https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01... Unfortunately, for my money, I think the only real way you can create an incentive structure which emphasizes stability and change is by offering some kind of form of insurance. My father was an electrician who often complained about how he never got paid adequately for the stellar, stable work he did, and one day I asked him whether he ever thought of raising his rates but providing a kind of service guarantee, where if a problem occurred that could be traced back to his own work, he would step in and perform the additional work at a reduced fee. Naturally he laughed out loud, because that's not how business works. Ownership of an already-mature product is sort of like providing an insurance policy by default, of course. And sticking with conventional designs can be a solid business strategy if you use their slow-changing nature to e.g. build the thing faster than you could otherwise. That's the strategy I'm using for my consulting: Stick with what we know best (Hugo+Bootstrap for a napkin sketch UI demo as fast as possible, then SQLite+Django+React to build out the main functionality ASAP too). Emphasize solving the _business_ problem over the shiny tech.
- mablopoule 3y ago
  I don't know if there is a name for it, but this is a plague for every security-related thing, or any jobs where the more skilled you are, the more people forget you (like a sound engineer for a movie production). An ex-director of a French national security agency complained about exactly that during an interview, that you get more budget after a terrorist attack, or after you stop one that was well under way, but never if you avoided the condition to create a terrorist cell altogether, or nipped it in the bud.
atoav 3y ago
Yet, the people who wrote the minimalist, elegant and usually open source software we all rely on (e.g. sqlite) are highly regarded. All of what you said is true, but there are still people who think a minimalist, rugged and reliable solution is superiour. That maintainability is a value in itself (and thus, one should not choose the wildest, most experimental dependencies).
Cthulhu_ 3y ago
I've been working in consultancy for most of my career and have been in so many projects by now that seemed to be bullshit rewrites in $tech of the month; at least two projects where microservices were pushed through. The last one I was in was funny because while they had a small army of consultants and self-employed engineers vying for influence and carving out their own slice of the pie, the existing team of running, working, earning .NET software was just going about their day. It was quite telling that after 1.5 years of that project, where all staff had already been replaced once, all they had to show for was a fancy product name and a presentation. And that the manager that led the project for ~2 years left right before or right when it went live - and he did that in a previous project too, where a working .NET backend for ecommerce was replaced with a Scala microservices on AWS system. I did hear about the latter; I heard they went back to .NET, but the Scala services are still up and running and a maintenance nightmare. But the lead developer got to play with his favorite tool and landed a job at lightbend because of it. Career-driven development, and I don't even believe he did it for his own career, but for self-gratification. Ecommerce is boring; REST APIs and a front-end are boring. But Scala, distributed systems, AWS, that's all cool and new. I'm so tired.
- liftsh 3y ago
  New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors. I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational. If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).
  - 3y ago
rewmie 3y ago
> No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. This. I recall the case of a couple of FANGs who on one hand expect their engineers to deliver simple, maintainable and robust systems to minimize operational costs, but on the other hand they demand engineers operate at the next level to be considered for a promotion, which means they are expected to design non-trivial systems which have a certain degree of complexity and require significant amounts of work to pull off. Therefore, as an unintended consequence, the pressure inexperienced engineers to push needlessly complex projects where they are required to design solutions well above their level of expertise, and put them in a position where their career is personally threatened if anything gets between them and their promotion-driven project.
brianmcc 3y ago
Not universally true. Just find a manager who values successful delivery of project goals and is fine with "boring" i.e. tried-and-tested technology. I blame Career-Driven Development for a lot of "shiny toy" (i.e. failed and complicated) projects. Whether that's wrong is a deeper question - if it leads to better salary through job-hopping and promotions, despite a catalog of failures, is it actually the wrong approach from an individual engineer perspective? I still say yes, FWIW; I enjoy seeing my projects succeed and thrive. But I know others may disagree.

morning-coffee 3y ago

^ this ^ Until we figure out a nice metric for "removing complexity" and then rewarding for it, it's not likely to change, IMO.

ronnier 3y ago

I really think we have too many people working at most companies. It pushes people to the extremes and edges just to have something to work on. Managers need more people under them to get promotions. And managers want to manage managers to keep moving up. They fill teams of people on products that could really be ran by a fraction of the engineers. But that’s not where we are, we are on large teams working on small areas of the product inventing areas to build in and often ruining the product as a result. We also get slower with so many people. The coordination overhead is killer and losing context as the product is sliced up into small parts that move on without you

sanderjd 3y ago
Yeah I dunno, I hear this a lot, but there has universally been way more work to do than people to do it at every company I've worked for. But that doesn't mean the right things are being prioritized.
- Aeolun 3y ago
  There is a lot of work, but a lot of that work is generated by people doing the wrong thing too often. If we had a smaller and more competent team, the initial build might have been marginally slower, but we wouldn’t have to spend a permanent 50% to just keeping down the technical debt.
  - Denzel 3y ago
    You’re working from a cost-efficiency / cost optimization perspective. That’s a great perspective in some contexts, for example, mature late-stage products, fully saturated markets, etc. Is cost efficiency an effective perspective for innovation or revenue growth? Mostly, no. As long as your risk-of-ruin is low, then you want to fail. Sometimes people misinterpret this as “doing the wrong thing”. But it takes doing a lot of wrong things to do the right thing. The difference between right and wrong, if there ever was such a simple dichotomy, is so marginal and only understood in hindsight.
    - Aeolun 3y ago
      You ask the executive if he wants to get to his goal with a team of 200 after lighting on fire 20M, or with a team of 20 after paying 2M. Ultimately you end up in the same spot, but one choice is fairly suboptimal there.
      - sanderjd 3y ago
        The whole point of the comment you replied to is that, if the "goal" is something innovative rather than just sustaining, then no, you don't end up in the same spot in those two scenarios. But this is why some executives are better for some kinds of businesses and others are better for other kinds. Some executives don't understand your parent comment's point (or just don't find it comfortable), and will be very allergic to the "waste" necessary to experiment and iterate on poorly understood projects. Other executives will be uncomfortable just constantly figuring out how to optimize costs without damaging revenues. A very tricky part of the lifecycle of many companies that get gigantic is to figure out when to flip this and start switching out the executive team to focus on a different model.

pavlov 3y ago

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scientist, an industrial designer, and a product manager with industry experience in the customer domain. The application was Windows native. User research was conducted on site with scientific rigor. Adhering to platform guidelines and conventions was a priority. I think I spent a few weeks redrawing hundreds of toolbar icons so they’d be in line with the Office 97 look (the kind of boring job you give to the junior). If the app stood out on the Windows desktop, that would have been considered problematic. Today a similar design team would only have a graphic designer and a PM, and neither of them would care the slightest about platform guidelines or customer domain. The UI is primarily an extension of the corporate brand. Hiring a cognitive scientist? Forget about it… Everything certainly wasn’t perfect in the Windows/Mac desktop golden era. But the rise of the web wiped out a lot of good industry practices too.

aldanor 3y ago
Today they might have a psychologist on the team to research which buttons may serve as dopamine triggers so you're a lot more likely to upgrade to Premium before thinking it over
- pavlov 3y ago
  Right. Making people click on things they didn’t mean to and buy things they didn’t want — those goals were not even a part of the 1990s UI paradigm.
  - hnlmorg 3y ago
    1990s design was all about preventing people from accidentally doing actions they might not have wanted to. Even down to the “Are you sure you want to quit” dialogues that were all the rage. It’s sad just where we are now compared to the design goals of old.

chillbill 3y ago

I don’t think it’s as easy as you’re making it to seem. The issue is that there are unintended consequences to each one of those points you mentioned. I’m pretty sure a substantial amount of thinking goes into software design from all aspects and it’s a bit reductive to say that it’s just lack of incentive. Humans doing software are not some machine learning algorithm to train with reinforcement learning techniques.

x86x87 3y ago

I call this "the tragedy of software development"

wildekek 3y ago

All of those are absolutely real. There is a lack of economics and a surplus of optics in the game for all players.

voz_ 3y ago

Uber was a massive example of this. The best engineers kept their head down and just tried to keep things afloat, fixing bugs, etc. However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such a way that it only ever encouraged “TL”/“architect”types to grow. This led to constant churn, horrible codebases, and utter bullshit self made problems which could only be solved by digging a deeper hole. There are companies who handle this well. Ultimately it comes down to engineering culture.

nine_zeros 3y ago
The career ladder is among the biggest fuck ups of the tech industry. They incentivize bullshittery more than actual innovation. There are more rewards for BS RFCs than in keeping the ship running.
- gtirloni 3y ago
  I had a completely different view of RFCs before coming into contact with some peers that followed this approach to the letter. RFCs for such small issues would take 10 pages and barely mean anything. Of course they would be praised by upper management (it didn't matter the RFCs would be ignored most of the time).

sirsinsalot 3y ago

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.

kylelahnakoski 3y ago
Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.
- sirsinsalot 3y ago
  In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/... Like most other engineering in the world really.
  - paulryanrogers 3y ago
    IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies. Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
    - 3y ago

marcus0x62 3y ago

And at least at the “enterprise” level for B2B software, there is intense customer demand for more features and, simultaneously, more stability. From my view, that and pressure from the analyst racket are the main drivers behind feature bloat with self promotion a distant third.

yieldcrv 3y ago

and the re-writes have to be in a trendy language that other companies are using, just for the engineer to stay relevant. everything about engineering group decisions are about creating a reason to use a newer framework in a way other people can vouch for.

bluGill 3y ago

There are exceptions to all the above, but only after the worst case burns from failure to do those things. If you are losing customers to competition that doesn't crash, then suddenly you can be the hero by making yours more stable. Of course only if you can do this before the company dies.

bombolo 3y ago

Coworker of mine wrote a thing in java… it was too slow (intensive locking between threads)… so he rewrote it in C… it was crashing all the time (because he sucks), then he rewrote it in go. Got promoted for this feat.

ilyt 3y ago
That's kinda what initally Go was made for IIRC. They noticed people which job is not programming but had to write some code (say some analytics or sth) often did it in Python, and if it was too slow they moved to C or Java and were predictably terrible at it, so that's why Go was made simple and with builtin concurrency primitives.
- bombolo 3y ago
  But his job is programming. He is very proud of his C skills. If you listen to him, it crashed because C is intrinsically bad (it is difficult yes), but I guess it was also such a bad codebase that rewriting it made sense. He also holds a grudge against me for having dared to rewrite a sacred C library he wrote (that was a constant source of segfault and I rewrote in 1 afternoon).
  - ilyt 3y ago
    Sounds more like his job is producing tech debt. I saw few people like that, basically none of their code was left as most of that needed to be eventually replaced coz it was shit.

deleted 3y ago

[deleted]

joshlemer 3y ago

I don't know, the more I advance in my career, the more I see it as the opposite. Wide eyed developers with big designs, who are obsessed with the technical aspects of a solution, who disregard the practicalities, long term implications at the social level (who is going to maintain this, do we have people that have that skillset, is this worth the effort, does it really matter to be this elegant, or is it more important to ship quickly and economically) come off as a bit immature and the more effective engineers who understand these priorities are given more respect and authority.

stuckinhell 3y ago
The problem for a lot of the social level issues is that it is pure pure politics.
gopalv 3y ago
> the more effective engineers who understand these priorities are given more respect and authority. The problem with "given more authority" I see is that management plucks these engineers out to make their day job basically "sit in meetings" if you're even slightly effective at simplifying life for everyone else. Because that is the place of most leverage to place those people, but then those people are in a constant tug-of-war with the first group of "fresh ideas". Eventually, the people who are in charge of the "prevention of bad architecture" become the bad guys because they (or me, I'm projecting) get jaded into just finding out what's wrong with something as fast as possible to be able to keep up with that workload. You go from a creative role to a fundamentally sieve role with destructive tendencies, where you are filtering out the good from the bad as fast as possible, be. First of all, not all new ideas are bad and "there's something bad about X" is not a "let's not do X". Secondly, going from making things to shooting down things is intellectual suffering if you have a bit of empathy. Some people on the "committee" with you don't have empathy & literally enjoy it - you're either trying to damage control on a case-by-case or building a "these assholes need to be fired" doc out of the meetings. I realized what I would become if I conflated authority and respect ("respect my authoritah!"). Quitting was really the only way out of it. But it wasn't hard to explain to my spouse that i needed to leave for a job a level down and which paid half as much, because she could see me bringing my "why the hell do we have to do this" attitude home & to family decisions.

Xen9 3y ago

This kind of problem surfaces in a large amount of systems involving humans and roles.

hinkley 3y ago

There’s a couple of woodworking hand tool companies who among other things make replicas of old school Stanley tools, the way Stanley used to make them (materials and tolerances). They also fuse the best elements of several eras or manufacturers to make slightly better versions. Surfaces from this one, handles from that one, adjustment mechanism from a third. I hope that I live to see a time when software applies modern algorithms to classic designs and produce “hand tools” in software.

Aerbil313 3y ago
The field of software is maturing as we’re reaching the end of Moore’s Law and time passes. Times of constant innovation is very slowly coming to an end, the curve is slowly flattening. You can already see it with general trends like type-safety, DX features universal in all languages (linting etc.), browsers finally becoming the universal OS (Wasm, WebUSB, GPU), more and more things being standardized every day.
- hinkley 3y ago
  Proebsting's Law says compilers double code efficiency every 18 years. I wonder what the doubling interval is for algorithmic performance. I expect it would be tough to calculate, like the cost of living, because algorithmic improvements rarel affect all aspects of code performance equally. Incremental improvements in sorting efficiency likely have one of the broadest reaches, followed by concurrency improvements and object lifetime analysis. Then there's a long tail of niche applications that only apply to certain domains. Only the Amdahl's Law parts of the code has a substantial impact on performance.

segh 3y ago

I'm not sure it's just incentives. Inexperienced early stage founders often end up solving imaginary problems, despite having a real incentive to get it right. The Y Combinator moto is "make something people want" because so many people don't.

sh34r 3y ago

I agree with just about everything you've said, except that bit about rewrites. Rewrite projects typically go down in flames, and on the rare occasions that they don't, the business stakeholders are still mad because their precious feature factory was down for maintenance for months.

Hackbraten 3y ago
> months Please.
whstl 3y ago
I don't think you two disagree, GP is just saying that large-scale rewrites are rewarded, regardless of the result. I've seen that happening even when stakeholders were unsatisfied.

analog31 3y ago

You can still get away with these things if your only user is yourself or maybe a small handful of non-enterprise folks. This could be why the so called "scientific" programmer feels like they can be as productive as a team of 10+ software developers. And also why the most frequent request from the users is: Please don't change anything. The principal-agent problem looms large in software.

hutzlibu 3y ago
"And also why the most frequent request from the users is: Please don't change anything." I think it is: "Please don't change anything I did not request" (who does not hate updates that break your workflow?) But they usually very much like changes, that makes life easier for them. Best way to find out, is to watch them using your tool and talk with them.

rapht 3y ago

You can think of it in even broader terms: being/staying lean, re-using tried and tested things, adapting your requirements to widely available solutions rather than developing custom solutions to fit your requirements, making everything work more efficiently, etc -- all those resource-minimization issues are "less" problems: not good problems to be working on when your raison d'être is "more" -- and that's the only raison d'être for a lot of people and actually for all businesses. (Obviously there are also specialists for doing "less" "more": unsurprisingly, they are generally paid a cut of savings.)

AndrewKemendo 3y ago

I’m going to reference this comment in the future when I build my next software product. Thanks

throw10920 3y ago

They're not mutually exclusive. FOSS software has vastly different incentives than commercial software, yet suffers from many of the same problems: bugginess, poor performance, lack of documentation, feature misprioritization, bad UI. That alone indicates that the problem is not merely "misaligned incentives". Actually, you can reduce most problems down to "misaligned incentives" if you're overly reductive enough. That doesn't mean that it's a useful way to think about the world.

jrockway 3y ago
I think Free Software suffers from the misaligned incentives. Take documentation for example. Why would I write it? I already know how the system works. I designed it! If I forget in a few years, a quick glance at the code will refresh my memory. One would argue that you should write documentation so that people will use your thing. That's true! But there is almost no incentive to have users; you pay a cost, but they pay nothing in return. (Someone will send a bugfix now and again, of course, but it's very very rare.) Some other incentives are balanced, though. Persistent low performance or bugginess affects the author and end users equally; the more the author uses their own software, the more this will hurt. Sometimes the low performance is a design trade off; Python isn't Rust, and the users seem to be okay with that. It was done on purpose. Sometimes low performance is a factor of the author's needs; you're trying to run the thing on 1 billion machines, they only have 1; something has got to give. But that's not misaligned incentives so much as it is lack of suitability for a particular purpose. A screwdriver is terrible for hammering in nails. That's not the screwdriver's fault.
- indymike 3y ago
  > I think Free Software suffers from the misaligned incentives. It's really hard to tell what the motivation of any given free software author is. That makes it really hard to even know what incentives matter to any give author, team or community. It's just really diverse. > That's true! But there is almost no incentive to have users; you pay a cost, but they pay nothing in return. It's fascinating to see free software with huge user bases getting on with a tiny number of contributors. It seems like good code + near zero support cost + near zero support expectation seems to work.

xyzelement 3y ago

Maybe I am biased by my background in finance tech but I saw a ton of guys get rewarded for what (at the time) seemed like boring maintenance of systems. In retrospect - it was recognized that they built or took good care of money making systems with little drama and that was well appreciated by the companies. In FAANGs I see now more of "what will get me promoted" versus "what is gonna make the company money" ethos.

sanderjd 3y ago
Promotion driven features are definitely not entirely a myth IMO, but on the other hand, anecdotally I saw quite a few people get promoted at Google for doing make-things-work-better work. The trick was figuring out which were the important things to maintain and make small improvements to, rather than just which were the things that seemed fun to tinker with, but weren't as impactful.
throwaway2037 3y ago
"finance tech" -- those people maintaining those systems are middle-aged, comfortable, and well-paid. If you were junior under them, you would never want to stay. Fifteen years ago, there were large fresh hire classes each year. Tons of juniors around the office. Plenty of young ones dreaming up unnecessary "upgrades". Most of that is gone as the industry has matured. If anything, the hoards of junior hires have moved from finance to Big Tech.

llanowarelves 3y ago

I like that it's this way so we can easily compete with these dysfunctional companies. Don't fix them :)

tzhenghao 3y ago

"Show me the incentive, I'll show you the outcome." - Charlie Munger

woah 3y ago
Isn’t he the guy who tried to get a university to build a giant windowless dormitory cube?
- zimpenfish 3y ago
  I mean, he's not wrong though - the incentive was "University gets a large amount of cash" and the outcome, predictably, was "University bends over backwards to accommodate insane requests of donor". (The correct solution, obviously, is that universities should be sustainably state-funded and not require mega-donors with their associated insanities, etc. to survive.)
- pphysch 3y ago
  Still don't understand the opposition to that. Students get affordable, safe, private housing on campus, where there's a million places to hang out beyond your windowless bedroom. Libraries, open spaces, study halls, cafes. The alternative is often paying $1K for some barely maintained triplex basement shared bedroom off of campus, from a negligent landlord.

mattgreenrocks 3y ago

Definitely. I’ll say one thing though: all of those skills you mentioned as not being valued are extremely useful for indie dev/taking ownership. Shipping simple + correct code frequently is extremely possible with sufficient practice and discipline. More to your point, this is why I switched toward being a research engineer. There is a higher barrier of entry, projects are quite technically challenging, and constraints often force thinking of a world of computing beyond the tiny sphere of the web browser. It’s hard work, but I love it. If this resonates, you are in the US, and looking for a change, drop me a note (see profile).

sanderjd 3y ago

I don't think these "No"s are entirely right, though they are directionally right. But there are actually healthy businesses (and healthy divisions within less healthy businesses) out there that do incentive those behaviors, and it's a huge competitive advantage for them.

sheepscreek 3y ago

How do companies keep pushing their quarterly numbers higher and higher? By manufacturing innovations! Welcome to 21st century capitalism.

bbor 3y ago

Just want to throw out a way we could align everyone’s incentives: a robust universal economic safety net. If people were working to make a good product rather than stop their children from starving, our natural inclination to take pride in our work would be allowed to flourish. Not gonna convince anyone but hopefully someone reads this and starts thinking about such options. They are not as impossible as those in power would have us believe.

jongjong 3y ago

With developers, incentive misalignment is just insane at all levels. - There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design). - There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far more important). The costs of this tends to fall on other developers who come in later and act as scapegoats for the 'apparent 10x developer'. - The industry keeps dismantling narratives which would otherwise help to reward talent. For example, many companies dismiss the idea of a '10x developer' - Probably because they are aware of the previous point about the fast developer who cuts corners and creates technical debt for others. 10x developers do exist, but they're not what most people expect because paradoxically, they may be slow coders when it comes to LOC metrics and speed of implementation for new features; their code really only shines in the medium and long run and it improves the productivity of their colleagues too so it's hard to properly allocate credit to 10x devs and they only really matter on greenfield projects.

zerbinxx 3y ago
Mega agree with this. It was really bad for my personal/career growth to get a ton of praise for doing things fast: granted, a lot of people doing the praising had precious little experience in tech themselves. I probably have 2-3 whole dead years where I could have been learning/improving a lot more but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned because there was no incentive for anyone but me to maintain it, and who would want to because it was shitty code with hacks and tech-debt, and anything that isn’t writing a fucking mountain of new garbage code gets in the way of shiny star collection.
- testacct22 3y ago
  > but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned I feel like I've fallen into this hole at my current gig, where I just churn shit out to solve a problem as quickly as possible I get away with it just bc general code quality was already not good to begin with Biggest mistake was going fast the first time, now I'm getting assigned way more shit Word of advice to readers: don't make the same mistake I made. You'll just get taken advantage of

viraptor 3y ago

Just for context for others: This is an extreme description that doesn't match many of the actual jobs. My team/environment is the exact opposite of this, for example. I think parent projected their experience way too far on the whole industry.

siilikuin 3y ago

Reminds me of one of my favorite papers ever: "Nobody Ever Gets Credit for Fixing Problems that Never Happened". https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01... Unfortunately, for my money, I think the only real way you can create an incentive structure which emphasizes stability and change is by offering some kind of form of insurance. My father was an electrician who often complained about how he never got paid adequately for the stellar, stable work he did, and one day I asked him whether he ever thought of raising his rates but providing a kind of service guarantee, where if a problem occurred that could be traced back to his own work, he would step in and perform the additional work at a reduced fee. Naturally he laughed out loud, because that's not how business works. Ownership of an already-mature product is sort of like providing an insurance policy by default, of course. And sticking with conventional designs can be a solid business strategy if you use their slow-changing nature to e.g. build the thing faster than you could otherwise. That's the strategy I'm using for my consulting: Stick with what we know best (Hugo+Bootstrap for a napkin sketch UI demo as fast as possible, then SQLite+Django+React to build out the main functionality ASAP too). Emphasize solving the _business_ problem over the shiny tech.

mablopoule 3y ago
I don't know if there is a name for it, but this is a plague for every security-related thing, or any jobs where the more skilled you are, the more people forget you (like a sound engineer for a movie production). An ex-director of a French national security agency complained about exactly that during an interview, that you get more budget after a terrorist attack, or after you stop one that was well under way, but never if you avoided the condition to create a terrorist cell altogether, or nipped it in the bud.

atoav 3y ago

Yet, the people who wrote the minimalist, elegant and usually open source software we all rely on (e.g. sqlite) are highly regarded. All of what you said is true, but there are still people who think a minimalist, rugged and reliable solution is superiour. That maintainability is a value in itself (and thus, one should not choose the wildest, most experimental dependencies).

Cthulhu_ 3y ago

I've been working in consultancy for most of my career and have been in so many projects by now that seemed to be bullshit rewrites in $tech of the month; at least two projects where microservices were pushed through. The last one I was in was funny because while they had a small army of consultants and self-employed engineers vying for influence and carving out their own slice of the pie, the existing team of running, working, earning .NET software was just going about their day. It was quite telling that after 1.5 years of that project, where all staff had already been replaced once, all they had to show for was a fancy product name and a presentation. And that the manager that led the project for ~2 years left right before or right when it went live - and he did that in a previous project too, where a working .NET backend for ecommerce was replaced with a Scala microservices on AWS system. I did hear about the latter; I heard they went back to .NET, but the Scala services are still up and running and a maintenance nightmare. But the lead developer got to play with his favorite tool and landed a job at lightbend because of it. Career-driven development, and I don't even believe he did it for his own career, but for self-gratification. Ecommerce is boring; REST APIs and a front-end are boring. But Scala, distributed systems, AWS, that's all cool and new. I'm so tired.

liftsh 3y ago
New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors. I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational. If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).
- 3y ago

rewmie 3y ago

> No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. This. I recall the case of a couple of FANGs who on one hand expect their engineers to deliver simple, maintainable and robust systems to minimize operational costs, but on the other hand they demand engineers operate at the next level to be considered for a promotion, which means they are expected to design non-trivial systems which have a certain degree of complexity and require significant amounts of work to pull off. Therefore, as an unintended consequence, the pressure inexperienced engineers to push needlessly complex projects where they are required to design solutions well above their level of expertise, and put them in a position where their career is personally threatened if anything gets between them and their promotion-driven project.

brianmcc 3y ago

Not universally true. Just find a manager who values successful delivery of project goals and is fine with "boring" i.e. tried-and-tested technology. I blame Career-Driven Development for a lot of "shiny toy" (i.e. failed and complicated) projects. Whether that's wrong is a deeper question - if it leads to better salary through job-hopping and promotions, despite a catalog of failures, is it actually the wrong approach from an individual engineer perspective? I still say yes, FWIW; I enjoy seeing my projects succeed and thrive. But I know others may disagree.