In fact, this is my first comment here in HN. Little by little.

And at the end of the day, if you're respectful etc, who cares about being downvoted or having people argue back to you? Just take it on the chin.

https://news.ycombinator.com/item?id=16131314

Edit: It works since to downvote you need 500 karma, but everyone can upvote, so getting many upvotes is a lot easier than getting many downvotes.

Oh, I see. You personally haven't been downvoted into oblivion and/or had the door slammed in your face, so everything is cool then. 100% of the people who were censored must have been terrible people. Heil Dang, etc.

That's why there are places on the internet (like here) where, usually, I don't find the usual online fluff content.

I've always been the vocal outspoken critic. XML, EJB, annotations, aspects, ORMs, everything JavaScript, agile, ad nauseum. (My non-technical list is way longer.) It's always cost me.

I really wish I could tell young me to just smile and STFU.

Here have an upvote!

No leetcode, no Bay Area, no FAANG.

Just people writing the code responsible for our banking, travel, supermarkets and many other systems which underpin our society.

I still have a strong suspicion that either your friends gave you wildly inflated numbers, or you happen to know some serious outliers. Check this out for a reality check - the highest-paying Eurozone country is Germany, with an average dev salary of about 60k, and 76k for seniors: https://blog.helloastra.com/2021/10/18/the-average-software-...

Freelancing is a different story.

https://ie.talent.com/salary?job=software+developer https://de.talent.com/salary?job=software+developer

(this says Ireland is almost on par with Germany, which sounds about right)

Do you have more details about the country and industry? As this is way way above the Java dev salaries in Austria and they'd kill for this kind of money without grinding leetcode. Nobody pays Java devs that kind of money here.

Positions like these don't grow on trees and since you say there's no leetcode, Linkedin or big-tech involved, I'm guessing there's other forms of gatekeeping for such a lucrative and easy gig, like having the right industry connections or knowing the right people in order to hear about the openings I would assume, as if they were to advertise this salary on Linkedin or other places they would be drowning in quality applicants, for even less money than that.

It's a bit like in politics; when times are good for the majority, most normal people aren't interested in politics; they have better things to do; this apathy makes it easier for freaks to get power and start messing with things... Until it gets so bad that regular people start noticing and begrudgingly getting involved in politics.

I am regularly up at night in a cold sweat worrying about how if I suddenly find a technically fulfilling job, realizing I forgot everything about computers after a decade on working on meaningless front end JavaScript framework.

What you do as your first job massively influences you career. I did .NET for years by the fluke that is what my first job did. If they did Java, I would be an expert in Java. If I worked somewhere they needed a compiler written in C++ I would have done it and may have a compiler career.

The paradox is as a graduate you generally, unless very exceptional or well connected, or live in the (not "a") tech city, just need to get that first job.

It is hard to get that breaking opportunity, and so that thing that will have echoes throughout your career, you don't have much control over! The reason it is hard to get the first job is because it needs interview experience, and you have very little proof yet. You are asking a company to take that leap of faith.

Later side stepping is possible but very hard as you are competing with people who can be paid the same as a web dev with deep experience.

Also as a young person back then, I had approximately zero confidence, both in myself and even that programming is a good thing to do. Getting into it was very weird, I was probably the only person at my high school of hundreds who geeked out on electronics and programming, for example.

Nowadays with HN and other sites, there is an online community such that even in a country town you can get a sense of community and what is possible. With that any graduate now could hatch a decent plan for their career. They might take any job to pay the bills, but aim to get into a FAANG for example, knowing what it pays and how to go about it. 2020's are amazing.

On the front end, the trends tend to be more extreme; people will not take you seriously unless you give up on whatever tools you use and go straight for React or VueJS... Then when TypeScript comes along, everyone has to switch to that... I couldn't believe it when people started combining JSX with TypeScript... It's essentially a double-transpiled language now... The trends keep adding more complexity and everyone is forced to switch to that regardless.

Introducing a transpiled typing system on top of a dynamically typed language is a recipe for all sorts of insane complexity, which is what I experience whenever I try to use TS. If you consider all the time and effort it took to introduce types for every NPM project out there, all the development of the language itself, the effort expended by individual devs and teams to learn the syntax...

...might it have been the same amount of effort just to introduce some strong types into Javascript itself? It's not like the language can't adapt, and there are already some strong types when you're working with the graphics APIs.

It doesn't make sense; kind of like transpiling lower level assembly code into higher level C code. You could always argue that there is value in forcing arbitrary constraints onto developers but in the end, you need to ask the question "is it worth the complexity?"

TS is really flexible and you can do some crazy gymnastics with it - I don't favour that. Just keep it very simple and don't go crazy with the generics.

I've never had a problem at all, I've never had to dig into what was transpiled.

I spent a ridiculous amount of time trying to design types. At some points I couldn't figure it out, or I ran into some limitation of the language to express what I need. So my code has a bunch of exclamation points everywhere to assert that a null ain't coming. It feels dirty.

Just too hard to use for me.

