29 ms·

Building for the 99% Developers

477 points by bdburns 5y ago

ilrwbwrkhv 5y ago
That's why the number 1 advise I give to anyone starting a business: Just use Rails.
recursivedoubts 5y ago
Excellent article. Most people need to get some data from a database to a web page and back again, to paraphrase dhh (I think). This does not require a huge amount of architecture or infrastructure in most cases, even at scale. The engineering challenges should be elsewhere, not in this relatively simple and solved problem.
- amw-zero 5y ago
  It’s a solved problem? The most difficult to navigate and extended codebase I ever saw was a medium-to-large sized Rails codebase.
  - dilyevsky 5y ago
    Just a simple matter of programming
  - valyagolev 5y ago
    I absolutely agree with your comment and I’m sad that it’s being downvoted. Thing is, I see all the times web frameworks that would be used in those cases, but improve in many directions almost irrelevant for it. Performance? Ability to do same webapps in yet another boring scripting language? Very specific and rigid abstractions and fancy tools that provide for very little flexibility? Fancy reactive approaches that manage to turn the codebase inside out, create hard and undebuggable problems out of the easy ones, and sometimes provide random subset of guarantees of various degrees of usefulness (I’m actually a fan of FRP, just not the misuse of it)? Somehow Django, with its clear admin system and other out-of-the-box QoL modules remains as close to the most practical and useful approach as one can imagine. (Still even people who use it manage to reimplement its parts for no reason. Every sufficiently big webapp contains a bad, buggy, incoherent implementation of 90% of Django) There are incredible amounts of money and effort and time to be solved by creating frameworks and abstractions that help with the glorious use-case of “huge, annoying, evolving in all the wrong directions essentially CRUD app”. Yet we’re not even stuck with Django - I see webdev regressing into horrifying piles of JS…
  - bcrosby95 5y ago
    Because Rails doesn't encourage modularization. It's fine at small sized codebases but eventually you want to "package by feature" (to borrow a Java term) rather than by layer.
    - Lio 5y ago
      Out of the box rails provides Modules, Concerns, Engines and Gems as mechanisms to package by feature. If you want to back that up with static types Ruby > 3.0 provides that out of the box too. What is it you think it's lacking?
- krageon 5y ago
  > in most cases I'd say it's so close to every single case, thinking about the rest is best characterised as daydreaming.
ctvo 5y ago
Who is trying to switch to GraphQL? Especially for service to service, internal calls?
- dham 5y ago
  Unfortunately a lot of companies right now. Although the smart ones have already done the switch and are now trying to switch off. I've seen a lot of suspect technologies in my career but GraphQL is definitely the worst
  - pcstl 5y ago
    Out of sincere curiosity: Why do you think GraphQL is so bad? I've been using GraphQL for a little while now and I've had nothing but good experiences (although my use case might not be the most common) so I'm interested in knowing what makes you think so poorly of it.
    - oleg_antonyan 5y ago
      Not the one you asked, but I'm also stuck with supporting graphql in relatively small project. Zoomers invented SOAP. It's a perfect example of adopting what FAANGS do just for the sake of it. It's probably great when you have dozens of consumers with very different needs and usage patterns. But for the single frontend it adds way too much complexity on the server-side. Debugging, testing, writing tons of boilerate code, not to mention POST requests for getting data - everything becomes more complicated with 0 benefits
      - alphabettsy 5y ago
        Zoomers invented SOAP? Are we thinking of the same Zoomers? Same SOAP?
        coryrc 5y ago
        GP means GraphQL is a Zoomer's version of SOAP (with all that implies)
blurker 5y ago
> Just like influencers in any other field, developer-influencers often describe a reality that is aspirational even for their own companies. It may be true that people writing about ideal processes live in an idealized situation where it’s possible, in which case they’re the exception that provides the rule. But most of the time — even if it’s true in one part of an organization or at one moment in time — this reality does not hold across their entire company and forever more. BINGO! This really resonated with me. It's a good reminder that developer social media is going to have some of the same things going on as regular social media, like unrealistic comparisons to idealised snapshots.
austincheney 5y ago
My personal recommendation is to do some self reflection on what things are most important to you when it comes to spinning up a new project and build your own kit. This is your tool bag as a developer. I have seen a lot of people try this and fail because they aren’t building a personalized kit, they are putting together popular dependencies. That is radically different. When you build your own kit it is tiny and extremely portable. You dig into the nuts and bolts to see what works and what plays well together. Since it’s all your personal preferences you maximize on productivity every time you use it. The best part is that you only have to build it once. Then after it’s a few hours of maintenance every six months as your requirements and preferences evolve.
- pm90 5y ago
  What happens when you work at a company that uses a different stack though? Can’t force a Java shop to start using Golang just because I like it and have developed my experience around it.
  - macintux 5y ago
    Unless you’re a megalomaniac CTO. Amazing what companies will do (typically disastrously) when a new CTO arrives.
AnotherGoodName 5y ago
You'd be surprised at how fast you can create something with an SQL database, a well used backend framework (eg. Rails) and a well used frontend framework. The things big tech companies do are usually to avoid scaling problems. In particular scaling on the engineering side. The above can scale to billions on the user side if needed but 10k engineers constantly updating and messing with a traditional SQL schema doesn't work. You'd be crazy to try to replicate something like the big tech companies database storage systems when you're just starting out. You don't have 10k engineers. You may think "but i want to scale to a billion users". Well you still don't have those problems. The scaling problems big tech companies have are scaling to 10k engineers.
- arvinsim 5y ago
  One cannot predict the future but I agree that for most indie outfits, YAGNI would apply.
- urthor 5y ago
  It's also that, in the past, the capacity of our monoliths to scale was far lower. There's many apps that need say, a 100GB database in 2022. Those apps also needed 100GB database in 2007, when horizontal scaling was the hottest thing around. Nowadays however, Moore's law has steadily overtaken an order of magnitude of use cases from 2007. Maybe 1/10th of the 2007 use cases still need that kind of enormous, big tech scaling.
  - adra 5y ago
    Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usually best for more senior teams that have specific need for it.
    - Nextgrid 5y ago
pmarreck 5y ago
On the one hand, your MVP version 1.0 should probably be built in anything that is fast and works. On the other hand, you're gonna want to rebuild that ASAP in something that has legs for longevity's and paying down tech debt's sake. You won't potentially have an edge over any competitors by using their same tech stack.
- macintux 5y ago
  I suspect that for most companies, the tech stack they run, the custom software on top of it, isn’t meant to be a competitive advantage. It’s just the cost of doing business.
  - pmarreck 5y ago
    Right, but I know that to be false. In the extreme case to prove my point, if you write your stack in Brainfuck on top of Oracle, you're going to have a much harder time than if you write it in JS on top of Postgres
alberth 5y ago
We way over complicate things. SQLite can be used for 95% of real world use cases. And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases. And don’t fool yourself into believing you’re not in that 1%.
- bob1029 5y ago
  We've been using SQLite for 100% of our data persistence needs for the last ~5-6 years now. Our largest single environment is probably getting close to 500gb total size. Hundreds of concurrent users are no problem for us, even without these enhancements (we use WAL currently). The biggest single trick I learned was to use 1 sqlite connection instance for the entire lifetime of the application. You can add orders of magnitude more throughput with this path. SQLite serializes writers by default so dont duplicate the effort. You can even use the RETURNING keyword to grab insert keys without needing to lock over LastInsertRowId. We also are close to 100% of business logic being executed via SQL queries as well.
  - alberth 5y ago
    That’s great to hear. Would you mind sharing how you implement/use 1 connection?
    - bob1029 5y ago
      I would just think of it as 1 global static SQLiteConnection instance. There's really not a whole lot to it. Like 4 lines in a class file to set this up.
      - alberth 5y ago
        How do you implement this using a stateless stack (eg PHP)?
        dgfitz 5y ago
        I’d build a (stateful) shim micro service that the stateless code interacts with, no idea if that is the “most correctest” solution though
FpUser 5y ago
>"Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers." My approach - I could not care less about what FAANG does. Due to their scale and org structure they are solving problems which 99% of mere mortal businesses will never face. I am not a luddite and am constantly looking for new things that can make my development easier. But I consider those from ROI point of view as I am vendor with clients and I want to make money, not waste it. Coolness factor, fashion, corporate propaganda / indoctrination mean zilch to me.
- hzlatar 5y ago
  I am curious to know how you evaluate a new development product in respect to the ROI? What characteristics should a product have to satisfy your criteria for considering it?
  - FpUser 5y ago
    Example - I have JSON based RPC so that systems from other vendors can talk to mine (enterprise backends written in C++). It works like a charm and has ben doing so for years. Here comes this architecture astronaut and tells ma that I should do GraphQL and proceeds to explain me how powerful and cool it is and how everybody and his cat uses it. So on the downside I will waste a gobbles of time and money, on upside - zilch because nobody gives a shit. The problem is already solved for us year ago so buzz off. And that guy could not give a single example of how it can help me. Just spreading FUD about existing things. There are numerous opposite examples when I see that this new tech, lib, tool actually saves me time and money. I pay quite a few dollars for software tooling. Well if the tool does not offer perpetual license it is a no go for me then. This is all that matters to me. On desktop for example I skipped moving to that .NET bandwagon and stayed with Delphi for my GUI desktop products. They worked 20 years ago and they work the same now. Single 10MB self updating exe with zero deployment issue. And free from numerous limitations imposed by UWP. Competitor is 1GB package with crapload of problems and every update turns a nightmare for customers. In my case all the time is spent creative stuff that brings me new customers / money instead of feeding someone else. Sure it costs me few hundred a year but that is peanuts.
