TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Building for the 99% Developers

477 pointsby bdburnsover 3 years ago

43 comments

AceJohnny2over 3 years 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.<p>Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those &quot;99% developers&quot;. The ones who don&#x27;t read HN, the ones who don&#x27;t code for fun. Everyone for whom coding is something that gets in the way of their real objective.<p>No wonder they produced bad code! But that&#x27;s not the point: they&#x27;re solving something else. They&#x27;re not spending effort making bug-free maintainable code, they&#x27;ve got more important things to do. They&#x27;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&#x27;s all around us (for better or for worse)<p>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...
评论 #30372226 未加载
评论 #30370754 未加载
评论 #30371138 未加载
评论 #30370685 未加载
评论 #30372828 未加载
评论 #30371504 未加载
评论 #30371557 未加载
评论 #30373359 未加载
评论 #30371800 未加载
评论 #30370796 未加载
评论 #30374315 未加载
评论 #30370862 未加载
评论 #30393531 未加载
评论 #30375190 未加载
评论 #30371250 未加载
评论 #30372455 未加载
评论 #30378252 未加载
评论 #30376242 未加载
评论 #30372473 未加载
评论 #30373373 未加载
评论 #30371207 未加载
评论 #30373154 未加载
AnotherGoodNameover 3 years ago
You&#x27;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.<p>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&#x27;t work.<p>You&#x27;d be crazy to try to replicate something like the big tech companies database storage systems when you&#x27;re just starting out. You don&#x27;t have 10k engineers. You may think &quot;but i want to scale to a billion users&quot;. Well you still don&#x27;t have those problems. The scaling problems big tech companies have are scaling to 10k engineers.
评论 #30369501 未加载
评论 #30369926 未加载
评论 #30370772 未加载
评论 #30369118 未加载
blurkerover 3 years ago
&gt; 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.<p>BINGO! This really resonated with me. It&#x27;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.
usrbinbashover 3 years ago
&gt; 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.<p>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.<p>We have seen this with everyhing: Languages, coding standards, paradigms, editors, organisational methodology, interview methodology, frameworks, databases, security, design basics,...the list is endless.<p>But here is some truth:<p>C is still written. As is pure JS. Imperative&#x2F;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 &#x27;ol RDBMS still work great. bash is still the dominant shell. grep&#x2F;cut&#x2F;awk are still great for analysing logs. Water still flows downhill.<p>&quot;new&quot; and &quot;better&quot; are 2 different words, with different meanings. Something that&#x27;s new <i>could</i> be better. But he fact that it&#x27;s new, in itself, doesn&#x27;t automagically <i>make</i> it better. And even if its better in one scenario, its doesn&#x27;t have to be better in all scenarios.
评论 #30371834 未加载
评论 #30374054 未加载
muglugover 3 years ago
Article mentions a tweet which narrows in on a prime culprit: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;copyconstruct&#x2F;status&#x2F;1456129831821709315" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;copyconstruct&#x2F;status&#x2F;1456129831821709315</a><p>&gt; 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.<p>There&#x27;s a pride element there: developers don&#x27;t want to admit that they work in less-than-stellar conditions.<p>Some developer talks also double as recruiting events, and you&#x27;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.
评论 #30370251 未加载
评论 #30370075 未加载
brunoborgesover 3 years 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.<p>Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs&#x2F;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&#x27;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).<p>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.<p>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.<p>All this is caused by the push in the industry for companies to go Cloud Native.
评论 #30370961 未加载
评论 #30370843 未加载
评论 #30370736 未加载
bjterryover 3 years ago
99% feels like an exaggeration. I&#x27;ve talked to many developers from non-FAANG companies, and it isn&#x27;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 &quot;1%&quot;.<p>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&#x27;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 &quot;You&#x27;re not Google.&quot;<p>I feel like some of this is a bit fatalistic. The 99% can follow a DevOps playbook if they realize its value, and it&#x27;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&#x27;t use source control, and now they do! Some technologies and practices are so impactful, you should aspire to them no matter what you&#x27;re environment is (e.g. code review, CI&#x2F;CD).<p>The 99% concept also hides a lot of important details, as it&#x27;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.
评论 #30369956 未加载
评论 #30369860 未加载
评论 #30369728 未加载
评论 #30369523 未加载
评论 #30369967 未加载
评论 #30371863 未加载
alberthover 3 years ago
We <i>way</i> over complicate things.<p>SQLite can be used for 95% of real world use cases.<p>And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases.<p>And don’t fool yourself into believing you’re not in that 1%.
评论 #30369175 未加载
评论 #30369664 未加载
评论 #30369540 未加载
评论 #30375252 未加载
sirspaceyover 3 years ago
This article didn’t resonate with me as much as I was expecting.<p>While the insights on developer influencers was sharp, the article itself felt like more of a reaction than an evaluation.<p>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.<p>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.).<p>I’d really welcome counter-arguments to the point I’m making, so I’ll frame it this way:<p>This felt like the same kind of “playing to the crowd” that dev influencers do, just a different crowd.
评论 #30369620 未加载
FpUserover 3 years ago
&gt;&quot;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.&quot;<p>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 &#x2F; indoctrination mean zilch to me.
评论 #30375283 未加载
评论 #30372827 未加载
bikamonkiover 3 years 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.<p>React makes sense for FB&#x27;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.<p>99% developer feels compelled to learn and adopt what is trendy because that is what the client&#x2F;market&#x2F;boss demands; but it is you the &#x27;engineer&#x27; who has to tell the client&#x2F;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.
评论 #30372843 未加载
评论 #30374694 未加载
评论 #30373022 未加载
cheriotover 3 years 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&#x27;s effectively a smaller, less featurefull version of what google runs on, but it&#x27;s light years ahead of what we were using before.<p>A huge portion of the industry will be 10, 20, even 30 years behind and that&#x27;s fine. I don&#x27;t think there&#x27;s any myths about this.
cebertover 3 years 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.<p>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&#x2F;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.
评论 #30372410 未加载
评论 #30372304 未加载
评论 #30372302 未加载
msoadover 3 years ago
I understand the point of the article but I have a different approach when I decide to start a company. I&#x27;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 &quot;top 1%&quot; engineers. See Figma for instance, it is built using technologies far ahead of its time. And that&#x27;s why it&#x27;s such a delight to use.<p>pi&#x27;s article on this seems relevant here:<p><a href="http:&#x2F;&#x2F;www.paulgraham.com&#x2F;pypar.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;pypar.html</a>
austincheneyover 3 years 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.<p>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.<p>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.
评论 #30369930 未加载
progxover 3 years ago
The developer bubble.<p>99% of all developers had enough todo with their work, they don&#x27;t have time to write shiny articles about the used technology.<p>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&#x27;t.
评论 #30370692 未加载
zuhayeerover 3 years ago
&quot;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.&quot;<p>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&#x27;re ever working on a 100% refactor of something to a new framework or system, chances are you&#x27;re not focused enough on the top line problems at your company. Which is related to <a href="https:&#x2F;&#x2F;rkg.blog&#x2F;desperation-induced-focus.php" rel="nofollow">https:&#x2F;&#x2F;rkg.blog&#x2F;desperation-induced-focus.php</a>
thrower123over 3 years ago
In a similar vein, the old classic Choose Boring Technology is worth reviewing from time to time.<p><a href="https:&#x2F;&#x2F;mcfunley.com&#x2F;choose-boring-technology" rel="nofollow">https:&#x2F;&#x2F;mcfunley.com&#x2F;choose-boring-technology</a>
bloodyplonker22over 3 years 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&#x27;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&#x27;re much better in practical use cases in non gigantic companies.
crypticaover 3 years ago
Great to see that big VCs are having these deep insights. As a developer, I&#x27;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.<p>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&#x27;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.<p>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&#x2F;framework you wanted or even build your own lightweight in-house framework (or no framework at all). It&#x27;s no longer the case.
评论 #30370963 未加载
sanxiynover 3 years ago
a16z invested to Replay, &quot;The Time Travel Debugger for Web Development&quot;. Go read about it here <a href="https:&#x2F;&#x2F;medium.com&#x2F;replay-io&#x2F;launching-replay-the-time-travel-debugger-for-the-web-f886f0897d38" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;replay-io&#x2F;launching-replay-the-time-trave...</a> and read this again. It all makes sense.
评论 #30369653 未加载
mbeexover 3 years ago
&gt; 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.<p>Certainly not for me personally, nor for the 10 or so companies I&#x27;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).<p>Just look at who the owners of github (most people know it) and especially gitlab (most people don&#x27;t) are.<p>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&#x27;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.
jasfiover 3 years ago
I&#x27;ve been working on an SDK for Flutter that is simpler, easier to code, and is closer to HTML&#x2F;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: <a href="https:&#x2F;&#x2F;nexusdev.tools&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nexusdev.tools&#x2F;</a>
pmarreckover 3 years ago
On the one hand, your MVP version 1.0 should probably be built in anything that is fast and works.<p>On the other hand, you&#x27;re gonna want to rebuild that ASAP in something that has legs for longevity&#x27;s and paying down tech debt&#x27;s sake. You won&#x27;t potentially have an edge over any competitors by using their same tech stack.
评论 #30369981 未加载
recursivedoubtsover 3 years ago
Excellent article.<p>Most people need to get some data from a database to a web page and back again, to paraphrase dhh (I think).<p>This does not require a huge amount of architecture or infrastructure in most cases, even at scale. The engineering challenges should be <i>elsewhere</i>, not in this relatively simple and solved problem.
评论 #30368752 未加载
评论 #30371114 未加载
mschuster91over 3 years ago
&gt; 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.<p>Not to mention, this sort of company needs to do a <i>careful</i> evaluation if the chosen product and especially <i>support</i> for it is likely to be around for a while. Many got bitten hard by Angular&#x27;s demise - and now imagine this for something like a database that&#x27;s supposed to hold your entire corporate data.
picturover 3 years 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.
streamofdigitsover 3 years ago
I think the article makes a very important point about under-resourced developer teams but misses an opportunity to point out that most <i>other</i> teams within organizations and businesses face similar constraints.<p>I think this favors stacks and frameworks where the business logic of a domain is already reflected, at least partially.<p>This might explain why some open source frameworks persist and thrive even while their &quot;tech&quot; is deemed obsolete &#x2F; deficient...
d--bover 3 years ago
I am not sure what the point of the article really is.<p>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.<p>It’s just that I don’t see those myths being myths in the first place.<p>In fact, thinking that the 1% is any different is perhaps the biggest myth in the article.<p>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
评论 #30370763 未加载
intrepidsoldierover 3 years ago
When I was a programmer, I was never on Twitter, HN, or Reddit.<p>Stackoverflow maybe sometimes.<p>When I became a Product Manager, I started voicing opinions on all these forums.
adraover 3 years 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&#x27;s consistently an up hill battle trying to sell my peers on the realities outside their bubble, but it seems pretty fruitless.
kohlermover 3 years 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.
bncyover 3 years ago
&gt; 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.<p>This one hits really hard and I&#x27;d love to see more of that content.
sidcoolover 3 years ago
The name of the author of the article is Jean Yang. :) (I am aware it&#x27;s Jian vs Jean, but happy anyway)
kwertyoowiyopover 3 years ago
Thanks for the news flash. In other amazing discoveries, fire is hot and the sky is blue.
ChrisMarshallNYover 3 years ago
I remember this post[0], here, a while back.<p>I’ve been <i>shipping</i> (as opposed to <i>coding</i>), 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.”<p>I’m in the home stretch of an app that I’ve been developing for the last year and a half, or so.<p>The backend is written in PHP, and the frontend is a “classic” UIKit&#x2F;Storyboard&#x2F;MVC app, as opposed to a SwiftUI&#x2F;Combine&#x2F;MVVM project.<p>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 <i>know</i> that it would). There was no question that the classic patterns would work, so I picked them.<p>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&#x27;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.<p>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.<p>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.<p>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.<p>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>I’ve spent my entire adult life, delivering finished software</i>. It’s not always been great software, and it has not always been commercially successful, but it has <i>all</i> been “finished.”<p>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 <i>many</i> developers, far more productive than I. I guess times have changed.<p>[0] <a href="https:&#x2F;&#x2F;vickiboykis.com&#x2F;2019&#x2F;05&#x2F;10&#x2F;it-runs-on-java-8&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vickiboykis.com&#x2F;2019&#x2F;05&#x2F;10&#x2F;it-runs-on-java-8&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;OpenDoc" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;OpenDoc</a> <i>(Full disclosure. I was very much a “bandwagon” guy, back then, and even took an OpenDoc course, from Apple’s DU).</i>
metaph6over 3 years ago
that was a great read! Shared it on my company&#x27;s LinkedIn page :)
aaronbrethorstover 3 years ago
That’s a lot of words. Too long; didn’t finish reading. What are they trying to sell me on?
ilrwbwrkhvover 3 years ago
That&#x27;s why the number 1 advise I give to anyone starting a business:<p>Just use Rails.
wh-uwsover 3 years ago
let me calm down and breathe and I&#x27;ll take the bait ...<p>look just because you&#x27;re not Lebron James or Michael Jordan doesn&#x27;t mean you can&#x27;t go to your local basketball court and enjoy a game of pick up.<p>But the same way you don&#x27;t conflate what you need to do to be one the of the best people to ever play a game to play at all...<p>your software engineering team doesn&#x27;t need to feel completely useless because they aren&#x27;t immediately using &lt;insert new hot tool&gt; .<p>Everything in software engineering from side project to unicorn startup service is about tradeoffs.<p>Tradeoffs happen because of constraints.<p>I don&#x27;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.<p>I&#x27;m hoping you can read in this the need to be cognizant about manpower tradeoffs.<p>So yes I fully appreciate this as someone who has consulted, worked a public companies, and is now at a rapidly growing startup...<p>Just because your team isn&#x27;t meeting some imaginary ideal for some other form of team with different constraints doesn&#x27;t mean you can&#x27;t ever strive for any ideal or give up...<p>you just have to be realistic about trade offs...<p>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.<p>With rails you have scaffolds and endless convenience methods that let you be productive quickly even as a small team or shop...<p>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) ...<p>Because they were built by and more importantly FOR different types of teams.<p>Rails by the relatively slender (and famously against VC type scaling) 37 signals consulting crew and react by facebooks behemoth engineering team.<p>Of course they are going to build for their own trade offs...<p>why would you not?<p>(I intially opened this rant with this final piece thata I thought better of starting with but I still stand on the feeling...<p>The is the biggest piece of curmudgeonly nonsense I&#x27;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)
LAC-Techover 3 years 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)<p>I&#x27;d never bother suggesting it though:<p>- no one likes being told they&#x27;re small when they think they&#x27;re big<p>- it&#x27;s bad for devs careers (Resume-Driven Development)<p>- as TFA points out - it&#x27;s not what FAANG are doing so I&#x27;d lack legitimacy
评论 #30369481 未加载
评论 #30369338 未加载
评论 #30369324 未加载
评论 #30369524 未加载
评论 #30369642 未加载
oxplotover 3 years ago
Here are my rules for picking framework&#x2F;languages:<p>- Avoid if <i>specifically</i> 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&#x27;ll listen.<p>- Avoid if the developer base is mostly young people: They are energetic and they don&#x27;t mind complicating the shit out of something, because they can figure it out now and probably down the road. I&#x27;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).<p>- 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.
评论 #30370175 未加载
评论 #30370056 未加载
评论 #30370286 未加载
评论 #30370266 未加载
评论 #30370237 未加载
评论 #30370320 未加载
评论 #30370359 未加载
ctvoover 3 years ago
Who is trying to switch to GraphQL? Especially for service to service, internal calls?
评论 #30369159 未加载
评论 #30371153 未加载