IMO it's not that Typescript is limited at all, it's just that the type system is different, more complex and also more flexible - there are typically more ways to define types compared to Java/C#, so a lot more decision points trying to write something elegant, or even just idiomatic/understandable, so IMO the learning curve is steep. And then you get to the fun stuff with more abstract type definitions, infer keyword...

It screwed with my head way more than I thought it would. Structural typing was really different, I had to spend a long time rewiring my brain. But when I went back to C#, I felt like the type system was crude. I lost all the nice and easy ways of writing dynamic code and had to revert to defining surplus kludgy interfaces, delegates, etc. And in Typescript I'd finally figured out how to write null-safe code and remove almost all ugly coercions, then back in C# null references were a real possibility.

But the frustration left a worse impression than did the benefits. Perhaps if I was being paid to do it and had mentors around to ask for help. But I couldn't find any good advice online.

It took me far longer than a few hours to feel comfortable, probably more like over a month of coding to get to the point where I mostly understood how to express what I wanted with the type system, and had stopped doing C# things in TS and adhering to style guidelines - functional modules, types instead of classes, injecting dependencies etc. And another month or two? to really figure out how everyone has been (ab)using the type system to do more complex stuff.

Are you using "?" optional fields in your classes/interfaces a lot? If so, do you need to? Unless it's truly optional, you're basically making the type system less useful if you put that all over the place. If you have a lot of sparse objects, it's probably an indicator of a data type doing too much. You might be much better off splitting it into smaller interfaces and using union types when you need combined objects.

Even if you can't do the above, checking for null at the start of a function/block will "prove" to the compiler that it's not-null for the rest of the block, so an upfront check can save you from a lot of "!" assertions.

Even if you can't do either of the above, you can probably use the elvis operator "?." to safely dereference things that might possibly be undefined.

In my experience with typescript, there's a few good rules of thumb and things to keep in mind:

- Prefer "interface" over "class" for describing most data types. Especially plain old data objects that don't have methods. I'd forget about the definition of "interface" you might know from Java. It can be used that way, but it can also be used like you would use "struct" in C

- Use the "Partial" modifier instead of using "?" in the base structure if you need to do something like sparse updates. For instance a pattern I use a lot is:

   interface MyStruct { a: number, b: string }
   
   function update(original: MyStruct, updatedFields: Partial<MyStruct>) {
      return {...original, ...updatedFields}
   }

- If you're not worried about GC pressure, it's almost always better to return a new object than mutate an old one. The spread operator is great for this.

- Within reason, it's better to prefer smaller data structures and use type unions when you need fields from both in one object.

I think I went into the deep end with some non trivial generic functions. It's been a few months, but I remember ditching interfaces for classes so I could do some run time type checking.

I wouldn't have fallen into these traps with something like Java.

It's not even that there's only happy heads-down programmers off HN who support these mainstream techs. Even in the active userbase here, I'd wager there are tons of people who have an adequate or better experience with typescript or react, and may disagree with the dislikers. But we're not as invested in our liking, don't feel like it's worth engaging in, and none of the banter changes what is or where things are going. These are the de-jure tools that the majority definitely uses widely, which at least the first anti- comment, on front-end frameworks, acknowledged. Whatever the targets-of-the-day happen to be, they will crop up repeatedly, which further dissuades from trying to come back with a positive or even neutral opinion that might represent that silent majority's take. And the silent majority must constantly face Brandolini's Law; what it's doing may be working & have good reason, but it's hard to keep supporting & reasoning through with a pact invested in disbelieving.

I liked the top post talking about disagreeing with the direction. That can be contributive, be value based. So often though the protests amount to gatekeeping "you've done too much." I evaluate where these comments would fall on Steve Yeggie's Software Political axis, from Notes from the Mystery Magic Bus[1], and almost universally the voices are conservative; they object rather than suggest, they refuse rather than support. I'd like to see more progressive protests, that can surface good, that acknowledge value & need but reflow or redirect the energy elsewhere, rather than being unhappy with what is.

[1] https://gist.github.com/cornchz/3313150

I appreciate the high quality HN posts, but sometimes just like at a water cooler a bunch of us just wanna say, "agh I'm so sick of object oriented" and it doesn't mean "all object oriented programming is of no use".

TypeScript exists as a first step to adding types to JS. Some folks are currently trying to figure out a way to add type annotations that the JS engine will just ignore for now based on what we've learned from TS.

And how would it be different?

I've been using TS since 2016, both for front and back-end, and I can count an amount of times the transpilation abstraction leaked on one hand (and most of these were when I just learning TS and worked on weirdly configured projects). Aside from these, I could just forget about the fact that it's transpiled to JS under the hood.

It's had the pleasant side effect of also educating me on quite a lot--mixing in with people with different experiences and values has enriched my life, so I think it's a win-win. I just try and be careful to not get too wound up: that's the failure case haha (I'm not saying constantly check your blood pressure while using HN, but I'm not not saying it).

I was just talking about this, to someone, yesterday.