bloodyplonker22 5y ago
I use MongoDB, Cloudflare, Snowflake, and Datadog and I love them all because they are all great and easy to use products that get the job done and make it easy for other developers to collaborate as well. People will mock me mercilessly for not using free OSS, but guess what, I don't want to deal with the headache of setup and maintenance! These products all have their parallels at big companies (such as Borgmon and Bigtable), but they're much better in practical use cases in non gigantic companies.
LAC-Tech 5y ago
IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy
- ehnto 5y ago
  I agree, except as I am not in the VC rat race I am more than happy to suggest people keep it simple.
  - LAC-Tech 5y ago
    Neither am I - but all my reasons still apply. Try getting a job as a dev with vanilla JS and SQLite skills, as opposed to React and Microservice skills. What a business needs on a technical level doesn't matter when it comes to finding jobs.
- bgroat 5y ago
  I'm literally running 5 sites and $40k MRR on a $5 linode
  - devoutsalsa 5y ago
    I love hearing stuff like this. What are you using for your database(s)?
    - bgroat 5y ago
      MySQL - just checked. I would've sworn it was postgres. Just shows how much attention I pay to anything that isn't business logic
  - logankeenan 5y ago
    That’s awesome! Do you mind sharing about your tech stack or how you deploy?
bjterry 5y ago
99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup selling developer tools, by all means think about the 99% developers, but also know that a lot of them are in environments that don't spend a lot on tools and are averse to exploring new technologies. If you are a developer in one of these environments, well, the standard advice on Hacker News is already "You're not Google." I feel like some of this is a bit fatalistic. The 99% can follow a DevOps playbook if they realize its value, and it's cheaper to have DevOps than to not have DevOps, in the anything-more-than-short timeframe. The 99% can certainly have test coverage standards for new code. Somehow, we moved from a world where the 99% didn't use source control, and now they do! Some technologies and practices are so impactful, you should aspire to them no matter what you're environment is (e.g. code review, CI/CD). The 99% concept also hides a lot of important details, as it's defined by exclusion. The choices you need to make for an early stage startup, a mature WordPress shop for small businesses, and a legacy mainframe team in a F50 are as different from each other as they are from FAANG.
- newrotik 5y ago
  The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?
  - weq 5y ago
    So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out? Serverless allows anyone to be scale for minimal up-front cost and only pay for the usage they really need. So glad that FAANG attract all this rare talent so us no-FAANG engineers can make a buck.
    - lelanthran 5y ago
sirspacey 5y ago
This article didn’t resonate with me as much as I was expecting. While the insights on developer influencers was sharp, the article itself felt like more of a reaction than an evaluation. I’ve worked in many legacy companies. The rationale for staying on the tech stack they have, and the approach they take to DevOps, is not particularly well reasoned. Often they are experiencing painful consequences due to their adherence to old design patterns. I wanted each paragraph to be more diagnostic, frankly more reminiscent of the wide ranging and interesting debate we find here (especially when the old guard shows up and speaks with real authority and wisdom on how the problems they solve don’t map to Kubernetes, etc.). I’d really welcome counter-arguments to the point I’m making, so I’ll frame it this way: This felt like the same kind of “playing to the crowd” that dev influencers do, just a different crowd.
- adra 5y ago
  I think the point that should be well taken is that if you're hoping to service the greater programming community, you can't do so in your ivory tower solutions on a community Ill equipped to utilize them. From experience, DevOps done poorly is terrible and demoralizing. Agile done poorly (often) is terrible and slow. Take any best practice and try to apply it to any organization and you'll get a lot of flaming wreckage. Ideally those companies will have some pragmatic people that can nudge their people in the right direction gradually.
  - hvidgaard 5y ago
    Anything done poorly and terrible is, well, poor and terrible.
sanxiyn 5y ago
a16z invested to Replay, "The Time Travel Debugger for Web Development". Go read about it here https://medium.com/replay-io/launching-replay-the-time-travel-debugger-for-the-web-f886f0897d38 https://medium.com/replay-io/launching-replay-the-time-trave... and read this again. It all makes sense.
- joeldo 5y ago
  Are you implying that a16z wants websites to be as difficult as possible to maintain that a tool like this is necessary?
  - sanxiyn 5y ago
    I would say a16z is realistic about it. From the article, "Heterogeneity is here to stay".
  - exdsq 5y ago
    Haha never thought about that but it’s a fun connection
muglug 5y ago
Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 https://twitter.com/copyconstruct/status/1456129831821709315 > a lot of what most “developer influencers” say is fairly aspirational. Their own companies don’t necessarily do things as smoothly as they preach to others. There's a pride element there: developers don't want to admit that they work in less-than-stellar conditions. Some developer talks also double as recruiting events, and you're going to turn people off when you mention that the test suite takes a day to run and requires the use of a fax machine.
- djbusby 5y ago
  Easy to automate with Hylafax (2002), probably some SaaS API (2022) (there are at least a dozen Fax/SaaS things now)
- ryandrake 5y ago
  One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...
  - galaxyLogic 5y ago
    I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further. But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.
jasfi 5y ago
I've been working on an SDK for Flutter that is simpler, easier to code, and is closer to HTML/JS. You write your code on the back-end, although you could use the same SDK on the front-end. Nim is the initial back-end SDK: https://nexusdev.tools/ https://nexusdev.tools/
adra 5y ago
Yep, great write-up . I spent so many years in companies that were perpetually behind the times and rarely catching up. I now work for a large scale SAAS offering trying to sell to these developers. It's consistently an up hill battle trying to sell my peers on the realities outside their bubble, but it seems pretty fruitless.
d--b 5y ago
I am not sure what the point of the article really is. I mean it’s not wrong, we all live in that real world (my job is literally migrating off stuff) and recognize everything the author says. It’s just that I don’t see those myths being myths in the first place. In fact, thinking that the 1% is any different is perhaps the biggest myth in the article. Sure they have distributed crap to handle and uptime commitments to go by, but I don’t expect the life of these people to be much different
- mirekrusin 5y ago
  You may be lucky, surrounded by sane people. Having new joiner stating on 2nd day that the whole system has to be moved to microservices on graphql with blue/green continuous deployment to solve all past and future problems is a real problem, it does exist. Some people seem to fall into this trap described in the article of reading some blog post on some approach and fixating on it in religion-like mindset. It makes it hard to unwind ideas they throw into business people's minds because they all sound superficially great. You have to break it down to first principles and go through it, explain why things make sense for 10k+ engineering teams but don't for our dozen people team. They will call current architecture legacy from the start and that sticks with business people. The reality is often the other way around - big players would love to be able to run systems using those simple, straightforward arrangements: single version for all services, ability to have few minute downtime to upgrade system offline, single monorepo, single database – but they simply can't because they have thousands of people working on it, running at massive scales across the globe. When you say those things people get very defensive and it's hard to keep dialog on. Because those new things could actually work very well, but ie. not as replacement for everything but to create some satellite services, maybe for things that crystalized over years, unlikely to change and can be extracted as dedicated service, maybe graphql makes sense for admin section where the f/e team wants to experiment more etc. I'd say: - be rational - analyze from first principles - use N-order thinking - be open minded - for new tech and ~legacy~ current tech - judge on simplicity as one of main criteria - stop calling tech you're currently running without already available alternative "legacy" - it's your "current" tech - monoliths are not "legacy", they are desired if possible, split if they'd simply not work or you organically grew into maturity level where it start to make sense - same with single database - same with single versioning - same with single monorepo - use your own business reality as base for evaluation, not somebody else's reality
