[HN Gopher] Choose Boring Technology (2015)
___________________________________________________________________
Choose Boring Technology (2015)
Author : asyrafql
Score : 506 points
Date : 2021-02-21 08:01 UTC (14 hours ago)
(HTM) web link (boringtechnology.club)
(TXT) w3m dump (boringtechnology.club)
| killingtime74 wrote:
| Does using Java but with native image (compiled to binary) count
| as using an innovation token due to new packaging or no (due to
| Java?)
| gonzo41 wrote:
| It's a negative 1 because you could have made an EXE jar and
| run it with standard open jdk on the server.
| killingtime74 wrote:
| True enough
| [deleted]
| onetom wrote:
| Is Clojure a boring technology yet? :)
| wilsonthewhale wrote:
| I would argue yes. There has been an impressively little amount
| of churn in the last 10 years.
| elonvolo wrote:
| There's a lot of social status and perception-shaping tied up in
| who gets to do what innovation.
|
| I've noticed that the very same ilk of leadership/managers who
| would balk at the complexity of adding a linter or json schema
| validation and cite "someday, that would be nice, but for now
| we've got to get quick wins and ship features" would not hesitate
| to let a golden-boy architect who's also a drinking buddy add a
| CQRS microservice written in Go communicating in some hand-rolled
| bespoke protocol---just because it wins some folks cool points.
| reader_mode wrote:
| > My friend Andrew wears the same brand of black shirt every day.
| He thinks that if he conserves the brainpower it would take to
| pick something to wear, he'll bank it and be able to use it later
| for something else.
|
| >I don't know if this makes sense for fashion or what have you,
| but I really think there is something to this.
|
| Johny Bravo was conserving his brainpower all along !
|
| I kind of like this idea, will probably try this, jeans + long
| and short sleeved versions.
| Aeolun wrote:
| This works just as well with a slightly more diverse outfit. I
| have 3 pants, and 5 shirts, any combination between these is
| fine, so I just wear what isn't being washed at the time.
| mrtksn wrote:
| If I remember correctly, that's supposed to be the reason why
| Steve Jobs used to wear the same outfit all the time.
| bitwize wrote:
| Barack Obama had multiple copies of the same suit hanging in
| his closet. It was like Smurfette's closet. When the time
| came to make an appearance or do something presidential, he'd
| pick out a fresh suit and know exactly how he'd look in it.
| [deleted]
| datavirtue wrote:
| So we should all embrace Oracle?
| [deleted]
| ahstilde wrote:
| (2015)
| kalalala087 wrote:
| https://properfocusreview.medium.com/proper-focus-adjustable...
| kingkawn wrote:
| Black t-shirt guy is onto something...
| Svip wrote:
| This is why I prefer buying 15+ year old cars, you know
| everything that's wrong with them. OK, it just so happens that
| three cars I've owned has been over 15 years old when I bought
| them, but I haven't heard a good car analogy in a while.
| threeseed wrote:
| Modern cars are far more efficient, performant and easier to
| drive than a 15 year one.
|
| Just like modern web apps are far more scalable, highly-
| available, secure and performant then they were 15 years ago.
| lanius wrote:
| >Modern cars are far more efficient, performant and easier to
| drive than a 15 year one
|
| Can you clarify what being "easier to drive" means?
| sprkwd wrote:
| It's easier to fix 15+ Year old cars yourself.
| IshKebab wrote:
| How many people fix cars themselves?
| oblio wrote:
| It's also much easier to die in 15+ years old car.
| XCSme wrote:
| It's easier to not have to fix new cars.
| mortehu wrote:
| Agreed. I once owned a 30 year old two stroke moped. It was
| very easy to fix. In fact I fixed it almost every week.
| tonyedgecombe wrote:
| Yes, we just replaced our eleven year old car with a three
| year old. The same make and model and our fuel bill dropped
| by 25%. This is nearly half the cost of the car over the
| period we will own it.
| [deleted]
| pharmakom wrote:
| I agree with all the arguments in the post... but man, I am so
| unproductive in the mainstream languages (Java especially). It
| feels like running in sand once you've experienced the other
| side.
| iamacyborg wrote:
| Urgh, this feels familiar. Last year I left a company that was
| just wrapping up a new tech product, everything was microservices
| and mongodb. Trying to get a simple answer out of the engineering
| team about something as trivial as "how can I get a list of
| customers who have purchased product X" was almost impossible.
|
| They sure had fun building it though.
| andrewflnr wrote:
| In the event you haven't already seen it, you may find this
| skit amusing and/or sob-inducing.
| oblio wrote:
| Link?
| threeseed wrote:
| What does that even remotely have to do with micro-services or
| MongoDB ?
|
| If your query was exposed as a REST API you could have easily
| accessed it via a micro-service. And MongoDB has a pretty
| powerful and easy to use query language. I could've answered
| your query in about 5s.
|
| Sounds more like a business or process limitation.
| satyrnein wrote:
| It seems like you're assuming the data you need is all in one
| microservice. (In which case, why did you need
| microservices?)
|
| Let's say the report needs data from across two
| microservices, one is backed by mongodb and one is mysql, and
| both services have been crud endpoints but not ones that will
| give you the full data you need. This is a pretty typical
| scenario! So you could make new endpoints, but then you still
| need to "join" the data in code. Or you could set up data
| pipelines to sync data into into a data warehouse, where you
| query across everything.
|
| Or you could have kept everything in a monolith, and this
| would have actually been a 5 second SQL query.
| gaogao wrote:
| Still a 5 second SQL query with Presto or similar and a
| warehouse.
| thedevelopnik wrote:
| But now you need to build an ETL system and run a data
| warehouse. And you need a team of people who know how to
| build and maintain those.
| iamacyborg wrote:
| Just a generalised frustration that the technology team
| didn't seem to understand how the rest of the business needed
| the technology to behave.
|
| The reality is you don't need that sort of query exposed as
| an API, but you do need that data to be exported regularly
| into a CRM and marketing automation tools.
| msvan wrote:
| A lot of new technology eventually becomes boring technology, and
| this is because of adoption in companies exactly in the way the
| author is discouraging. When the new becomes boring, everyone
| gets to reap the benefits of the new tech.
|
| The world of software rests on the hard work of others, whether
| it's open source maintainers spending their free time making
| libraries for peanuts, or it's people going through the pain of
| productionizing a new technology. Being in the boring technology
| club is in a sense also being in the freeloader club, never
| contributing back to the state of the art.
|
| It's a good article. It makes us aware of the drive many have to
| use the new thing, and the negative consequences of following
| this drive blindly. But I'm also happy that people do it.
| the_gipsy wrote:
| I think there's an unfairness angle to it, if someone like the
| CTO makes the "boring" call. He then hacks maybe a few things
| here and there, but the one's to "sucker up" are the devs who
| have to program some "boring" shitty tech every day.
| ryanbrunner wrote:
| I don't think this has to be true. I've worked in many places
| (granted, smallish teams of less than 20 or so) where tech
| decisions were made collectively, without even that much input
| from the CTO.
|
| Choosing boring technology doesn't have to be a top down thing,
| although it probably needs to have some mechanism for aligning
| a whole team (since 10 different "boring technologies" are no
| longer boring and bring along all the problems of using shiny
| new toys).
| jeromenerf wrote:
| In my experience "boring" is less correlated to "shitty tech"
| than poor organization.
|
| Most dev work is "blue collar" work, following top down
| business decisions. The opportunities for devs to push
| impactful bottom up projects for a company business are rare at
| best.
|
| I have always preferred organizations where business problems-
| to-solve were pushed top-down rather than executive decisions.
| It encourages business understanding, initiatives and
| ownership.
| phabora wrote:
| Blue collar is not a synonym for subordinate.
| datavirtue wrote:
| Dude, you can go home and play with any toy you want.
| soheil wrote:
| Having shiny cool tech to solve problems isn't all too different
| than having 1. a hip office to work at, WeWork-style 2. wearing
| the latest fashion or latest cool hoodie if you're in SV 3.
| latest mechanical keyboard design ... the list goes on and on. It
| makes everything easier, 1. you can hire easier because the hip
| engineers see new shiny thing and would love to work on it most
| likely even if there is a slight pay cut or even if the product
| doesn't appeal to them as much as working at another company,
| senior engineers tolerate shiny new tech because a. they know
| they were once awestruck by other technologies when they first
| came out b. there is always a non-zero probability the shiny new
| thing is actually fundamentally better not just a short lived
| fad.
|
| It's not a great explanation because it's a human issue, which
| usually as its solution has a mixed bag of technical and
| emotional reasons.
| chrischapman wrote:
| The aviation industry has an expression: "there are old pilots
| and there are bold pilots but there are no old bold pilots".
| Young, inexperienced pilots often take unnecessary risks and
| occasionally learn important lessons - sometimes terrifying
| lessons. Those lessons lead to a more cautious approach to flying
| as they grow older. It seems to me that boring tech is equivalent
| to cautious flying. Experience matters. Maybe its time to co-opt
| that expression into the developer world - "there are old coders
| and there are bold coders but there are no old bold coders".
| Ageism is a problem in the tech world. Experience will almost
| always consider (maybe even prefer) boring tech - generally for
| good reasons. Perhaps its time to value experience a bit more
| than we have.
| nkg wrote:
| I have dreadful stories about the amount of technical debt my
| team has faced because of one hedonist developer. He was good,
| but he had failed to understand the beauty of a boring stack. He
| kept reinventing the wheel, and over-engineering every part of
| the project. Keeping this in mind, I only pick shiny new tech if
| it achieves a superficial task, is fast to implement, and can be
| replaced easily.
| lovetocode wrote:
| What a great post!
|
| > I learned a lot. It kept me motivated through hard times with
| no customers, as I kept saying to myself if this won't work, at
| least I'd learn something.
|
| This is where I am at right now. I am trying to moonlight my own
| learning platform with two kids and a full time job, using a new-
| to-me technology is what keeps me going. It removes the stress of
| success because, no matter what, I succeed in some corny kind of
| way. Both myself and my existing employer get a better version of
| myself I'm the end.
| wrnr wrote:
| This stack can be radically simplified:
|
| Apache: managing open connections. Memcache: holding stuff in
| memory. Postgresql: Save stuff to disk. Cron: Schedule things.
| Python: wire the above things together
|
| ... or a good reason the pick Go or Java
| hnedeotes wrote:
| Or better, Elixir + Postgresql
| nhumrich wrote:
| Not sure elixir qualifies as "old and boring tech"
| hnedeotes wrote:
| (this got out of hand...) I understand what you're saying
| and think you're right, in terms of not having had the same
| time running in the wild to have the same knowledge base
| and ecosystem as other solutions.
|
| But looking at what it actually is, it's a layer over the
| much older underlying technology, which is Erlang, once you
| look at the frameworks used, they are basically
| implementations of things we consider old approaches,
| despite including new features. Some examples:
|
| - Phoenix - it's a MVC framework, it's not much different
| from any MVC framework except it doesn't have the "model".
| You can entirely use it in that "boring" CRUD app way and
| it will be a great choice. It's performant and has a
| templating system for HTML, a plug system that looks like
| middlewares. But if you need to use web sockets without
| ceremony or want to try something shiny like live views,
| you can as well. You're not forced to though and you don't
| need to use nodejs for your js either (as an example)
|
| - Ecto - It looks like an ORM but isn't an ORM, it's
| default choice for database is Postgresql. It's a library
| that mimics SQL itself (the helpers and the way you use it
| are as they would be used in SQL but designed to be chain
| able and sanitised), it also has easy ways of executing SQL
| while still sanitising it and also of writing raw SQL. So,
| pretty boring in all senses except the slight change in
| syntax to write the queries in elixir. This means for
| instance a distinct clause would be distinct(query,
| [table_mentioned_in_query], asc:
| table_mentioned_in_query.platform) This is not written as
| sql, but it maps to sql one to one. It uses schemas which
| are just that, schemas that map how values are dumped and
| cast from the DB, they're not models/objects, they're just
| data structures. But if you want to get fancy it also has
| embedded schemas if you want to use jsonb for instance,
| that allow you to use jsonb columns while still maintaining
| a "typed" schema from dump to read.
|
| What may look a bit alien is perhaps the access to OTP
| libraries that Erlang offers, the way the VM works and
| certain abilities that come from the way you will structure
| an app, but even those when we think about them, it's
| basically what any OS does, or the way kernels work. You
| have processes, they have identifiers, you can name them,
| you can run a lot of them concurrently, they can have
| separate lifecycle trees/dependencies, they have
| interfaces, you pass "messages" between them. Maybe what's
| "new" when you compare it to other languages is that this
| is not usually available to them but I would argue that
| most of our systems are implemented exactly in that way
| because it's the most reasonable outside very specific
| constraints/needs.
|
| When you use Elixir, Phoenix and Ecto you don't need to use
| these (or understand them deeply), usually the libraries
| take care of that for you. You can start as if you were
| writing a nodejs, rails, .net, python or whatever
| application. But then if you actually need you have a host
| of utilities and a runtime that I think is excellent for
| the kind of things most apps out there need, in a single
| runtime, and you can take it pretty far before you need to
| extend the stack and that has value in itself I think.
| yellowapple wrote:
| Elixir, probably not.
|
| Erlang (and more broadly OTP), however, definitely
| qualifies IMO, at least depending on point of view. And
| given that Elixir is just an alternate language targeting
| OTP on Erlang's VM, there ain't much stopping folks from
| treating it as exactly that (and sticking with things like
| Yaws and Mnesia/CouchDB instead of the latest Phoenix
| hotness).
| cutler wrote:
| So long as you don't need to do any heavy lifting or
| computation.
| davidw wrote:
| It's not too difficult to farm work out to code written in
| C or C++.
| benzible wrote:
| Jose Valim Reveals "Project Nx" (Numerical Elixir):
| https://news.ycombinator.com/item?id=26076680
| trestenhortz wrote:
| Generalizations like "choose boring technology" are just
| unhelpful slogans.
|
| Truth is you should choose technology given consideration of its
| pros and cons, not on the basis of some slogan.
|
| There are very good reasons to use mature technologies and very
| good reasons to use current technologies and very good reasons to
| use absolute cutting edge technologies.
|
| When someone comes at your approach wielding a slogan, be
| skeptical.
| arkitaip wrote:
| The author even addresses your criticism, i.e. how the title of
| the talk makes people focus on the wrong detail level of his
| thesis...
| ithkuil wrote:
| Should "chose boring titles" be a thing?
| linspace wrote:
| Yes, specially since different people will have different ideas
| of what is experimental and what not. Python is boring tech at
| this point for most people, but not everyone maybe using SAS
| for data analysis or Java for backend. You will need to
| evaluate case by case if it makes sense or not to change that
| stack, there is no silver bullet.
| wffurr wrote:
| Thanks for summarizing the talk so concisely.
|
| Maybe read it before commenting next time.
|
| I wish HN had a feature where it could detect that you clicked
| the link and disallowed commenting before that. At the very
| least you'd have to click the link, even if you just
| immediately click back without reading, and you'd know what you
| were doing was circumventing the spirit of the place.
| corytheboyd wrote:
| Interesting idea! Maybe instead of preventing you from
| commenting entirely, it just tagged all comments you leave as
| "have not read article". I think the shame approach would
| actually work, but too many people would vehemently reject it
| for it to ever work.
| zbuf wrote:
| Perhaps just annotate each comment with how many minutes
| between clicking the link and making the comment (similar
| to the green usernames)
|
| That way the reader can decide for themselves. I'm less
| inclined to object to hasty responses to discussion points
| than I am to top level comments, but that's just personal
| choice.
| corytheboyd wrote:
| The author even calls out the slogan as clickbait in the
| presentation.
|
| For what it's worth, it's a great read that I would recommend
| to anyone in the industry.
|
| They aren't forcing technologies on you, but driving home the
| true cost of long term maintenance and investing in the "core
| stack" that you already have instead of adding N technologies
| to solve N business problems. This is good stuff.
| ramraj07 wrote:
| One reason to use non-boring new technology is if it suddenly
| enables abilities that were previously not possible.
|
| The trap most engineers fail is that they only think about
| scaling. It's obviously an interesting problem, but until a
| company becomes successful it's not really something you should
| worry about, and for the most part things that (allegedly)
| scale well are more expensive, slower and harder to maintain.
|
| But there are so many ways to innovate that's not just about
| scaling: can you make your application faster? What are things
| you never even considered because you have subconsciously
| internalised as a physical limit of reality when actually it's
| not?
|
| One of the examples I'm currently exploring is the idea of
| moving a large amount of data in memory. I remember decades
| back when Google announced that it's search indexes are now
| fully in memory (they proudly announced that any given search
| query might run through a thousand computers). I cannot imagine
| how many possibilities it enabled for their product that were
| not possible before. The experimentation with new technology in
| pursuit of completely new ways of exploring your problem space
| should always be encouraged, and if boring technology cannot do
| it then that's when you give up on it.
| post_below wrote:
| I generally agree about slogans, but that seems unfair here.
| "Choose Boring Technology" isn't the sum total of the content,
| it's essentially the title. If you read past it, there is good
| stuff.
| m463 wrote:
| UH, he covered that specific point in the presentation
| (humorously).
| nickjj wrote:
| I think it's helpful if it brings awareness to the situation.
|
| I've spoken with 70+ different devs working on 70+ different
| projects of all sizes on my Running in Production podcast[0]
| and the choose boring tech phrase came up a whole bunch of
| times, and especially the idea of using innovation tokens. If
| it helps folks build and ship their app in a quick and stable
| way, that seems like a big win to me.
|
| [0]: https://runninginproduction.com/podcast/
| sdfhbdf wrote:
| It must have been a weird coincidence but I listened to a few
| episodes for your podcast and I've actually heard about
| boring technology in 100% of episodes I listened to
| nickjj wrote:
| Hah yeah, coincidence for sure. I don't have hard numbers
| in front of me but based on reference links to the boring
| tech site it's been mentioned at least half a dozen times.
| I know innovation tokens have been spoken about a few times
| outside of those linked episodes too.
| krenel wrote:
| > When someone comes at your approach wielding a slogan, be
| skeptical.
|
| I do agree. Although the point of the article is to _lean_ more
| on "boring technology" side of, and paying extra effort when
| considering adopting newest flashy things.
|
| Having read the article 3-4 time in the last years, I don't
| think they say "don't use new things", just "not too many new
| things at the same time"
| galfarragem wrote:
| It could be rephrased as: spend your "innovation tokens"
| wisely.
| trestenhortz wrote:
| Perhaps the title should be "err on the side of boring
| technologies", although I don't even agree with that. The
| right technologies for a project are the ones you deem to be
| right, given appropriate consideration of many factors. Your
| project may really need to use all beta release software,
| cause maybe it just does.
| krenel wrote:
| I would agree that we're talking about the same thing,
| really:
|
| > The right technologies for a project are the ones you
| deem to be right, given appropriate consideration of many
| factors
|
| It's _usually_ difficult to take into consideration all the
| factors of a new flashy thing. The unknown unknowns. Thus
| _maybe_ choosing a trendy set of technologies might
| indicate that the exercise of balance and consideration you
| were commenting and that I do agree with 100%, has not been
| as honest as possible.
| sverhagen wrote:
| It may. But probably it doesn't.
|
| Let's say you've given it the proper consideration, and
| it's clear beyond the smell of subjectivity that it needs
| to be flashy stuff, go for it. The point is that this is
| often not the case, and the argument is to go with boring
| then.
| pmohun wrote:
| This essay from David Perell touches on a similar concept:
| https://perell.com/note/lateral-thinking-with-withered-ideas...
|
| > It led to the 20th century's most successful game console: the
| Game Boy. One day, a gaming engineer named Gunpei Yokoi was
| commuting home on the train when he saw a man playing with an LCD
| calculator next to him. Unfortunately, Nintendo didn't have the
| budget to push the technological frontier at the time, so they
| used old technology to innovate. So long as the gameplay was
| engaging, Yokoi believed that players didn't care about technical
| details like colors or screen resolutions. Compared to its
| contemporaries, the Game Boy was durable and affordable, which
| removed barriers to entry for users and developers. People would
| play for hours because it used AA batteries that were cheap and
| easy to find. Today, the Game Boy has sold more than 118 million
| units.
| XCSme wrote:
| Hell yeah, I still love working on my 9 years old MySQL+PHP side-
| project. No build process, no issues with updating to latest
| package versions, it just works and you are not fighting with the
| language or tooling itself.
|
| I did add meanwhile some extra parts on top to improve the
| development and releasing process, but those parts can be changed
| and removed at any point and the project would still work as
| expected.
| 0xCMP wrote:
| I forget sometimes in interviews not everyone reads HN
| religiously. And I also forgot where I'd learned about
| "innovation tokens". Needless to say it would have helped to
| point interviewers to this full talk when explaining why we
| focused so hard on simplifying our technology stack.
| nine_k wrote:
| The title of this article, which makes rounds on HN, bothers me.
|
| It's not about choosing a "boring" tech. It's about choosing
| _tools you understand well and a master of_.
|
| You can be totally excited about e.g. TypeScript or Elixir, but
| as long as you have a solid experience of working with them, and
| a good understanding of their internals, they are safe bets.
|
| Choosing a perfectly boring thing like Cobol is not going to help
| if you have no solid mainframe experience.
| jonahx wrote:
| From the article:
|
| > I chose "boring technology" as the pithy SEO-friendly title
| for this content, and I regret it most days. It's kind of
| distracting. "Boring sounds bad, why is he saying it's good?"
| Et cetera. It's a real shitshow.
|
| > But what I'm aiming for there is not technology that's
| "boring" the way CSPAN is boring. I mean that it's boring in
| the sense that it's well understood. It's bad, but you know why
| it's bad. You can list all of the main ways it will let you
| down.
|
| > It's important to master the tools that you do pick.
| 11thEarlOfMar wrote:
| > New tech typically has more known unknowns, and many more
| unknown unknowns. And this is really important.
|
| Isn't this true in many facets of life? Like.... taking a new
| job... having your first kid... visiting a new city...
|
| Are there processes for engaging in any new experience that
| enable you to know the outcome is going to be net positive before
| commencing?
| altgans wrote:
| Two observations:
|
| - The slide with the jeep together with the "use boring
| technologies" slogan paints an interesting picture of the
| challenges of E-mobility in this century. There are going to be a
| lot of things no one expected.
|
| - How would you call this style of presentations? Zen-like? One
| catchy thing per slide? I find it pretty well done, and when I
| compare it to my own "wall of text" slides, I am a bit jealous.
| qmmmur wrote:
| This has to be the worst website to get the most basic
| information. Talk about over-engineering.
| siliconc0w wrote:
| I think what people sometimes fail to realize is that the
| software ecosystem has simply become more specialized. There is
| now a higher-bar due to the competition between entrenched
| technology companies with armies of engineers continuously
| optimizing everything. So, depending on the industry/domain -
| aside from a useful product you need to consider a lot more: apps
| that work across platforms, performance, security, compliance,
| SEO/marketing, analytics, speed of iteration/delivery,
| infrastructure reliability, etc. All these contribute
| requirements that add complication.
|
| So if you want a company that can do all that you are going to
| need specialists which typically come wielding specialized
| technologies. You can probably get away with generalists wielding
| 'boring' technologies for some period of time combined with SaaS
| solutions but it's hard to avoid the fast-moving increasingly
| specialized ecosystem forever.
| qnsi wrote:
| So, what would be a best boring backend stack today? The one
| mentioned in the article? Or java for python?
| rakoo wrote:
| The one you and your team master, where all the failing modes
| are known and predictable
| dang wrote:
| _Choose Boring Technology_ (but not the same article) -
| https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204
| comments)
|
| _Choose Boring Technology (2015)_ -
| https://news.ycombinator.com/item?id=23444594 - June 2020 (282
| comments)
|
| _The boring technology behind a one-person Internet company
| (2018)_ - https://news.ycombinator.com/item?id=20985875 - Sept
| 2019 (451 comments)
|
| _Choose Boring Technology_ -
| https://news.ycombinator.com/item?id=20323246 - July 2019 (344
| comments)
|
| _Choose Boring Technology_ -
| https://news.ycombinator.com/item?id=9291215 - March 2015 (212
| comments)
|
| Also: current ongoing thread
|
| _Choose Exciting Technology_ -
| https://news.ycombinator.com/item?id=26212563
| srich36 wrote:
| This is one of those posts where you can really feel the value of
| senior engineering/previous experience.
|
| I definitely have not approached choosing a new technology with
| the velocity vs. maintenance trade off, instead just choosing the
| technology best fit for the job at hand. But when looking at a
| system holistically, this may not be the best choice. It'll be
| good to at least know to consider this in the future (although
| I'll admittedly probably still bias towards "fun" technologies).
| z3t4 wrote:
| By committing to an technology early you are limiting your
| options! You are limiting the possible ways problems can be
| solved. You are limiting the talent pool/hiring options.
| matthewfelgate wrote:
| Thank you for sharing and explaining this. As a former software
| engineer I finally understand the other side of the argument.
| More than just being told it's a "business decision".
| fiftyacorn wrote:
| I still think the Simplicity Chapter in the Google SRE book sums
| this up best
|
| https://sre.google/sre-book/simplicity/
| carapace wrote:
| "Boring" in the sense used here really means something like
| "reliable" or "low-maintenance". Think of the old Maytag
| Repairman ads: he's just sitting there waiting for a call that
| never comes because Maytag washing machines are so reliable, get
| it?
|
| Interestingly, this kind of boring can be measured. On the other
| hand, the kinds of things that one finds fun is idiosyncratic and
| subjective. I think it's an important distinction: we can argue
| about "boringness" with data, but a discussion of "exciting"
| software is much more like a discussion of personal tastes.
|
| Take Elm for example, it's a highly reliable system for building
| front-end web apps, so in that sense it's very boring (in a good
| way!) but whether or not you find it exotic or exciting has a lot
| to do with your personal experience with Functional languages and
| such. To some people Elm seems like a toy, while to others it's a
| strange new world.
| phabora wrote:
| Really good presentation. Even in this form. These are the best
| arguments for choosing Boring Tech that I've seen yet.
|
| Almost gave me a sinking feeling:
|
| > If you behave that way you miss out on the part of the curve
| that we call "mastery." That's a state to the right on this
| curve, where there are still problems. Everything still sucks but
| it feels manageable.
|
| > The grim paradox of this law of software is that you should
| probably be using the tool that you hate the most. You hate it
| because you know the most about it.
| ywei3410 wrote:
| The hypothesis fails because it assumes all curves are the same
| - and all tech has the same number of kinks; which is patently
| false.
| tpetry wrote:
| The problem with the non-boring technology club is that
| programmers see what problem FAANG companies are solving and
| wanting to be on the edge on new technology too. But they don't
| have the same problems. Another problem is they want to show what
| they can do. If they tell in an interview they are working with
| rails/django and a postgresql database they fear they look
| incompetent using those old technologies. So they try to convince
| their companies their products need to be rewritten in mongodb,
| react with graphql in a micro service stack and many more state
| of the art technologies.
|
| And in the end many developer years are wasted just rewriting a
| working an existing software in a new stack they are not yet
| comfortable with and the new product is much less stable than the
| old one.
|
| I love basecamp for their hotwired stack and showing that you can
| make the great software with old boring technologies and just a
| little bit of javascript magic pixie dust.
| cutler wrote:
| Yes, Hotwire is another game-changer from that genius DHH. So
| much so that Django and Laravel already have their own
| implementations. I just love the passion that guy has for what
| he does and his commitment to Ruby. I think Rails is an even
| better choice since it became boring.
| vyrotek wrote:
| He's a smart guy but this feels more like a pendulum swing.
| ASP.NET had a similar implementation called AJAX UpdatePanels
| back in the mid 2000's.
| threeseed wrote:
| Basecamp is a simple app though. Ridiculously simple.
|
| That app could have been written in the mid-1990s using
| WebObjects in just a few months.
|
| Technologies like MongoDB, React, GraphQL, Microservices etc
| exist because modern, real-world apps are generally far more
| advanced than just a glorified CRUD app. Consumers simply have
| higher expectations and more demands for what web apps should
| be able to do.
| overkalix wrote:
| > modern, real-world apps are generally far more advanced
| than just a glorified CRUD app.
|
| ... are they?
| ryanbrunner wrote:
| While this is somewhat true and you can't solve everything
| with Rails + Postgres, you should ask yourself very, very
| hard about whether what you're building is in that category
| (and further, whether every part of what you're building
| falls into that category).
|
| Far, far too often I think a significant source of complexity
| is enthusiastically added by engineers themselves assuming
| that the problem they're solving is sufficiently complex that
| boring technologies just aren't up to the requirements of
| their project.
|
| My current gig is writing a very traditional Rails app (we
| hardly even dabble in Stimulus or Javascript all that much).
| Prior to that, I worked on a Javascript-backed fully reactive
| real-time app using the latest and greatest of technologies.
| My boring old Rails app, IMHO, has a much nicer user
| experience, far fewer quality issues, and is well loved by
| customers, where the bleeding edge Javascript app was
| constantly deried by customers for being difficult to use,
| buggy and unintuitive. You can go a long way with simple
| technologies if you design your experiences well.
| nizmow wrote:
| Typically though, FAANGs still solve their problems with boring
| technologies.
| stepbeek wrote:
| I was very disappointed when I joined Amazon to learn we were
| using plain old Java with servlets (this was 2015, I think
| kotlin is more common now). Since leaving I'm in awe of how
| sensible the technical decision making that led to that was.
| redisman wrote:
| I interviewed with Stripe and one of the engineers
| mentioned they're transitioning many services to a exciting
| new technology called... Java. That was in 2021
| dilyevsky wrote:
| Not true - they use cutting edge tech that sprawls around
| sfba a few years later all the time. Maybe not on the web
| side bc you aint gonna add much value by doing that anyway
| usrusr wrote:
| They are big enough to follow all paths concurrently. The F
| is famously doing their own PHP and while the G was tickling
| "shiny receptors" all over the world with Go (which
| ironically could be seen as an example in boring technology
| enlightenment, considering how it is basically a modern take
| on 1980ies language features), they were also doing so much
| plain old java that the parts of the internal tooling they
| did for maintaining their own sanity published as Guava
| easily had more impact on the viability of java as a language
| than everything Oracle has ever released (yes, including Java
| 8 lambdas).
| jefftk wrote:
| Yes! I work at a FAANG and over my time here it's been C++,
| Java, Python, and JS. The least "boring tech" part of my work
| has probably been that were moving from JS to Typescript?
| Mostly, we want to use things that we're confident can do
| what we need, and that we're confident don't have hidden
| surprises.
| rossdavidh wrote:
| All true, but I would like to add that their manager would like
| to say (when interviewing at FAANG) that they managed cool edgy
| new technology as well. So they are not motivated to stop these
| things because it sprinkles hot keywords on their resumes, as
| well.
| soheil wrote:
| > they fear they look incompetent using those old technologies
|
| It sounds like you're saying the fear is unwarranted. It very
| much is a real fear as long as people interviewing them
| actually count that against them and value new tech.
| thewarrior wrote:
| It's because job hopping programmers are compensated for how
| rare their skill is in the market and not how much value they
| add to the business. It's another flaw in capitalism.
|
| Reward employees a direct and substantial cut of the profits
| and incentivize to them to stay 5-10 years and these behaviors
| should disappear.
|
| The loss of job security, frequent job hopping has created more
| incentives to optimize for the next job switch and not value
| add.
|
| The explosion of startups also contributes to this. They often
| have to attract employees by offering the promise of autonomy.
| Most startup employees know they aren't getting rich. So they
| milk the startup for maximum resume points and move on.
|
| The VCs unload these bloated companies into inflated stock
| markets and the cycle continues.
|
| DHH runs really small companies and pays his employees really
| well and doesn't work them too hard. Employees have no real
| reason to leave. They see a direct link between the low
| overhead and their job security and work life balance. Aligning
| incentives fixes this.
| soheil wrote:
| > they want to show what they can do
|
| Or more like it's the scarcity, by definition new tech still
| doesn't have many experts in it. So if you're one of the few
| that learns it you're all of a sudden pretty differentiated
| compared to your peers. Even if the new tech turns out to be
| pure garbage down the road it doesn't matter because in the
| meanwhile you can land the hippest jobs and win the admiration
| of your peers by being so far ahead of everyone else.
| djoldman wrote:
| > So they try to convince their companies their products need
| to be rewritten in mongodb, react with graphql in a micro
| service stack and many more state of the art technologies.
|
| I find it interesting that these technologies are considered
| "state of the art" (SOTA). What does SOTA mean in this context?
| I could see an argument for postgresql and rails/django being
| SOTA as I think many believe them to be fairly mature, secure,
| and feature complete.
| DC1350 wrote:
| If you have a shitty job then it's really hard to get the
| experience you need for something better unless you invent
| problems. That's why making things way more complicated than
| they need to be is actually a good thing.
| jmartrican wrote:
| The way I see it is that one should master their stack. If you
| work over and over again with the same stack you will know it
| well. You will be able to move mountains with it. But it takes
| years to arrive to that. It takes implementing multiple projects
| the same way over and over again.
|
| You need the wherewithal to stick with your stack and not get
| lured away. Maybe this is what boring means. Maybe boring is
| different to different engineers based on their background.
|
| Sometimes you cannot select the stack cause there might be more
| senior engineers at a company and they have more sway. This is
| fine as long as the engineers picking the stack have picked a
| stack they have mastered and it is boring to them. As a regular
| engineer in their team I would hope to rely on their expertise
| and would hope to learn from them.
|
| I remember at one job a rogue engineer picked a boring backend
| that would have been fine. But they fell behind because the other
| engineers knew their boring stack a lot better. Ultimately the
| rogue engineer had to switch to the other boring stack. The rogue
| engineer just was not fast enough to master it and implement the
| features required to keep pace with the demands of management.
| These demands were trace centralized logging, security, and of
| course features. So while they were still learning the ropes, we
| were moving on to even more advanced security, logging, and
| feature requirements. They just couldn't keep up.
| bob1029 wrote:
| > The way I see it is that one should master their stack. If
| you work over and over again with the same stack you will know
| it well. You will be able to move mountains with it. But it
| takes years to arrive to that. It takes implementing multiple
| projects the same way over and over again.
|
| This is 100% how we did things for the last 5 years. We used
| the exact same basic tools & APIs, but iterated on how we
| integrated them together by way of our code.
|
| We took what most people would call a "toy" stack, consisting
| of just C#/AspNetCore/SQLite (and recently Blazor), and turned
| it into something that can serve thousands of users in
| production across several B2B customers. We don't use any sort
| of containerization or cloud tech. Our software can be deployed
| by unzipping a file on the target environment and running a
| single command. You would be surprised at how much speed you
| can get out of SQLite when you have had 5 years to live with
| and experiment with its capabilities. On top of its extensive
| internal testing framework, I have several testaments to its
| stability sitting in our customers' environments right now.
| We've got OLTP SQLite databases that are getting close to 1TB
| in production without any signs of distress.
|
| So, instead of focusing all of our energy on shiny things, we
| focused on building a 100% integrated vertical with (mostly)
| boring tech so that we can fully manage the lifecycle of our
| software product with the product itself. We have a management
| web interface built out for everything we need to do for
| building & operating the solution. We are very close to being
| able to partner with other organizations who can run the
| implementations on our behalf because the software is so easy
| to manage now. This is the type of real-world horizontal
| scalability the CEOs are after.
| jmartrican wrote:
| Thanks for sharing that. I think we need more of these
| stories of how a team was able to use the boring tools they
| mastered to implement amazing things.
| gilbetron wrote:
| This is a great comment and is spot on. Mastery has exponential
| returns over proficiency. The best thing is that mastery feels
| really good once you have it. I've been bouncing around the
| past several years not finding what I want, but I've realized
| the past year that I want to have the mastery with a stack that
| I haven't since my C/C++ OpenGL computer graphics years.
| koheripbal wrote:
| This equally applies to a company's business process. Focus on
| a specific scalable business model that scales - don't make a
| special niche process for every "opportunity" that comes by.
|
| It also applies to managing your life, personally. Know what
| things you do, what your personal goals are, and don't let
| yourself get distracted by the latest and greatest social media
| trends or stuff your friends are doing.
|
| Focus. Mature. Achieve.
| danjac wrote:
| The "opportunity" is often a dangling carrot from a big
| enterprise customer. It's very hard for a cash-strapped
| startup looking to make bank and reputation to turn these
| opportunities down, and they don't look at the TCO and long-
| term costs in terms of complexity and tech debt.
| jmartrican wrote:
| > don't make a special niche process for every "opportunity"
| that comes by.
|
| At my current job we call those snowflakes. "no snowflakes"
| is the motto of one of our senior architects.
| vasco wrote:
| I agree completely. Another angle that is less common is
| remaining at one company you believe and respects your work. If
| you find somewhere like that, years of working in the same
| domain can make you more effective. Not to speak of the
| advantages of a team that works together for 5+ years and the
| power that comes from true camradarie with your team mates.
|
| It's sad that most places - and by definition the largest
| places also - end up being a meat grinder and people just hop
| companies and teams within companies every year or two. By the
| time you start understanding the domain you move on. It takes
| years to internalize a problem and understand it deeply.
| jmartrican wrote:
| So true. I feel empathy towards management that need to keep
| their engineering teams intact.
| polote wrote:
| previous discussion (348 comments)
| https://news.ycombinator.com/item?id=20323246
| jsnell wrote:
| Also:
|
| https://news.ycombinator.com/item?id=23444594
|
| https://news.ycombinator.com/item?id=9291215
| mikesabbagh wrote:
| I think that technology used needs to be chosen based on today's
| needs and not tomorrow's. Startups that decide to deploy 5
| containers on kubernetes make me cry. The time and cost to
| operate and maintain this beast is beyond any estimate compared
| to even hosting each container on a seperate vm. This read was
| very satisfying, thank you
| syastrov wrote:
| Reading this sounds like dejavu.
|
| A company I've worked with also had a PHP monolith which was
| supposed to be split up into microservices to improve
| maintainability. The choice of language was free, and the first
| ones were, kid you not, written in PHP using some alpha-quality
| library which was supposed to make PHP asynchronous, to improve
| "scalability". Comically, this stack was used in an image-serving
| service which had to perform blocking image resizing using
| ImageMagick. Due to this misunderstanding of the technology, the
| only way to keep it afloat was to run 90 containers in a home-
| managed Kubernetes cluster just to keep requests from queuing up.
| Another comic misunderstanding of this paradigm was when I traced
| down a bug where the process seemed to hang due to the fact that
| the developer had intentionally added a call to sleep in a loop.
| Coming from a Java/.Net background, they believed it would cause
| the "current thread" to sleep in order to not hog resources. This
| was problematic since the application (like nodejs) was single-
| threaded.
|
| I didn't want to work with that stack, so when it was my turn to
| work on a new microservice, I chose Scala + MongoDB (same as
| Etsy) because I wanted to learn about functional programming.
| Ironically, the microservice was basically a "checkbox as a
| service", but I and the tech lead on the team were too
| brainwashed/high on learning new things to realize the
| overcomplexity.
|
| The entire thing was an expensive lesson that I and some others
| got to learn from. The ones who didn't learn kept their
| microservices ideology and found other jobs.
|
| Fast-forward and the entire thing was scrapped and rewritten as a
| Django + Postgres monolith. Not to say that it wasn't costly to
| do a rewrite, but infinitely less costly than continuing down the
| microservices road. Long live boring technologies.
| revskill wrote:
| Technology is just a tool, or not ?
|
| By a tool, i mean, we still use boring algorithms (which exist
| long before the tech is born to adapt it efficiently).
|
| So, boring tech or not, it's not the point, as long as it serve
| your purpose.
| gscho wrote:
| I enjoy reading this each time it gets posted but can we please
| get TLS enabled? It's so easy these days.
| moonbug wrote:
| but why.
| hacker_newz wrote:
| It is pretty embarrassing for someone in tech not to set up
| properly.
| methyl wrote:
| How do we make progress if everyone just chooses to use boring
| technology which is already established? There would be no Rust,
| no Ruby or other great pieces of technology as they cannot thrive
| without communities. Communities cannot thrive if everyone
| neglects everything that's new and exciting.
| atoav wrote:
| I guess it goes like this: Is there much at stake? Choose a
| boring technology. Is it a experiment or a toy project? Choose
| whatever floats your boat, knock yourself out, have fun and
| learn on the way.
|
| Trying out new things makes a ton of sense. But trying them out
| in a domain where unforeseen consequences could potentially
| destroy you is not a smart move.
| cutler wrote:
| Since most commercial projects have much at stake how would
| new technologies ever get a chance to become mainstream? For
| this to happen there has to be some risk-taking otherwise
| we'll be permanently stuck in the current situation where a
| bunch of scripting languages designed in the mid-90s for
| single processors are tasked with handling much bigger
| workloads on multi-core machines. Hence the current wave of
| bolted-on gradual typing.
| phendrenad2 wrote:
| I always found it funny that companies will go to extreme
| Herculean lengths to hire the best programmers, and are
| incredibly fearful and paranoid that they could be making a "bad
| hire", and yet once hired they don't spend a second making sure
| engineers aren't completely running the software product off the
| rails and killing the company internally. The author mentions
| trying to rewrite Etsy's backend in Scala and MongoDB. That
| probably cost the company X million dollars. Etsy could still be
| recovering from that.
|
| The industry constantly mints senior engineers who have been
| bitten by complexity, but doesn't want to hire them, or listen to
| them. More often than not senior engineers pretend to be excited
| about complecting the tech stack, because hey, it pads their
| resume with the latest buzzwords and they've given up trying to
| fight against it anyway.
|
| The last line of defense against a rogue engineering team is
| managers who have studied this stuff. How many engineering
| managers can spot the common situation "the engineers are bored
| and they're rewriting perfectly-good codebases in Common Lisp and
| OCAML for funsies"? And how many know what to do about it when
| they see it?
|
| Anyway, this is a cool website, and it'll be useful to point
| people to it in the future, so thanks for that.
| Mikushi wrote:
| > The last line of defense against a rogue engineering team is
| managers who have studied this stuff.
|
| If your engineering team is the one pushing in that direction
| I'd reckon the company was in a bad spot to begin with to have
| hired that team because it strongly indicates that the
| management layer (head of tech/CTO) has no technical clue.
|
| Hire strong Lead Developers with a proven track record of
| delivering value to companies they worked at and you'll be
| mostly fine.
|
| Also there's not much to study, in 99% of the cases in a web
| based startup if your stack deviates from a monolith with one
| of PHP/Ruby/Python/.NET/Go + Mysql/Postgres/MSSQL you're doing
| it wrong.
| js4ever wrote:
| What's wrong with Node.js? It's super mainstream now. We have
| it in production since years, I see a LOT of companies
| migrating from everything else to node since years and it's a
| growing trend from what I see at my level with startups and
| even enterprises
| Mikushi wrote:
| Nothing, just forgot about it.
| collyw wrote:
| The language for one. There are decent choices of language
| for backend work. Why anyone would choose JavaScript is
| beyond me.
| Kwantuum wrote:
| The thing is, if you have any sort of front-end that is
| not entirely server-side rendered, you're going to have
| to work in JS at least some of the time. If your back-end
| is also in JS, you now get the benefit of isomorphic code
| for things that you may want to do on both front-end and
| back-end.
|
| Then there is also the fact that JS is actually a pretty
| great language if you know how to avoid the footguns.
| Granted that's not always easy, but it's a language with
| lexical closures and easy and familiar syntax, it's also
| very expressive and has a vast ecosystem supporting it.
| And you can even add the typescript compiler on top if
| you want compile-time type-checking.
|
| It's also async out of the box, and while that doesn't
| solve all problems, it scales surprisingly well with no
| performance tuning whatsoever, it even has decent
| asynchronous primitives that make it easier to write
| correct code.
| lostcolony wrote:
| Yeah; even without frontend code, JS is surprisingly
| compelling. It's easy to hire for, easy to write
| reasonably performant IO code in, the footguns are pretty
| much all well documented and generally understood (rather
| than requiring knowledge of the deep magic to debug),
| library support is top notch, and as a language it
| supports both OO and FP, while being pretty small in
| scope, terse without encouraging too much code golf.
| whimsicalism wrote:
| Oh, but Python is an ideal backend language?
|
| Give me a break.
| dukeyukey wrote:
| If you want something mature, with libraries for
| everything, solid backwards compatibility and basically
| the best "boring" choice, go with Java. And if your devs
| want to mess around a bit, mixing some Kotlin in is
| basically harmless and easy to reverse if needed.
| hackerfromthefu wrote:
| It's generally high maintenance, npm dependencies,
| deprecations, leftpad, javascript new shiny culture etc
|
| You can make it work with more maintenance, but you did ask
| the question what's wrong with it!
| chrisco255 wrote:
| It's really not high maintenance at all. Leftpad issue
| was fixed in less than hours the same day it happened and
| since then the NPM tooling for package management has
| improved a great deal.
|
| JS shiny new culture doesn't really exist on the back end
| (and even front end js has calmed down in recent years).
| Express.js, the go-to framework 7 years ago, is still the
| go-to framework on Node today.
|
| Node and Mongo are at this point "boring tech". Their
| limitations and trade-offs are well known, their benefits
| are also well-established, and their APIs and tooling
| have matured.
| onetom wrote:
| Recommended "literature":
|
| 1. 10 Things I Regret About Node.js - Ryan Dahl - JSConf EU
| (https://www.youtube.com/watch?v=M3BM9TB-8yA)
|
| 2. Brendan Eich: JavaScript, Firefox, Mozilla, and Brave |
| Lex Fridman Podcast #160 (https://youtu.be/krB0enBeSiE)
| redisman wrote:
| Sure but there are all known issues to any Senior Devs.
| You don't have to pull shady hairballs from npm for every
| little feature you can think of. I've ran node in
| production for the last 5 years so at least to me it
| counts as battle tested and "boring".
| criddell wrote:
| And what about the front end? What's the best, most boring
| choice there?
|
| I was on a project for a bit using React and although it felt
| like an obvious way to write things, I can't help but feel
| you can't create something that will last for a decade with
| it.
| 1337shadow wrote:
| Unless you're trying to make a really rich SPA, it could be
| something of: unpoly, htmx.org, barbajs, knockoutjs,
| turbolinks/stimulusjs... Anything that lets you enjoy
| server side rendering, whatever your framework
| autogenerates for you (ie. forms) is better to "just have"
| than "have to implement", instead of having 2 projects (one
| API, one frontend), or even no frontend framework at all
| (ie. mvp.css and plain HTML), you can do a whole lot of
| relevant projects with that already.
|
| Webcomponents in plain JS are also great to not have to
| deal with JS class/HTML Element binding and lifecycle
| yourself.
|
| Why not add a bit of Flutter or React for a few features,
| but for most pages it's going to be an expensive overkill.
| BigJono wrote:
| You absolutely can. React is the gold standard right now.
| It's already been king for 6 years and it's not going
| anywhere. The hype for angular died down. The hype for vue
| has started to die down. This little bit of hype svelte has
| at the moment will die down.
|
| React does have a ton of problems but they all come from
| the next level of dependencies down. Shit like Gatsby and
| Nextjs won't pass the test of time. Neither will redux
| (it's already pointless) and all the convoluted bullshit
| like redux-saga. If you learn to build stuff using just
| react and other basic dependencies (like express on the
| back end), you'll be in a good position going forward. None
| of that stuff is going anywhere.
| spurgu wrote:
| Gatsby at least spends a lot of effort playing cat and
| mouse with Google's Pagespeed algorithms so you don't
| have to. That by itself has tons of value.
| criddell wrote:
| My instinct is to build a native front end and connect to
| the back end over a REST (or similar) API. To me, that
| feels like the boring technology route.
| BigJono wrote:
| Yeah, that's totally legit, and what I would default to.
|
| The reason stuff like React exists isn't because it's
| some big generic library for doing "frontends" that
| everyone has to use (even though that's how people see
| it, how it's marketed, and how people use it). If you
| want to know what a library is good for it's easiest to
| look at what it was originally built for, the very first
| problem it solved.
|
| For libs like React, that problem is DOM manipulation.
|
| For most of the interesting things you can build on the
| web these days, DOM manipulation becomes a problem at
| some point because the solution has an inherent
| complexity to it that becomes hard to manage. That
| complexity is in procedurally updating the DOM,
| specifically getting the order of insertions and
| deletions correct and keeping track of every possible
| state the DOM can be in to make sure your app doesn't get
| in a weird state that it can't recover from.
|
| The way React (and vue, angular, svelte etc, all the
| modern libraries) fix that problem is by changing the
| programming paradigm from procedural to declarative. The
| declarative paradigm is just fundamentally much simpler
| for the exact problem of handling DOM manipulation in a
| large app.
|
| If you're learning, or building something for yourself
| and not worried about spending time on refactors, then
| it's definitely worth building something in vanilla JS
| first, running into some sticky DOM manipulation
| scenarios yourself, and solving them the hard way. People
| make the mistake of using React when they don't need to
| because they don't have a good understanding of where
| that line is in the inherent complexity of a web
| page/app, where you start to get a very good returns on
| bringing React in to simplify some of that complexity.
|
| That's also why I really don't rate vue, angular or
| svelte. React is a big library in terms of code size
| (over 100KB still I think?), but almost all of that
| complexity is internal. The exact same API and
| functionality is exposed by Preact, which is a few
| kilobytes. React has a really small API, pretty much just
| three functions: createElement, render, and useState. I'm
| a big fan of libraries that do big things with only a few
| functions. Do one thing well and all that. There's also
| the JSX transform, which is a straight line for line
| transform, meaning the code you write is very similar to
| the code that runs in the browser, you can follow it line
| by line with no surprises.
|
| React is a good tool to have in the toolkit, after you've
| gotten comfortable with vanilla JS. I wouldn't write it
| off based on how other people present it. You just need
| to avoid the insane amount of complexity and cruft that
| people have built around it. All that complexity will go
| away when people go running after the new shiny thing,
| but React or something very similar to it will stick
| around for a loooooong time because the fundamental ideas
| are so simple and powerful. DOM control through
| declarative coding, code over configuration, utilising
| the JS language itself as much as possible instead of
| relying on DSLs, and simple transforms that maintain the
| integrity of your code all the way to the production
| build.
|
| If anything replaces React it either have to be quite
| similar, or be another entire paradigm shift (maybe the
| whole DOM/CSSOM thing will get replaced at some stage,
| who knows?)
| ZephyrBlu wrote:
| React has innovated somewhat with lifecycle methods and
| hooks, but the main value is not in it's API. It's the
| ecosystem and scheduler.
|
| Preact is a good alternative if you have a small app, but
| the reason it's so small is because it doesn't have a
| scheduler which might cause issues with larger apps.
| Aeolun wrote:
| > Neither will redux (it's already pointless) and all the
| convoluted bullshit like redux-saga.
|
| I can't speak to your own use case, but redux and saga
| absolutely save our bacon when working on a huge
| enterprise app.
|
| I don't even want to think about the crazy kinds of stuff
| we'd have to do without them.
|
| Maybe someone will come up with a better abstraction, but
| I really think these are fairly good ones.
| wwww4all wrote:
| Have you tried redux toolkit? createSlices?
|
| Redux has greatly improved workflow for integrating with
| React. The main issue with Redux is that it pretends to
| be generalized state management engine, with all the
| overhead, while it's in a shotgun wedding with React.
|
| Will React team attempts another state management, aka
| Flux, when Redux does 95% of features and is slowly being
| absorbed into React eco system anyway?
|
| Gatsby/nextjs will likely merge into a single React
| static site generator. Similar to React router and Reach
| router merger.
|
| React is like jquery, it's going to be around forever.
| React is almost at the core web infrastructure tech
| level, just by consensus alone.
| acemarke wrote:
| Not sure what you mean by the "pretends" statement.
|
| Both the Redux core and Redux Toolkit _are_ completely
| UI-agnostic, and can be used with _any_ UI layer or even
| standalone.
|
| Yes, most Redux usage is with React, and we do orient our
| docs around the assumption that you're probably using
| Redux and React together, but there's many people who are
| using Redux separately.
| wwww4all wrote:
| The "pretends" comment is light hearted joke (or is it?)
| about keeping Redux UI library agnostic. When we all know
| React is the 8000 pound gorilla pulling on Redux.
|
| The default assumption for any production React
| application is that it will need Redux at some point.
| It's much more efficient to start the React project with
| Redux, than trying to bolt on Redux after React project
| is underway after a while. Redux Toolkit does make things
| bit easier.
|
| It's like how React pretends that JSX is optional, when
| we all know JSX is requirement in React projects.
|
| Thanks for all the work on Redux and Redux Toolkit.
| acemarke wrote:
| Fair enough :)
|
| Yeah, as I've been redoing our docs, I've really tried to
| emphasize the "take some time to decide if you _really_
| need Redux" aspect:
|
| https://redux.js.org/tutorials/essentials/part-1-overview
| -co...
|
| FWIW, we do take the "UI-agnostic" part seriously. We've
| got an upcoming new API for Redux Toolkit that we've
| dubbed "RTK Query", currently available as a preview
| release. We've got an example of it working with Svelte,
| and I know I saw someone else trying it out with Vue:
|
| https://rtk-query-docs.netlify.app/examples/svelte
| deckard1 wrote:
| I've been using React since 2014 or so.
|
| I can't speak for Angular or Vue, but I'm 100% sold on
| Svelte. It cuts out all of the crap that React and Redux
| introduced (lifecycles, hooks, boilerplate, etc.) and
| boils it all down to fundamentals. You can read the
| entire docs in a day and fully understand how everything
| fits together. I dare say it, but Svelte's docs are a
| breath of fresh air. It's rare that I read documentation
| and want to keep reading it.
|
| To me, that's what boring tech is about. It's about
| finding the simplest, cleanest way to do what you need to
| do. I hope Svelte takes the path of long-term stability
| over features and complexity and innovation for the sake
| of it. What they have right now is a solid foundation.
|
| > convoluted bullshit like redux-saga
|
| Wait until you meet saga's bigger brother RxJS/redux-
| observable. Someone on HN once mentioned JIRA was using
| RxJS and I realized "ah, that explains why JIRA is the
| slow pile of absolute shit it is." From just knowing a
| company is using RxJS I can already guess at the type of
| internal communication and politics at play in the
| company, as well as what their code base looks like.
| laurent92 wrote:
| and Java?
| gurkendoktor wrote:
| The Java community has some great developers, but also a
| lot of Serious Software Engineers who will sabotage
| everything with extra complexity, and then everyone who
| learned Java in school and never felt like looking at
| another language (not even Kotlin).
|
| Java is definitely "boring technology", but hiring random
| Java developers will probably sink a company faster than
| doing the same for Go.
| whimsicalism wrote:
| > everyone who learned Java in school and never felt like
| looking at another language
|
| A large reason I avoid Java teams.
| cbm-vic-20 wrote:
| The GP comment mentions the need for finding engineers
| with "a proven track record of delivering value", yet
| here we have a concern about "hiring random Java
| developers".
|
| Is the industry biased against great engineers who have
| been working with Java for the past 20 years, even if
| they "deliver value" (which is pretty much impossible to
| determine externally)?
| lostcolony wrote:
| No.
|
| But I, personally, am biased against hiring people with
| only Java on their resume. Because 90% of the time what
| I've encountered are people who haven't examined their
| technology choices, questioned the status quo, tried to
| -improve- things.
|
| That's not a sleight on Java, per se, but it is against
| anyone with only one language on their resume. It's just
| that if there is only one language on a resume in web dev
| land, it's almost always Java.
| blandflakes wrote:
| Yup - it's _possible_ to build uncomplicated software in
| Java, especially in recent iterations of Java and more...
| restrained modern frameworks. However, there 's no
| guarantee that you're actually going to either join a
| team or hire a Java expert with those tastes.
| cutler wrote:
| Although still new I'm wondering whether Kotlin could be
| admitted to the boring technology category given that it
| was built to dovetail with Java and has first class
| Spring support?
| stepbeek wrote:
| I've found kotlin to be wonderfully boring. There are
| definitely some sharp knives that get abused though. I've
| met a few people who want to throw OO in the bin and
| treat kotlin as pure FP to their detriment.
| user5994461 wrote:
| Startups are more commonly on python/ruby/node/php. It's
| faster to start with and to iterate.
|
| Java and .Net are more common in longer-lived, larger
| projects, or when performance matters.
| hackerfromthefu wrote:
| and where maintainability and tco matter
| collyw wrote:
| I think maintainability is mostly down to developer skill
| and the ability to abstract to the right level. A good
| Python dev will likely leave far more maintainable code
| than an average Java dev.
| nift wrote:
| Can't one always say that? Wouldn't it be more fair to
| compare equal level of skill?
|
| I mean, in most cases it doesn't really matter what tech
| you choose as 1. Most products don't really need "massive
| scale" 2. It's more important to be proficient in the
| tech you pick rather than it being the "best tech ever".
| I mean Facebook still uses PHP no?
| jermaustin1 wrote:
| > A good Python dev will likely leave far more
| maintainable code than an average Java dev.
|
| And a GOOD Java dev will likely leave far more
| maintainable code than an AVERAGE Python dev.
| whimsicalism wrote:
| I have yet to see this in an enterprise setting, maybe my
| standard for "average python dev" is too high.
| lostcolony wrote:
| I have yet to see a maintainable Java project of any
| reasonably large size, anywhere.
|
| Java programs are larger than those in other mainstream
| languages, just by dint of the verbosity of the language
| (and research backs this up; studies showing errors per
| LOC are consistent regardless of the language).
|
| Ergo...
| rachelbythebay wrote:
| How about "leaves the industry rather than have to use terrible
| things at dumb companies", thus giving a survival bias that
| selects for shiny. I know I feel that way about a lot of stuff
| now.
| vvanders wrote:
| That's a really common pattern in gamedev too. Median career
| is something like ~3 years so those that stick around are
| okay with the crunch and other shitty parts of the industry.
|
| Combine that with gatekeeping/I did my time you have to do
| yours and not much has changed there over the years.
| blackrock wrote:
| What's the pay like for senior games engineers?
| ryandrake wrote:
| You don't even have to go that drastic. I was also tired of
| the "new technology treadmill" in software development, so I
| just changed roles in the same industry. Did a little product
| management for a while then settled on project management--
| for those same software companies. The pay is much worse but
| at least I'm not spending my time re-writing working software
| into "non-working software, but hey, it's in Scala."
| hkt wrote:
| One of the most relatable posts I've ever seen on HN. Same
| reason I'm working towards getting out.
| mtrovo wrote:
| That's a fair point and I can totally relate to it. There's a
| toxic relationship of startups always trying to one up each
| other to attract more attention as a great place to work and
| in general tech stack is just another tool on this fight. As
| a consequence workers are pushed to the same mindset, where
| fixing a problem with 10 microservices and a dozen AWS
| services is the expected and if you prove you can solve the
| same problem with a single machine running a cronjob with no
| external dependencies you're the weird one.
| soheil wrote:
| > I always found it funny that companies will go to extreme
| Herculean lengths to hire the best programmers
|
| Because you may know how to hire the best or have the skill to
| know who the best are, but you don't know how to _be_ the best,
| so how can you judge their work if by definition you 're not as
| good as they are?
| tootie wrote:
| I've never witnessed rogue engineers. If the team has business-
| driven objectives how could they possibly have enough time to
| chase rainbows? Any time a rewrite or refactor has been done in
| my org, it was pitched up the chain of command and explained in
| terms of business value (ie performance, maintenance,
| retention).
| code_duck wrote:
| I had a small business depending on the Etsy API during the
| time they transitioned some storage to Mongo. The immediate
| effect for us was a downturn in functionality and reliability
| with no apparent advantages. In the midst of other serious
| concerns about their direction, we questioned why Etsy was
| doing this on the API mailing list and were told basically we
| didn't know what we were talking about and it wasn't out
| business. Fair enough, sort of.
|
| It was a hot time for NoSQL and document DBs. Having
| investigated using Mongo myself to little avail, I asked why
| they didn't just use Postgres. If I recall correctly, a couple
| years later they published a Mongo at Etsy postmortem which
| concluded they should have just stayed with Postgres.
| collyw wrote:
| I am left maintaining a mongo db from 7 years ago or so, when
| NoSQL was peak hype cycle. Like you say it's crap.
| NomDePlum wrote:
| Lots of good reasons to use NoSQL. All pretty much hang off
| what sort of data access pattern you need.
|
| If you have an application that retrieves an works on a top
| level entity then NoSQL fits very nicely. When you have a
| dataset that is shared and aggregate information is needed
| not so much and you are likely better of considering a SQL
| database of some sort.
| bitwize wrote:
| > When you have a dataset that is shared and aggregate
| information is needed not so much and you are likely
| better of considering a SQL database of some sort.
|
| There are best practices for this. Simply create a
| microservice per table, and then create a microservice
| that acts as a client to the other services and
| aggregates or joins the data from those services.
|
| No, I'm not kidding. This is literally what people do and
| recommend.
| c-cube wrote:
| And remember to implement distributed 2 phase commit to
| guarantee consistency! So much simpler than using old
| crufty sql
| bitwize wrote:
| Oh, pish and tosh! That's too much engineering! Instead,
| handwave about "eventual consistency" and save millions
| in infrastructure costs! Totally worth it for the
| benefits of being truly abstracted from your data storage
| layer. Because, you know, people change their database
| back ends more often than they change their sheets.
| stepbeek wrote:
| This is a good point. If we ignore obvious key-value
| examples, I'm curious about how much data really isn't
| relational.
| b0afc375b5 wrote:
| For anyone else curious, I found the postmortem here:
|
| https://mcfunley.com/why-mongodb-never-worked-out-at-etsy
|
| Which was compiled here:
|
| https://github.com/icy/w2w
| Kwantuum wrote:
| That repo is interesting. A quick ctrl+F seems to indicate
| that pretty much every instance of "MongoDB" is "Moving
| from Mongo to Postrges or DynamoDB" (there is one single
| entry of moving _to_ Mongo from MySQL). Almost as if Mongo
| is just not a good database (or people are too eager to use
| it for things which it does not do well).
| gravypod wrote:
| Making efficient use if mongodb is very difficult but if
| you build your app and expectations correctly you can get
| something very performant. For example pre-4.x listing
| huge collections was unexpectedly extremely slow.
| chrisco255 wrote:
| Yeah Mongo is 10 years old or so at this point. This
| article was written in 2015 about decisions made years
| earlier. It's now reached maturity and stability. It's
| now "boring tech".
| Yeroc wrote:
| Um, even if it's mature technology that doesn't negate
| the costs of operating two different databases which is a
| large part of what the original presentation is about.
| ChrisMarshallNY wrote:
| I don't do "boring," as much as I do "mature and robust." I
| like _shipping_ products, as opposed to just "writing" them,
| and shipping is boring. Lots of annoying intricacies and
| processes.
|
| I'm writing a fairly large-scale app, right now.
|
| It's written in Swift (frontend), using IB (classic UIKit), and
| PHP/MySQL/Postgres (backend).
|
| It does not use SwiftUI (shiny), or Rust (shiny, but a bit more
| dusty), or some form of NoSQL.
|
| I picked standard UIKit, because I like SwiftUI, but the app
| has a fairly intricate and non-simple storyboard. I am not
| confident that SwiftUI is up to the task, and I _know_ that IB
| can do it.
|
| I've been writing in Swift since the day it was announced, so I
| already know it is up to the task, despite being a fairly new
| kid on the block.
|
| I picked PHP, because I'm already quite decent with it, and,
| despite the hate, it is a perfectly good, performant, proven,
| and supported enterprise language. There's a better than even
| chance the server will be swapped or rewritten in the future,
| so it's a good idea to use my implementation as a PoC and
| architecture model, anyway. It will need to run the system
| during the nascent phase of the project, so it needs to be
| solid and secure. There's no way I will take the risk of
| writing such a critical system, in a language I barely know
| (See this scar? I've done that -long story).
|
| I picked MySQL and Postgres, because they are proven, robust
| databases, and can be installed on most low-cost hosting
| solutions (the app is for an NPO). I used PDO to interact with
| the databases, for security and reliability, anyway, so it's
| entirely possible to add support for more databases, in the
| future.
|
| Also, backend is not my specialty. What I did, was design a
| layered architecture that will allow future "shiny" engineers a
| path to replacing the engine. I wrote an abstraction layer into
| the server, allowing a pretty wholesale subsystem replacement.
| The app communicates with the server through a classic REST-
| like JSON API, so there's another place for a swap. I'm not
| married to a system like GraphQL, with the need for
| dependencies; but the layered architecture allows use of
| GraphQL, anyway, if people really want it (it is cool and
| robust, but is difficult to use without some _big_
| dependencies).
|
| Speaking of dependencies, I do everything in my power to
| eliminate them. I have been _badly_ burned, in the past (not
| too distant, either -I had to do an emergency dependencyectomy,
| just a couple of weeks ago), by over reliance on dependencies.
| It means some extra work, on my part, but not crippling.
|
| Speaking of boring, few things are more boring than
| documentation, testing and quality coding techniques. My
| testing code usually dwarfs my implementation code. I spend
| many boring hours, running tests, and examining results.
|
| In my experience, I don't think I've ever written a test that
| wasn't necessary. They _always_ expose anomalies. I just went
| through that, in the last week or so, as I was refactoring a
| legacy system for the app I'm writing. I actually encountered
| and fixed a couple of issues (including a really embarrassing
| and scary security bug) that have been in the backend for two
| years.
|
| But that's just me. WFM. YMMV.
| oblio wrote:
| Why 2 DBs?
| ChrisMarshallNY wrote:
| Wow. Someone actually looked at the project.
|
| I set it up, so that all the security stuff was sequestered
| into its own "silo." This allows things like using
| monitoring and logging, or a hardened host, without
| affecting the main datastore.
|
| The deal is, is that I expect the tech to get swapped out,
| down the line, for something more modern, and it might not
| even use SQL. But security is quite important (especially
| with the target user base of the initial release). I went
| kind of overboard with some structural support for
| security. I am quite aware that I could get better
| performance from a single, related DB, but I wanted to
| start off with an infrastructure-level support for
| security, with the anticipation of future tech making up
| for any performance issues.
|
| In my experience, security is often spackled on, after the
| fact, and I think that it's important to start from
| scratch, with security.
|
| Also, note the ridiculous simplicity of the DB schemas.
| That was because I used... _yecchhh_ object-oriented design
| as the Model, and the datastore actually represents a
| generic base class state. This allowed me to write a whole
| bunch of code, early on, and test it, then never have to
| look at it again. The implementation was done in layers,
| over a period of seven months. Each layer was treated as a
| standalone project, with its own lifecycle and testing. The
| idea was to develop a robust structure that I could
| consider reliable, then build on top of that.
|
| It worked fairly well.
| cutler wrote:
| Isn't all this planning for future redundancy what the
| article is arguing against?
| ChrisMarshallNY wrote:
| I don't look at it that way. I have a very "wishy-washy"
| design approach. I call it "paving the bare spots"[0]. It's
| definitely not a "classic" approach, and it would not be
| something that I would recommend to anyone that is not
| extremely experienced.
|
| The idea is that I am not actually aware of what the final
| product will look like, when I start, so I take a very
| careful approach. I spent 27 years, working for a
| "Waterfall-based" corporation, where the system had to be
| 100% designed up front, and the end result would "meet
| spec," while still sucking. I am not particularly thrilled
| with many agile approaches, either, as I see many of the
| same problems. It's really just shifting the tech debt
| around.
|
| My approach actually results in my having to throw away a
| lot of really good, tested, code, but I still end up moving
| lightning fast, and coming out with good results. If you
| look at my portfolio, you will see a whole bunch of small,
| heavily-tested module projects. Many of these were things
| that I ripped out of other projects, but didn't want to
| throw away. Some of them are crazy useful, like the
| Persistent Prefs Utility[1], or the Generic Swift Toolbox
| utilities[2], which show up in most of my work. The fact
| that they are treated as independent projects, with heavy
| testing, means that I can reuse them with confidence.
|
| The Spinner project[3] was an example of a UI I designed to
| be a central aspect of an app, then decided not to use it,
| as it deviated too much from the user workflow I had in
| mind. It will be back, but not until it's the best
| approach. Eye candy is nice, but it still needs to be
| usable.
|
| That modular approach is not new at all. I think I may have
| been doing it since the early nineties.
|
| True, there is flexibility, but that flexibility is
| implemented as a single-point hinge, not a bendable
| continuum. It's very clear where the flexibility goes, and
| that point is well-tested. I just got done refactoring the
| server, where I added a more flexible way of allowing users
| to implement security postures, and I'm really, really glad
| that I did things the way that I did. It was a pretty big
| job, adding personal tokens (the new functionality), but a
| lot of the work was making sure that I stuck with the
| "philosophical" domains of each layer, and testing the
| living bejeezus out of the code.
|
| And each point of flexibility has a very clear domain. For
| example, the ANDISIOL layer is where the SQL turns into
| functions. You can rip out everything below that, and
| replace it with whatever you like, as long as the same
| functional API is presented to BASALT. That's a fairly
| classic pattern.
|
| [0] https://littlegreenviper.com/miscellany/the-road-most-
| travel...
|
| [1] https://riftvalleysoftware.com/work/open-source-
| projects/#RV...
|
| [2] https://riftvalleysoftware.com/work/open-source-
| projects/#to...
|
| [3] https://riftvalleysoftware.com/work/open-source-
| projects/#RV...
| lapcatsoftware wrote:
| > I don't do "boring," as much as I do "mature and robust."
|
| > I've been writing in Swift since the day it was announced
|
| May I ask how you consider these to be compatible?
| ChrisMarshallNY wrote:
| _> May I ask how you consider these to be compatible?_
|
| It was a calculated risk. Since the company I was working
| for, at the time, was never going to use Swift, my "bread
| and butter" was at no risk, whatsoever. We were a C++ shop.
| I just started working with it on nights and weekends.
|
| Being a C++ shop, however, we were quite familiar with
| Lattner and LLVM, so we were aware of his propensity for
| WIN. That gave me some confidence, going forward. Also,
| Apple didn't just announce a language. They also announced
| a full system API, as well as a product roadmap. The API
| showed they were serious about it. Those don't come in
| Cracker Jack boxes. They take some _serious_ work and
| investment.
|
| It was definitely a risk, but I'm a conservative, scarred
| veteran of many errors in judgment (can you say "OpenDoc"?
| I knew you could!). I wasn't about to run into a burning
| dumpster, half-assed, and I thought it was worth it. I knew
| it would take four or five years to mature, and it has. I
| tend to play the long game. I learned that, from all those
| years, working with the Japanese.
| asphaltycode wrote:
| I appreciate these posts quite a bit. Can you give
| another example of "playing the long game"?
| lapcatsoftware wrote:
| > I actually mentioned that. Like, immediately after the
| quoted phrase.
|
| I'm rereading your previous comment multiple times but
| unfortunately still failing to see what you're referring
| to. The only explanation I can see is "we were quite
| familiar with Lattner and LLVM, so we were quite aware of
| his propensity for WIN. That gave me some confidence,
| going forward."
|
| > They also announced a full system API, as well as a
| product roadmap.
|
| I'm not quite sure what you mean by "a full system API",
| and does Apple _ever_ announce a product roadmap? I would
| definitely be interested in this roadmap of which you
| speak. :-)
| ChrisMarshallNY wrote:
| You are correct. It was the next comment I made (so I
| removed that smartass line).
|
| I apologize.
|
| They have had a Swift roadmap forever. I think it's now
| kept on swift.org. I'll see if I can find it. I think
| it's a fairly sparse one. I really only cared about the
| evolution through ABI Stable. All I needed to hear, was
| that was a goal.
|
| You are right. They tend to eschew roadmaps, but they did
| a "hard-sell" with Swift. They knew it would be difficult
| to build momentum with.
|
| "Full System API" is the native frameworks; UIKit,
| AppKit, WatchKit, etc., as well as things like WebKit and
| MapKit.
|
| When Swift was announced, they had APIs for most of that
| stuff. I was pleasantly surprised. I had a full app,
| working within a day or so (using beta Xcode, of course).
| lapcatsoftware wrote:
| > I really only cared about the evolution through ABI
| Stable.
|
| Ok, but that came later and wasn't present in 2014.
|
| > they did a "hard-sell" with Swift
|
| I agree with that. :-)
|
| > "Full System API" is the native frameworks; UIKit,
| AppKit, WatchKit, etc., as well as things like WebKit and
| MapKit.
|
| Swift did of course have bridging to Objective-C and the
| preexisting Objective-C API. I find it strange to equate
| language bridging with announcing a full system API -- an
| API originally announced around the turn of the century
| (can't believe I'm using that phrase now). Cocoa-Java,
| which no longer exists, also had such bridging, as does
| PyObjC and MacRuby/RubyCocoa. Still, most of the system
| API to this day are written by Apple in Objective-C.
| ChrisMarshallNY wrote:
| That's a good point. I never thought of that. It was
| actually an old bridge. I remember when they tried to
| make Java a "full citizen" language. Boy, that flopped...
|
| SwiftUI shows promise, but it is still quite nascent.
|
| Pretty much every bit of code I write is "pure" Swift
| linkage. I like things like Swift's enums too much to
| give them up. They make APIs really fun.
| addicted wrote:
| The blog isn't really an argument against MongoDB however.
|
| In many ways it's an argument for MongoDB considering if you've
| built a JS based application MongoDB minimizes any additional
| learning and having to translate between the objects on the
| front end and in the backend. Non relational DBs are also
| easier to scale horizontally without requiring any application
| changes.
|
| The OP is an argument against introducing new technology
| without a significant clear benefit. It's basically saying that
| simply having a new tech can add significant complexity,
| unknown unknowns, and require much more maintenance and other
| costs.
|
| So if your web application is currently running on MongoDB and
| it's running well then this is an argument to stick to MongoDB
| instead of say migrating to postgresql going forward.
| Buttons840 wrote:
| > The engineers are bored and they're rewriting perfectly-good
| codebases in Common Lisp and OCAML for funsies?
|
| Sounds like the bored engineers need to be allowed to go home
| early, or have some 20% projects.
|
| Also, as John Gall teaches us with his tounge-in-cheek, yet
| never-the-less true principles[1] -- a principle so obvious
| most never give it any thought:
|
| "New System, New Problems"
|
| Can someone please just ask "what do we expect some of the new
| problems to be?" If you get blank stares and no good answers,
| then you know they haven't thought it through.
|
| [1]: https://en.wikipedia.org/wiki/Systemantics
| theptip wrote:
| > "what do we expect some of the new problems to be?"
|
| A name for this I've heard (and use) is the "pre-mortem"; you
| can get folks in the right headspace for what you are
| suggesting by asking them to imagine they are writing a post-
| mortem after the proposed initiative failed.
|
| A good way of surfacing failure modes / potential quagmires.
| Buttons840 wrote:
| > imagine they are writing a post-mortem after the proposed
| initiative failed
|
| I was thinking more along the lines of "imagine they are
| writing a post-mortem after the proposed initiative
| _succeeds_ ". Even if everything goes perfectly, what do we
| honestly expect to have at the end? A system without
| problems? Nonsense.
| carapace wrote:
| > trying to rewrite Etsy's backend in Scala and MongoDB.
|
| The first Sid came in and wanted to rewrite in C++.
|
| Then the second Sid wanted to rewrite in Java.
|
| The whole time the HTML is 25% space chars, served, sent,
| received, discarded, because the PHP guy likes deep
| indentation, and the DB is constantly burning like the sun
| because all the business logic is in stored procedures.
|
| (That was the problem, not which abstraction the servers are
| written in, since all they do is pass data back and forth to
| the fiery inferno of the database.)
| austincheney wrote:
| You are clearly not a JavaScript developer. It really feels
| like everybody has just given up and thrown in the towel. There
| are no good developers, let some giant monster framework make
| all your decisions, and frequently chase shiny shit. Of course
| this means starting over, from scratch, in small sections of
| the product every couple of years.
|
| > The industry constantly mints senior engineers who have been
| bitten by complexity, but doesn't want to hire them, or listen
| to them.
|
| Again, in JavaScript land that is not what it sounds like. The
| industry has minted a bazillion expert beginners who have never
| moved out of their parent's basement and had to live on their
| own (in a technology sense). They are fanatically _invented
| here_ fearing original code more than job termination and now
| they have somehow risen to make architectural decisions about
| the future health of your software and business.
|
| I guess they failed to understand that choosing boring software
| is different than depending on a package manager to write all
| your software.
| monsieurbanana wrote:
| I'm not used to see that amount of hate directed to fellow
| programmers in a hn comment.
| collyw wrote:
| There is no hate in that comment, just criticism.
| sdfsfsf3kjdf wrote:
| Extremely shallow criticism based off of little more than
| personal anecdotes.
| austincheney wrote:
| Most comments, on any subject, that aren't praise fit
| that description.
| austincheney wrote:
| There was no hate intended in my comment, but I can
| understand how you came to that conclusion. My experience
| posting on r/javascript of Reddit has taught me some
| developers are insecure, extreme conspiracy-theory paranoid
| insecure, about working without their favorite framework.
| spion wrote:
| How much experience do you have working with JS?
| austincheney wrote:
| I have been writing it full time about 13 years. I love
| writing in this language, and TypeScript even more. I am
| just frustrated by what appears to be some combination of
| insecurity, false expertise, and a vehement lack of
| passion in the work force. If I want to be happy I should
| move on to a different technology stack, but I really
| enjoy making products in this language.
| BigJono wrote:
| It's funny, I have about 13 years experience, have been
| senior in both enterprise, start-ups and everything in-
| between, and have basically the exact same view about
| front end dev as your original post.
|
| Except I fucking hate using Typescript, and totally
| wasn't expecting to see you mention you like it, given
| all the other stuff.
|
| IME all the same people that overengineer everything with
| god awful dependencies are the same ones pushing super
| hard for typescript on every project I'm on. When they
| get their way (as always, since everything is decided
| democratically and everyone is dragged down to the level
| of the worst dev on the team), they write the worst
| typescript ever. On my last project, one of the people
| championing typescript defined some constant strings
| containing css breakpoints as the type 'string | int'.
| Rather than getting knocked back as one of the dumbest
| lines of code in the history of front-end, this somehow
| generated 3 pages of discussion in code review then got
| left in. I'd give the person a pass, assuming they'd
| never used a typed language before, except (a) they were
| senior and (b) they're the one that wanted types. These
| "seniors" lack even the most basic understanding of the
| shit they're using, but feel the need to impose their
| opinions about libraries, tooling and languages
| constantly.
|
| I don't feel like I'd mind using TS at all on my personal
| projects, but on work projects with average devs it just
| adds another entire layer of complexity that they spend
| hours and days and weeks and months wrangling with
| instead of writing any code that might be remotely
| useful, by say, maybe implementing a business
| requirement, or doing anything that makes the company
| money instead of pissing away millions in salaries
| playing npm lego.
|
| Plus, although I'm not familiar with any of it since I'm
| never the one pushing for TS, and so never the one
| setting it up, I've seen people spend absolutely
| ludicrous amounts of time tinkering with webpack and
| fussing over TS integration with 3rd party libraries and
| whatnot.
|
| I'm surprised you haven't run into more of these people
| that just seem to use TS as a complexity multiplier for
| every bad engineering decision they make. Like spending 6
| months setting up Gatsby or Next isn't costly enough for
| them, so they decide to tack on 3 months of TS
| integration and 'upskilling' for 3000 combo points, when
| they already (more or less, usually less) know how to
| write Javascript.
| austincheney wrote:
| TypeScript is nice when you are working with data
| structures because everything can be defined as
| interfaces, including functions and methods. This allows
| you to identify errors as you are writing code instead of
| having to execute it. Of course this only works if you
| make use of strict type definitions. TypeScript is like
| steroids in that it only makes you more of what you
| already are, which could be quite negative. TypeScript is
| not a supplement for missing discipline.
|
| > I'm surprised you haven't run into more of these people
| that just seem to use TS as a complexity multiplier for
| every bad engineering decision they make.
|
| AngularJS claims to be TypeScript but most instances of
| Angular code rarely make use of type definitions, which
| then defeats the whole point of TypeScript and then only
| contributes to spaghetti and tech debt.
| deckard1 wrote:
| > some constant strings containing css breakpoints as the
| type 'string | int'
|
| yeah this really is the fundamental problem with
| TypeScript advocates. They seem to come in two different
| breeds: A) people that would rather be doing Haskell but
| are forced to use JavaScript because that's where the
| jobs are and see nothing at all wrong with type inference
| and error messages that are 10 lines long and completely
| indecipherable by actual humans, and B) people that have
| never used a language that isn't JavaScript and have no
| clue how to structure type interfaces within an actual
| system (you end up with partial/omit and optional fields
| every-fucking-where and no rhyme or reason behind
| anything).
|
| For some stupid reason this entire industry seems to
| suddenly believe that a 40+ year old debate of static vs.
| dynamic typing was settled because Microsoft came out
| with TypeScript.
| spion wrote:
| This really isn't true, and TypeScript _is_ fundamentally
| different from most other typed languages (except perhaps
| for typed Scheme / typed Racket) and as such is often
| used in different ways. You should look into the
| differences.
| [deleted]
| spion wrote:
| Similar situation here. I disagree that frameworks are
| the problem though. Build tools, especially related to
| CSS and assets are IMO the biggest issue. TypeScript's
| support for monorepos could also be better.
|
| Things have improved a lot since 2009 however, IMO. There
| was barely a concept of modularity at that time, the
| tools (e.g. AMD / requirejs / r.js) were way worse and
| managing the state of the DOM was a pain, jQuery or
| otherwise.
| mro_name wrote:
| I always wonder how package managers go along with software
| engineering maturity level > 1 requiring repeatability.
| chokeartist wrote:
| > The last line of defense against a rogue engineering team is
| managers who have studied this stuff. How many engineering
| managers can spot the common situation "the engineers are bored
| and they're rewriting perfectly-good codebases in Common Lisp
| and OCAML for funsies"? And how many know what to do about it
| when they see it?
|
| Also product managers (myself) who hold the P&L bag and tell
| folks like them to get fucking real when they are smoking dope.
| jboy55 wrote:
| "the engineers are bored and they're rewriting perfectly-good
| codebases in Common Lisp and OCAML for funsies"
|
| Had this literally happen to me, but I was a low level manager
| and this was happening in another team. One thing I've taken
| from it, at the time the feeling around Sr Management was that
| we needed to allow this or we would lose the engineers. They
| allowed it, and after the conversion, those engineers left to
| start their own company. The remaining engineers had to deal
| with undocumented OCaml code and keep it running and were
| resentful.
|
| I have seen this with React vs Vue, where an engineer not
| liking React, just did his code in Vue. 'We have to let him do
| this or he'll leave', but he left on his own accord.
|
| Lesson, stick up for your codebase, and if engineers don't like
| it, let them leave or make them leave. The other engineers on
| your team will like it, and some of them will become your new
| Sr Engineers.
| DC1350 wrote:
| Anyone in a hiring market that favors the job seekers has to
| look out for this. Employers typically see the employee as a
| tool to solve their problems, but I think a lot of managers
| don't pay attention to employees who use the company as a tool
| to further their careers. Resume driven development, chasing
| metrics, and self promotion are way faster routes to progress
| than actually doing a good job. Getting the job I want is a
| long process. I'm going to take the most direct route to that,
| and it's a manager's job to make sure our interests are
| aligned.
| Nextgrid wrote:
| In the case of a lot of tech companies, the entire market is
| broken and leads to weird incentives rarely seen in any other
| industry: companies that aren't profitable, don't have a real
| product people pay for, don't have a clear, plausible path to
| profitability and yet somehow stay in business because
| investors are happy to burn money.
|
| This completely reverses the typical market dynamics. The
| company is more focused on catering to investor's wet dreams
| than actually solving business problems, and "engineering
| playgrounds" with 3 different programming languages,
| microservices, AI & blockchain netting them a 5-figure monthly
| AWS bill is something that appears to please investors more
| than a rock-solid, "boring" backend. Maybe the complex
| architecture succeeds at obfuscating the fact there's no
| business model nor plans for one?
| thewarrior wrote:
| Job hopping programmers are compensated for how rare their
| skill is and not how much value they add to the business.
| It's another flaw in capitalism.
|
| Reward employees a direct and substantial cut of the profits
| and incentivize to them to stay 5-10 years and these
| behaviors should disappear.
|
| The loss of job security, frequent job hopping has created
| more incentives to optimize for the next job switch and not
| value add.
|
| The explosion of startups also contributes to this. They
| often have to attract employees by offering the promise of
| new tech. New tech can propagate these days same way how
| Bitcoin prices rise. Our industry is in a financial bubble
| which has created a complexity bubble. The financial bubble
| collapsing will pop the complexity bubble leading to huge
| surge in boring / low overhead stable tech.
|
| Not to mention how ageism plays into this. People will hire
| someone who spent the past 5 years switching between 5
| different JavaScript frameworks over someone who spent five
| years writing Java at some boring company.
|
| Most startup employees know they aren't getting rich. They go
| on to milk the startup for maximum resume points and move on.
|
| The VCs unload these bloated companies into inflated stock
| markets and the cycle continues. Some small progress at the
| cost of tens of billions and lots of running in the same
| place.
|
| Our industry is like some eccentric Howard Hughes drowning in
| so much money that all we do is come up with ever more
| esoteric contraptions to escape from reality.
|
| DHH starts really small companies and pays his employees
| really well and doesn't work them too hard. Employees have no
| real reason to leave. They see a direct link between the low
| overhead and their job security and work life balance. Since
| the team is smaller the work is less alienating / hyper
| specialized leading to a deeper connection with the company
| and its customers. Aligning incentives fixes a lot of
| problems.
| postfacto wrote:
| Why the downvotes? This comment's dead accurate.
| Toine wrote:
| Damn, spot on.
| eloff wrote:
| I don't buy this theory, because I don't think there are many
| investors that actually care about the tech stack. If they
| are, I'd say they're bad investors.
|
| You could create a successful company on any tech stack. It's
| really like trying to invest in a company based on the way
| they decorate their HQ. Does it matter at all? Maybe only if
| it's ridiculously extravagant compared to their revenue.
| astura wrote:
| >I'd say they're bad investors.
|
| No argument from me there.
| tluyben2 wrote:
| I often wonder why investors love paying 5 figure aws bills;
| even worse, why they consider lower bills or not using 'the
| cloud' a sign of cto incompetence. Even if the company can
| run on $500 hosting instead. Must be because it is easy to do
| DD on: AWS, check, TS (JS is now a reason to not pass VC dd I
| heard from friends) check , React check, microservices,
| check, etc.
| aeternum wrote:
| Not using the cloud has many hidden risks. You need
| multiple physical locations for reliability, those now need
| to be staffed.
|
| If you instead use cheaper 3rd party hosting companies, you
| may have hurdles to growth and future migration cost since
| those companies do not have many of the certifications
| required.
|
| From an investor POV, paying a little extra now is often
| worth it to reduce risk and remove barriers to explosive
| growth.
| ksec wrote:
| 1. They are already an investor in Amazon. They have an
| interest, both in the actual spending and the trend setting
| of current and future companies to use AWS.
|
| 2. It is actually increasingly hard to get an industry wide
| reputable hosting provider ( Cloud, VPS , Metal or not )
| that many investors could agree upon. Just like you said
| which makes DD harder.
|
| 3. Amazon actually offer heavy discount and even lots free
| credit to startup by accredited VC. Meaning the difference
| in the first few years is actually tiny. And in your
| example, if it can be run on $500 budget elsewhere you can
| bet it will literally be free on AWS from those startup.
| dehrmann wrote:
| There's definitely a stage for startups where the AWS bill
| doesn't matter because sustaining user growth is more
| important, but there's also a stage where the company,
| usually B2B, is trying to improve margins because it helps
| a lot with valuation.
| jacquesm wrote:
| My main recipe for crisis management when a company is about to
| go off the rails or if it has already happened: cut down on
| complexity. 9 out of 10 times that's enough to get things
| moving again. Highly frustrating that we keep making these
| mistakes over and over again without ever learning from them.
| Complexity has a price, you should only spend it if you really
| need it.
| aidos wrote:
| It's hard enough managing code complexity in software
| projects; introducing tooling into the stack that exacerbates
| the issues is definitely a large own goal.
| jacquesm wrote:
| One of the main culprits is often virtualization. Used
| without a good understanding of what goes on under the hood
| it is super easy to create a situation that heavily
| overloads some data path to storage without being aware of
| it because it's all so nicely abstracted away. Fifty
| virtual machines trying to access the same storage layer is
| a pretty good recipe for a disaster.
| spmurrayzzz wrote:
| This is often a struggle I've had as an engineering manager
| (though also as an active individual contributor). When I push
| back on adding new components roughshod to a stack, its often
| framed as "not invented here" dogma. I certainly can do a
| better job at communicating my sentiments, because I can and do
| predictably come off as a "grumpy old man" in these
| conversations.
|
| But more often than not, this feedback comes from engineers
| that a) have never been (as you say) bitten by complexity, or
| b) they aren't in the position to deal with all the negative
| consequences for those decisions.
|
| There's probably some wisdom in letting your direct reports
| experience the kinds of failure in making these decisions, so
| they develop that sort of empathy, but the cost of that failure
| is sometimes just unacceptable for the business; especially in
| periods of cash runway constraints.
| twic wrote:
| > How many engineering managers can spot the common situation
| "the engineers are bored and they're rewriting perfectly-good
| codebases in Common Lisp and OCAML for funsies"? And how many
| know what to do about it when they see it?
|
| I think there is a tension between this kind of actively
| guiding anti-complexity management and hiring "top talent".
|
| The very best developers are capable, and avoid complexity. The
| next best developers are capable, and love complexity. The
| worst developers are not capable.
|
| There aren't enough of the very best developers for a company
| to plan around hiring only those. So, if you want to hire
| developers who are at least capable, you have to give them some
| leeway to make things overcomplicated. Yes, that incurs a real
| cost to the business. You can think of that as just being
| another part of their compensation package.
| jacobr1 wrote:
| Also it is almost never for "funsies," it is instead usually
| the "wrong solution" to a very real problem. The current
| system has bad performance, or doesn't support some new use
| case that is a major company initiative or whatever. But
| instead of fixing/augmenting the existing system the
| (probably multiple accumulated pain points by now) are used
| to justify an overly complex change. In fact the change
| probably becomes known internally at the company as some
| silver bullet that will fix all woes further reinforcing the
| drive to do it.
|
| Even the best developers get ignored if they try to justify
| pure-tech-debt fixes. So they learn to include fixing tech-
| debt as part of a fixing a problem that has some _direct_
| business relevance if addressed. This gets clearly observed
| and taught to the all tiers of developers further obscuring
| the rationale for architectural changes from more senior
| management.
| BigJono wrote:
| Yeah the key thing here is it's just so easy to spin
| anything as the solution to some problem the company has,
| and there's always problems around.
|
| "for funsies" probably isn't that far off. Because the
| process is more like someone gets interested in something
| at some point. Then at that point +~1-6 months someone
| raises a problem and some senior dev gets stuck on the idea
| that the awesome thing they read about can solve it. Then
| before you know it whatever tool they want to use has more
| bells and whistles than the average mars lander and does
| everything short of curing cancer.
|
| There's rarely any good correlation between the problem and
| the solution. That gap can just be bridged by buzzwords.
| The true correlation is usually between the solution and
| whatever the most senior dev on the team thinks is shiniest
| at the moment.
| vp8989 wrote:
| "The very best developers are capable, and avoid complexity.
| The next best developers are capable, and love complexity.
| The worst developers are not capable."
|
| It's not always in one's control to avoid complexity. The
| simplest solution to a problem in a lot of cases may be 2-3x
| the lift (simplicity tends to require more work, complexity
| is easy) and thus blocked by the business. A holistically
| simpler solution may be blocked politically because a certain
| team doesn't want to own some functionality etc ...
|
| I would say the best developers can see complexity coming and
| have a healthy fear of it, the medium devs don't mind
| complexity and the worst devs can't get _anything_ done
| without increasing complexity.
| ZephyrBlu wrote:
| It seems like a lot of people are too lazy to simplify
| things though.
|
| You see this a lot with writing as well. It's very easy to
| ramble on, it's very hard to concisely convey your point.
| zmmmmm wrote:
| > The simplest solution to a problem in a lot of cases may
| be 2-3x
|
| This is such an important point. For whatever reason it has
| become ingrained in people's heads that the simplest
| solution must by reductionist logic be the easiest one. And
| therefore the easiest solution is the simplest one and it
| is good to be lazy and just introduce complexity
| everywhere.
| lapcatsoftware wrote:
| > There aren't enough of the very best developers for a
| company to plan around hiring only those.
|
| I've seen no evidence that companies are even _trying_ to
| hire developers who "avoid complexity". If anything, the
| interview processes are designed to select for engineers who
| bathe in complexity. There are so many interviews which
| consist of "How would you rewrite from scratch this thing
| that already exists?"
| koonsolo wrote:
| I'm doing technical interviews.
|
| There is such a shortage of people that know the basics of
| programming, that selecting for such l33t skills is out of
| the question.
|
| The hiring process right now is not about selecting the
| best, it's about selecting those that pass some low bar.
| ZephyrBlu wrote:
| What do you classify as the basics of programming. for
| loops and if statements?
| koonsolo wrote:
| Maybe I exagerated, but you can't believe that 50% of
| candidates have such a low capability.
|
| "How high do you score your C++ skills out of 10?" "9/10"
| "OK, can you explain what a pointer is?" blank stare...
| "no idea"
| ZephyrBlu wrote:
| I was genuinely curious what you classed as basic
| programming.
|
| I would definitely consider pointers pretty fundamental
| if you're a C++ dev.
|
| It is pretty hard to believe that 50% of candidates don't
| know what a pointer is. I've barely touched C/C++ and
| still know what pointers are and how they work.
| meheleventyone wrote:
| > I've barely touched C/C++ and still know what pointers
| are and how they work.
|
| Congratulations you've successfully triggered the
| pedantic interviewer. You will now face six questions on
| pointers in C++ they just looked up each more trivia
| based than the last.
| lapcatsoftware wrote:
| Who would pass the technical screen must answer me these
| questions three, ere the onsite he see.
| ryandrake wrote:
| I don't know what your company is, but it may not have a
| reputation for paying well. I've worked both at well-
| paying FAANG companies and lots of BasicAverageTech
| companies, and the candidate flow is night and day
| different. There is no shortage of people that "know the
| basics." In fact, there is no shortage of really strong
| candidates. They are out there, looking around to job hop
| like everyone else. It's just that they are probably just
| not applying at your company. Not that you can personally
| do anything about your company's compensation, but that
| might explain it.
| koonsolo wrote:
| This is europe, and as far as I can tell all companies
| here have that problem.
|
| On the other hand, great for us who can code :D.
| koonsolo wrote:
| There is one problem with this: It will get on the nerves of
| the developers that love simplicity.
|
| I'm one of those, and it really gets on my nerves when
| systems are overengineerd, or use tech that has more
| drawbacks than benefits for our specific case.
| zmmmmm wrote:
| > So, if you want to hire developers who are at least
| capable, you have to give them some leeway to make things
| overcomplicated
|
| This is always a challenge in general - how do people learn
| the lessons of complexity without creating it and then seeing
| the effects? I wish there was a better word for it as every
| person who reads "complexity" says well "duh of course I
| don't want that" before they then go and manufacture another
| bucket full of it. Complexity masquerades as simplicity - in
| the first instance it nearly always solves the immediate
| problem better than anything else. Recognising the latent
| complexity of choices is one of the hardest but most
| important skills to learn.
| mrweasel wrote:
| That's definitely part of it. I also think developer sometimes
| aren't sufficiently critical when picking technologies and
| solutions. They fall into the trap of looking at how bigger
| companies operate, without considering if they actually have
| the same requirement, budget or even problem.
|
| For example, you need a search feature. ElasticSearch is big in
| search, there's lots of article about people implementing
| ElasticSearch. Very infrequently do I meet people who just
| starts out with the full text search in their database, or
| maybe just try something extremely simple, like Sphinx, even if
| it would solve their problem quicker, safer and cheaper.
|
| It's honestly starting to become a bigger and bigger issue.
| During the last few weeks I've talked to one customer who is
| think: Kubernetes. They don't have the funds, staff or need for
| Kubernetes. What they do need to do here and now is to focus on
| smarter utilisation of their cloud providers features and
| reduce the reliance on expensive VMs.
|
| Another customer is going all in and wants to implement all the
| things. We're talking Kubernetes, Kafka, ElasticSearch and
| more. They'r are currently running on just a small number of
| VMs. While their stack does need updating, maybe start smaller?
| stepbeek wrote:
| Great point. I'm working with a client right now where 90% of
| the operational pain and low impact dev could be resolved by
| admitting that the project does not need to resemble a FAANG
| system.
| yw3410 wrote:
| The problem is the client doesn't want to admit it - if you
| ask the client how much volume they're realistically
| expecting and they insist on a ludicrous number; what do
| you do?
| deckard1 wrote:
| One company I worked for went to great lengths to emulate
| FAANG.
|
| But they were a medium sized company. They were absolutely
| _crushed_ under the weight of FAANG "best practices" and
| technology. They lost time rewriting perfectly fine code.
| They chased the microservice fad. And they lost market
| share.
|
| It's in the interest of FAANG to maintain this idea of
| needing k8s, this massive CI pipeline, certain processes,
| etc. etc. Because _it slows down competition_. It halts
| startups. It slows progress. They want to throw as much
| overhead as possible at smaller companies.
|
| The thing people need to realize is that FAANG are
| _entrenched_. They are as risk-adverse as can be. They will
| happily write unit tests and maintain 100% test coverage
| and do all of this crap because they are more scared of
| losing market share than innovation. They are in full
| defense mode. Google is implementing all manner of
| protectionism to maintain their ad market, for example.
| Plus, they have the deep pockets to pull it off. Any
| company smaller than FAANG will sit there with their wheels
| spinning.
| lumost wrote:
| It's a mixed bag, if you hire engineers who exclusively want to
| refine the existing toolchain - you may find that solving new
| product problems becomes more difficult. You may get stuck with
| an ancient oracle stack drawing down your entire companies
| profit margin. Or the team responsible for some technology has
| ossified so heavily that your launch date is moved to twenty
| never.
|
| You can immediately spot a misaligned engineering culture when
| every team has its own tech stack and its own ops as it means
| that none of the teams trusted each other for anything and had
| to resort to federation. On the flip side you can se bad
| engineering cultures where decisions are made based on pure
| conformity with what was previously built regardless of the
| problem being solved.
|
| There's a happy middle-ground, a company like etsy with 200-400
| engineers can happily afford a small team of 2 engineers trying
| out scala/mongo for something, it might work out, and nuking it
| from orbit won't cost _that much_ in the grand scale of things.
| jay_kyburz wrote:
| TIL: Complect: To join by weaving or twining together;
| interweave.
| rajacombinator wrote:
| >counting on managers to _defend_ against this behavior and not
| actively promote and drive it
|
| Good luck...
| madeofpalk wrote:
| This reminds me of Google's mysterious new operating system
| "Fuchsia" that they've been developing semi-publicly, which was
| said to mainly be a "senior talent retention program"
| layoutIfNeeded wrote:
| It's not really about retaining talent, rather preventing
| them working for their competitors.
| roenxi wrote:
| They are fearful and paranoid of making a bad hire _because_
| they don 't know how to assess whether the engineer is
| destroying the company from the inside.
|
| If there was a reliable general algorithm to make good software
| managers would hire lousy engineers then tell them to execute
| the algorithm. There isn't, they can't. The fallback is to be
| as picky as possible about who has influence on the software.
| whimsicalism wrote:
| > They are fearful and paranoid of making a bad hire because
| they don't know how to assess whether the engineer is
| destroying the company from the inside.
|
| This is the obvious conclusion. I wonder when investors will
| wake up to the value of having engineering-savvy management.
| a1369209993 wrote:
| > I wonder when investors will wake up to the value of
| having engineering-savvy management.
|
| To be fair, engineering-savviness and willingness to be
| management (especially the kind of management that are
| legible to investors) are substantially anticorrelated.
| agumonkey wrote:
| It seems companies have emergent human emotions, we all do the
| same, 'worry too much then trust and forget' rather than go
| gradual and long term.
| nicois wrote:
| The redis/memcache example doesn't make a lot of sense to me,
| unless the idea is that a separate memcache instance is deployed
| alongside each backend, while redis would have been a single
| instance.
|
| I'm all for boring technology; reimplementing web protocols and
| semantics in JS is a disaster - and would probably have made a
| clearer case study than comparing to memory-first database
| caches.
| the_gipsy wrote:
| Especially when he said that some people _did_ have to work on
| that setup to scale it up. Sounds like devops work, so the same
| would have happened with redis, right?
| CamouflagedKiwi wrote:
| He covers this - the operational setup & expertise to scale
| Memcached already existed because Etsy already used it
| elsewhere. It would have had to be built and learned (mostly)
| separately for Redis.
| the_gipsy wrote:
| I meant the part where he talks about maintenance later on.
| ryanbrunner wrote:
| Maintenance is also something that has to be learned (and
| "built up" in the sense that you're going to accumulate
| playbooks and processes over time).
|
| If a team already existed that knew the ins and outs of
| memcached, knew how to resolve any problems it
| encountered, already had appropriate monitoring / alarms
| / etc, that's a massive leg up over needing to do all
| that with a completely new technology.
| muramira wrote:
| Lots of people here are shitting on mongodb(maybe rightly so).
| But I think the biggest problem is that the developers making the
| decision on what kind of DB to use just do not understand these
| tools. I always recommend reading Designing Data Intensive
| Applications as soon as you have an inkling that you will be
| asked to make such decisions in the near future.
| XCSme wrote:
| I decided to use MongoDB for a pretty big online multiplayer
| game and it worked very well, not many issues and the
| development time was a lot faster than trying to use SQL.
| solanav wrote:
| I can understand this from the perspective of a manager or
| company owner. "Happiness comes from shipping products" or
| "Choose boring technology" make a lot of sense if you are
| maximizing profit and don't need to work with the tech yourself.
|
| If you are an engineer and you want to try a new technology, go
| for it. Even if it doesn't make sense. Learn new things, don't
| stick with the boring tech. Maximize your own happiness and your
| own knowledge, not the profit of your higher-ups.
| cjfd wrote:
| Actually, also as an engineer much happiness comes from
| shipping products. Also, happiness comes from programming as
| opposed to configure and/or repearing a baroque tech stack with
| technologies that are not needed anyway but still break every
| other week. The latter thing comes with anger and the desire to
| scold (if not worse) the persons who needlessly brought in the
| complexity. If you want to learn new things there is your spare
| time where you are welcome to experiment with whatever.
| h3mb3 wrote:
| > "Choose boring technology" make a lot of sense if you are
| maximizing profit and don't need to work with the tech
| yourself.
|
| This view feels so strange to me.
|
| As an engineer, I find myself the happiest when I manage to
| build the simplest and the most maintainable thing for the
| business requirements. Extra happy, if it turns out we didn't
| paint ourselves into a corner when those requirements increase
| or change.
|
| I just want to minimize my own tears in the future.
|
| > If you are an engineer and you want to try a new technology,
| go for it. Even if it doesn't make sense.
|
| Imagine how immoral this advice sounded like if it came from
| the mouth of a carpenter, an auto mechanic or a doctor.
|
| Maybe this just activates my PTSD acquired from working in a
| startup with a long history of codecampers doing CV-Driven
| Development.
| DC1350 wrote:
| Why do you care how successful the company you work for is?
| reader_mode wrote:
| >If you are an engineer and you want to try a new technology,
| go for it. Even if it doesn't make sense. Learn new things,
| don't stick with the boring tech. Maximise your own happiness
| and your own knowledge, not the profit of your higher-ups.
|
| If you're a responsible adult you'll probably be the one who
| has to ship the stuff you started with the "flashy framework X"
| - boring technology is about maximising happiness - it just
| takes a while for this to sink in.
| FeepingCreature wrote:
| Learn new things, don't stick with the boring tech, try
| exciting new products.
|
| Don't put them on the critical path of your company without an
| exit plan.
| WJW wrote:
| Boring technology also has the benefit of not waking you up in
| the middle of the night as often, because most of the weird
| bugs have been rooted out by other people. This can also be a
| downside of course, depending on how your particular org
| rewards "firefighters".
| mikewarot wrote:
| >If you are an engineer and you want to try a new technology,
| go for it. Even if it doesn't make sense. Learn new things,
| don't stick with the boring tech. Maximize your own happiness
| and your own knowledge, not the profit of your higher-ups.
|
| Yes, by all means, have fun, at HOME, not on company time.
| XCSme wrote:
| > Learn new things, don't stick with the boring tech
|
| If you had a choice, isn't it better to build cool stuff with
| boring technology instead of building boring stuff with cool
| technology?
|
| I think his point was to focus more on the product not on
| technology, and by choosing a boring technology you will likely
| have more time and fewer problems shipping awesome products.
| serial_dev wrote:
| Totally, one can understand both sides.
|
| In my opinion, it also works in the other direction, where the
| managers push things onto the developers. "Can we use this
| blockchain thing?", "we need to do AI", "we should use this
| cross platform mobile app tool I heard and read 3 minutes
| about".
| golemiprague wrote:
| Useless advice of the type of "choose the right tool for the
| task", what is boring? what is the right tool? That's always the
| question, not the answer. There are also so many other variables
| to decide success and outcome that I am not sure anyone can point
| their finger to the technology stack and certainly claim that it
| is the cause of this or that.
| bottled_poe wrote:
| Lots of good stuff in this article. The way I read this is that
| all technology choices boil down to business cases which attempt
| to predict costs and benefits. I think it is important to note
| that the pros and cons which get weighed up in such a situation
| will cut across all aspects of a project - not just hard aspects
| (eg. Functional needs, performance, complexity, technology
| maturity, etc) but also importantly soft aspects like
| compatibility of the technology with team culture, individual
| personalities, career objectives, etc. It's a complex problem and
| assessing the value of each pro/con is mastery which I believe
| requires a vast amount of knowledge and experience.
| yters wrote:
| My internal devops group has this issue. We had a working system
| on teamcity and the hashicorp stack and linkerd. Now we are
| working on a brand new system using gitlab and openshift and
| istio. Highly redundant with, from my perspective, only
| incremental advantage. At the beginning I spoke out against this,
| but failed to convince anyone. Progress has been alright because
| of our new 10x hire who hated the old tech and loves the new
| stuff. But once he is out of the picture, we will be maintaining
| two highly redundant stacks both requiring deep technical
| knowledge to maintain effectively. I guess bailing is always an
| option, but I would prefer to be a force for good somehow. Any
| suggestions?
| alchemism wrote:
| Welcome to politics :-) My only suggestion is that one must
| consider both pathos as well as logos when making rhetorical
| appeals.
| yters wrote:
| Good point. Pathos is not with the boring old tech approach
| :)
| user5994461 wrote:
| I'm surprised one guy can bring in gitlab, openshift, and istio
| all by himself. They're not small things to setup and to
| migrate existing software to.
|
| Typically how this goes, few of the existing software migrate
| to the new stack (it's too much work to migrate and it doesn't
| work as well). After the guy is gone, you can deprecate the new
| stack immediately and don't bother supporting it. I've seen it
| happen a lot.
|
| What you don't say is how large the company is. For startups
| and small companies, my experience is that every generation of
| developers (couple years) will rewrite most of everything.
| That's just how things go in startup, filled by eager young
| folks who have no experience and build their resume. That's
| only possible because there isn't that much code in the first
| place.
|
| Larger companies can be stuck with multiple stacks because
| there's too many software to migrate and no sucker to do it.
| Older projects are stable and have no active developers working
| on them, they're not going to be rearchitectured. Other
| departments/developers know that they can't trust the shiny new
| tool from your department, that's going to be deprecated next
| year, they don't adopt in the first place (a great example of
| why large companies resist changes).
|
| It's just the state of the industry I guess.
|
| IMO it's crazy how few people working on tools/frameworks can
| inflict migrations on a hundred developers/projects (thousands
| in larger companies), often for no benefits.
|
| I realize this doesn't answer your question, how to help?
|
| No idea. Would be nice to cancel projects early before they
| reach that stage. It's probably too late now.
|
| What you can improve is your perception. If it makes you feel
| better, one pro of all this churn is that there are many more
| jobs, doing rewrites over and over again. It's nice to have a
| job in the current climate.
| yters wrote:
| He is handling the integration. The maintenance of the
| products falls on the ops team. He is doing a great job. I
| just don't think he will stick around to maintain things once
| he is done, and we will have two stacks to migrate and
| maintain.
| nathanganser wrote:
| And then it read "Attention is precious" and I realized I was
| losing my time and should got back to more important stuff :P
___________________________________________________________________
(page generated 2021-02-21 23:00 UTC)