I'm often accused of being a "killjoy," or a "dreamkiller," by today's yutes. This is because I say 'orrible things, like "Have you considered what happens if..?" or "We tried that, a couple of years ago. It didn't work out, and here's why...".

In actual point of fact, I'm exactly the opposite. It's my job to Make Things Happen. I plan to ship everything that I do, and my work is generally focused around the endless practicalities and compromises, necessary to get products out the door.

This has often resulted in me being called every name in the book, as I try to avoid chasing shiny, and keep the eye on the ball. In my days of yute, this would keep me awake at night, worrying whether or not I had made the right decision, if I was an unintended, out-of-wedlock child, or if I really was a goose-stepping fascist.

But I have been getting stuff out the door, for pretty much my entire adult life.

These days, I sleep like a baby.

This hits too hard. I’m still in the “acceptance” phase of grief over the death of my ideal that there’s a “right” technical solution for every problem. And I’m in my 40’s.

It starts by accepting them, right off the bat, then using the time that I'd otherwise spend in fruitless pursuit of shiny, doing things like testing and documenting the codebase.

Experience gives me the ability to see them, at the start of things, other than waiting to run into them, later.

I’ve recently switched jobs and my team doesn’t write integration tests for our services but rather manually test them with postman. It’s definitely odd and very inefficient.

Today, the frameworks bite me in the ass about once a week, but I think it’s worth it to get safe React with strict TypeScript, and plenty besides.

Caveat: All infrastructure requires a lot of maintenance, though! YAGNI still applies, and hopefully you have (or are on) a team dedicated to supporting the tools that you do need.

XSS has long been a solved problem.

Security is definitely not an argument for using front end JS frameworks as they add attack vectors and complication to the stack.

Right now my position is something like tech lead, at least I do technical decisions in our company. And there's no way I'll allow to write anything complex without React.

And sites are bad not because of React. Sites are bad because of other things. If anything, React helps making sites less bad.

Second best thing is TypeScript. I don't like tooling, though, but I think it gets better.

This might be the oldest, grumpiest man on the front lawn yelling at childreniest take we on web dev, that I’ve ever heard

Web apps were never this complex before the creation of frontend web frameworks.

Frontend web frameworks have their use in rich apps, but using them for general web pages is just complicating things for no good reason.

It would definitely be better if there were a way to side-load those libraries as a standardized strata underneath the main browser content to save resources. So if someone uses React to do their form, yes it seems costly but the cost only needs to be paid once, and then the relevant framework is cached more statically than the transient web cache (and with an alternative to domain-based cache, such as checksums or signed binaries, to determine if two domains are using the same framework and save the download cost for all sites you visit using that framework).

... but only better if the tricky engineering questions around caching were sorted. There's plenty of risk that you'd end up with gigabytes of cached frameworks, because the current solution means I don't have to care if one site is using React 12 and another is using React 12.1.

But this isnt my field of expertise so I'll have to take your word for it that you're not joking.

Doing a form that will do things people expect these days (client-side validation, formatting, error-handling and highlighting / locating fields with errors in them, auto-fill of addresses... What, you don't expect the user to type in a whole address without verifying it's a real address, do you, there's validation services these days!) is the kind of thing you may want a framework for.

This relatively simple "Contact us" form (https://aflcio.org/contact) loads nine custom fonts, JQuery, an email-decoder script from Cloudflare, and a host of other things. Why nine custom fonts? Because the AFL-CIO has a brand and they're not obliged to deviate from it just because your browser doesn't have the font they use, anymore than they wouldn't show their logo because your computer doesn't have the logo yet. Why JQuery? Probably because there's a button on the page that hides and shows a field, and even in The Year Of Our Lord 2022 those are still an absolute witch to write without bugs in plain JavaScript. The email-decoder script is, I think, self-evident; lets them save the bandwidth of rejecting your input if you put "no" as the email address. And of course, the tracking scripts because they want to know how people are finding the "Contact Us" form (are they coming in from the main page? Is there some specific page that should be answering their question that they're falling over into "Contact Us" instead? Are they coming in from completely outside our org because someone shared a deep-link on a political site and said "Go bug the AFL-CIO", because if yes they can use that tracking to pre-filter the messages they get from that entry-path and bin them all low-priority). I'm seeing some inefficiencies in the Inspector (it's loading some Android-specific icons, probably because it's not good about refraining from loading assets for its mobile layout), but a lot of that stuff I'm not surprised at all to see.

There are several driving factors underpinning this phenomenon. One is that frameworks are more flexible (per unit of code written) than bare-AJAX development, so there's plenty of "everything looks like a nail" thinking going on; once you've paid the up-front cost to build out a dev environment using a framework, it's cheap to keep using it. Another huge factor is that relative to the web experience of, say 15 years ago, there are many incentives to push a lot of work (especially validation of inputs) client-side; few places have truly full-stack developers (or, more often, don't allow the authority for one developer to go hacksaw into the front and backend whenever they feel like it), so simply implementing one new validation rule may be a bunch of back-and-forth tickets if implemented server side or a couple hour's work if done client-side. And client-side work saves the server computation costs (and often bandwidth costs, even when one factors in the up-front cost of loading all that framework boilerplate if the site's used long enough per session).