wh-uws 5y ago
let me calm down and breathe and I'll take the bait ... look just because you're not Lebron James or Michael Jordan doesn't mean you can't go to your local basketball court and enjoy a game of pick up. But the same way you don't conflate what you need to do to be one the of the best people to ever play a game to play at all... your software engineering team doesn't need to feel completely useless because they aren't immediately using <insert new hot tool> . Everything in software engineering from side project to unicorn startup service is about tradeoffs. Tradeoffs happen because of constraints. I don't expect a consulting shop to build code the same way an open source project does or a publicly traded company that has been profitable for 10 or 20 years. I'm hoping you can read in this the need to be cognizant about manpower tradeoffs. So yes I fully appreciate this as someone who has consulted, worked a public companies, and is now at a rapidly growing startup... Just because your team isn't meeting some imaginary ideal for some other form of team with different constraints doesn't mean you can't ever strive for any ideal or give up... you just have to be realistic about trade offs... my favorite example of this is thinking about a system like rails vs early react (loooong next.js or even before the context system) or a lot of things built in the python web ecosystem. With rails you have scaffolds and endless convenience methods that let you be productive quickly even as a small team or shop... with early react or python web you were largely left to your own devices out side of the core flows they had solved (painting updates to the dom with react or some rudimentary crud stuff with django or flask) ... Because they were built by and more importantly FOR different types of teams. Rails by the relatively slender (and famously against VC type scaling) 37 signals consulting crew and react by facebooks behemoth engineering team. Of course they are going to build for their own trade offs... why would you not? (I intially opened this rant with this final piece thata I thought better of starting with but I still stand on the feeling... The is the biggest piece of curmudgeonly nonsense I've ever read... its like someone training an ml model on last 5 years of HN comments and churning out a click bait blog post)
oxplot 5y ago
Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. - Avoid if the developer base is mostly young people: They are energetic and they don't mind complicating the shit out of something, because they can figure it out now and probably down the road. I'm old, and I just want things to work and I want to understand how it all works without spending a week and wrestling with tooling. Not all out-of-college folks are the same but most are (and I used to be one, so there). - Avoid kitchen sinks: borrowing ideas sparingly is fine - throwing in every new feature in another language you come across makes for a soup, not a tool. A good heuristics is the rate at which features are added. Look for logarithmic trend.
- travisgriggs 5y ago
  Would you be willing to share some of the languages/frameworks that have made the cut or washed out for you based on the rubric you’ve given. I’m honestly curious.
  - oxplot 5y ago
    I specifically avoided mentioning examples as that'll stir up a lang-war.
    - ZephyrBlu 5y ago
      Your rules are so vague that I have no idea which languages/frameworks would qualify and which ones wouldn't. Does React specifically mention big companies, have a young developer base and is a "kitchen sink"? I have no idea. Is Python a "bad" language? What about Go? C++ kind of seems like a kitchen sink, is it "bad"? I really have no idea how to figure out if these rules apply to any languages/frameworks.
      - 5y ago
Yhippa 5y ago
cheriot 5y ago
In a lot of ways, large tech companies are living in the future. They have to invent things that later open source tools will imitate and then others start to use. Examples: map reduce, various rpc standards like graphql and grpc, and a whole mess of non-relational data stores. I work with kubernetes a lot right now and it's effectively a smaller, less featurefull version of what google runs on, but it's light years ahead of what we were using before. A huge portion of the industry will be 10, 20, even 30 years behind and that's fine. I don't think there's any myths about this.
pictur 5y ago
Nowadays, there is a lot of focus on process in software development. and this often allows us to miss the target. The tools used are important yes, but how you use them is more important.
metaph6 5y ago
that was a great read! Shared it on my company's LinkedIn page :)
aaronbrethorst 5y ago
That’s a lot of words. Too long; didn’t finish reading. What are they trying to sell me on?
AceJohnny2 5y ago
In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code for fun. Everyone for whom coding is something that gets in the way of their real objective. No wonder they produced bad code! But that's not the point: they're solving something else. They're not spending effort making bug-free maintainable code, they've got more important things to do. They're doing the accounting for their small company, point of sale for the shops in their city, all the kind of things that may not be glamorous but that's all around us (for better or for worse) So while I puttered around in my self-congratulatory ivory tower of unix, Microsoft understood what the real world needed, for the 99% of developers...
- mro_name 5y ago
  I think it's much more profane - Microsoft didn't understand what the real world needed, they just leveraged a monopoly (that IBM let them establish) to frame what a computer looks and feels. They shaped the world to their liking and now it looks like a match. duh.
  - math-dev 5y ago
    Basically this
  - just-tom 5y ago
    I'd argue the opposite. All Microsoft did was understand what the world needed. Were they successful because of their great marketing or their flawless coding? No. Was Windows spread like a wildfire because it solved real world problems? Yes. Is it one of the most, if not the most, influencial software ever made? Yes, no matter how dull and incompetent people might say it is. For the accountants out there, school teachers and doctors, it was magic.
    - mro_name 5y ago
progx 5y ago
The developer bubble. 99% of all developers had enough todo with their work, they don't have time to write shiny articles about the used technology. This should make it clear that many great articles on many great technologies are written by a few, most of which are at an academic level and have less to do with the practice of 99%. But everybody thinks that using this tools that way is normal, it isn't.
- maccard 5y ago
  I don't think this is true. As a developer my job isn't just to crank out code, it often involves doing tasks that are important to the company like interviewing people, writing documentation, occasional team meetups. One of the things that's pretty apparent after spending time on HN and other forums is that these articles when well written are absolutely excellent marketing material. It makes sense for a company to allocate development resources to writing them.
ramyarjahani 5y ago
[dead]
cryptica 5y ago
Great to see that big VCs are having these deep insights. As a developer, I've essentially had to leave the industry because all the small software companies are constantly coercing all their developers into using specific tools and processes from big tech companies and unicorn startups and I was constantly pushed towards solutions which are too bureaucratic to work efficiently in a small company setting. I was too passionate about coding to butcher it in this way so I left the professional sector and focused on open source (thankfully I have enough side income to do this). It's mental torture to come to work every day, working in an industry which is supposedly all about logic and problem solving and be constrained by what is essentially religious dogma when applied in context. 10 years ago, it was such fun to be in the software industry as a developer. The company directors would trust you to choose any stack/framework you wanted or even build your own lightweight in-house framework (or no framework at all). It's no longer the case.
- exdsq 5y ago
  Weirdly one of the reasons I moved from development to a test engineering role is you have way more technical freedom. I can basically use whatever tool I want because there’s way less oversight as long as the job is done. Want to test a CLI? Use Go/Rust. Want to load test a website? Use Scala. Data parsing? Write a lexer in Haskell. I think I’ve used almost every language in the top 30 in production thanks to this. And it’s not even just language - need reporting? Try a new web framework. Need to store data between tests? Try a new database. I’ve written far more fun code in a testing role than I ever could in a dev role :)
  - cryptica 5y ago
    Sounds like you found a good way to keep learning on the job. This approach wouldn't work for me though because I like building products and features. The way I kept learning was by doing open source on the side.
brunoborges 5y ago
Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves the performance problem with dozens, sometimes hundreds of replicas for one particular microservice. Many developers don't even understand the impact the JVM has when running on a single core (yeap... you get Stop the World GC - aka Serial GC - by default). And then, the dev team decides to move to a new language because of performance and cost issues. And that by itself just brings many other problems. All they had to do was keep the same amount of CPU and memory, but less VMs and replicas, with more vertical resources. Depending on the workloads and the system, it is even possible to reduce the cost. All this is caused by the push in the industry for companies to go Cloud Native.
- zhughes3 5y ago
  So you can’t scale java horizontally?
  - lvice 5y ago
    I don't know java, but that's not the message I got from the comment. It looks like with java, 3 VMs with 2 cores are better than 6 VMs with 1 core, which may be forgotten when configuring equivalent kubernetes services.
    - brunoborges 5y ago
      Exactly that.
  - hvidgaard 5y ago
    I don't think you quite understood what (s)he wrote. The problem is using JVM without understanding some basic properties of it. Scaling is a matter of how you programmed it, not the language used.
  - 5y ago
intrepidsoldier 5y ago
When I was a programmer, I was never on Twitter, HN, or Reddit. Stackoverflow maybe sometimes. When I became a Product Manager, I started voicing opinions on all these forums.
streamofdigits 5y ago
I think the article makes a very important point about under-resourced developer teams but misses an opportunity to point out that most other teams within organizations and businesses face similar constraints. I think this favors stacks and frameworks where the business logic of a domain is already reflected, at least partially. This might explain why some open source frameworks persist and thrive even while their "tech" is deemed obsolete / deficient...
zuhayeer 5y ago
"I’ve encountered so many teams who say that migration will happen “next quarter.” The reality is that, even when they manage to finally start, migrations have become continuous, rather than discrete, processes. A 99% Developer team with legacy code and a lean team is probably never going to convert their entire code base over to microservices or GraphQL. For most organizations, tech stacks and tool chains are heterogeneous, a combination of the layers of languages, frameworks, and tools that have been picked up over the years." Generally observed that the less you see engineering as an ideal state or set of standards, and rather as a living and breathing organism in your company, the easier your life will be. If you're ever working on a 100% refactor of something to a new framework or system, chances are you're not focused enough on the top line problems at your company. Which is related to https://rkg.blog/desperation-induced-focus.php https://rkg.blog/desperation-induced-focus.php
mbeex 5y ago
> It’s well-known among developer tools creators, for example, that integrating with GitHub and GitLab will help make your tool much more useful and appealing. Certainly not for me personally, nor for the 10 or so companies I've worked for as a freelancer over the last 10 years. Among them are some - real - market leaders as well as small and fine companies that are extremely demanding when it comes to self-used technology (including development tools, of course). Just look at who the owners of github (most people know it) and especially gitlab (most people don't) are. More generally, just the single arbitrary picked difference between one company producing something tangible and another producing a pure software product should be eye-opening to anyone who has had both types of experiences. As for my career path, I've worked in instrumentation, avionics, cars, and Embedded, among others. Each with a very different culture, even among themselves, not to mention compared to software companies.
usrbinbash 5y ago
> Too many people believe that aiming for good software quality means you need to fully adopt that new technology, whether it’s microservices, GraphQL, or distributed tracing. You’re not done until you’ve switched fully over to the ideal technology. This. We are constantly presented with new and shiny things. And then, barely a year later, there is the next ideal technology. And the next, and the next, and the next. We have seen this with everyhing: Languages, coding standards, paradigms, editors, organisational methodology, interview methodology, frameworks, databases, security, design basics,...the list is endless. But here is some truth: C is still written. As is pure JS. Imperative/Prodecural code never went away. Websites on servers we can physically touch are still deployed. People still write working implementations for almost everything under the sun from scratch. Information-Dense, slim, efficient interfaces that get jobs done are still there. As are monolithic architectures. Good 'ol RDBMS still work great. bash is still the dominant shell. grep/cut/awk are still great for analysing logs. Water still flows downhill. "new" and "better" are 2 different words, with different meanings. Something that's new could be better. But he fact that it's new, in itself, doesn't automagically make it better. And even if its better in one scenario, its doesn't have to be better in all scenarios.
- pjmlp 5y ago
  Indeed, that is why even though I regulary rant about C or its influence in C++/Objective-C, I am not naive to think it is going to go away until we switch to something radically different in computing models (away from UNIX, quantum, whatever), hence why at the same time there is a very big value in achieving some improved security while using those languages, regardless that we still cannot make it 100%, 90% there is better than nothing.
