> It seems like suddenly half the internet forgot about the term "user-agent", which up until recently was almost always our browsers, but sometimes feed readers, which was acceptable it seems.
Was it really "suddenly"? it seems like for the past decade there has been an ongoing push to make everyone use "chromium" based browsers. I remember 10-15 years ago you would get blocked for not using IE or whatever, even though the site worked fine and there was no technical reason for the block.
It was over 12 years ago when google effectively killed RSS to prevent alternative methods of access.
> I remember 10-15 years ago you would get blocked for not using IE or whatever, even though the site worked fine and there was no technical reason for the block
Reminds me of when I discovered that Google Inbox worked in Firefox, even though Google decided to only allow Chrome to access it:
I think that "ongoing" push you're talking about was/is accidental, because a lot of people use Chrome. What I'm seeing now seems to be intentional, because people disagree with the ethics/morals surrounding AI, or seeing a large impact on their servers because of resource consumption, so more philosophical and/or practical, rather than accidental.
But who knows, I won't claim to have exact insights into exactly what caused "Chrome is the new IE", could be it was very intentional and they never stopped.
I don't remember Google (search, at least) ever not working in any browser I tried, and I used some oddball browsers over the years. Maybe apps like gmail and docs, but they simply would not work in other browsers. Remember in its early years Chrome was a darling because it was supporting the "modern" web. That was the whole stated reason Google developed Chrome: to support modern, rich web applications, and force other browsers to do the same if they wanted to stay relevant. Nobody guessed that Chrome would eventually be the new IE.
Google has a very long history of downgrading or even outright blocking off their services based on User-Agent. Them doing it to Opera in particular was a big story back in those "early days". And no, it's not because it wouldn't work - people literally made it work by spoofing the UA.
> We are curious if this type of distinction between current and former employees is typical for post-IPO RSU settlements.
I'm watching this thread, but just as a reminder that it benefits the company to be as vague and complicated as possible for ex-employees trying to exercise their equity rights. You and your equity are effectively dead weight to the company now and it's in their best interest to get you to forfeit as much as possible. The best time to cash in your equity is always when you are still an employee.
Working for a Silicon Valley startup feels like those scenes in a con movie: You're the wide eyed bettor at the pool table, convinced you have a shot...Until you realize you've been playing against world-class hustlers.
I don't think it was always that way. There were lots of overnight millionaires when tech unicorns were going IPO like gangbusters. But we haven't had a true unicorn in years, so right now, getting paid in equity is choosing to work for nothing.
This is cynical and more frequently wrong that right. In most cases, the company is trying to avoid securities regulation screw ups, tax screw ups, other regulatory or legal screw ups. Sometimes they are overly conservative and it seems annoying, but that's what they are doing.
As an example, Stripe went out of their way to get former employees paid.
This is not cynical. The situation is that a) there will be a team of very expensive lawyers and accountants working out how to best implement the plan that benefits the company (whom you can’t compete) and b) crucially, you have no control and prior on knowledge on what that plan would look like. It is not about the company trying to screw an individual over, it’s more the fact that the company will be very unconcerned if their plan is against your benefit, and you have no way to align your own benefits with the plan.
100% disagree. Just because one company goes out of the way for PR good will does not many many other companies will. Many companies do not care about you once you are a departed employee.
For example, see how easy it is to get your bi weekly paycheck copies. Most will not reply at all.
Many companies will throw existing employees and even founders under the bus if they think their is a few dollars to be won. To think they wouldn’t play games with ex employees is naive in the extreme.
Wow, check stubs used to be the basic social currency around renting and etc. Are you saying people can't get these anymore? Or maybe they know too much and don't care?
I assume GP is talking about getting paystubs from a former employer, not from a current one. I've never had any trouble getting paystubs from my current employer; they were always available through the HR website portal (ADP, Workday, etc.).
> This is cynical and more frequently wrong that right
If you are joining a startup as an employee and expecting your equity to worth something its important to be aware of the risks. And trying to sell as an ex-employee is a Risk.
Maybe I'm a cynic but having worked in employee equity I have seen more times that companies essentially turn their back on ex-employees than i have seen them actively helping them on liquidity transactions like tender offers.
I don't think it's cynical at all. Unfortunately I can't provide concrete examples, but I recall many instances over the past 15 years or so reading stuff here on HN where founders/companies expressed a belief that they should be able to claw back even vested equity from employees who have left the company pre-IPO.
It's super super gross, but it's unfortunately a thing. Hopefully that's not what's going on here with OP, but I wouldn't be surprised if it is. If the company is offering a sell-to-cover option to existing employees, they are certainly capable of doing so for former employees as well.
True that the company needs to follow regulations. But they could do "net exercise", or "sell to cover". Instead they choose "pay cash or forfeit" path.
Even that has downsides - they are effectively guaranteeing a large sale right at the end of the lock-up. It's hard to know if investors pushed back on that or from where the pressure came. This stuff is more complex than it seems, companies are rarely just being d*cks.
That's pretty normal, though, and they're offering sell-to-cover as an option to their current employees, so that sale at the end of lock-up is going to happen regardless.
I'm not convinced these events represent a significant enough number of shares to move the price, though. And regardless, many current and former employees will use this opportunity to dump more shares than just to cover withholding. I wouldn't be surprised if the number of shares sold normally at that time will dwarf the number sold to cover tax withholding.
I agree with you, but just to play devils advocate: use the property you are permitted to use and build parking on your own property. If you can't fit a garage or parking space on your land, you didn't think through the purchase for your needs.
If I live in single family housing that is adjacent to a business district and I have no driveway then street parking can be pretty efficient. I can leave my car in front of my house all night long and in the daytime when I go to work people can come from other neighborhoods and park there while they take their lunch and do their shopping. If someone builds a multistory apartment building at the end of my street and doesn't provide adequate parking then now I am competing for the space in front of my house every night. Okay, so I install a driveway, now only I can park in my driveway and no one can park in front of my house (because there's a driveway there).
> If I live in single family housing that is adjacent to a business district and I have no driveway then street parking can be pretty efficient.
You are the one who chose the house. if you have a single family house with no driveway you self selected to not having a car. its not the other citizens in the city who forced you to buy that house and then buy a car where you had nowhere to park it. Even if there was adequate parking before and now there isn't, what gives you perpetual rights to a shared resource?
Why should other people in the city suffer for your lack of foresight?
Sure. They chose a house which at the time had shared on-street parking available, a situation which was not guaranteed to persist forever.
But if they had shown "foresight" and insisted on a suburban house with a drive and a garage, resulting in more yardage of road for the taxpayer to maintain and low density reducing walkability increasing car traffic - has society been improved by their "responsible" decision not to depend on the shared resource?
The person who wanted a single family house with easy parking moves out of the way for other people who don't have those requirements and frees up more space for businesses and apartments who prioritize being in the center as opposed to living in inefficient single housing with a car.
I don't get the argument that its some type of right to have a single family house in an urban center with a place to park your car in front. Thats a luxury.
I can't speak for other posters but I'm personally not trying to make the argument that any one is entitled to the street parking in front of their house.
I lived in a single family house in this sort of scenario for about 15 years in a neighborhood that was experiencing rapid commercial development. (The street one away from mine went from a sparse arterial-through-light commercial zone whose most prominent offerings were a plumbing supply store, a pet hospital and a dental clinic to a bustling thoroughfare of dense resturaunts, shopping, and bars).
When I moved in only 3 houses on my block had driveways and off street parking. It was easy to find parking on the street any time. As the area developed it became as I described above, with mostly residents parked on my street at night and ample turnover during the day for the neighboring businesses.
When the properties behind my house became four story apartments the parking situation began to change on my street and, like you suggest, people started moving out and selling their houses.
But the buyers didn't immediately tear them down and put up 6-story apartments, instead they all got individually replaced or bones-down remodeled into more massive and luxurious single family residences. And they all got driveways.
After that it was impossible to park on my street without a motorcycle or a smart car. All day long people would try to cram in between adjacent driveways where they didn't quite fit and my rich neighbors would come out and leave passive aggressive notes on their windshields.
I was the last house on that street without a driveway, but I worked nights so the spot was pretty much defacto mine. Eventually I sold that house and the next owners scraped it and built a > $1m residence with a driveway. Over ten years later and the situation there remains the same.
It's possible that eventually all those houses will give way to multifamily then high rises, but for the current investment I imagine it will be a while. For how many generations will the parking in that neighborhood be dysfunctional?
Maybe it could've been avoided if developers and planners just ponied up for more underground parking and transit connections, who knows?
Part of what Shoup talks about that gets less attention is actually managing parking when it gets scarce. Your reasoning about creating your own parking spot on your own property is correct. In terms of the street parking, there are various ways of managing it to ensure there are some spots free most of the time.
I can't count the number of great creations that started as a "cheap knockoffs" of something else.
> Even the name.
"A" for app? Even if it didn't make sense (and I think it does) it's short, memorable, and "making sense" wouldn't matter. Didn't stop "Venmo", "Snowflake", or "Apple" haha
Don't be too committed to your taste in UI/Names. You might miss out on good products like this one
The difficulty stems from you have to rewrite the encoding/decoding canonicalization library in every language you want to consume the data with as opposed to simply piggy backing off of default implementations and the language's standard crypto libs.
For example most JSON parsers default to interpreting numbers from JSON as floats or ints. but in the canonical format you would have to force all parsers to interpret them as exact decimal values. then determine how to encode them (is one hundred "100" or "1e2") etc.
> The price point is too painful for home use unless you place your frame high above inaccessible without ladders.
When i read this comment i had to go look at the product because i was expecting 10-20k. Looks very reasonable to me. The most expensive is only $2500? and the cheapest only $600? Seems super inline with what I would expect to pay for art.
You're not paying for art. You're paying for paper you can later display art on.
Also, with e.g. an oil painting on canvas, the cost of producing that is the time of the artist to paint it by hand. I don't think 10-20K is anywhere reasonable for e.g. a mass-produced inkjet-printed thing. Likewise 10-20K for a PNG file would be even more insane.
Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome.
Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.
the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
> Almost never have a met a person who was equally good at both.
Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it.
The thing is, you need an actually senior engineer for that. Not some kid right out of college that is somehow called a principal.
These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design.
On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers to deliver a good UX.
On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.
It really depends on the product (or feature) how much of that expertise is necessary. You need some domain experts for sure who really know the ins and outs of the specific backend and frontend technologies to architect the overall app and build system, and do the hardcore stuff like optimization that you mention.
But fullstack engineering is just much more individually productive, if you're updating a settings page why involve multiple engineers and coordinate a handoff, when one engineer can just add the API calls on the backend and add the new toggles to the frontend in a single day? Most software doesn't need to be beautifully polished and completely excellent.
Anyway I personally just find it fun, I get to breathe life to a vision end-to-end and tackle a wide variety of problems, and I can deliver quickly. Even if I'll never be (and don't desire to be) a super expert in one technology.
They’re definitely not totally different, it’s still programming. I’m competent in both and have occupied both roles in my career, but more importantly I’ve worked with people much better than me in both areas :) They were more similar than they were different.
I do agree with you that there are skills specific to each layer of the stack and they don’t all cross apply. You definitely don’t get to be good at backend and then magically be a strong frontend engineer! But I think a good backend engineer has a bright future as a good frontend engineer and vice versa, should they choose to pursue a different branch of our discipline.
Carpentry and cabinetry are both wood working as well, and both professions have somewhat of an overlapping tool set. However the professions are still very different, and being good at one will not make you good at the other. A good carpenter will have to learn a whole new skill set if they want to be a good cabinet maker.
By your own admission, you are a front-end developer, so why do you feel qualified to make such a broad, sweeping statement? Just because it feels different now does not mean it will once you’ve spent years working with it. Just the idea that ‘optimization’ and ‘speed’ are a back-end thing…
It’s a very recent thing that these things you describe are even considered related to front and back-end at all. If you go even 7 years back you’d have needed to consider all these as a “back-end” developer.
How you optimize for speed, size, and memory are very different between the frontend and the backend. On the frontend the best optimization is quite often to simply let the backend handle it.
For example if the the app is too slow because we are pulling in thousands of records and rendering it to the DOM, the correct optimization is to paginate the results. Both frontend and backend devs should know that. However the frontend dev needs to make the pagination a fluid UX for the user, decide between page controls or infinite scroll, implement search on type, set the correct aria-attributes so assistive technology knows this is an incomplete list, etc. The backend dev however needs to optimize the database queries, decide on the type of pagination (keyset vs. limit-offset vs. cursor etc.) and map the response such that the frontend won’t have to do too much work ones received (I guess a frontend dev should be able to do the latter; but it is hard to ask a frontend dev to be an expert in optimizing database queries; or implement proper keyset pagination [although if the UX team decides on infinite scroll that limits the possible pagination types a little]).
> If you go even 7 years back you’d have needed to consider all these as a “back-end” developer
I have been a frontend dev for almost 15 years, and I very much disagree with you here. I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers (case in point: Intl.PluralRules became widely available 7 years ago).
This may have been true in 2009 when web-apps were fairly simple (often just a series of form submissions), you had a good idea about the screen size of your users, it was hard to mess up accessibility (and yet, many developers did), localization was mostly done on the backend, single page apps were almost unheard of, etc. But not in 2018.
> I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers
This is all HTML & CSS. Bootstrap made responsiveness normal ever since it was introduced. If you have any form of server rendered application you have to handle these. It’s not like you can choose to hand it to a nonexistent front-end dev, since there is no separate front-end.
I think a lot of frontend engineers can do backend work and vice versa, but it takes a lot to be very good at both. It's not impossible but also I think it's rare that a backend engineer would voluntarily decide to also become a frontend expert instead of leveling up their backend skills.
Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.
A true fullstack developer is a jack of all trades.
The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one."
A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack.
But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, early stage company or greenfield project where building fast, lean and "good enough" is the target.
One of the important things about employing full stack engineers at small companies is that the skillsets of frontend and backend don't always meet the needs of the work they're doing.
Consider two examples: sending an email, which requires typical frontend skills but is by nature in the backend code; and configuring invisible backoff and retries in the frontend, which is the opposite.
I call myself a full stack engineer even though my ability to do design-adjacent work is pretty bad because I've spent a lot of time working in this middle ground. When you want to e.g. move PDF generation from the server to the client, or you want to untangle the horrible Redux caching layer that doesn't invalidate things properly, that's a specific blend of skills that's neither fully one nor fully the other. This is less about cost and more about a niche between the two fields.
Consider also data engineers, or teams with a technical lead rather than an EM, or any other role that sits between worlds.
I’ve met people who haven’t solved a partial differential equation in 10 years and still remember how to do it whereas some people barely remember the library they used last week and have to keep a mountain of notes.
The people in the former camp have a lot of very deep knowledge on a lot of things.
Someone who can solve a partial differential equation with an hour refresher after ten years but most importantly can identify a situation where a differential equation is useful even if they can't solve it outright is still useful. If they're keeping a zettelkästen level system of notes and can get back up to speed on the specifics quickly but retain conceptual knowledge then I don't see any reason to dismiss them.
One issue our industry has is how to identity a great generalist. Broad conceptual thinking is harder to test and interview for than specialized tasks.
The second part of that adage was added on I believe centuries after the attestation of the first part. It's still a nice saying, of course. I think there's a third part to the phrase but I can't remember it for the life of me.
That's true, but the original phrase was from the 1500's so added centuries later could still mean centuries of usage.
It's important to not see any iteration of the phrase as either praise or insult. There is nothing wrong with being a specialist or a generalist, only that there are uses for both.
Most of the time being very good doesn't matter, when you're thrown into a process that's designed to extract mediocre work out of everyone, regardless of how good they are.
I'd imagine it's more common that a frontend dev moves to backend dev role.
From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.
Also they tend to have very good API design skills, since they understand both sides intimately.
> I’ve definitely met people that were equally competent at both
Tbh this is a meaningless statement. How on earth is any sane person supposed to compare competencies?
I both describe myself as full-stack and associate with other people who do the same. There isn't a single person among us who would try to pitch ourselves as equally competent on the front end and the back end. Who would do this? Why? To what end? This simply ignores why people actually use the term "full stack": to indicate willingness to take on work, not competency.
> I’ve definitely met people that were equally competent at both
This is somewhat silly because there's no good way to compare backend and frontend abilities. And why would you! A full stack engineer indicates willingness to tackle both sides, no equivalent competancy.
> Almost never have a met a person who was equally good at both.
I am literally that person. It's a good thing we've never met, or you wouldn't be able to say that anymore!
Edit: Sorry for sharing my professional responsibilities, where some of my clients pay me for front-end work, some for back-end work, and some for both. I forgot that people on the internet that have never met me know what I do better than I do, and that I'm not good at it! Please don't tell my clients that have been paying me continuously for 15 years....
perhaps you are the exception that proves the rule :shrug: or perhaps its hard to objectively measure one's owns abilities. which is the most common thing i have seen from "full stack" interviewees.
> perhaps you are the exception that proves the rule
As someone who worked directly with OP, I can confirm they are highly exceptional. Don't be too surprised when you encounter talented people on HN. I challenge you to be more inquisitive, rather than dismissive.
Or, you just think you’re literally that person. No offence, I’ve met my fair share of developers who are full of themselves but are barely tolerable at best.
Well they didn’t say that they are specialist level at both. It could be that they are mid/good level at both, which isn’t a particularly egotistical view to have of oneself. I got the impression that they were highlighting their skillset is more broad than deep, which is basically what you’d expect from a good full-stack developer.
I’ve met a lot of programmers early in my career who were full of themselves, and a number of more experienced ones later in my career that understood their own capabilities very well.
In my experience, I've seen no benefits (and sizable downsides) to using Python on the backend when the front end is React vs. using Node. There are tons of robust API frameworks for Node, a huge ecosystem, etc. So with Node and Python it's more potayto-potahto, and if that's the case, there are benefits to having everything in Typescript for standard server/client cases.
Note I'm not saying do this everywhere if there is a place where there are clear benefits to using another language. For example, while IMO the difference between Python and Node on the server for standard CRUD type apps is really one of preference, that's not the case for doing something with ML or LLMs, where the ecosystem around Python is much bigger, robust, and more generally familiar to the AI crowd.
What are the downsides? Benefits are if you use something that uses Pydantic models (say, fastapi + sqlalchemy) for example you seem to be able to get more granular control over DB types than, in my recent experience anyway, we had using Prisma / Nextjs.
We switched over, have fastapi generate an openapi.json, then use Kubb to have it auto-generate typescript types (it can also do zod models), done.
TBH the hardest thing for a long time about Node backend engineers isn't that there isn't great frameworks but a lot of times people choose node for the above use case. So developers who write Node backends were some breed of frontend people who chose node because they didn't want to learn another language as opposed to learning the language because it was the best tool for the job.
Anyways recently the typescript backend scene is developing a lot better than even a few years ago. stuff like NextJS becoming more popular and more stable better backend typescript frameworks coming out.
My comment was mostly aimed at using backend languages for frontend as opposed to necessarily targeting Typescript
Yeah, I agree with that. When I first saw the title on the article I thought "ergh...", because while I think Go is a fine language that really excels in some contexts, the number of developers who are familiar with "Go for the front end" is vanishingly small. My initial distaste was tempered by the fact that I thought they at least had a good reason for wanting to eliminate "need to code twice" for their different front ends.
FWIW I was a primarily a Java server developer for the first ~15 years of my career, then switched to Node and really loved it. It was at that point that I fell into the benefits of my "Typescript everywhere" mantra because it solved so many problems I had seen with the common setup of Java on the backend and Javascript with the rise of SPAs on the front end.
On my company’s latest project we are using Spring Boot on the backend with Typescript and React on the front-end. We are using Swagger for API specs which means we can generate type safe Typescript code for the front-end, including schemas for Zod and Tanstack query functions. With this codegen I can’t see many benefits to using Typescript on the backend, although the project is a rather standard CRUD app. I can understand why you might not want to use Java, but surely there are better backend choices than Java or Node?
I am curious - could you explain how you are benefiting from using Typescript on both back and front end?
When I've posted this before, the main objections I've got have usually been from the perspective on individual developers, or stuff like "you can't actually share a ton of code between front-end and back-end". That's not my primary point (though there are some places where it is nice to share code, e.g. input validation that you may want to run on the client for user experience/performance reasons but then that you also need to run on the backend for security reasons). The biggest benefit I've seen is in team dynamics which results in bugs getting fixed faster and new features getting added faster because it's easier for team members to "cross" backend/frontend boundaries.
I think you feel that way because you're comparing Node to Python. Neither of them are particularly good languages for servers. Languages like Go and Java/Kotlin are much better when you're building complicated systems that need to be performant and reliable.
Hard disagree on Node (at least if you're using Typescript) not being a good server language, and I say this as someone who was a Java dev for the first 15 years of my career. I've seen more performance nightmares with Java compared to a well-written Node server, though Java has improved a ton in recent years with things like virtual threads and the community has generally seen the error of the unnecessary AbstractFactoryBuilderGenerator shit that was so common for a long time in Java.
Go is not the best for ML and scientific applications in my experience. Orchestration is fine but the libraries just aren’t there, Gonum alone is way behind NumPy/SciPy
It's kind of funny to me how derided full stack developers are as unskilled generalists. It would have been unthinkable back when I started web development to only learn half of what it takes to build a website.
> People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
Full stack developer here who disagrees. Most web apps are not that complicated and if there are the term 'backend developer' will be replaced with something more specialised as well.
> the backend story for me is still weaker than using Python or elixir, etc simply serving an API
That is a very odd statement, Python has a lot of issues that NodeJS never had, in terms of developer experience I believe NodeJS is superior just based on the fact that I don't need to know what a virtual environment is and I don't need to choose between different incompatible package managers before I even write my first line of code.
> if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.
If the only consumer of the API is your frontend, why would you want to have such a strong boundary?
> the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
This statement can easily be hard countered by the rise of full stack frameworks like NextJS and the fact that the whole backend-frontend separation didn't always exist, it mainly happened because of SPAs.
> People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
I never interpreted Full Stack to mean homogenous competency, which is a rather strange concept if you think of it.
In fairness, the goalposts for frontend dev shifted significantly in the past 10 years.
But also, no one thinks Full-stack developers are experts at everything. We are well aware they are the jack-of-all-trades developer archetype, that's why we hire them. They come in all kinds of shapes like you allude to, more like a starfish of skillsets with varying degrees of skill in each leg.
But perhaps the best thing you get out of the starfish, is you know they'll be able to pick up whatever you throw at them, and they won't complain that that they can't do it because it's not "frontend" or not "backend".
Corallary, good programming is universal. I find people tend to be experts in business domain and framework, regardless of where that lives on the front/back spectrum.
As backend developer/devops that dabbles in (Web) frontend, I am fully spot on the point of view.
The only kind of frontend I could equally consider myself good, are native frontends on Apple and Microsoft platforms, but that is because native GUIs do most of the UI work and don't require CSS wizardy skills to turn divs into drop down boxes with type-ahead search.
I also think having one language can be a detriment at times. The JavaScript that you write on the server is so different than that on a browser. Same with Clojure/ClojureScript. This idea that everything is in one language so everything is understandable to everyone just isn’t true in my experience. It’s more like trying to learn to speak Brazilian and European Portuguese at the same time
There is something to be said about language _pairings_ though. I was building with a Python backend and ClojureScript front end for about 8 months and it. was. [expletive]. miserable. The context switch between the two languages was insane.
I rewrote the backend to Elixir and the problem completely went away. No more context switching. Elixir is amazing at what it does. ClojureScript is amazing for UIs and state management. Everything is functional and immutable.
That being said, I do occasionally wish the data validation could be written in one language and used on both places. But that’s just the engineer in me - in practice I have had 0 data validation mismatch errors
When you have a team of full-stackers with some front-end focused, some back-end, and some in the middle, with the right team culture these people can learn from each other and grow into well-rounded full-stack devs.
And given the current market, companies can be more selective.
backend engineering is really straightforward nowadays. same as frontend, its mostly knowing a couple tricks about how to format data. mostly is language agnostic api calls of some kind and you can have minimal transformation code over some fully managed platform. typescript seems to be one of the more supported transpilation tools.
> People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost. May be at some point help from a subject area expert would be needed — set up proper db indexes, center that div properly on a small viewport. But being able to iterate without the need to communicate, debug miscommunications, or wait on another person’s availability is a massive efficiency gain. Most product work doesn’t require deep specialization—just someone who can get things working end to end, refine as needed, and know when to pull in an expert.
The alternative is siloed devs constantly handing off half-finished work, where backend waits on frontend for an API contract, frontend waits on backend for an endpoint, and everyone waits on QA. Been there, done that. A competent “full stack” dev sidesteps that bottleneck and ships.
> So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost.
Its a short term productivity boost sacrificing for long term maintainability and future productivity.
I would take 1 backend engineer + 1 frontend engineer over 3-4 "fullstack engineers" any day of the week.
Same reason you hire an architect, electricians, carpenters and plumbers to build a house instead of getting an equal number of handymen and telling them to get at it.
Thats not to say a layperson can't build a house, but having experience and training about a specific domain can make later modifications and updates significantly easier.
You don’t get back to architect when you’re doing plumbing. You don’t get back to plumbing when doing electricity.
And not only those are often highly isolated tasks but those domain have specialist in it as well. You might go to electrician who can do high voltage installations and you don’t care because he can to general wiring too (thus being full stack).
But there’s different about sacrifice that’s bigger issue. In software engineering handoff costs can be absurdly high. Teams can be allocated and if backend team misses on deliver the next window of opportunity can be in couple weeks. In micro, highly agile teams it’s yeah whatever, but I’ve yet to see a dedicated team of frontend/backend that’s on standby for the other party.
> Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
I would not be surprised if in 10 years from now, there will only be full stack web developers.
I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.
Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...
Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.
I think the trap people fall in is that LLMs don't need to be novel or reason as well as a human to revolutionize society.
Plenty of value is already added just by converting unstructured data to structured data. If that is all LLMs did they would be still be a revolution in programming and human development. So much manual entry and development work has essentially evaporated overnight.
If there was never a chat based LLM "agent" LLMs just converting arbitrary text to structured JSON schema would be the biggest advancement in comp sci since the internet. There is nothing equivalent that existed before except for manual extraction or rule based hard coding.
Judging LLMs based on some criteria of creativity or intuition from a chat is missing the forest for the trees.
After this past election cycle I don't see how people can make that comment with a straight face.
Media in general is very right leaning. Some like CNN and NYT are maybe slightly more left than far right fox news, but there aren't many "left leaning" mass market news sources that are essentially felating one party for millions of people.
NYT and CNN, etc are all very critical of democrats when there is a controversy. This is stark contrast to fox news which essentially is willful ignorance of anything bad republicans / trump has done.
The "normalization" of Trump's corruption by media in general should be enough to see which way they lean.
Its just that if anybody is slightly less than full blown fox news conservative they get labeled as left leaning by everyone in the media so there is some idea of "balance" but conservative media (fox news, conservative podcasts, etc) are overwhelmingly mass market and the majority.
Wow. You don't need to be very right leaning to feel the complete opposite. I'm simply amazed someone could feel that way, as nearly all media is very left-leaning (to my perspective).
And there's the core of issue. If you use vague terms like "left" and "right", then different people in the discussion will be using different definitions. You're using them to mean socialism vs capitalism, whereas others mean Democrats vs Republicans. Some are even using liberal vs conservative. Occasionally, I've seen it as authoritarian vs libertarian, even though that should be an orthogonal axis. If you're going to commit to the logical sin of the false dichotomy, at least say what you mean.
You have many misunderstandings that you should probably have right first before continuing
CNN leans pretty far left, but not as left as MSNBC
NYT leans pretty far left, similarly to CNN
Reddit leans very far left, so does Facebook and Instagram
Media in general is very left leaning. For example, Youtube, Disney, Netflix are the biggest online video content house, and they all lean heavily left. Even Max leans slightly left. There is no right leaning online content house. And all contents are moving to online.
What you're calling "left" is center-right in the rest of the developed world. None of those are left leaning. They are all pro-corporate, pro-capitalist, anti-worker "infinite growth forever" media. Some of the journalists who work for them are left, but the owners are largely conservative and force them to cover Democratic scandals just as much as Republican ones, while Fox News and other conservative media outlets just outright ignore Republican scandals entirely.
If mainstream media in America was left, Bernie would have just finished up his second term.
Interesting to be around for the birth of a false fact like "the media is right leaning". Overnight you see people start parroting something that's clearly untrue.
Maybe you haven't been paying attention the past 5 years, but there has been a dramatic shift to the right in media. Companies change ownership and the new owners take advantage of the historical left leaning nature of the media.
The magic trick fox news and conservatives has pulled is by being so far right that center/slightly right parties look far left. The normalization of the MAGA movement is evidence of this right leaning media machine.
Look at who owns the "left leaning" media companies. CNN is owned by conservatives.
Joe Rogan, Candace Owens, Tucker Carlson audience dwarf most other channels these days. fox news has almost 3-4 times the viewership of CNN which is the preferred example of a "left leaning" network to balance them.
The rights constant raging against mainstream media is an attempt to distract from the fact that mainstream media is in fact conservative.
I was at a speaking engagement where yudkowsky said quite clearly said to the audience "Even if my research has a 0.0000001% chance of preventing AI from destroying humanity it is worth it to fund my research"
To them their rationalization leads them to believe that because 0.0000001% > 0% they should be funded millions of dollars "just in case" AI goes rogue they can use their philosophical toolset to contain it.
I'm saying he pulled it out of his ass. To qualify as an "overestimate" it would have to be an estimate, meaning based even loosely on physical reality.
Was it really "suddenly"? it seems like for the past decade there has been an ongoing push to make everyone use "chromium" based browsers. I remember 10-15 years ago you would get blocked for not using IE or whatever, even though the site worked fine and there was no technical reason for the block.
It was over 12 years ago when google effectively killed RSS to prevent alternative methods of access.