All of this pushing of complexity to the client does come at a cost of client performance (and sometimes bandwidth, depending on how solid the caching logic is), so (especially at big companies like Facebook and Google) it's a constantly-shifting tradeoff. Google in particular has some incredibly clever partial-rendering logic in-house to allow them to push pieces of a big page on-the-fly to the client, saving bandwidth by rendering a mock button with no behavior attached until the user tries to click on it (and then the behavior script flies in as-needed). Of course, that's a huge amount of complexity that requires tight hand-in-glove coordination between client and server, so the framework that supports it is even more thick and robust, etc.

At the end of the day, "simple web sites" (unless they are truly read-only, in which case just use Hugo and call it a day) are still client-server distributed computing problems with complexity that scales nonlinearly.

Nested ternary operators... though, because of how TypeScript does constants, I saw why they used this way of doing things so often.

Such a shame, since this is ‘a great way’ to dissuade women[1].

[1]: https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless...

It's a mistake for companies to assume that just because someone has 3 years of professional experience with a particular tool, that they like that tool. I've witnessed many developers catch Stockholm syndrome after spending lot of time using (and becoming an expert in) a specific tool but I regard this is as a sign of inexperience.

Older me is now super embarrassed by my prior enthusiasm for object oriented programming and misc methodologies. I have very vivid memories of grey beards dismissing my naivety and me thinking "they just didn't get it." [0]

If there's any kind of karma, today's noobs will live long enough to be mocked by even younger noobs.

Small solace, I know.

[0] I always remember criticisms. I've got the voice of doubt in the back of my head always wondering what I'm missing, what if they're right, etc. It's a serious bummer.

There's probably a saying somewhere along the lines of "There are two kinds of programmers: those who admit they get Imposter's Syndrome, and those who are too afraid to admit it."

We all have those doubts. I've been in this since... what, 1994 professionally I suppose, and I still have doubts. It's totally normal. IS is not limited to software development either.

Even worse, people don't even bother to look at other options even if it's just to learn from them.

Compare the new hip thing with a different one and people get defensive.

The fact is, there is an essential complexity that simply can not ever be reduced. But we should also strive to not get blinded by the n+1 failed, bad attempt because true, novel approaches do turn up from time to time, e.g. nix actually solves the dependency hell problem.

Which is funny because most modern devops tools are written by organizations with no experience maintaining critical systems or large scale.

Very, very few come out of teams working on the real stuff. Both FAANGs and other companies are not going to release their crucial internal tools and not even discuss them in public.

> may include both the learnings as well as the mistakes

"release early" is not something anybody should do for production critical tools like devops stuff.

> frankly, most people aren’t building things that are critical or require scale

100% agree, but if I build ships they have to fit safety standards even if most people never meet rough seas.

https://en.wikipedia.org/wiki/Silent_majority

Over half my coworkers including some very talented developers have no public repos. As someone with almost 200 that always blows my mind.

How do you work in software for years and not find some little hole you want to fill. That’s not a judgment call, that’s an honest question on my part. I want to understand.

Software engineers seem unique among professionals that you’re expected to maintain a hobbyist body of work that’s also your professional calling card.

I don’t even mean in that sense though, I just don’t understand having a skill like that and not using it for fun.

For what it’s worth, the best salespeople I know have almost no purely home life and are taking calls and making deals all hours of the day.

That's not the right conclusion to make. There are lots of developers who code in their spare time, but don't make their code public on Github.

I have had several side projects, but I am not inclined to share my code on Github. Either because I intend to make money off them, or because I don't have time to manage an open source project. Part of it is also caused by "imposter syndrome", where I don't have time to make the code good enough for public view.

You have over 200 public repos, which means you have a different view. But that doesn't mean that your coworkers don't do things on their spare time.

To be honest, I feel this attitude is beginning to spread to potential employers. Now we are expected to publish and be rated on our public repos, and it will just lead to lots of burned out developers in a few years that feel pressured to publish OSS and practice leetcode.

For me, I like coding, just like I like eating and I like socializing. The fact that I eat and socialize at work doesn't mean I try to avoid eating and socializing outside of work. Similarly the fact that I use a computer at work and or code at work doesn't mean I try to avoid using a computer and or code outside of work.

My working on whatever my company wants me to work on is not the same as me pursuing a hobby even if they overlap in the activities required to do both.

Also, some people just really enjoy it.

https://news.ycombinator.com/item?id=32593135

In my case, when I started in this industry 10 years ago I found most of my joy in coding, as time passed by I engaged into different hobbies that brought more joy to my life and ended up allocating more time on them than coding.

It's surprising (and awesome!) to me how much open source repos have become a part of many people's CV/resumé.

This is also possible because of competition. I am a student. All my peers grind much more Leetcode than me. So I put at least some code on GitHub and add that to resume. Not necessarily useful for others, but experiments I did etc.. included.