- dahart 5y ago
  > new, in itself, doesn't automagically make it better. Indeed. It’s often the case that new is worse, and the authors and influencers pushing the new don’t know it yet, or sometimes they do but they downplay that knowing it will take time to get better, and underestimate how long. The reason old defaults to better is simply because it’s been used more, it automatically solves more problems because by the time it’s old it’s been built to solve more problems and it’s weaknesses have been fixed or patched or shimmed or worked around. Old isn’t automagically better either, of course, and things can get too old and too shimmed, but if the new thing is solving the same problems and being compared to something well tested and used by many, it’s very unlikely to be better until it starts getting old. Maybe we should take a minute to ask: better for who? Better for customers is different than better for programmers. New is both more fun and easier to maintain. New is better for programmers. Old is better for customers, it’s more stable and changes more slowly. There is something pretty important to be said for being an early participant in a project, programmers who are involved in building and integrating new things automatically become more productive than programmers who get hired to maintain old things. I’ve seen this first-hand in several different ways, the most stark of which was selling a company to programmers better than me, but took years to become productive because they didn’t know how everything worked and didn’t want to break anything. There is also something to be said for replacing old with new. I’ve seen first hand teams tear down old engines because they felt crufty to build new ones, with the promise that it was going to be fast and easy and that they learned their mistakes the first time. Two completely separate companies launched into a 1 year rewrite that ended up taking 5 years, costing tens of millions, and making a good deal of the same mistakes over again before they were done. Both cases were failures to evaluate how well things were working in the old system, they were blinded to the overall success by the long list of rather minor problems.
