[HN Gopher] A student asked how I keep us innovative - I don't
___________________________________________________________________
A student asked how I keep us innovative - I don't
Author : SerCe
Score : 181 points
Date : 2023-10-10 12:00 UTC (11 hours ago)
(HTM) web link (ntietz.com)
(TXT) w3m dump (ntietz.com)
| kubb wrote:
| This post seems to be mistaken in its understanding of
| innovation. It seems to take it as using new technologies. But
| this is a misunderstanding.
|
| Innovation means inventing novel solutions that solve relevant
| problems better than what has been known before. This could be
| creating a new tech, and using it, but it could also be applying
| existing tech in a novel way.
|
| So you could be innovative using old technology, and you could
| use new technology, but not be innovative.
|
| I guess the company where the author of the post works is neither
| innovative, nor do they use new technology, but there's space on
| the market for companies like that. Principal engineers who work
| there don't even need to know the meaning of innovation.
| mattgreenrocks wrote:
| IMO, most people don't want to be working on innovative things,
| despite what they say. It is brutally hard sometimes, and you
| have to be okay with being alone to figure things out in your
| own.
| mlindner wrote:
| This is a great answer if the thing you're building isn't
| innovative. If it's just a nodejs storefront site. However it's a
| pretty garbage answer if you're say trying to create a new thing
| that's not been seen before.
| xnx wrote:
| Very sound advice. It's amazing how many projects never identify
| what problem they're trying to solve, or lose track of it
| immediately to focus on the technology.
| mysterydip wrote:
| "our project is just like x but written in y!"
| sublimefire wrote:
| "it is very easy use, I wrote it in a week"
| reactordev wrote:
| >"Now reduce down the solution"
|
| I love this part. This is the validation after proof that you
| indeed, solved the correct problem. Because if you can't shave
| away the complexity to the underlying problem and "get to the
| heart of it" then you didn't solve the problem yet. You merely
| handled its edge-cases.
| datadrivenangel wrote:
| The bleeding edge is called the bleeding edge, because you risk
| cutting yourself on it!
|
| Innovation can be good, but you have to understand the
| risk/reward profiles.
| atomicnature wrote:
| However, isn't innovation usually about building something
| exciting from output perspective, rather than about the building
| materials? We want the most reliable building materials, but how
| you put them together to get novel functionality, or other
| desirable characteristics at a higher level is what makes a
| system innovative.
| [deleted]
| ngrilly wrote:
| I am a proponent of "choosing boring technologies", but I don't
| see how it relates to building innovative products and services.
| You can create an innovative product or service using boring
| technologies under the hood. I really like the post otherwise.
| feoren wrote:
| I think the article is a good response to the question the
| student asked, though:
|
| > "As a principal engineer, how do you make sure your company
| stays at the forefront of innovation?"
|
| This is most likely about using all the shiny new technologies
| in a rapidly changing "forefront of innovation". The article
| simply isn't about building innovative products and services.
|
| Of course, choosing boring technologies is one of the ways that
| you can help save engineering brain-cycles for the actual
| innovative core product or service you're building.
| js8 wrote:
| Yeah, I favor a slightly different rule. Choose a conservative
| technology in places which are not a core competency of your
| new product. Building a new product is risky, and you should
| minimize the additional risk coming from a technology choice,
| except the parts where you're actually trying to beat the
| competition. That should be the focal point of innovation.
| ngrilly wrote:
| Totally agree. That's why I like the notion of "innovation
| tokens", also mentioned in the seminal post "Choose Boring
| Technologies" [1]. You choose boring technologies for
| everything, except for a few topics that will differentiate
| your solution, where you get to spend your "innovation
| tokens".
|
| [1] https://mcfunley.com/choose-boring-technology
| bdcravens wrote:
| As most companies aren't pure tech, usually the core
| competency isn't the software itself. Sometimes when it is,
| it's hidden away (for instance, background processing of
| data) and the best thing you can do is keep as easy to reason
| about as possible.
| bdcravens wrote:
| It also applies to trying to avoid being clever with the tech
| you choose.
| mattgreenrocks wrote:
| Younger devs conflate tech choices with innovation.
|
| They'll believe that a computer vision company is a dinosaur
| because they're using C++ and a glorified CRUD startup is hip
| and relevant because it uses Rust. It doesn't help that the
| anemic-ness of some domains doesn't set in until 1-2 years
| later.
| BlackFly wrote:
| I agree that novel technical choices are often conflated with
| innovation over eagerly. My experience is that in learning
| the lesson that these things are different many people over
| correct and assume that novel technical choices are only ever
| resume padding or useless hype.
|
| There are no silver bullets and the only way to get an order
| of magnitude improvement is iterated marginal improvements.
| That something is at best a marginal improvement shouldn't be
| taken for a lack of innovation.
| kritr wrote:
| Using newer technologies sometimes buys development velocity,
| which is a good indication of innovation.
| LtWorf wrote:
| Or it makes development slower due to lack of
| documentation, support, and libraries for the chosen
| technology.
| innagadadavida wrote:
| The tearoom is ask is "Can I hire an average software engineer
| with 2-5y experience who'll will have no problems keeping this
| running 99.999% of the time while doing development and
| deployments?
| Justsignedup wrote:
| Well put, and is a great read for people to understand the
| fundamentals of leading an eng team. What sort of thinking goes
| into it. I feel like this perfectly explains how I need to think
| on a daily basis.
|
| Lead engs are about bringing order to a chaotic eng process.
| __xor_eax_eax wrote:
| Meh. Reading the techniques behind the giant GCloud DDoS before
| this, if you're not understanding the latest and greatest
| technology and you're attackers are, you're going to be
| victimized.
|
| To me this sounds like a stogy old grey-hair being defensive
| about why its okay to be obsolete. Its not
| dvas wrote:
| Socialize the design: _" Find people who you think will be
| contrarian, and have them poke holes in the design"_
|
| Happy to see this mentioned! By involving everyone, the
| experienced engineers will usually ask the harder questions and
| test the assumption of your design and the juniors to learn and
| re-evaluate assumptions they have about building software. Almost
| a win-win for everyone.
|
| Even though in these discussions there may be a social aspect
| where certain individuals are trying that much harder to find
| disadvantages of a proposed design (many reasons which readers
| are probably familiar with). However, I think this becomes a net
| positive to the overall engineering as everyone tries to bring
| their A-game to these discussions.
|
| Anyhow, my experience has been that collectively reasoning about
| a design (assuming the team feels comfortable with criticism)
| will always get results quicker.
| EdgeExplorer wrote:
| Unfortunately a lot of contrarian people think "it wasn't my
| idea" is a hole in a design even if they would never say it.
| indigochill wrote:
| Not a problem if they don't say it since then it's not
| derailing the conversation. It could even be a benefit if it
| motivates them to look for actual holes.
| convolvatron wrote:
| you just have to refuse to accept input like 'I don't buy
| it', 'I tried something like that before and it was a
| failure', 'thats a code smell', 'I saw a blog post about
| how that is an anti pattern', and other unsubstantiated
| disses on an approach. if its so bad, you should really be
| able to put some real words behind that.
| kjkjadksj wrote:
| Seems like that would invite armchair engineering like you seen
| in HN comments. "Couldn't you just do the easy and obvious
| thing?" The answer is probably a long no and the creator had
| your thought already before realizing the true scope of the
| work.
| delusional wrote:
| I find this pretty easy to deal with. You just don't engage
| with that question. Make it clear to the people you are
| discussion it with what kind of things you want input on
| (architecture, design, product market fit), and make it very
| clear when you consider their input out of that scope. People
| will very quickly learn what sort of comments you care about.
|
| This form on "collective design" usually uses a
| confrontational form of rhetoric, but the exercise is very
| much collaborative.
| 8note wrote:
| That's great stuff to include in your design doc, at least on
| an appendix
| ar_lan wrote:
| It's definitely double-edged. The main thing I've learned
| regarding this is to clearly document this answer somewhere,
| very early on.
|
| I recently learned this because I was asked this precise
| question and basically had to drudge up all my two-quarters-
| ago research that was the answer to this question. My answer
| to their question was "yes we could do the easy thing,
| but..." and everything trailing the "but" is a very long
| string of small points that add up to something that tipped
| the scale (at least in my and several other folks opinions).
| But without that laid clearly out they thought I was just
| over-engineering for the sake of job security or something
| like that.
| reactordev wrote:
| Without proper management, you're correct. It would. I would
| retort, never start a sentence with a negative. Find
| something you do agree upon, make comments about the stuff
| that you do like, before going into the details of what you
| don't. This way it's clear where those boundaries are and in
| what context the disagreed design would need changing, if
| any. This also prevents brilliant jerks from completely
| destroying the confidence of others to even present designs
| to the group. Yes, it's a little showy, using more words than
| are necessary, but it keeps the human aspect of agreement and
| cooperation in-tact.
| Jensson wrote:
| > I would retort, never start a sentence with a negative.
|
| "Could you do the easy and obvious thing?" means the same
| thing, I don't see how it makes a difference.
| reactordev wrote:
| Easy and obvious are subjective.
| ozim wrote:
| I believe parent was more into "could you do xyz?" Where
| xyz is easy and obvious thing, but no one would
| explicitly phrase it exactly like "could you do easy and
| obvious thing?".
|
| This way proposing xyz as a solution is positive not a
| negative.
| _jal wrote:
| >"Find people who you think will be contrarian, and have them
| poke holes in the design"
|
| Socializing the design is good advice.
|
| Seeking out contrarians is not.
|
| It costs you much more to defend particular engineering
| tradeoffs than it does to raise questions about them. So unless
| you have a good relationship with your "contrarian" and they
| will operate in good faith, you'll quickly end up exhausted and
| dispirited after the anklebiters attack.
|
| Architecture astronauts and other armchair engineers will suck
| up all your energy with half-baked ideas they aren't even
| invested in, if you let them.
| ska wrote:
| Contrarian probably isn't the right term, but there is real
| value in having someone come at the problem with a different
| set of blinders than you have - particularly if they
| understand their role is not to redo the design but to stress
| test the existing one. I suspect this is what you mean by
| "good faith" and "good relationship".
| reactordev wrote:
| it's a win-win-win. Win for the seniors to ask the harder
| questions and make sure there's alignment. Win for the juniors
| who learn and re-evaluate assumptions and bias. Win for the
| business because they get the best design (at the time, with
| the resources on hand) for the ask.
|
| It's important to make sure that folks who are doing the work,
| agree upon the work. Building a bridge only works if the
| engineers are building a bridge, not a suspended walkway of
| dubious quality because they didn't like the design so some
| wood and rope is what you got.
| atoav wrote:
| Important additional requirment: _do not_ have a manegerial
| class that will throw all reasoning of those on the ground out
| of the window and demand it to be done a certain way.
|
| I had a boss like that once. He could literally turn everything
| into shit. You had a good plan for an event room, he strikes
| everything useful out for "minimalism" and aesthetics reasons.
| Then they ended up with a room that was both expensive and
| unusable. No wall sockets pure concrete ceiling ("to show the
| carrying structure"), a reverb time worse than in a church.
|
| For him it was always looks above literally everything else, no
| matter if it was about architecture, furniture, tools or
| graphic design. And he had the habbit of impulsively demand
| changes after months of planning, as soon as things started to
| take shape. Horrible.
| paulryanrogers wrote:
| The Jony Ive school of management?
| charlie0 wrote:
| The issue I see here is that being a contrarian is not enough.
| In order to drive change, one must also have influence. It
| doesn't matter how good a design is if others are not quick to
| agree with it.
| intelVISA wrote:
| Can be a tough act to balance in reality: "assuming the team
| feels comfortable with criticism" is where this well-meaning
| process falls over in most shops.
| yndoendo wrote:
| One of the best design evaluation methods I found was to
| teach and train others on the products. Occasionally doing
| onsite project installations was a good feedback loop. I
| wouldn't let them know I was a principal designer. Would sit
| back and see how well they grasped the design and constantly
| take notes on how to improve it.
|
| I want criticism about the designs. Tell me where you think
| the product is junk and why. There is not one user but many
| users you are designing for in a single product. Each has an
| unique take and requirements. Features to sell it, those that
| write the checks, and those that use it daily must both be
| met.
| Exoristos wrote:
| If your shop is full of grown children, like this, then, face
| it, you're doomed regardless.
| convolvatron wrote:
| so much discussion around software engineering these days
| is based on infantilization and making sure you get
| _something_ out of your fundamentally dysfunctional team.
| its pretty disheartening.
| Pannoniae wrote:
| Isn't what agile/scrum literally is? Or "equaliser"
| languages like Go? Both a trained monkey and a senior
| engineer will be equally mediocre in using it. Zero room
| for improvement.
| mattgreenrocks wrote:
| Individual programmer skill is seen as taboo to discuss
| despite it having a huge impact on project outcomes.
| mattgreenrocks wrote:
| Absolutely. It's a toxic, nihilist mentality that leaks
| into tools that greatly influence how we think.
|
| Bad programmers are an organizational failure. You cannot
| fix that with tools.
|
| You can make it easier for devs to fall into a pit of
| success, however. But, it's fine line between
| facilitating that versus foisting things on users under
| the guise of being "opinionated." The reality is it is
| often taken to be patronizing, such as views of nextauth
| on storing local usernames and passwords.
| anotherhue wrote:
| I keep waiting for the O'Reilly book "Agile: Managing
| Mediocrity".
| lfowles wrote:
| I've observed it used as a great way to shut down projects
| that don't immediately have demonstrable results
| ska wrote:
| > is where this well-meaning process falls over in most shops
|
| I would argue that if you have this problem, it is
| fundamental, and your team will never be firing on all
| cylinders until you fix it. Admit it is not easy if the
| dysfunction is well set in.
| saulpw wrote:
| Great, but then how do you fix it, how long will that take,
| and how do you get any work done until then?
| ska wrote:
| Incrementally is the answer to most of your concerns, but
| the specifics will depend a lot on context. More
| concretely, this is bread and butter stuff for
| engineering leadership. I mean that in the broad
| (including experienced staff) sense, not hierarchically.
| a1o wrote:
| > On my personal projects, I will usually go with whatever sparks
| joy.
|
| I think this is the right thing for personal projects. I think
| throwaway toy projects should be free to go that route too.
| sublimefire wrote:
| I like to think about it like R&D in a company. You do not
| spend all of the budget on it but just some part, like 15%.
| Similarly you try out new things and spend some time on it,
| like 15%.
| sdoering wrote:
| I agree. I once built a small weather application that changes
| the background image based on the weather being reported.
|
| I wanted to understand single page applications a bit better
| and just decided to do it in Vue. Had never done anything
| bigger than a bit of web tracking in JS before. So it was quite
| a fun experience. I still sometimes enjoy using it (it is still
| running and available, so I like to visit it like sn old
| friend).
| Joel_Mckay wrote:
| Thank you for being honest with the kid, as a lot of folks
| exploit peoples inexperience for financial reasons as policy.
|
| In general, there are a few assertions people make:
|
| A. The industry always changes
|
| B. The industry always follows the same trend
|
| Both are incorrect, but rather the truth floats somewhere between
| the two.
|
| A better question is often "what skills will offer long-term
| fiscal utility?"
|
| The answer to that utility question exposes the dirty side of the
| tech industry:
|
| 1. is the concept an orthogonal theme from purely Academic or
| Commercial Marketers? If Yes, than the probability it will still
| be around in 2 years is vanishingly small.
|
| 2. is the role occupied by Senior staff over 35 at more than 6
| firms? No, than the probability of redundancy increases
| exponentially with time, as the skill demand is under artificial
| supply manipulation due to wage suppression, regulatory capture,
| and or tax incentives refactored into a subsidy.
|
| 3. what is the average ratio of staff with the skill still
| present at firms over 3 years? if less than 5%, than the roles
| still fall under churn-and-burn economics, and at some point the
| stock valuation bump will need ritualistic HR sacrifices. if over
| 90%, than a roles true value is marginal, and will be bid down in
| pay over time.
|
| 4. An "award for the worlds smartest sucker" is not a certificate
| that will hold value. Anyone that claims they know what will
| happen in 5 years is a fool selling something like nonsense
| vendor certifications, media packages, and or political rhetoric
| (STEM etc.)
|
| 5. Does the skill require physical presence? No, than the law of
| outsourcing bids down skill value over time due to irrational
| competitors.
|
| 6. Integrity in whatever you choose to do is important regardless
| of the role. For example, someone using an emotionally charged
| subject in an 72% LLM generated article will antagonize the wrong
| people eventually.
|
| 7. Copying what others do... often means one will land in second
| place... or worse.
|
| Good luck out there, =)
| taylorbuley wrote:
| I feel this. But at the same time, there are these unproven
| toolchains that just feel right and I am OK adopting them.
| GraphQL is one today. React (and before it, Backbone.js) before.
| Hell, even CoffeeScript. Angular 1.0 was one thing, but I don't
| regret a single one of those other implementations.
| tikhonj wrote:
| Another "use popular tech because it's popular" article dressed
| up as engineering wisdom. "Nobody gets fired for choosing IBM"
| isn't supposed to be aspirational!
|
| The most effective organizations I've seen have been the ones who
| are the most willing to both use "non-standard" technologies
| _and_ develop their own tools in-house. There 's a question of
| causation--are they more effective because they're open-minded,
| or do they get away with weird choices because they're more
| effective?--and, from what I've seen, it's a bit of both. But
| I've absolutely seen, first-hand, that top-down standardization
| on enterprise "best practices" is absolutely _not_ a recipe for
| anything beyond passable mediocrity. If anything is a sign of
| weak engineering leadership, it 's that.
|
| I'm not saying that a team should use different technologies _for
| the sake of using different technologies_ , I'm saying that
| strong engineering leadership means having a clear technical
| vision and culture where the popularity of a tool is very low on
| the list of considerations when choosing what to use.
| [deleted]
| pdonis wrote:
| _> "use popular tech because it's popular"_
|
| ...is not what the article is saying. It's saying that you
| should use _boring_ tech when it is sufficient to get the job
| done that you need done. "Boring" is not the same as
| "popular"; indeed, "popular" is often skewed by hype about the
| latest shiny new toy. "Boring", as it is used in the article,
| just means "does job X and is proven by much experience to work
| for that purpose".
|
| _> I 'm not saying that a team should use different
| technologies for the sake of using different technologies_
|
| And this is the same point the article is making. The article
| is saying you should only use different technologies to the
| extent that you have to to get the job done that you need to
| get done.
| tikhonj wrote:
| "Boring" inevitably means "popular" in these
| discussions--"popular" in the sense of "mainstream" and
| "widely used" rather than "trendy" or "hyped", but it's still
| a popularity contest at the end of the day.
| jf22 wrote:
| I have never encountered a scenario where "boring" meant
| "popular".
| ska wrote:
| > "Boring" inevitably means "popular" in these discussions
|
| No it really doesn't.
|
| In this context it means something more like: we know this
| approach has been successfully shipped hundreds of times
| for similar use cases. There may be warts, but they are
| known, and it will work.
| pdonis wrote:
| _> "Boring" inevitably means "popular" in these
| discussions_
|
| Not the way the article is using the term "boring", or the
| way the post I responded to was using the term "popular".
|
| "Boring" means choosing the tech on the basis of it being
| proven to work by much experence. That is what the article
| is advocating doing _unless_ the boring tech simply won 't
| do the job you need it to do. The "boring" tech might well
| also be popular, but that is irrelevant to what the article
| is saying because the tech is not being chosen for its
| popularity, it's being chosen for its technical capability.
|
| "Popular" means choosing the tech on the basis of its
| popularity. That means not even looking at whether the tool
| meets technical requirements. That is what the post I
| responded to was describing, and arguing against. But the
| article is not advocating _for_ doing this, so arguing
| against it is not arguing against the article at all.
|
| _> it 's still a popularity contest at the end of the
| day._
|
| Not if the criterion is technical merit. See above.
| BlackFly wrote:
| The person you responded to is using a different definition
| of popular than you are.
|
| Popular: 1. Widely liked or appreciated. 3. Of, representing,
| or carried on by the people at large.
|
| In the phrase, "use popular tech because it is popular" you
| should think of the latter definition: carried on by the
| people at large. Hence the comparison to "Nobody got fired
| for choosing IBM." Instead some people decide to call this
| "boring" technology and you have a movement of people trying
| to make boring choices glamorous that the person you are
| responding to is lamenting. The article is saying to use
| popular technology (definition 3 above) because of the
| implications of "at large".
|
| Pragmatically, the folklore isn't helpful. Choosing boring
| technology and then building an ad hoc layer on top of it
| compared to using a cutting edge off the shelf solution for
| the problem at hand shouldn't be an easy decision based on
| engineering folklore. The difficulty is often in seeing that
| your actual problem is well adapted (never perfectly) to a
| particular novel technical choice and compounding that is the
| difficulty of knowing about the novel technology and what
| problem it is actually adapted to solving. Hence the need for
| technical vision and understanding of the problem.
| pdonis wrote:
| _> The person you responded to is using a different
| definition of popular than you are._
|
| No, he's conflating "popular" as he uses the term with
| "boring" as the article uses that term, which, as I
| explained, is not valid. As the GP uses "popular", I
| _agree_ that tech should not be chosen because it is
| "popular"; see my response to tikhonj's follow-up post. But
| as I noted in that response, the article is not arguing
| _for_ choosing tech because it is "popular" in that sense.
|
| _> The article is saying to use popular technology
| (definition 3 above) because of the implications of "at
| large"._
|
| No, the article is saying that you should not even _care_
| whether tech is "popular" in any of your senses; you
| should choose tech based on whether it _does the job_ that
| you need done based on much prior experience. I.e., based
| on technical criteria, not popularity (in any sense).
|
| The article does imply that tech that does the job you need
| done based on much prior experience will be "popular" in
| your sense 3, but that does not mean it is telling you to
| _choose_ the tech based on popularity.
| kelsey9876543 wrote:
| The author makes a horrible assumption themselves right in
| their opening argument that "most of the things you are trying
| to do have been done already". How is a business going to find
| value copying and pasting sql solutions from stack overflow as
| honestly suggested by the article author? Horrible advice, pick
| the correct tool for the job, sometimes that tool is brand new
| because you are doing something brand new. The author
| completely avoids the real question which is how to select what
| new technology to use by saying only choose old technology.
| blincoln wrote:
| It is not a horrible assumption for the vast majority of
| developers.
|
| Even if the business they're supporting is doing something
| genuinely new (and IMO that's rare), most of the software
| written for that business is almost certainly going to do
| something similar to a bunch of existing software.
|
| ChatGPT's Vision add-on is able to do things like generate
| code for a web dashboard from a screenshot of a mockup
| because nearly every web dashboard is extremely similar
| except for the branding and labels on the data/elements.
|
| Most developers working for a business are writing that kind
| of code. It's the dev equivalent of hiring an architect and
| contractor to build a house. The result may very well be
| unique overall in some way, but nearly all of it would be
| based on well-tested designs and components. Most people
| wouldn't want the contractor to fabricate custom roofing
| panels out of recycled Russian submarine titanium, because
| even though it might have a "wow" exotic factor and some
| tangible benefits, having maintenance done on it would be a
| nightmare, and there are likely to be surprises no one
| considered because it was the first house to use them.
|
| Software is even worse in some ways. I've seen complex
| products built on flash-in-the-pan frameworks of the moment
| that ended up with problems so close to the foundation that
| fixing them would require a complete rewrite or forking the
| (now unsupported) framework and making low-level
| architectural changes there. At least with a titanium roof,
| the worst-case scenario is having to replace the entire roof.
|
| There's some audience bias here, because people who read
| Hacker News are more likely to be working for startups that
| do something genuinely new, and _maybe_ even writing code
| that does something genuinely new, but IMO it 's still not
| very common.
| marcosdumay wrote:
| I'd bet the people programing the LHC detectors have plenty
| of their problems already solved in Stack Overflow.
|
| If most of the things you are trying to do were never done,
| you will never achieve anything, with complete certainty. Not
| even if you are trying to make art.
| turtlebits wrote:
| Disagree - everything novel has been done already. Technology
| at its basic form is moving/transforming data. Too many
| engineers fall into the trap of chasing what's new.
| scubbo wrote:
| A relevant slideshow (with captions):
| https://boringtechnology.club/
|
| You can tell it's getting old because it used Phony Stark as a
| symbol for innovation, but the underlying message is timeless.
| sublimefire wrote:
| Totally, if you want to solve the problem you do not want to
| create more problems by solving it. Great slides and captions
| BTW.
|
| Nothing pisses me off more that to maintain two stacks at the
| same time - the good and the bad. The bad one was enough.
| garba_dlm wrote:
| > if you want to solve the problem you do not want to create
| more problems by solving it.
|
| but if, in contrast, what you want to create is a business
|
| then it's easy to argue you actually DO want to create more
| problems; partially so you can "solve" them in "the next
| version" (or something); this way your "customers" (which
| really are looking more like victims) can have a real
| motivation to upgrade; to buy the next version, to keep on
| being "valued customers"
|
| this is why making tech products used to be very different
| from making consumable goods (e.g. food); right up until all
| businesses turned into subscriptions businesses and other
| kinds of rent-like schemes
| GrumpyYoungMan wrote:
| Solid article. The one quibble I have is IMO that there should be
| mention that, when the choice is made to use an untried
| technology, it needs to be acknowledged and communicated that
| this carries some level of risk and an increased chance of not
| meeting the project goals.
| jackblemming wrote:
| Not interested in hearing people parroting the boring technology
| mantra over and over. Maybe say something novel for once. Also
| maybe choose technology based on pragmatic metrics, not how old
| it is. "Choose boring technology" is like MBAs saying "we're data
| driven".
|
| And I guarantee if we look at this persons tech stack it's
| probably slathered with a bunch of shiny new AWS crud that's "web
| scale".
| stouset wrote:
| > "Choose boring technology" is like MBAs saying "we're data
| driven".
|
| This is so true.
|
| "Choose boring technology" is also used to post-hoc justify
| whatever choices you've already made. To many, golang is boring
| and Rust is unproven. To others, both are unproven and C/C++
| are boring. Who's right? Everyone and no-one.
| tikhonj wrote:
| C is boring in the same way that weaving through traffic at
| full speed on a motorcycle is boring--people have been doing
| it forever and some of them haven't even gotten hurt by it...
| willcipriano wrote:
| Would you consider a different pattern, woven on a old loom a new
| technology?
|
| A app is not a "new technology". A microprocessor is a technology
| and the code you run on it is just another pattern on the loom.
| terminous wrote:
| > Would you consider a different pattern, woven on a old loom a
| new technology? A app is not a "new technology". A
| microprocessor is a technology and the code you run on it is
| just another pattern on the loom.
|
| It's not useful to get pedantic about the definition of a "new
| technology." What is your point? Take the example cited in the
| article about deciding whether to store your data in SQL
| databases, vector databases, or blockchains. Are you saying
| that this is a purely aesthetic choice and not a choice that
| bakes in a lot of other patterns and decisions?
| willcipriano wrote:
| It's a different mindset once you start thinking in those
| terms. Inventing a new technology sounds impossible but
| writing some code isn't difficult. You'll be less likely to
| get paralyzed daydreaming about the lofty future of this new
| technology if it's just some code that can be thrown away at
| any time for something better.
|
| When we list humanities technological inventions a century
| from now, I don't think we will be listing CockroachDB or
| similar.
| terminous wrote:
| > it's just some code that can be thrown away at any time
| for something better.
|
| That's exactly what the author is arguing against.
| Decisions about foundational infrastructure (frameworks,
| databases, programming languages) have consequences for the
| organizations that decide to use them. Switching costs can
| be high. Lock-in of all kinds is real.
|
| > When we list humanities technological inventions a
| century from now, I don't think we will be listing
| CockroachDB or similar.
|
| That isn't at all what I or the author of the article was
| saying.
| willcipriano wrote:
| In this use, sometimes technology will upgrade itself
| with new technology that uses technology to prevent the
| users from doing things the technology previously had the
| technology to do, but it no longer has the technology due
| to the technology that was downloaded and installed on
| the technology in the user's closet.
| MattPalmer1086 wrote:
| Everything is built on top of other stuff. Surely a micro
| processor is just a product made using chip fabrication
| technology? Which itself is just a commoditised production
| method based on other... err... technologies.
|
| You could pick another word at some arbitrary level, but I'm
| not sure it's a particularly useful distinction to draw.
___________________________________________________________________
(page generated 2023-10-10 23:00 UTC)