Because most people (myself included, 16 yrs professional experience) don't want to do unpaid work outside of work hours. How do you not understand that?

I also have a lot of hobbies that scratch the same itch, like making music. In fact, making music feels like more of a whole brain workout than programming, so I’d much rather spend more of my limited time on Earth doing that than writing more code.

These people are also good at politics. There is a reason bill gates is rich and rms isn't.

Love does not mean spending every waking hour on something.

I love my spouse, yet I need to socialize with other people, as well as alone time.

A full-time programming job fills up maybe 200% of the time I want to spend on that in a year.

I love my job. A lot. I also love my wife, my kids, my friends, my community, and a wide variety of time intensive hobbies.

No word of a lie, a few years ago a 'crypto' person told me that all the code I was working exceptionally hard at was a complete waste of time. Blockchain technology would solve everything. I just had to wait. And I am still waiting!

I have a lot to show for the work I have done since that conversation with buttons I have put online getting clicked millions of times with nobody personally thanking me. It is 'silent majority' code. No idea where the 'crypto' person got, I stick to my own lane and I don't need to rubber-neck.

Although it is good to share one's work so nobody else has to reinvent the wheel, if I have a better solution and I have developed it in the context of dedication to the day job, then that software gives a commercial advantage to my employer. Even if the core of the idea is mine and that I developed it in my own time, I 'bat' for my employer, and, if it is in their interests to keep the repo private, then I will.

There is also the matter of peer review. My colleagues are too busy to spend time on my pet projects.

The 'crypto' person has one of those LinkedIn profiles where they have more than the maximum amount of connections, with all kinds of grand job titles and the rest of it. I am just a programmer and I do not need a job title. I don't even need LinkedIn and I do not spend time inventing a grander version of myself online.

For code samples I can share the code that I worked on, albeit removing any business logic that is not mine to share. In my niche, with recruiters that know me, this 'just show me the code' works fine.

What if everyone worked like me? There would be no fine repos to plunder!!! Well, there are a few pull requests I have put into public repos and the majority of the population cannot say that. Plus, if I spend two decades silently writing code, then, one day, post a repo, it is going to be good.

To be honest the code I was writing two years ago makes me cringe with shame at how naive it is, so I doubt that my efforts from before that would have been for the wider public good, even if they did fix a business problem at the time. I have sometimes had to get working code rather than beautifully refactored code, then onto the next project.

Can't speak for Reddit, but that's not at all the case here. For example, I often speak of my hatred of microservices here. I'll get some upvotes and agreement, some people telling me it's a dumb opinion, and some people telling me we're doing it wrong and explain their right way. Believe it or not, I learn a lot from different people and their experiences.

I can't think of a single topic that seems to be prevelant here that doesn't have a sizeable amount of disagreement, in fact. And I wouldn't have it any other way.

I would expect the true silent majority just uses monoliths. If it works and doesn't make people complain every day when they work on it, why use a microservice? That's more work.

Everyone likes to think of microservices as a modern high tech thing, but to me it seems like old fashioned unix stuff, that appeals to people who enjoy doing simple weekend projects, trying to make their job into a series of tiny projects of the type they might do at home for fun.

The focus seems more on individual parts than on the vision of the complete project.

Of course it seems to just mostly move complexity into the high level gluing it all together, and spread it out in bits of interface code, but if you are more interested in working on simple but interesting challenges, and don't mind the more hands on dev ops maintenance work, and aren't that into building complex systems, I imagine you would like it.

I have never seen services (of any size) succeed in a place that wasn't using them to do vertical partitioning of a system.

I imagine you are probably talking about horizontally scaling each of those vertical partitions, but the phrasing is really confusing.

My criticism is more general, that the usual idiom is confusing and misleading for people that don't know it already. Maybe it shouldn't be usual.

It's exactly this for me. Unix has been around longer than I've been around and will outlive my career if not my life. Components have been successfully updated and replaced mostly without significant disruption. Unix is a model for producing and maintaining complicated systems.

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

http://erlang.org/pipermail/erlang-questions/2008-January/03...

If your dev guide in the wiki says "to run unit tests, use docker-compose exec monolith test some.package.test_class", you're in danger.

This company needs to start breaking the monolith down into, well maybe not microservices, but at least smaller monoliths, if they want to achieve what they want to achieve.

Microservices won't magically fix issues with tightly coupled components or poor achitecture. Those problems can and do still happen with them.

Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane.

It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.

Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.

The microservices equivalent needs Kubernetes to run your tests.

As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit.

But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.

That's more of a terminology point IMO, and probably not what they were talking about.

It's very complex. It has it's business use cases, but if you don't need it (or don't need full-blown OAuth2) then don't use it. If you're worried about the future separate auth user from account internally in your application (SSO ready) and move on.

It sometimes feels like there's a cabal of people who think the more complex something is, the more skilled they are for being able to implement it. That's not really where the skill lies for an engineer.