ChrisMarshallNY 5y ago
I remember this post[0], here, a while back. I’ve been shipping (as opposed to coding), for my entire adult life, and I’ve learned (the hard way, of course) that “ship” is always at least a couple of clicks back from “bleeding edge.” I’m in the home stretch of an app that I’ve been developing for the last year and a half, or so. The backend is written in PHP, and the frontend is a “classic” UIKit/Storyboard/MVC app, as opposed to a SwiftUI/Combine/MVVM project. It’s fairly ambitious, and, when I started, I was not confident that “the bleeding edge” would work (it might have, but I didn’t know that it would). There was no question that the classic patterns would work, so I picked them. It’s coming along great; far better than I had originally envisioned the project. It is ultra-high-quality, fully native, with only one small external (meaning that I didn't write it, myself) dependency (the backend has zero dependencies), has many capabilities that have only appeared in the last couple of OS releases, is easily localized, conforms to multiple device configurations, dark mode, accessibility features, etc. I read (here), about a well-known app that had been a highly successful classic native app (probably written in ObjC) that was supposed to be rewritten in SwiftUI, but the project failed, and was eventually shipped in Electron. That’s kind of my worst nightmare. I suspect the developers had to put clothespins on their noses, for much of the project. I will be releasing software, using more cutting edge tech, but all in good time. It’s unlikely to be “cutting edge,” by the time I use it. I like to give the stack enough time to smooth off the rough edges, before I rely on it for ship. I know that many fairly well-known applications for Apple platforms, are still written in Objective-C. Even Apple still uses it, for some of its internal tooling. I will admit that one gamble I took, was jumping on the Swift bandwagon, almost immediately, but there were multiple signals that it was not another OpenDoc[1], and that I could trust it. I’m fairly conservative about bandwagons. It’s earned me more than a few sneers (especially since I’m an older chap), but -and this bears repeating-, I’ve spent my entire adult life, delivering finished software. It’s not always been great software, and it has not always been commercially successful, but it has all been “finished.” There was a post here, some time back, where the author challenged the reader to mention three projects in their career that they had finished. My comment was that I could mention thirty, and point to the repos. This was met with incredulity, which shocked me, as I have known many developers, far more productive than I. I guess times have changed. [0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/ https://vickiboykis.com/2019/05/10/it-runs-on-java-8/ [1] https://en.m.wikipedia.org/wiki/OpenDoc https://en.m.wikipedia.org/wiki/OpenDoc (Full disclosure. I was very much a “bandwagon” guy, back then, and even took an OpenDoc course, from Apple’s DU).
sidcool 5y ago
The name of the author of the article is Jean Yang. :) (I am aware it's Jian vs Jean, but happy anyway)
mschuster91 5y ago
> For instance, companies with legacy systems that can’t afford to migrate to the newest architectures need to adopt new tools differently than newer companies, or companies that can dedicate a team to a large migration. Not to mention, this sort of company needs to do a careful evaluation if the chosen product and especially support for it is likely to be around for a while. Many got bitten hard by Angular's demise - and now imagine this for something like a database that's supposed to hold your entire corporate data.
cebert 5y ago
I believe Serverless technologies are a game changer for the 99%. I work at a firm that could be considered part of the 99%. We build mission critical apps, but don’t have entire teams dedicated to building platforms or managing Kubernetes. Most of our talent is average compared to FAANG. We don’t have SREs or developer advocates, but we do have customers who rely on our software for life and death situations. Serverless technologies help us build scalable, highly-available, and performant cloud applications that run by default in multiple availability zones and multi-region with minimal additional effort. We leverage GitHub Actions to drive our CI/CD process and automated testing. Instead of focusing on managing servers and cloud infrastructure, us simple 99% developers, those who get passed up by FAANG and Leetcode grinder interviews, can build solid applications that provide value to our customers and generate nice profit margins. The 99% can deliver apps that can perform similar to the 1% with far less complexity.
- zozbot234 5y ago
  CGI was the first Serverless technology. Then PHP did it even better.
  - emrahsamdan 5y ago
    Serverless as a term mixed up with FaaS. In 2022, Serverless is more general as it can be defined anything that autoscales to infinity and scales to zero when not used and pay per use. Amazon DynamoDB is also serverless in that sense for example.
    - zozbot234 5y ago
      > anything that autoscales to infinity and scales to zero when not used and pay per use Ah, you mean grid/utility computing. But as you point out that's broader than FaaS.
- pokepim 5y ago
  100% agree. Even tough i work at F500 company our team acts like a startup. With server less we don’t need to hire expensive devops and shell out millions for expensive k8s clusters. I am pretty sure it’s the future for most of us.
thrower123 5y ago
In a similar vein, the old classic Choose Boring Technology is worth reviewing from time to time. https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
bikamonki 5y ago
I never jumped into the React wagon, just as I never took the Wordpress train. You do not hire an 18-wheeler to deliver a pizza. Engineers on any subject have one job: design the optimal solution, be it a bridge or an SPA to take online orders. React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. Even vanilla JS does the job in most cases. 99% developer feels compelled to learn and adopt what is trendy because that is what the client/market/boss demands; but it is you the 'engineer' who has to tell the client/boss how that bridge is to be built. When was the last time you went to a doctor and said: hey doc I have this, give me that medicine.
- netizen-936824 5y ago
  >When was the last time you went to a doctor and said: hey doc I have this, give me that medicine. Allow me to introduce to you: pharma advertising in the US
- waffle_maniac 5y ago
  > When was the last time you went to a doctor and said: hey doc I have this, give me that medicine. My physician friend fires patients for doing this kind of stuff. Usually they demand unnecessary x-rays and CT scans.
- H1Supreme 5y ago
  > React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. And that would be what? Exactly? I did a personal project last year that was vanilla HTML/CSS/Js, with some templating in Go (I know it's templating isn't the best, comparatively). By the end, I wish I would have done it in React. I ended up re-inventing the wheel for a lot of things, and ended up with something that was decidedly messier. All while attempting to be more simplistic. I wish Web Components would have taken off. When Polymer first launched, I was totally on board. I loved the idea of writing vanilla frontends, and using Web Components where I needed extended functionality (vs a full framework). But, it didn't, and unless your site is super simple, and mostly static, React et al. are the best ways to create frontends.
deleted 5y ago
[deleted]
kohlerm 5y ago
Not sure I understand what the message of the article is. Sure not everything companies with big scalability requirements do, makes sense for smaller projects. Nevertheless some principles still make sense. E.g. a mono-repo can make sense (again depends on what you want to build) and it is even easier to handle at a small scale.
kwertyoowiyop 5y ago
Thanks for the news flash. In other amazing discoveries, fire is hot and the sky is blue.
msoad 5y ago
I understand the point of the article but I have a different approach when I decide to start a company. I'm going to hire all the weirdos that want to build things in Rust and try EdgeDB or render in WebAssembly. I think most great software are built by those "top 1%" engineers. See Figma for instance, it is built using technologies far ahead of its time. And that's why it's such a delight to use. pi's article on this seems relevant here: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
bncy 5y ago
> what coding, testing, and shipping looks like with short-staffed teams, teams without dedicated devops experts, and teams where everyone who originally built the system has left. This one hits really hard and I'd love to see more of that content.

477 points by bdburns 5y ago

That's why the number 1 advise I give to anyone starting a business: Just use Rails.

Excellent article. Most people need to get some data from a database to a web page and back again, to paraphrase dhh (I think). This does not require a huge amount of architecture or infrastructure in most cases, even at scale. The engineering challenges should be elsewhere, not in this relatively simple and solved problem.

amw-zero 5y ago
It’s a solved problem? The most difficult to navigate and extended codebase I ever saw was a medium-to-large sized Rails codebase.
- dilyevsky 5y ago
  Just a simple matter of programming
- valyagolev 5y ago
  I absolutely agree with your comment and I’m sad that it’s being downvoted. Thing is, I see all the times web frameworks that would be used in those cases, but improve in many directions almost irrelevant for it. Performance? Ability to do same webapps in yet another boring scripting language? Very specific and rigid abstractions and fancy tools that provide for very little flexibility? Fancy reactive approaches that manage to turn the codebase inside out, create hard and undebuggable problems out of the easy ones, and sometimes provide random subset of guarantees of various degrees of usefulness (I’m actually a fan of FRP, just not the misuse of it)? Somehow Django, with its clear admin system and other out-of-the-box QoL modules remains as close to the most practical and useful approach as one can imagine. (Still even people who use it manage to reimplement its parts for no reason. Every sufficiently big webapp contains a bad, buggy, incoherent implementation of 90% of Django) There are incredible amounts of money and effort and time to be solved by creating frameworks and abstractions that help with the glorious use-case of “huge, annoying, evolving in all the wrong directions essentially CRUD app”. Yet we’re not even stuck with Django - I see webdev regressing into horrifying piles of JS…
- bcrosby95 5y ago
  Because Rails doesn't encourage modularization. It's fine at small sized codebases but eventually you want to "package by feature" (to borrow a Java term) rather than by layer.
  - Lio 5y ago
    Out of the box rails provides Modules, Concerns, Engines and Gems as mechanisms to package by feature. If you want to back that up with static types Ruby > 3.0 provides that out of the box too. What is it you think it's lacking?
krageon 5y ago
> in most cases I'd say it's so close to every single case, thinking about the rest is best characterised as daydreaming.

ctvo 5y ago

Who is trying to switch to GraphQL? Especially for service to service, internal calls?

dham 5y ago
Unfortunately a lot of companies right now. Although the smart ones have already done the switch and are now trying to switch off. I've seen a lot of suspect technologies in my career but GraphQL is definitely the worst
- pcstl 5y ago
  Out of sincere curiosity: Why do you think GraphQL is so bad? I've been using GraphQL for a little while now and I've had nothing but good experiences (although my use case might not be the most common) so I'm interested in knowing what makes you think so poorly of it.
  - oleg_antonyan 5y ago
    Not the one you asked, but I'm also stuck with supporting graphql in relatively small project. Zoomers invented SOAP. It's a perfect example of adopting what FAANGS do just for the sake of it. It's probably great when you have dozens of consumers with very different needs and usage patterns. But for the single frontend it adds way too much complexity on the server-side. Debugging, testing, writing tons of boilerate code, not to mention POST requests for getting data - everything becomes more complicated with 0 benefits
    - alphabettsy 5y ago
      Zoomers invented SOAP? Are we thinking of the same Zoomers? Same SOAP?
      - coryrc 5y ago
        GP means GraphQL is a Zoomer's version of SOAP (with all that implies)

blurker 5y ago

> Just like influencers in any other field, developer-influencers often describe a reality that is aspirational even for their own companies. It may be true that people writing about ideal processes live in an idealized situation where it’s possible, in which case they’re the exception that provides the rule. But most of the time — even if it’s true in one part of an organization or at one moment in time — this reality does not hold across their entire company and forever more. BINGO! This really resonated with me. It's a good reminder that developer social media is going to have some of the same things going on as regular social media, like unrealistic comparisons to idealised snapshots.

austincheney 5y ago

My personal recommendation is to do some self reflection on what things are most important to you when it comes to spinning up a new project and build your own kit. This is your tool bag as a developer. I have seen a lot of people try this and fail because they aren’t building a personalized kit, they are putting together popular dependencies. That is radically different. When you build your own kit it is tiny and extremely portable. You dig into the nuts and bolts to see what works and what plays well together. Since it’s all your personal preferences you maximize on productivity every time you use it. The best part is that you only have to build it once. Then after it’s a few hours of maintenance every six months as your requirements and preferences evolve.

pm90 5y ago
What happens when you work at a company that uses a different stack though? Can’t force a Java shop to start using Golang just because I like it and have developed my experience around it.
- macintux 5y ago
  Unless you’re a megalomaniac CTO. Amazing what companies will do (typically disastrously) when a new CTO arrives.

AnotherGoodName 5y ago

You'd be surprised at how fast you can create something with an SQL database, a well used backend framework (eg. Rails) and a well used frontend framework. The things big tech companies do are usually to avoid scaling problems. In particular scaling on the engineering side. The above can scale to billions on the user side if needed but 10k engineers constantly updating and messing with a traditional SQL schema doesn't work. You'd be crazy to try to replicate something like the big tech companies database storage systems when you're just starting out. You don't have 10k engineers. You may think "but i want to scale to a billion users". Well you still don't have those problems. The scaling problems big tech companies have are scaling to 10k engineers.

arvinsim 5y ago
One cannot predict the future but I agree that for most indie outfits, YAGNI would apply.
urthor 5y ago
It's also that, in the past, the capacity of our monoliths to scale was far lower. There's many apps that need say, a 100GB database in 2022. Those apps also needed 100GB database in 2007, when horizontal scaling was the hottest thing around. Nowadays however, Moore's law has steadily overtaken an order of magnitude of use cases from 2007. Maybe 1/10th of the 2007 use cases still need that kind of enormous, big tech scaling.
- adra 5y ago
  Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usually best for more senior teams that have specific need for it.
  - Nextgrid 5y ago

pmarreck 5y ago

On the one hand, your MVP version 1.0 should probably be built in anything that is fast and works. On the other hand, you're gonna want to rebuild that ASAP in something that has legs for longevity's and paying down tech debt's sake. You won't potentially have an edge over any competitors by using their same tech stack.

macintux 5y ago
I suspect that for most companies, the tech stack they run, the custom software on top of it, isn’t meant to be a competitive advantage. It’s just the cost of doing business.
- pmarreck 5y ago
  Right, but I know that to be false. In the extreme case to prove my point, if you write your stack in Brainfuck on top of Oracle, you're going to have a much harder time than if you write it in JS on top of Postgres

alberth 5y ago

We way over complicate things. SQLite can be used for 95% of real world use cases. And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases. And don’t fool yourself into believing you’re not in that 1%.

bob1029 5y ago
We've been using SQLite for 100% of our data persistence needs for the last ~5-6 years now. Our largest single environment is probably getting close to 500gb total size. Hundreds of concurrent users are no problem for us, even without these enhancements (we use WAL currently). The biggest single trick I learned was to use 1 sqlite connection instance for the entire lifetime of the application. You can add orders of magnitude more throughput with this path. SQLite serializes writers by default so dont duplicate the effort. You can even use the RETURNING keyword to grab insert keys without needing to lock over LastInsertRowId. We also are close to 100% of business logic being executed via SQL queries as well.
- alberth 5y ago
  That’s great to hear. Would you mind sharing how you implement/use 1 connection?
  - bob1029 5y ago
    I would just think of it as 1 global static SQLiteConnection instance. There's really not a whole lot to it. Like 4 lines in a class file to set this up.
    - alberth 5y ago
      How do you implement this using a stateless stack (eg PHP)?
      - dgfitz 5y ago
        I’d build a (stateful) shim micro service that the stateless code interacts with, no idea if that is the “most correctest” solution though

FpUser 5y ago

>"Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers." My approach - I could not care less about what FAANG does. Due to their scale and org structure they are solving problems which 99% of mere mortal businesses will never face. I am not a luddite and am constantly looking for new things that can make my development easier. But I consider those from ROI point of view as I am vendor with clients and I want to make money, not waste it. Coolness factor, fashion, corporate propaganda / indoctrination mean zilch to me.

hzlatar 5y ago
I am curious to know how you evaluate a new development product in respect to the ROI? What characteristics should a product have to satisfy your criteria for considering it?
- FpUser 5y ago
  Example - I have JSON based RPC so that systems from other vendors can talk to mine (enterprise backends written in C++). It works like a charm and has ben doing so for years. Here comes this architecture astronaut and tells ma that I should do GraphQL and proceeds to explain me how powerful and cool it is and how everybody and his cat uses it. So on the downside I will waste a gobbles of time and money, on upside - zilch because nobody gives a shit. The problem is already solved for us year ago so buzz off. And that guy could not give a single example of how it can help me. Just spreading FUD about existing things. There are numerous opposite examples when I see that this new tech, lib, tool actually saves me time and money. I pay quite a few dollars for software tooling. Well if the tool does not offer perpetual license it is a no go for me then. This is all that matters to me. On desktop for example I skipped moving to that .NET bandwagon and stayed with Delphi for my GUI desktop products. They worked 20 years ago and they work the same now. Single 10MB self updating exe with zero deployment issue. And free from numerous limitations imposed by UWP. Competitor is 1GB package with crapload of problems and every update turns a nightmare for customers. In my case all the time is spent creative stuff that brings me new customers / money instead of feeding someone else. Sure it costs me few hundred a year but that is peanuts.

bloodyplonker22 5y ago

I use MongoDB, Cloudflare, Snowflake, and Datadog and I love them all because they are all great and easy to use products that get the job done and make it easy for other developers to collaborate as well. People will mock me mercilessly for not using free OSS, but guess what, I don't want to deal with the headache of setup and maintenance! These products all have their parallels at big companies (such as Borgmon and Bigtable), but they're much better in practical use cases in non gigantic companies.

LAC-Tech 5y ago

IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy

ehnto 5y ago
I agree, except as I am not in the VC rat race I am more than happy to suggest people keep it simple.
- LAC-Tech 5y ago
  Neither am I - but all my reasons still apply. Try getting a job as a dev with vanilla JS and SQLite skills, as opposed to React and Microservice skills. What a business needs on a technical level doesn't matter when it comes to finding jobs.
bgroat 5y ago
I'm literally running 5 sites and $40k MRR on a $5 linode
- devoutsalsa 5y ago
  I love hearing stuff like this. What are you using for your database(s)?
  - bgroat 5y ago
    MySQL - just checked. I would've sworn it was postgres. Just shows how much attention I pay to anything that isn't business logic
- logankeenan 5y ago
  That’s awesome! Do you mind sharing about your tech stack or how you deploy?

bjterry 5y ago

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup selling developer tools, by all means think about the 99% developers, but also know that a lot of them are in environments that don't spend a lot on tools and are averse to exploring new technologies. If you are a developer in one of these environments, well, the standard advice on Hacker News is already "You're not Google." I feel like some of this is a bit fatalistic. The 99% can follow a DevOps playbook if they realize its value, and it's cheaper to have DevOps than to not have DevOps, in the anything-more-than-short timeframe. The 99% can certainly have test coverage standards for new code. Somehow, we moved from a world where the 99% didn't use source control, and now they do! Some technologies and practices are so impactful, you should aspire to them no matter what you're environment is (e.g. code review, CI/CD). The 99% concept also hides a lot of important details, as it's defined by exclusion. The choices you need to make for an early stage startup, a mature WordPress shop for small businesses, and a legacy mainframe team in a F50 are as different from each other as they are from FAANG.

newrotik 5y ago
The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?
- weq 5y ago
  So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out? Serverless allows anyone to be scale for minimal up-front cost and only pay for the usage they really need. So glad that FAANG attract all this rare talent so us no-FAANG engineers can make a buck.
  - lelanthran 5y ago

sirspacey 5y ago

This article didn’t resonate with me as much as I was expecting. While the insights on developer influencers was sharp, the article itself felt like more of a reaction than an evaluation. I’ve worked in many legacy companies. The rationale for staying on the tech stack they have, and the approach they take to DevOps, is not particularly well reasoned. Often they are experiencing painful consequences due to their adherence to old design patterns. I wanted each paragraph to be more diagnostic, frankly more reminiscent of the wide ranging and interesting debate we find here (especially when the old guard shows up and speaks with real authority and wisdom on how the problems they solve don’t map to Kubernetes, etc.). I’d really welcome counter-arguments to the point I’m making, so I’ll frame it this way: This felt like the same kind of “playing to the crowd” that dev influencers do, just a different crowd.

adra 5y ago
I think the point that should be well taken is that if you're hoping to service the greater programming community, you can't do so in your ivory tower solutions on a community Ill equipped to utilize them. From experience, DevOps done poorly is terrible and demoralizing. Agile done poorly (often) is terrible and slow. Take any best practice and try to apply it to any organization and you'll get a lot of flaming wreckage. Ideally those companies will have some pragmatic people that can nudge their people in the right direction gradually.
- hvidgaard 5y ago
  Anything done poorly and terrible is, well, poor and terrible.

sanxiyn 5y ago

a16z invested to Replay, "The Time Travel Debugger for Web Development". Go read about it here https://medium.com/replay-io/launching-replay-the-time-travel-debugger-for-the-web-f886f0897d38 https://medium.com/replay-io/launching-replay-the-time-trave... and read this again. It all makes sense.

joeldo 5y ago
Are you implying that a16z wants websites to be as difficult as possible to maintain that a tool like this is necessary?
- sanxiyn 5y ago
  I would say a16z is realistic about it. From the article, "Heterogeneity is here to stay".
- exdsq 5y ago
  Haha never thought about that but it’s a fun connection

muglug 5y ago

Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 https://twitter.com/copyconstruct/status/1456129831821709315 > a lot of what most “developer influencers” say is fairly aspirational. Their own companies don’t necessarily do things as smoothly as they preach to others. There's a pride element there: developers don't want to admit that they work in less-than-stellar conditions. Some developer talks also double as recruiting events, and you're going to turn people off when you mention that the test suite takes a day to run and requires the use of a fax machine.

djbusby 5y ago
Easy to automate with Hylafax (2002), probably some SaaS API (2022) (there are at least a dozen Fax/SaaS things now)
ryandrake 5y ago
One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...
- galaxyLogic 5y ago
  I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further. But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.

jasfi 5y ago

I've been working on an SDK for Flutter that is simpler, easier to code, and is closer to HTML/JS. You write your code on the back-end, although you could use the same SDK on the front-end. Nim is the initial back-end SDK: https://nexusdev.tools/ https://nexusdev.tools/

adra 5y ago

Yep, great write-up . I spent so many years in companies that were perpetually behind the times and rarely catching up. I now work for a large scale SAAS offering trying to sell to these developers. It's consistently an up hill battle trying to sell my peers on the realities outside their bubble, but it seems pretty fruitless.

d--b 5y ago

I am not sure what the point of the article really is. I mean it’s not wrong, we all live in that real world (my job is literally migrating off stuff) and recognize everything the author says. It’s just that I don’t see those myths being myths in the first place. In fact, thinking that the 1% is any different is perhaps the biggest myth in the article. Sure they have distributed crap to handle and uptime commitments to go by, but I don’t expect the life of these people to be much different

mirekrusin 5y ago
You may be lucky, surrounded by sane people. Having new joiner stating on 2nd day that the whole system has to be moved to microservices on graphql with blue/green continuous deployment to solve all past and future problems is a real problem, it does exist. Some people seem to fall into this trap described in the article of reading some blog post on some approach and fixating on it in religion-like mindset. It makes it hard to unwind ideas they throw into business people's minds because they all sound superficially great. You have to break it down to first principles and go through it, explain why things make sense for 10k+ engineering teams but don't for our dozen people team. They will call current architecture legacy from the start and that sticks with business people. The reality is often the other way around - big players would love to be able to run systems using those simple, straightforward arrangements: single version for all services, ability to have few minute downtime to upgrade system offline, single monorepo, single database – but they simply can't because they have thousands of people working on it, running at massive scales across the globe. When you say those things people get very defensive and it's hard to keep dialog on. Because those new things could actually work very well, but ie. not as replacement for everything but to create some satellite services, maybe for things that crystalized over years, unlikely to change and can be extracted as dedicated service, maybe graphql makes sense for admin section where the f/e team wants to experiment more etc. I'd say: - be rational - analyze from first principles - use N-order thinking - be open minded - for new tech and ~legacy~ current tech - judge on simplicity as one of main criteria - stop calling tech you're currently running without already available alternative "legacy" - it's your "current" tech - monoliths are not "legacy", they are desired if possible, split if they'd simply not work or you organically grew into maturity level where it start to make sense - same with single database - same with single versioning - same with single monorepo - use your own business reality as base for evaluation, not somebody else's reality

wh-uws 5y ago

let me calm down and breathe and I'll take the bait ... look just because you're not Lebron James or Michael Jordan doesn't mean you can't go to your local basketball court and enjoy a game of pick up. But the same way you don't conflate what you need to do to be one the of the best people to ever play a game to play at all... your software engineering team doesn't need to feel completely useless because they aren't immediately using <insert new hot tool> . Everything in software engineering from side project to unicorn startup service is about tradeoffs. Tradeoffs happen because of constraints. I don't expect a consulting shop to build code the same way an open source project does or a publicly traded company that has been profitable for 10 or 20 years. I'm hoping you can read in this the need to be cognizant about manpower tradeoffs. So yes I fully appreciate this as someone who has consulted, worked a public companies, and is now at a rapidly growing startup... Just because your team isn't meeting some imaginary ideal for some other form of team with different constraints doesn't mean you can't ever strive for any ideal or give up... you just have to be realistic about trade offs... my favorite example of this is thinking about a system like rails vs early react (loooong next.js or even before the context system) or a lot of things built in the python web ecosystem. With rails you have scaffolds and endless convenience methods that let you be productive quickly even as a small team or shop... with early react or python web you were largely left to your own devices out side of the core flows they had solved (painting updates to the dom with react or some rudimentary crud stuff with django or flask) ... Because they were built by and more importantly FOR different types of teams. Rails by the relatively slender (and famously against VC type scaling) 37 signals consulting crew and react by facebooks behemoth engineering team. Of course they are going to build for their own trade offs... why would you not? (I intially opened this rant with this final piece thata I thought better of starting with but I still stand on the feeling... The is the biggest piece of curmudgeonly nonsense I've ever read... its like someone training an ml model on last 5 years of HN comments and churning out a click bait blog post)

oxplot 5y ago

Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. - Avoid if the developer base is mostly young people: They are energetic and they don't mind complicating the shit out of something, because they can figure it out now and probably down the road. I'm old, and I just want things to work and I want to understand how it all works without spending a week and wrestling with tooling. Not all out-of-college folks are the same but most are (and I used to be one, so there). - Avoid kitchen sinks: borrowing ideas sparingly is fine - throwing in every new feature in another language you come across makes for a soup, not a tool. A good heuristics is the rate at which features are added. Look for logarithmic trend.

travisgriggs 5y ago
Would you be willing to share some of the languages/frameworks that have made the cut or washed out for you based on the rubric you’ve given. I’m honestly curious.
- oxplot 5y ago
  I specifically avoided mentioning examples as that'll stir up a lang-war.
  - ZephyrBlu 5y ago
    Your rules are so vague that I have no idea which languages/frameworks would qualify and which ones wouldn't. Does React specifically mention big companies, have a young developer base and is a "kitchen sink"? I have no idea. Is Python a "bad" language? What about Go? C++ kind of seems like a kitchen sink, is it "bad"? I really have no idea how to figure out if these rules apply to any languages/frameworks.
    - 5y ago

Yhippa 5y ago

cheriot 5y ago

In a lot of ways, large tech companies are living in the future. They have to invent things that later open source tools will imitate and then others start to use. Examples: map reduce, various rpc standards like graphql and grpc, and a whole mess of non-relational data stores. I work with kubernetes a lot right now and it's effectively a smaller, less featurefull version of what google runs on, but it's light years ahead of what we were using before. A huge portion of the industry will be 10, 20, even 30 years behind and that's fine. I don't think there's any myths about this.

pictur 5y ago

Nowadays, there is a lot of focus on process in software development. and this often allows us to miss the target. The tools used are important yes, but how you use them is more important.

metaph6 5y ago

that was a great read! Shared it on my company's LinkedIn page :)

aaronbrethorst 5y ago

That’s a lot of words. Too long; didn’t finish reading. What are they trying to sell me on?

AceJohnny2 5y ago

In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code for fun. Everyone for whom coding is something that gets in the way of their real objective. No wonder they produced bad code! But that's not the point: they're solving something else. They're not spending effort making bug-free maintainable code, they've got more important things to do. They're doing the accounting for their small company, point of sale for the shops in their city, all the kind of things that may not be glamorous but that's all around us (for better or for worse) So while I puttered around in my self-congratulatory ivory tower of unix, Microsoft understood what the real world needed, for the 99% of developers...

mro_name 5y ago
I think it's much more profane - Microsoft didn't understand what the real world needed, they just leveraged a monopoly (that IBM let them establish) to frame what a computer looks and feels. They shaped the world to their liking and now it looks like a match. duh.
- math-dev 5y ago
  Basically this
- just-tom 5y ago
  I'd argue the opposite. All Microsoft did was understand what the world needed. Were they successful because of their great marketing or their flawless coding? No. Was Windows spread like a wildfire because it solved real world problems? Yes. Is it one of the most, if not the most, influencial software ever made? Yes, no matter how dull and incompetent people might say it is. For the accountants out there, school teachers and doctors, it was magic.
  - mro_name 5y ago

progx 5y ago

The developer bubble. 99% of all developers had enough todo with their work, they don't have time to write shiny articles about the used technology. This should make it clear that many great articles on many great technologies are written by a few, most of which are at an academic level and have less to do with the practice of 99%. But everybody thinks that using this tools that way is normal, it isn't.

maccard 5y ago
I don't think this is true. As a developer my job isn't just to crank out code, it often involves doing tasks that are important to the company like interviewing people, writing documentation, occasional team meetups. One of the things that's pretty apparent after spending time on HN and other forums is that these articles when well written are absolutely excellent marketing material. It makes sense for a company to allocate development resources to writing them.

ramyarjahani 5y ago

[dead]

cryptica 5y ago

Great to see that big VCs are having these deep insights. As a developer, I've essentially had to leave the industry because all the small software companies are constantly coercing all their developers into using specific tools and processes from big tech companies and unicorn startups and I was constantly pushed towards solutions which are too bureaucratic to work efficiently in a small company setting. I was too passionate about coding to butcher it in this way so I left the professional sector and focused on open source (thankfully I have enough side income to do this). It's mental torture to come to work every day, working in an industry which is supposedly all about logic and problem solving and be constrained by what is essentially religious dogma when applied in context. 10 years ago, it was such fun to be in the software industry as a developer. The company directors would trust you to choose any stack/framework you wanted or even build your own lightweight in-house framework (or no framework at all). It's no longer the case.

exdsq 5y ago
Weirdly one of the reasons I moved from development to a test engineering role is you have way more technical freedom. I can basically use whatever tool I want because there’s way less oversight as long as the job is done. Want to test a CLI? Use Go/Rust. Want to load test a website? Use Scala. Data parsing? Write a lexer in Haskell. I think I’ve used almost every language in the top 30 in production thanks to this. And it’s not even just language - need reporting? Try a new web framework. Need to store data between tests? Try a new database. I’ve written far more fun code in a testing role than I ever could in a dev role :)
- cryptica 5y ago
  Sounds like you found a good way to keep learning on the job. This approach wouldn't work for me though because I like building products and features. The way I kept learning was by doing open source on the side.

brunoborges 5y ago

Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves the performance problem with dozens, sometimes hundreds of replicas for one particular microservice. Many developers don't even understand the impact the JVM has when running on a single core (yeap... you get Stop the World GC - aka Serial GC - by default). And then, the dev team decides to move to a new language because of performance and cost issues. And that by itself just brings many other problems. All they had to do was keep the same amount of CPU and memory, but less VMs and replicas, with more vertical resources. Depending on the workloads and the system, it is even possible to reduce the cost. All this is caused by the push in the industry for companies to go Cloud Native.

zhughes3 5y ago
So you can’t scale java horizontally?
- lvice 5y ago
  I don't know java, but that's not the message I got from the comment. It looks like with java, 3 VMs with 2 cores are better than 6 VMs with 1 core, which may be forgotten when configuring equivalent kubernetes services.
  - brunoborges 5y ago
    Exactly that.
- hvidgaard 5y ago
  I don't think you quite understood what (s)he wrote. The problem is using JVM without understanding some basic properties of it. Scaling is a matter of how you programmed it, not the language used.
- 5y ago

intrepidsoldier 5y ago

When I was a programmer, I was never on Twitter, HN, or Reddit. Stackoverflow maybe sometimes. When I became a Product Manager, I started voicing opinions on all these forums.

streamofdigits 5y ago

I think the article makes a very important point about under-resourced developer teams but misses an opportunity to point out that most other teams within organizations and businesses face similar constraints. I think this favors stacks and frameworks where the business logic of a domain is already reflected, at least partially. This might explain why some open source frameworks persist and thrive even while their "tech" is deemed obsolete / deficient...

zuhayeer 5y ago

"I’ve encountered so many teams who say that migration will happen “next quarter.” The reality is that, even when they manage to finally start, migrations have become continuous, rather than discrete, processes. A 99% Developer team with legacy code and a lean team is probably never going to convert their entire code base over to microservices or GraphQL. For most organizations, tech stacks and tool chains are heterogeneous, a combination of the layers of languages, frameworks, and tools that have been picked up over the years." Generally observed that the less you see engineering as an ideal state or set of standards, and rather as a living and breathing organism in your company, the easier your life will be. If you're ever working on a 100% refactor of something to a new framework or system, chances are you're not focused enough on the top line problems at your company. Which is related to https://rkg.blog/desperation-induced-focus.php https://rkg.blog/desperation-induced-focus.php

mbeex 5y ago

> It’s well-known among developer tools creators, for example, that integrating with GitHub and GitLab will help make your tool much more useful and appealing. Certainly not for me personally, nor for the 10 or so companies I've worked for as a freelancer over the last 10 years. Among them are some - real - market leaders as well as small and fine companies that are extremely demanding when it comes to self-used technology (including development tools, of course). Just look at who the owners of github (most people know it) and especially gitlab (most people don't) are. More generally, just the single arbitrary picked difference between one company producing something tangible and another producing a pure software product should be eye-opening to anyone who has had both types of experiences. As for my career path, I've worked in instrumentation, avionics, cars, and Embedded, among others. Each with a very different culture, even among themselves, not to mention compared to software companies.