From the discourse on forums these days, someone fresh to the field might think there's no such thing as an internal API or an ongoing ETL layer without breaking each feature down to its own container and throwing the whole thing on Kubernetes. All those systems that are two to four layers and decomposed into half a dozen or so parts at the outer interface still exist in the world, even if they're not on track to be one container per feature.

Quite the opposite - they think about architecture as opposed to a crappy unmaintainable hodgepodge that the vast majority of web applications are.

Inferiority of web-based apps doesn’t come from nowhere.

Let's say you have 2 opposing POV: A or B

"A" has a silent majority so only 5 of the 5,000 people post a comment about A being the right POV.

"B" is a passionate minority so 5 of the 50 people post a comment about B being the right POV.

To the viewer, it looks like a balanced discussion and a topic open to much debate, both sides have equal voice but in reality "A" is by far the most accepted position.

For example you have 99% of scientist agreeing about global warming.

You have 1% who disagree.

So they write that "Some scientist disagree" and it sounds like its up for debate or maybe a significant portion know something the others don't.

In the pursuit of a "Balanced" POV they tip the scales vs just reporting where the scales are at accurately.

Very sorry but it absolutely is the case here. Your anecdotal data is limited to you, but HN very much operates as a hive mind, it just hides it better.

Considering this place to be "superior" to other places only leads to complacence and further strengthens the echo chamber.

Most of us here agree with you.

Found some screenshots from the early years:

https://www.reddit.com/r/historyofreddit/comments/q1zks/redd...

However; check out subreddits like /r/rust, it looks a lot like HN

Wonder how much of a difference it makes that most HN users can't downvote.

I think Programmer Anarchy was a early adopter of microservices and as they ran a business as developers I think this may have been useful

> polarize: divide or cause to divide into two sharply contrasting groups or sets of opinions or beliefs. > "the cultural sphere has polarized into two competing ideological positions"

Hmm...

Compare any topic relating to capatilism, the plights of the low income classes or politics in general. I often amuse myself comparing the takes between the two sites relating it those topics.

Also HN is more clinical, it discussed the death of Swedish reporter like it was a cold case ready to be ripped through.

And also more easily distracted by seemingly innocent open questions like in politics for example "Why is it X job to care about this?" since you can't dismiss it with a short meme it creates discussion that the OP only wanted to distract from the original article.

Apart from that HN discourse is 100% better than reddit and I agree with you in some terms.

What I'm NOT in favor of is the disrespect of legacy. There are millions of systems out there in the world in manufacturing environments. These systems are ancient, I worked in a shop making gears for 5 years. The CNC lathe we used had a GE computer running it from 1970, and it used mylar punched tape to store programs. It was a huge investment when it was purchased, and there was an old guy (about 70) who they called for repairs on it and much of the other ancient hardware. This shop had 6 employees, including me. At it's peak, there were 50 or so, during and after the Viet Nam war.

That hardware was sooooo old, but it still worked, reliably turning out the same few types of shafts and other parts we need to turn into gears and splines and other gear shaped objects (like turbine blades).

The programmer in me desperately wanted to keep the lathe, the motor, and just replace the control system with GRBL, but even if that was free, and worked the first time, the risk that an upgrade represented was completely unacceptable.

When you're in a job shop, there are parts you've been making for a generation in small quantities (less than 500). Those parts are relied upon by other businesses as part of their product. If you "upgrade" any part of your process, you risk producing a part which doesn't work somewhere down the supply chain. If you make that happen too many times, you'll lose your customers.

It's also important to know that gear cutting was only a step in the production chain... we didn't start from raw materials most of the time, we were given a "blank" on which to cut teeth, that already had many operations performed on it. It was almost never just a matter of sawing off a new piece of metal and starting over. You had to respect the work already put into a gear blank, or shaft to cut splines on.

The incentives in manufacturing are strongly against any type of change. However, they aren't blindly obeyed. If there are new jobs, then it's reasonable to try out the new machines or new systems in those cases. If something can cut the cost of a part by half, then it might be worth the risk, if the customer approves a change.

Please don't think that those in the silent majority of the world are un-reflective of the needs for security and other patches... but if things break every Wednesday, they'll disable Windows Updates forever, for very good reason.

But there's an implication of moral purity at play. Are those who just quietly "mind their own business" a good, wholesome but misrepresented group?

On the contrary, I think that in matters with far reaching consequences, which computing is, silent majorities are the problem. Unreflectively going along with the programme becomes a kind of passive negligence which should not be lionised in a folksy way.

It enhances risk. The latest tool language and/or framework is uncharted territory

A tried-and-true solution has had a lot of bugs and issues documented and some of them solved.

It also mean the team must take a break from development to learn whatever the new thing is. Some will need more time than other, which may slow it down even further.

A lot of systems are developed in domains where "go fast and break things", A/B testing etc. would not be at all advisable.

The main selfish focus on "adopt whatever is hip this week" is to pad resumes with it, consultant can come in to help train people $$$. Consultants will fight for it to use the newest and greatest since it may increased development time $$$.

An older tech stack doesn't mean never updating the system. either. Perl still gets updates. Linux distros still get updates. In fact, often a newer piece of software will introduce bugs including security bugs that were fixed in older software long ago. All things being equal, though, using a language with better string handling and memory safety can be a boon if your old stuff is in something like C.

It's an interesting dynamic. I've been on both sides in my career. Silent is much easier but doesn't get you recognition & promotions.

...and don't forget to include the wonderboy/girl from the overpaid consulting firms that come in and tell the CEO they are doing everything wrong and should move everything to: (pick the latest technology fad)

and then 2-3 years later they come back and convince upper management to move to the next big thing...

https://www.hanselman.com/blog/dark-matter-developers-the-un...

Why is being heard a good thing? When I was at school I was the insufferable kid who always put their hand up as I knew the answer. Thinking somehow that the teacher wanted to know the answer. What I learned as I grew up is a lesson learned is better than a lesson told.

Put another way, if you are not listening to the person who signs the checks, than your career will be rather short.

"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." (The Washington Post October 25, 1911)

(i've written on it here and how it does favor creators https://www.swyx.io/puwtpd#why-does-this-work-on-them )

I've been passively reading HN for a few years as a junior dev after my team lead introduced the site to my before even creating an account.

I've been making comments on a few topics of interest now and then in the past three years.

Since a few months I feel like "yeah, I should probably write some docs + blog posts" which might be interesting to other HN readers.

I've also noticed that some HN users write a lot of comments to any kind of post whereas others mainly commment on articles related to their are of expertise.

There are a lot of developers out there, tens of millions. That little bubble of users actually commenting on HN is tiny in comparison. So, yes it's good to be aware of that and appreciate the world is bigger than that. At the same time, like with politics, just because they are silent does not mean they don't have opinions. And they vote. With their feet. They'll adopt practices, tools, and technology they like or need and walk away from other things.

This is one of those things that "everyone knows". It may have been true at some point, but it definitely isn't true anymore. The reality is that most discussons here treat PHP fairly, giving it credit where it deserves it and also pointing out its weaknesses.

Examples:

- (2022) https://news.ycombinator.com/item?id=32325055 : top comment praising PHP

- (2022) https://news.ycombinator.com/item?id=30219984 : the top comment is a fairly positive comment overall, without falling into zealotry.

- (2019) https://news.ycombinator.com/item?id=19917655 : the top comment is someone praising Laravel and the "modern" approach to php. The general feeling is that PHP got some things right (shared-nothing), doesn't offer anything particularly unique but is surprisingly effective in reality.

Personally, I dislike this attitude. I think the internet is a good signal for what will be in the streets in 2-4 years time unabated. The attitude OP reflects is one that was valid in the 90s and early 2000s, but not today.

Not being skeptic in 2022 of comments or news online is being very naive.

I simply forget. Maybe that's how they get you. They wear you down.

Moreover "the internet", whatever the meaning, is not a faithful representation of the "real world". Go tell the millions of people without toilets or working the whole day the slacktivists spending their days on twitter represent their struggle...

Places like this, get caught up in “shiny,” and that doesn’t always reflect reality.

For example, it is fashionable, hereabout, to throw shade on PHP.

I present Exhibit A, the “Fishtank Graph”[1].

We were just discussing something similar, yesterday, in the SwiftUI thread[2].

[0] https://vickiboykis.com/2019/05/10/it-runs-on-java-8/

[1] https://w3techs.com/technologies/history_overview/programmin...

[2] https://news.ycombinator.com/item?id=32631219

I do feel like engineers who put themselves out there and engage on HN, Github, Chat groups, etc, get "polished" and get better as engineers, assuming that association in these forums causes them to read more code or think about paradigms.

If "silent" are mostly keeping to themselves, they might have some of their own innovations independent from mainstream engineering, but lack common knowledge, which can be accounted for by reading a lot of programming books, release notes, docs, etc.

Unrelated, some unsolicited feedback for bloggers, I like to click on images to zoom in (quicker than ctrl+equal 5 times). So at the very least please wrap the images in a link to the image src. a humble request.

I suggest using a TamperMonkey script to accomplish this on your end; outside of thumbnail galleries, it runs against common expectations, so you'll have better luck taking control yourself.

Bubbles on HN;

Entry level Web Developers are getting $200K per year working in FAANG or Big Tech. Non-FANNG are getting $150K anyway.

Ruby may be dead, but PHP is even more dead.

Java may rule the enterprise, but you should not mention Java.

No one uses Oracle or MySQL, why would you want that? Postgres is the only DB forward.

Everything should be Remote. Communication should always be Async.

Oh, Ada is the second Forbidden Fruit on HN.

Facebook is...... OK I guess we shouldn't go there.

USB-C will solve all cabling problems. Everything should be USB-C.

5G is useless.

AV1 and AVIF. The video and image standard to rule them all.

Nothing should be centralised. Everything should be distributed.

Finally, The unwritten rule of HN. You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet.

* Everything should be free and open source. Just because small portion of the HN can donate to their favorite projects, everyone should run on donations. Ads are forbidden on the internet. No internet business should be a profitable company.

* Tiring and useless interview process designed by FAANG etc is no way a farce and a totally justified practice (some version of Stockholm syndrome there)

* Private companies should not interfere in the politics/internal matter of another country. (This view quickly changes when they see the negative effect of same companies in their own country)

* YC is the best and the most exclusive startup accelerator/incubator in the world. If you got accepted in YC, you have won in life.

I'd say it's the opposite. The view you're expressing: that the standard software interview process is somehow "useless" strikes me as a bubble here.

I'd wager most people not on hackernews don't hold your view.

To be fair, some ads are absolutely obnoxious.

I have never ran into anyone anywhere, cyberspace nor meatspace, who has claimed that 5G was actually useful for something.

Personally I have it turned off on my device, there’s not enough of a noticeable benefit and a non zero hit to my battery to have that part of the modem turned on.

What inflated most in the past 3 years is the ego of engineers. :-) On blind and job-seeking forums/groups, people incessantly flaunted their packages: $500K with 3-year experience. > $1M for an L7 applied scientists, getting promoted to staff engineer 3 years after graduating, and etc.