usrbinbash 5y ago

> Too many people believe that aiming for good software quality means you need to fully adopt that new technology, whether it’s microservices, GraphQL, or distributed tracing. You’re not done until you’ve switched fully over to the ideal technology. This. We are constantly presented with new and shiny things. And then, barely a year later, there is the next ideal technology. And the next, and the next, and the next. We have seen this with everyhing: Languages, coding standards, paradigms, editors, organisational methodology, interview methodology, frameworks, databases, security, design basics,...the list is endless. But here is some truth: C is still written. As is pure JS. Imperative/Prodecural code never went away. Websites on servers we can physically touch are still deployed. People still write working implementations for almost everything under the sun from scratch. Information-Dense, slim, efficient interfaces that get jobs done are still there. As are monolithic architectures. Good 'ol RDBMS still work great. bash is still the dominant shell. grep/cut/awk are still great for analysing logs. Water still flows downhill. "new" and "better" are 2 different words, with different meanings. Something that's new could be better. But he fact that it's new, in itself, doesn't automagically make it better. And even if its better in one scenario, its doesn't have to be better in all scenarios.

pjmlp 5y ago
Indeed, that is why even though I regulary rant about C or its influence in C++/Objective-C, I am not naive to think it is going to go away until we switch to something radically different in computing models (away from UNIX, quantum, whatever), hence why at the same time there is a very big value in achieving some improved security while using those languages, regardless that we still cannot make it 100%, 90% there is better than nothing.
dahart 5y ago
> new, in itself, doesn't automagically make it better. Indeed. It’s often the case that new is worse, and the authors and influencers pushing the new don’t know it yet, or sometimes they do but they downplay that knowing it will take time to get better, and underestimate how long. The reason old defaults to better is simply because it’s been used more, it automatically solves more problems because by the time it’s old it’s been built to solve more problems and it’s weaknesses have been fixed or patched or shimmed or worked around. Old isn’t automagically better either, of course, and things can get too old and too shimmed, but if the new thing is solving the same problems and being compared to something well tested and used by many, it’s very unlikely to be better until it starts getting old. Maybe we should take a minute to ask: better for who? Better for customers is different than better for programmers. New is both more fun and easier to maintain. New is better for programmers. Old is better for customers, it’s more stable and changes more slowly. There is something pretty important to be said for being an early participant in a project, programmers who are involved in building and integrating new things automatically become more productive than programmers who get hired to maintain old things. I’ve seen this first-hand in several different ways, the most stark of which was selling a company to programmers better than me, but took years to become productive because they didn’t know how everything worked and didn’t want to break anything. There is also something to be said for replacing old with new. I’ve seen first hand teams tear down old engines because they felt crufty to build new ones, with the promise that it was going to be fast and easy and that they learned their mistakes the first time. Two completely separate companies launched into a 1 year rewrite that ended up taking 5 years, costing tens of millions, and making a good deal of the same mistakes over again before they were done. Both cases were failures to evaluate how well things were working in the old system, they were blinded to the overall success by the long list of rather minor problems.