I think it all started after 2020.03. The market dipped, and then bounced back, and there was a talent war, thanks to an influx of cheap capital. I remember that my Amazon friends were very happy for a $600K package for their L7 positions, but all of sudden that number seemed normal after the great package inflation since 2020.

Plenty of people are stuck with Oracle, but starting with it nowadays is something else.

I still believe it's a case of the Oracle people being incompetent, and the system technically being able to scale at a rate somewhat larger than 1. But if a potential gain can be acquired for a few million grand, but nobody has the technical capacity to actually acquire it, is the potential actually there?

https://news.ycombinator.com/item?id=32587740

>Entry level Web Developers are getting $200K per year working in FAANG or Big Tech. Non-FANNG are getting $150K anyway.

I don't browse job threads much and I don't pay attention to people mentioning salaries so I can't say.

>Ruby may be dead, but PHP is even more dead.

>Java may rule the enterprise, but you should not mention Java.

For PHP and Java, there is a very strong case to be made that "dead" means "utterly flawed and completely uninteresting and somewhat ugly\repulsive and only worth writing if the money is very very good", which is (in my very humble opinion) trivially true. It doesn't matter how much they are written, they are dead branches on the PL evolutionary tree, they won't have progeny or nostalgic mind share rooting for them as languages.

I don't know what people declaring Ruby "dead" mean, perhaps its about Rails falling off the hype train or Python eating a lot of its potential mind share and market niche. But Ruby is definitely nowhere close to Java or PHP in bad design, it's a descendent of Smalltalk (which Java aped badly) and Perl (which PHP aped badly), the union is very fruitful and the language is delightful.

And for what it's worth, I remember 2 times I was pretty heavily downvoted because I criticized java. Same goes for C++ and JS. I don't remember seeing anyone downvoted for hating PHP, but also none for defending them. Seeing bubbles is very correlated with what your own biases are.

>No one uses Oracle or MySQL, why would you want that? Postgres is the only DB forward.

Maybe Oracle Bad, that's real and very popular here on HN, for good reasons. I don't remember anyone seriously saying you can't use MySQL or only use Postgres.

>Everything should be Remote.

God no, that's aweful. This position has fierce opposition, including me.

>Communication should always be Async

Maaaybe ? I see plenty of opposition to this. My personal opinion is that good comm is not sync or async, it's exactly what it needs to be to get the message across.

>Oh, Ada is the second Forbidden Fruit on HN.

Not really, it doesn't get mentioned alot because it has miniscule online resources but whenever it's mentioned (e.g. in the context of formal verification with Ada\Spark) there is broad enthusiasm and interest.

>Facebook is...... OK I guess we shouldn't go there.

Haha, yes. Very true. But (like Oracle) also for very good reasons. But I agree that Apple, Amazon or Google aren't angels either, and it rarely get mentioned. In fact, if I can choose a single FAANG company to destory overnight, it would be Apple, their way of treating customers disgust me so much.

>USB-C will solve all cabling problems. Everything should be USB-C.

>5G is useless.

>AV1 and AVIF. The video and image standard to rule them all.

Interesting, I never even saw those opinions expressed once, and I'm fairly addicted to HN. I'm beginning to suspect there are "Meta-Bubbles", bubbles where your perception of what things are bubbles is itself bubble-like.

>Nothing should be centralised. Everything should be distributed.

Hmmm No ? There is an HN bubble against cryptocurrency, which should be impossible if what you're saying is true.

>You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet

True-ish, especially Rust. But there is plenty of aweful criticisms of Rust that always go something like "Everything the Rust compiler can do my own custom home-grown linter tool can also do, nobody needs memory safety if we just be careful also smart pointers and RAII". There is plenty of bad things to say about Rust, none of it leaves C and C++ in good light.

I know quite a few companies that develop on .net, mainly in C# instead of Basic of course. But I rarely see any discussions about it. Wouldn't know where to ask in-depth technical questions.