ChrisMarshallNY 5y ago

I remember this post[0], here, a while back. I’ve been shipping (as opposed to coding), for my entire adult life, and I’ve learned (the hard way, of course) that “ship” is always at least a couple of clicks back from “bleeding edge.” I’m in the home stretch of an app that I’ve been developing for the last year and a half, or so. The backend is written in PHP, and the frontend is a “classic” UIKit/Storyboard/MVC app, as opposed to a SwiftUI/Combine/MVVM project. It’s fairly ambitious, and, when I started, I was not confident that “the bleeding edge” would work (it might have, but I didn’t know that it would). There was no question that the classic patterns would work, so I picked them. It’s coming along great; far better than I had originally envisioned the project. It is ultra-high-quality, fully native, with only one small external (meaning that I didn't write it, myself) dependency (the backend has zero dependencies), has many capabilities that have only appeared in the last couple of OS releases, is easily localized, conforms to multiple device configurations, dark mode, accessibility features, etc. I read (here), about a well-known app that had been a highly successful classic native app (probably written in ObjC) that was supposed to be rewritten in SwiftUI, but the project failed, and was eventually shipped in Electron. That’s kind of my worst nightmare. I suspect the developers had to put clothespins on their noses, for much of the project. I will be releasing software, using more cutting edge tech, but all in good time. It’s unlikely to be “cutting edge,” by the time I use it. I like to give the stack enough time to smooth off the rough edges, before I rely on it for ship. I know that many fairly well-known applications for Apple platforms, are still written in Objective-C. Even Apple still uses it, for some of its internal tooling. I will admit that one gamble I took, was jumping on the Swift bandwagon, almost immediately, but there were multiple signals that it was not another OpenDoc[1], and that I could trust it. I’m fairly conservative about bandwagons. It’s earned me more than a few sneers (especially since I’m an older chap), but -and this bears repeating-, I’ve spent my entire adult life, delivering finished software. It’s not always been great software, and it has not always been commercially successful, but it has all been “finished.” There was a post here, some time back, where the author challenged the reader to mention three projects in their career that they had finished. My comment was that I could mention thirty, and point to the repos. This was met with incredulity, which shocked me, as I have known many developers, far more productive than I. I guess times have changed. [0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/ https://vickiboykis.com/2019/05/10/it-runs-on-java-8/ [1] https://en.m.wikipedia.org/wiki/OpenDoc https://en.m.wikipedia.org/wiki/OpenDoc (Full disclosure. I was very much a “bandwagon” guy, back then, and even took an OpenDoc course, from Apple’s DU).

sidcool 5y ago

The name of the author of the article is Jean Yang. :) (I am aware it's Jian vs Jean, but happy anyway)

mschuster91 5y ago

> For instance, companies with legacy systems that can’t afford to migrate to the newest architectures need to adopt new tools differently than newer companies, or companies that can dedicate a team to a large migration. Not to mention, this sort of company needs to do a careful evaluation if the chosen product and especially support for it is likely to be around for a while. Many got bitten hard by Angular's demise - and now imagine this for something like a database that's supposed to hold your entire corporate data.

cebert 5y ago

I believe Serverless technologies are a game changer for the 99%. I work at a firm that could be considered part of the 99%. We build mission critical apps, but don’t have entire teams dedicated to building platforms or managing Kubernetes. Most of our talent is average compared to FAANG. We don’t have SREs or developer advocates, but we do have customers who rely on our software for life and death situations. Serverless technologies help us build scalable, highly-available, and performant cloud applications that run by default in multiple availability zones and multi-region with minimal additional effort. We leverage GitHub Actions to drive our CI/CD process and automated testing. Instead of focusing on managing servers and cloud infrastructure, us simple 99% developers, those who get passed up by FAANG and Leetcode grinder interviews, can build solid applications that provide value to our customers and generate nice profit margins. The 99% can deliver apps that can perform similar to the 1% with far less complexity.

zozbot234 5y ago
CGI was the first Serverless technology. Then PHP did it even better.
- emrahsamdan 5y ago
  Serverless as a term mixed up with FaaS. In 2022, Serverless is more general as it can be defined anything that autoscales to infinity and scales to zero when not used and pay per use. Amazon DynamoDB is also serverless in that sense for example.
  - zozbot234 5y ago
    > anything that autoscales to infinity and scales to zero when not used and pay per use Ah, you mean grid/utility computing. But as you point out that's broader than FaaS.
pokepim 5y ago
100% agree. Even tough i work at F500 company our team acts like a startup. With server less we don’t need to hire expensive devops and shell out millions for expensive k8s clusters. I am pretty sure it’s the future for most of us.

thrower123 5y ago

In a similar vein, the old classic Choose Boring Technology is worth reviewing from time to time. https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

bikamonki 5y ago

I never jumped into the React wagon, just as I never took the Wordpress train. You do not hire an 18-wheeler to deliver a pizza. Engineers on any subject have one job: design the optimal solution, be it a bridge or an SPA to take online orders. React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. Even vanilla JS does the job in most cases. 99% developer feels compelled to learn and adopt what is trendy because that is what the client/market/boss demands; but it is you the 'engineer' who has to tell the client/boss how that bridge is to be built. When was the last time you went to a doctor and said: hey doc I have this, give me that medicine.

netizen-936824 5y ago
>When was the last time you went to a doctor and said: hey doc I have this, give me that medicine. Allow me to introduce to you: pharma advertising in the US
waffle_maniac 5y ago
> When was the last time you went to a doctor and said: hey doc I have this, give me that medicine. My physician friend fires patients for doing this kind of stuff. Usually they demand unnecessary x-rays and CT scans.
H1Supreme 5y ago
> React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. And that would be what? Exactly? I did a personal project last year that was vanilla HTML/CSS/Js, with some templating in Go (I know it's templating isn't the best, comparatively). By the end, I wish I would have done it in React. I ended up re-inventing the wheel for a lot of things, and ended up with something that was decidedly messier. All while attempting to be more simplistic. I wish Web Components would have taken off. When Polymer first launched, I was totally on board. I loved the idea of writing vanilla frontends, and using Web Components where I needed extended functionality (vs a full framework). But, it didn't, and unless your site is super simple, and mostly static, React et al. are the best ways to create frontends.

deleted 5y ago

[deleted]

kohlerm 5y ago

Not sure I understand what the message of the article is. Sure not everything companies with big scalability requirements do, makes sense for smaller projects. Nevertheless some principles still make sense. E.g. a mono-repo can make sense (again depends on what you want to build) and it is even easier to handle at a small scale.

kwertyoowiyop 5y ago

Thanks for the news flash. In other amazing discoveries, fire is hot and the sky is blue.

msoad 5y ago

I understand the point of the article but I have a different approach when I decide to start a company. I'm going to hire all the weirdos that want to build things in Rust and try EdgeDB or render in WebAssembly. I think most great software are built by those "top 1%" engineers. See Figma for instance, it is built using technologies far ahead of its time. And that's why it's such a delight to use. pi's article on this seems relevant here: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html

bncy 5y ago

> what coding, testing, and shipping looks like with short-staffed teams, teams without dedicated devops experts, and teams where everyone who originally built the system has left. This one hits really hard and I'd love to see more of that content.