Completely agreed. "Full-stack" developers fall into two camps; that is the "web developers" who know enough PHP/Node/Whatever to build a CRUD app with UI, and the serious software engineers who treat front-end as an "oh whatever" afterthought. Both end up with nothing but a huge mess at scale.
That's not my point. I'm saying that there's a difference between the full-stack generalist "web developers" who know HTML/CSS/JS/PHP/Ruby, and software engineers who build complex systems, typically in Java/C#/C++.
There are also people who do both. I started out with JavaScript and PHP and do a lot of React/Angular/Laravel stuff. But I have also worked on complex performance-sensitive business systems written in a mixture of C++ and Rust.
My boss at my last job had done the opposite. Coming from a tradtional compsci C/C++ background (many moons ago), he learnt Angular 2 for a frontend project that required it. Both his C++ and frontend code were among the best at our company.
Saying there aren't good fullstack engineers is like saying multi-instrumentalists aren't good musicians. Sure, the very very best violinists probably don't play other instruments at a high level. But the average multi-instrumentalist (who plays the violin) is a lot better than the average violinist.
I'm this way, and I don't know why. I try to avoid frontend, until I'm more or less forced into it. I can make something functional, but inevitably get grilled about my way of going about it or why I didn't use 2018x style. The fact is, I don't care. I hate every minute of it, and only learn enough to knock it out. I find myself mentally complaining every step of the way. I just don't like how the web as it is is designed, written, or fits together. I wish there was an off switch, as I know i'd be more valuable with these skills, but I'm just mentally unable to accept it.
Oh thank god! Finally glad to see this koolaid getting dispersed. I hope some of the glory gets reimbursed to embedded and systems level engineers too :)
Shouldn't a "full stack" engineer also be fully versed in hardware engineering, microprocessor architecture, kernel and driver programming, operating systems, programming language and compiler design, etc?
You sound like someone who is not good or dislikes either backend or frontend work and cheers for anybody who says that one person can`t do work. There are many of us who can.
So on the contrary, I am a generalist and love poking around all over the stack. But that's it. I am a crazy breadth person but dont like to go into the depth at each level as that has way too much overhead for me. So that limits my expertise (but not love to tinker) in any one area. In companies/places where we need to go beyond POC apps, standardization (within stack and tech) kicks in, and you are not going to be productive if you are not doubling down on one or two areas. Worse are political problems where as an "apps engineer" where you are implementing a bunch of interfaces but diving deeply requires you to transcend org boundaries (again I am not a fan of that, just reporting as I see it), limiting your productivity.
I once met a software engineer who said I was not full-stack because I didn't know how to add to the Linux Kernal. I once met a hiring manager who said I'm not front-end because I don't know how to vertically shard MySQL and "every front-end developer knows how to do that." Technology stacks differ per company and the definition of the title will also differ. That doesn't mean it doesn't exist.
Agreed, though I don't feel like a Full-Stack Engineer should do the DevOps Engineer job as seems to be required by this hiring manager. I am not saying you should not know the underlying component you are using in your stack though, just what you need to work on it, not how to administrate a large scale database deployment.
It seems that the world clearly lacks a definition of what Full-Stack Engineering really means ...
I wish. My recent task has been writing scripts to set up Postgres on a bare-bones linux server (including all security, software, users, nfs, hot backup servers, etc) and port an Oracle database over to the postgres database and update 1000s of oracle queries to work on postgres.
In my spare time I also had to create some new admin screens and do a bunch of back end work. I also created a bunch of new svg images for the admin screens.
Basically I'm expected to do everything from setting up and managing linux servers, security, install and configure software, set up oracle and postgres databases, do DDL and DML work, write server-side code, write web services, create images and do layout work, write test cases, write html, js, css, and know a bunch of JS libraries like vue, vuex, vue-router, webpack, jest, bluebird, lodash, async, tailwind, scss, etc. ad naseum.
Yup, it differs considerably depending on the job—the point I guess is that your breadth of experience spans the software in question from end to end.
I consider myself a “full-stack” programming language engineer because I’m equally comfortable with type theory, user experience design, practical implementation, and instruction-level optimisation. Am I a full-stack web developer because I’m equally comfortable with front-end design & development, server-side infrastructure, and networking protocols?
Some would say yes, some no—but I can readily develop, maintain, and optimise a whole application by myself if I need to. I may not do as good a job in any particular narrow area as a specialist in that area, of course.
Indeed I have seen front end Django developer jobs, when Django is most definitely a server side technology. However on multi tier systems it may be handling the "front end" of the system.
In a world with no SPA django is as much a front-end framework as it is anything else (just as JSP, ASP and a million other frameworks that render html on the server and send it).
A full stack developer is what turns into an Architect. If you cannot build, operate, tune and debug the full stack, at scale, you are not an architect.
I wouldn't agree. A building architect isn't an expert at all the trades that are required to fulfill his design; he just has a strong understanding of how everything fits together and what is/isn't possible.
Agree, and the mess is when an architect thinks they are the head and know better than everyone else. I doubt there would be a mess if the architect said let’s do x and someone said oh no y is a better approach and they lived happily ever after ;)
>A full stack developer is what turns into an Architect. If you cannot build, operate, tune and debug the full stack, at scale, you are not an architect.
Ah yes, I love cleaning up the mess every "architect" I've ever worked under has left on the front-end. Front end development is an arcane art, full of a million gotchas that have nothing to do with intuition, intelligence, or programming skill. It's just years and years of running into stupid mistakes and API quirks to build that domain knowledge. Anyone who doesn't respect and accept that is sorely mistaken.
This is starting from the assumption that every website must be an SPA, which I am not sure I agree with. Most of the time you really don’t need that much stuff on the client.
What makes you a "senior" engineer, anyway? I feel confident calling myself fullstack. I'm not going to list all of the things I have done and know how to do because honestly it would feel arrogant. But what lead to the thought process that backend and frontend developers should be separate anyways? Yes, it is complicated and time consuming to keep up with both backend and frontend development, but there's no way you're telling me some people believe it's actually impossible to do that. If you dismiss the frontend as unimportant, what the hell are you writing the backend for to begin with???
I like coding and I definitely find programming enjoyable. But, importantly, I don't write software for the hell of it. If you actually give a damn about software development, I don't understand how you could simply dismiss one side of software development due to where it gets executed in the stack.
You've spent enough time designing software that you can take a vague spec, design a solution avoiding common pitfalls and following a very easy path. Then you hand back a prototype followed by a complete and maintainable solution to a happy client.
At that point, your services should no longer be _required_ to keep the product working.
Everyone has their own definitions. Here are mine. Do note that a lot of people who think that they are senior, actually aren't by mine, and senior is something that can be reached by some with very little experience.
Junior - Needs close supervision. Can't reliably develop something more than 1k lines.
Mid level - Has learned to follow a design consistently. Doesn't keep an eye on the bigger picture. Likely to fall apart around 10k lines.
Senior - Can work in the weeds and keep an eye on the business as a whole at the same time. In my experience is likely to be able to design something that can scale to 100+k lines.
As far as I can tell you can use the title if you've worked for about 8 years in the field. (Not that I really agree with the definition. But basically from what I see they do the same work as non-senior engineers but the job listings want more years of experiences.)
That's optimistic. I usually see it at about 4 years, which is absurd, and directly leads to the 26-year-old senior dev I worked under a couple of jobs ago, who's primary concern in code reviews was that I always cache my jQuery selectors "for performance reasons".
I think that definition of "senior level of expertise" is a bit too much for full-stack engineers. I actually have worked with many engineers who are very comfortable working front to back end creating wholistic solutions. To me, full stack engineer is someone who can design and implement a wholistic solution. If you can build a todo app, you're pretty much a full-stack engineer (a junior one and also depending on the todo app implementation).
I didn't believe in full-stack engineering either, until I had a very hairy problem that required fighting with various interacting issues to obtain a specific level of "web performance".
And yes, I know about "font loading, images, SVGs, animations, auditing third party scripts". Still sometimes, you have to dig deeper in the stack to find the low hanging fruit that will make the difference between meeting requirements or not.
After throwing away the nice SVGs and replacing them by inline PNG (uglier, but you need that 15% size difference and the precious milliseconds), what do you do?
My current solution is a combination of various things - the last element being VPS close to the customers to provide resources with a very low latency.
(and by the way, if anyone happens to know reliable VPS companies in South America, Japan, South Africa, I would love some recommendations. I only know about Hetzner ZA and Linode JP. I would love to find some good host quality around Uruguay or Brasil)
I disagree with the article. It's a 1,000 word false dichotomy between Full Stack vs. Insert Specialist Here.
Sure, if you're a Fortune 500 company, go ahead and hire a DBA, Cloud Architect, Backend Engineer, UI/UX Designer, Graphic Artist, Social Media Marketer, etc.
You'll have a few million $ in salary overhead. It may take longer to produce a final product.
BUT, it will probably be way better than a product that a full stack developer knocks out.
BUT, if you're a startup or SMB or lean department and have a 100k budget and a 6 week deadline a full stack developer is a huge asset to your company.
Obviously when you take the same project and give it to a highly specialized team of people with lots of time they produce superior results. Do we really need an article about it?
PS. Giving a 10 person team a 1,000 hour time budget would not be a huge deal. Try not laughing when a single Full Stack developer asks for 1,000 hours.
not always. Just finished up a 7 week deadline in 12. 2x in my experience has been a fairly reliable estimate. A 3-4x project has either gone completely out of scope or was poorly estimated. And it’s not always the development team’s fault. Sometimes the client is not timely, or even habitually late with deliverables. Unless you’ve worked with them before and know what to expect, give the client a timeline of X but quote for 2X just in case.
Estimates are interesting and I encourage anybody to play with the statistics to see how it works. There are 2 scenarios you need to consider. First is the scenario where the stake holder asks for something, the thing is possible (i.e. it's a matter of working on it until it's done), they don't change their mind, the team doesn't have some kind of emotional incident (like people refusing to work together, someone having a serious health issue, etc). In that case you can split down the overall task into many sub-tasks and estimate each one. Each sub-task estimate will have a high variance, but the more sub-tasks you break it down into, the less variance the resulting overall estimate will have.
The key thing to understand is that while the overall variance will be small, you don't know what the multiplier will be. For teams that you are familiar with, technology that you are familiar with, etc, etc, in my experience people do tend to come out with about the same overall multiplier. Different teams are vastly different, though. I've had teams that operated anywhere from 0.5x (i.e. they overestimated by a factor of 2) to 4.0x (i.e. they underestimated by a factor of 4). It's always best to keep measuring your team's performance to figure out what the best multiplier to use (this is what's known as "load average" in some "agile" systems -- the inverse is "velocity"). Care must be taken to dissuade people from trying to optimise the load average/velocity because it will undermine your estimations -- usually I don't tell people what it is.
Now the other scenario is also fascinating, but requires much less statistics to understand well. Basically this is when the stake holder constantly inserts urgent requests, or cancels tasks mid-development because they thought of something better. Or when your team sits around for 5 days arguing about whether to indent with spaces or tabs. Or upper management decides to "accelerate" the process by constantly inserting new members into the team. Or someone intentionally tries to sabotage your project because they have a "competing" project in the company (or possibly just because they see you as a threat to their eventually triumphant march to the heights of the org chart). Or your lead developer decides that today is the day to institute a national "bring a firearm to work" day. In those cases your schedule is fiction, no matter what process you used to create it.
BTW, all of those things have happened on teams I was on in my career :-). Incidentally, not having a firing pin in a weapon is not considered evidence that it was "just a joke", strangely enough...
Excellent points, I think the whole point of SCRUM planning is to get estimations correctly and it is not as easy reading few articles on it. Hence involving a scrum-master is highly recommended who is usually a person like mikekchar who has done it multiple times atleast.
The scrum master has to have a fundamental understanding that 8 hours of work is not one day. It's generally interrupted by meetings, helping out a coworker, crisis mode on some bug and also generally fucking around with coworkers. When a Dev says 8 hours that should automatically be translated to 16-24 because they won't actually be able to be "heads down"
The interesting thing is that statistically, the things that interrupt a developer occur at a predictable rate. What's not obvious, though, is that you can't predict the completion of a single task. You can predict the completion of a statistically significant collection of tasks. If someone is asking "How long will it take to do X", where X is a single task and is banking the company on the reply, they are a fool. But if you ask "How long will it take to do 30 x" and you have some data to show how long x usually takes, then you can actually give some good replies.
Even more interesting (and I was thinking about this only 5 minutes ago), there are models for defect discovery rates. This basically means that when we write code we make software errors. The amount of time it takes before we discover the error is a random variable with a particular distribution. There are several models which try to allow you to determine how long it will take before you find 90% of the errors, for instance. I was just thinking that I bet the model for errors in requirements is probably very similar to the model for software errors and you can probably fairly easily model how long it will take you before you discover 90% of the remaining functionality that you need after you make the initial plan. Indeed, I've measured in a few groups I've worked on that for those groups they needed another 30% of the overall project time to complete tasks that were not anticipated at the start. Unfortunately I no longer have access to that data so I can' look at it in more detail.
(NB: 30% was just for those teams and those projects -- I don't for a second believe that the number is universal. The fact that it was similar for a few teams is probably coincidental.)
Unless your numbers are completely random just for the example, deciding to run an 1,000 hour project with 10 people is a disaster by itself. How would you involve 10 people in a short 3-4 weeks project?
The numbers were only to make the point that hours are more easily accepted when it's split among a larger team. Yet the same quality is expected when a single Full Stack dev does the project in 1/4 the time and budget?
There's another thing, a team of specialists usually requires more management, planning and a good team culture to avoid "not my job to think about that" syndrome.
I think you are making the false dichotomy between a full stack developer working and a full stack developer working well on all three areas.
Few people says one person can't do it all. Few people say that nobody can do it. But we specialize in areas for a reason. It takes a lot to be an expect in an area, and multiple that by three and its even more work and time.
So sure, one person can do it all. Sure, one person can do it all well. But the later is much rarer than the former. And have specialized people for each area who can focus exclusively on their area is better.
The article is titled "I Don't Believe in Full-Stack Engineering", yet states "If you’re only hiring full-stack engineers" as though they are something the author believes exist.
It seems that the real approach of this article should have been to outline why hiring ONLY full-stack engineers may not be a good idea.
It's a common idiom. Someone who says "I don't believe in psychics" means "people who call themselves psychics don't have the abilities that implies", not that nobody claims to be one.
This article is conflating junior developers with full-stack engineering.
I work on the entire stack. Can I work with databases and write queries? Sure. Can I do it as well as a data architect? No. That's not what's expected of a full stack engineer.
We can have meaningful, productive discussions with everyone on all parts of the stack. We'll talk with the data architect, write/tweak a query if we need to, we'll talk with the product manager and collect some features, we'll communicate the requirements to a backend engineer if one exists and help prepare the API as necessary to ensure the frontend can query for only what it needs when it needs it, and we'll connect it to the frontend which we built (yes, even using data chunking, semantic UI, and accessibility, all of which are expected in professional front-end development)
To the purist engineer, none of this is part of their reality because the purist doesn't have business requirements or tradeoffs. In the real world of business, these skills generate profit and are especially useful with new products and prototypes. If you're experienced enough and have a great team with you, you can execute on this with minimal technical debt that doesn't create long-term problems while still providing users with a great experience.
Tradeoffs matter a whole lot. I recently had to replace some beautiful SVGs by PNGs for various reasons centered around the business requirement that a page be below some size, and loads in less than some time.
A purist would cringe. I cringed a bit too. But the end result matters the most.
That’s interesting, I was under the impression that SVGs where smaller for logos and, well, vector graphics. Would you mind sharing what kind of graphics you were working with?
Like you, I would have thought SVGs would be smaller, but experimentation proved that they weren't. It hadn't be checked before, but new options had to be found around the whole stack!
So instead of the crispy SVG that scaled so well, now there are some custom-sized PNG instead - served by geographically close VPS. It seems very dirty on paper, but in practice it works much better than the previous solution that as I purist I found very cute and clever. Unfortunately, it didn't achieve the goals and had to be discarded.
I find that a funny example that illustrates how full-stack engineering is very real.
If you only display the images at a predefined size, a PNG (designed for that size) will be crisper than an SVG. Discovered this at a previous job where we were doing a rebrand, we were using SVGs for the logo and monograms on the website and the designers complained that they didn't look good. We compared them with equivalent PNGs and the quality was much better.
General guidance:
* Photo - Use JPG, WebP or similar
* Images used at a single predefined size, where quality matters, e.g. logos - Use PNG
* UI graphics that are displayed at integer multiples of the base size, eg 24, 48, 72 - Use SVG
* Illustration graphics - investigate trade-offs between size and quality for both SVG and PNG
In this particular case, it wasn’t integer coordinates that were the issue, but the antialiasing quality, browsers (at the time, 3 years ago, might be better now) just couldn’t cut it. Say what you like about Adobe, but their algorithms are top-notch.
On the integer coordinates side of things, if an SVG has horizontal or vertical lines, I’ll always make sure they’re well-aligned before putting them into a UI.
Completely agreed. I find it much easier to communicate with specialists like our DBA, or DevOps team, having at least some mid-level experience or knowledge in each different domain.
Exactly. At small companies you need developers with multiple skill sets so you can keep overhead low during your infancy and growth stages.
As you grow, companies can and do hire specialists who do one thing and one thing well which is great. But those things still need to be communicated and coordinated with other teams which is why having someone with multiple skill sets to bridge that communication gap is so important even in larger organizations.
Full stack generally stays to the product side of both. They tend to have a relatively shallow context on the current goings on of infrastructure/tooling, but can focus on one area or another when the time calls.
Agreed. I would also add, I don't think frontend vs backend accurately describes how skillsets are clustered anymore -- especially with JavaScript's increasing ubiquity.
I would cluster skillsets into: ops, development, and design.
Ops: making things highly available, logging, performance monitoring, reliability, deployment scripts
Development: Writing code on both frontend and backend.
Design: Visual design and CSS/HTML
Most developers I've interacted with at various companies write both APIs in the backend and user facing UI. In my experience it's becoming increasingly rare that a frontend developer doesn't also write backend code.
They typically aren't very good at making their apps deployable and highly available, and they also aren't very good at making things look good with CSS. Sure they can do it, but it isn't their specialty and it would be quite a learning curve or it just takes them much longer than someone who does just that.
When hiring people, I like to find people who are strong individually in those 3 areas (ops, programming, design). I don't try to find programmers who can do ops or design. I don't worry so much about a frontend engineer being able to do backend work and vice versa, the crossover is generally smooth and interchangeable.
It is generally easy to find ops, and programmers who specialize and are talented. Designers who can do visual design and code it up are a bit rarer, so sometimes it is needed have 1 person do design and another person code it up.
Also, a very senior person is obviously going to be stronger in each of those areas, so full stack is highly correlated with working experience.
I think the crossover between frontend and backend is less effective than you imagine. Generally a backend dev writes horrible frontend code and viceversa.
A very senior backend person will probably know many things about ops and frontend, but probably not about design.
A very senior frontend person will probably know a lot about design, UX and have a good enough experience with backend, but is probably not going to implement good ops practices.
In the React / Node world I haven't seen this to be true. I can imagine it being more so if the languages and tooling are different like in the case if someone was doing Java backend Angular frontend.
Same with Vue. I used to be more back-end, but frameworks like Vue and React make front-end feel more like traditional back-end, and are a joy to work with.
I'd separate the client side scripting and styling / layouts, actually. While JS and JS frameworks are fun and enjoyable to work with, and I can architect the JS stuff well to make maintainable code bases, CSS is still a mess for me. Though getting better at that as well. Flex-box and CSS Grid changes the game completely from using floats to do layouts.
> so sometimes it is needed to have 1 person do design and another person code it up.
Honestly, even when it is the same person doing both, I feel like it is best practice to do these activities separately anyway. As in, literally on a different day, with a different mindset.
If you design an application's looks and UX according to how the code 'should' work, particularly backend code (DB queries and endpoints etc) you'll most of the time end up with something that's suboptimal for the user without being able to see it - because you have this very detailed mental model of the system behind the curtain and it's 'obvious' that things should work in this way or that in strict accordance with how that system is organised - whereas the user knows / cares nothing about these things and wants things organised in a way that's more intuitive to them.
> That's not what's expected of a full stack engineer.
That is highly variable. In a world where a lot of middle management considers "tech people" fungible, this is EXACTLY what is expected from a full stack engineer.
And, you get to do the work of front end, back end, and database developers all at once for the price of 1 person. What's not to love?
Only partially "/s", because although I'm not in that kind of position at the moment, I've seen it.
One thing I find interesting is that people refuse to believe that something is possible when they themselves are terrible at it. I suppose this is the new "there's no 10x engineers"
I've always wanted to build a server from scratch: build a simple chip running a one-trick web server that can respond to a GET request and have it serve up a single page application, and a not-a-lot-of-bauds serial modem connected to the internet through a gateway of some sort. It'd probably take me a year of nights and weekends, but at the end I would be comfortable calling myself a full-stack developer.
what's the takeaway from this blog post? There's no such thing as a full stack engineer so don't bother learning about databasing and server concerns and devops; just focus on front-end? Are we just criticizing people for doing their jobs to the best of their ability?
A full-stack engineer is not always going to write the best front-end ever; there may be some kludgey stying and some non-semantic HTML (divs and spans!). As a non-DBA, queries may not have optimal execution paths. There may be questionable backend design decisions.
This is an obvious conclusion and does not really speak to the value that a developer brings to an organization. Development is a means to an end, and there are plenty of business cases that an experienced full stack developer can solve in a 'good enough' manner.
We run the risk of letting the perfect become the enemy of the good. Any mature developer should have one or two areas of deep expertise and have enough skill in other domains to get a job done.
I would appreciate this if more front-end specialists actually had all four of the skills that the author claims separates them from full-stack devs: elegant CSS, high-performance web engineering, accessible markup, and in-depth knowledge of React/Angular/etc. I've not observed this to be true. All too often a person only knows the JS framework and doesn't know/care about any other aspect of their platform.
It depends what the organization is willing to sacrifice. If you want everything done well, then you should get specialists, or pay well for one of the rare persons who can master almost everything.
Internal software usually doesn't have to be as aesthetic on the front-end (UI) such that you can maybe sacrifice there, for example.
Sometimes you can throw hardware at poor performance if performance tuning is not a person's forte, but sluggishness may snag you at a bad time before you have time to upgrade to a more powerful box(es).
I'm the only competent developer in our company. So believe it or not, but I'm doing it all, from tinkering in disassembled Oracle 9i JDBC driver, to planning Oracle migration to writing SQL queries, reverse-engineering stored procedures, modifying Delphi sources, writing Java code, writing Kotlin code, writing HTML, JavaScript, CSS, Objective
C, rolling out some tiny PHP website, writing brute-forcer to crack P12 private key because someone forgot password LoL. Sure, I'm not an expert in any of those fields. I don't even like most of them. Give me task to write Kotlin library (reimplementing React!) and I'd be happy sitting in the corner for the next few years. But I don't have that luxury and generally stuff I'm doing works well enough. And given our income, it's just not possible to hire few competent developers and they would do nothing most of the time anyway. But if I can do it all, I'm busy most of the time and I can have some money as well. Full stack, that is.
> I laughed a bit when I read that you use Oracle and don't have the budget for more people.
Why? Because you believe the former causes the latter?
There are many valid criticisms to be levied against Oracle the company, enteprise software in general, and especially its pricing.
However, it's important to remember that, for many businesses, it's either impractical or downright impossible to hire enough engineers to make up for to lost features of replacing Oracle with even somethig as relatively feature-dense as PostgreSQL.
I think the idea though is most companies that have such small development team usually don't have the need or expertise to take advantage of those features.
That idea just doesn't stand to reason, though, to be fair, if you say "most companies that" you're expressing a stereotype, which can easily fail, as it does here, when applied to a specific case.
I personally know a "such a small development team" (i.e. a single person) who certainly has the expertise, by virtue of having trained to become an Oracle DBA after a fairly extensive career as a software engineer.
As for need, I'm no expert on Oracle's unique features, but the GP specifically mentioned "reverse-engineering stored procedures", which implies at least previous developers thought there was a need to use an arguably advanced database feature.
In fact, even just having a substantial quantity of stored procedures written in PL/SQL, perhaps at a time when that company had (or contracted out to) a larger development team may make it prohibitive to switch to any other language. Reliably implementing business logic as-is is a pretty big feature.
for many businesses, it's either impractical or downright impossible to [...] make up for [...] features of replacing Oracle
I would have granted you this if you'd said "for a few specialized businesses", but you're waaay overselling it. 99.9% of businesses using Oracle would do just fine with a "lesser database".
And I would grant you that if you could make the credible argument that a "lesser" [1] database could be a suitable replacement on a drop-in basis, without significant engineering effort.
As I pointed out in a downthread comment, a very useful feature is that existing stored procedure that encode business logic already work.
Are you really saying that only 0.1% of business database users fall into even that category? My second-hand (DBA I know) experience contradicts this, but if you have a better source, I'm certainly interested.
[1] I don't actually intend to make any overall value judgment, since my point isn't that Oracle has feature/performance superiority over any other database. Instead, I'm saying that it has specific features that the business needed at the time it was chosen that may not be offered by a different one.
Of course once you already have application an built around a platform, the switching costs can be high. See also: IE6. No argument from me there.
But Oracle doesn't sell their product with the pitch "hahaha too bad you're stuck with us". They try to convince the next generation of ill-informed technology leaders that it would be a mistake to choose anything else. I've heard the pitch, and by the third time I heard "invest in Oracle RAC" I was consciously suppressing the urge to punch the salesman.
I'm saying that 99.9% of Oracle customers would have been significantly better off from a cost, flexibility, and support perspective going with an alternative like Postgres when they started building their product. And most of the remaining 0.1% would have been better off with MSSQL.
> I'm saying that 99.9% of Oracle customers would have been significantly better off from a cost, flexibility, and support perspective going with an alternative like Postgres when they started.
Although I agree that some huge proportion [1] of businesses today would do very well to seriously consider Postgres as the first option before even looking at Oracle, I don't recall this being true 17 [2] or even 10 years ago.
Remember, we're likely talking about non-tech businesses here, ones where they're sustaining operations with a single developer. You mention "ill-informed technology leaders" but it's hard to imagine there are any technology leaders actually involved on the buyer's side.
I don't think it's helpful to look back at such a decision through the lens of today's technologies and the kind of talent/expertise that is, today, available to a business whose core competency is tech.
I'm no fan of "enterprise" anything, so don't mistake my critique as cheerleading Oracle. I just feel the context of technology decisions is paramount. It also seems especially germane to the overall thread topic, which is whether a generalist can possibly have enough depth in key areas to be considered competent enough in them.
[1] your repeatedly asserted claim of 99.9% is extraordinary, requiring extraordinary evidence.
[2] Oracle 9i was released in 2001. EnterpriseDB wasn't founded until 2004.
I was building enterprise apps 10 years ago. 20, actually. I made the same arguments then, and I will stand by this evaluation now.
It reminds me of the early 2000s when IBM and WebLogic were selling 5-figure appserver licenses hand-over-fist into enterprises. I would have to dig, but I do recall a study sometime later finding that almost all of these customers were just using them as servlet containers. It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
> I made the same arguments then, and I will stand by this evaluation now.
To whom? This particular business? 999 out of 1000 businesses (each of whose needs you evaluated and found only one of whom really needed Oracle and therefore excluded)?
What was the argument? That they could do it cheaper by hiring (possibly then non-existent) Postgres DBAs and using Postgres instead of Oracle DBAs and spending exorbitant amounts of money on Oracle?
To us, technical people, that argument might sound perfectly reasonable, but to a non-tech executive it might sound cuckoo-bananas crazy.
> It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
This strikes me as a dismissive stereotype. As you admit, it's not as if they made a choice that failed to function at all. Social proof is a thing. They merely paid a very high price.
Where were all the people who did have an idea of what to do, those 20 years ago? Busy trying to educate them, or separate them from their money? How about you?
Me? 20 years ago I was busy building ROLAP engines that ran cross-RDBMS, because the customer had already decided to blow a million bucks on Teradata et al before I even got there.
I'm not quite sure what your point is. It's all understandable because nontechnical people were making technical decisions? That doesn't make it ok.
And yes, quite a lot of those overpriced appserver installs failed to function. Let me tell you about the time I wrote the backend for Sprite's Sublymonal campaign; their IBM-operated datacenter couldn't provision WebSphere capacity in time (lead time > 2 months), so I ran the thing off a couple VPS nodes (IIRC rackspace), hiding the whole project from their IT staff.
My point is also that making sweeping, moralizing statements like "doesn't make it ok" (nor the repeated forays into other enterpise software topics) isn't helpful in general, and it certainly isn't helpful in furthering understanding or intellectual curiosity on the specific topic, as it relates to Oracle and a single, generalist (arguably "full-stack") engineer performing a sustaining and development role.
Errr... the cost value of Oracle database is skewed. It simply costs sooo much it's impractical for most companies to use, especially if they cannot afford more then 1 decent engineer.
We are talking about 10000s of dollars per CORE (not even per cpu).
Also for that matter, I've never met a company that uses oracle features that aren't available in Postgres or can be made with MySQL and another service such as Redis or ElasticSearch.
It also impractical to maintain without a dedicated DBA.
Which usually means that if a company uses OracleDB they are loaded with money.
> > I've never met a company that uses oracle features that aren't available in Postgres
> I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
As somebody working on PostgreSQL full time, I very much agree on that. Neither today nor back in the 9i days has PostgreSQL implemented everything Oracle provides. Nor the reverse, for that matter. And I'm not just talking about features nobody uses.
> > It also impractical to maintain without a dedicated DBA.
> That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I do think it's easier to operate several databases, including PG, without a dedicated DBA in comparison to Oracle. Obviously it's entirely possible for both.
Today's prices. 10s of thousands it is still whether you get it at retail price (which is unlikely) or if you amortize it for several years (including yearly support of course).
An actual small user is still likely to pay 10s of thousands of dollars a year.
> I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
Can you provide me with such a feature that Oracle has but Postgres doesn't and is in demand?
Oracle db is a masterpiece and has the best performance of any database I'm aware of , sometimes several times more if properly configured. That was it's big selling point in days of vertical scaling - the hardware was often a lot more expensive then oracle's licensing.
Why are you bringing up a version from 2001? Was that mentioned in parent posts?
> Businesses whose core competency isn't tech and/or who aren't located in a tech hub aren't likely even to consider the "make" option.
Business without tech as a core competency outsource.
> That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I suppose you could run an oracle DB with no or little DBA support. But the companies I know who use it use features that require constant DBA support - replication being the biggest one.
> Why are you bringing up a version from 2001? Was that mentioned in parent posts?
Yes, Oracle 9i was specifically mentioned, which is why I find it bizarre, if not inappropriate, to criticize (let alone laugh, as an upthread commenter did), with not just "20/20 hindsight" but also with today's technology availability.
> Business without tech as a core competency outsource.
That's just a synonym for "buy" in the "buy vs build" decision, whereas "make" is a synonym for "build".
Yes Oracle 11g XE is free although you are stuck a version behind the latest 12c release. You get a lot of stuff in there although you are limited on db size as well. You do get apex which you can use to build web apps easily and all your pl/sql will work but there are some limitations around Java in the database and anything that relies on that. It's definitely worth a go, but if you are starting from scratch Postgres is probably more appealing now.
It's historical reasons. They use Oracle 9i with 15-year old software and they don't have budget to upgrade, so, I guess, they'll use it for another 15 years. Actually it works well for its age. I'd say that PostgreSQL would as well and I'd choose it any day if I have to pay for it. But I have to work with what I've got.
5 people, me as a developer, another guy as a mostly database stuff (he knows Java and sometimes helps me, but prefers to work with database-related tasks), 2 kind of management guys to work with papers, money, documents and all that stuff and recently we hired one young guy to help with boring stuff (something like first line technical support).
The first time I touched HTML I was ~19 years ago for my middleschool's technology class, where we were to implement a very simple (and ugly) webpage.
Later, in highschool, the first real programming language I learned was Java, and I did some personal projects with that on my own.
After graduating college without any marketable skills in the height of the recession, my sister (a SWE) introduced me to Python and then JavaScript. I weighed my options and found that going into front-end development would be ideal for me; I had an eye for design and it was simple enough to begin. I learned JavaScript through-and-through, but contemporaneously I learned backend web-development (via Python, Django and Flask). When an opportunity at work opened up, I transitioned to doing backend development (of which I was already familiar from personal projects).
Having done both, I do not see why they are mutually exclusive. I think the issue is that most people who call themselves full-stack engineers do not actually fit the description; it sounds like a good thing to label oneself. I see this often with bootcamp grads who know JavaScript only, and can run their code with Node, so they believe that they are now backend developers.
To learn the backend, I built from scratch:
* a simple (and crappy) ORM
* a simple (and crappy) db-backed session system
* a simple form-generator (similar to Django forms, for flask)
* login / user handling (etc)
To learn the frontend, I built a simple single-page-application, using vanilla JavaScript.
I have worked for years doing both backend and frontend development (JS visualizations for SVG/canvas, data-heavy SPAs, backend APIs, Golang services to process data, work with AWS, docker, etc), and I doubt that I am unique. Full-stack developers do exist, though of course one only has so much time and "jack of all trades, master of none" will apply to many.
Many of these new-bootcamp grads build a simple Node web-app without realizing many of the problems (and solutions) inherent in the backend and label themselves full-stack. That's the problem; not that the frontend is somehow too difficult to master, or that the backend is somehow out of reach.
The misunderstanding the author makes is that a Full Stack Engineer is a specialist in all roles. They're not. They're simply Intermediate to Senior in most.
I'd defer to a specialist in essentially every field, but if you require a broad range of work to be done without hiring a half-dozen people, I'm who you're looking for. The best title we have got that kind of experience is Full Stack.
(It's also a well-understood recruiting buzzword you can use to quickly indicate the work you want and the salary you expect.)
198 comments
[ 2.9 ms ] story [ 234 ms ] threadI blogged this with the point of view of a full-stack developer that can do front-end development, but rather didn't a while ago: https://coderbyheart.com/the-full-stack-developer-trap/
My boss at my last job had done the opposite. Coming from a tradtional compsci C/C++ background (many moons ago), he learnt Angular 2 for a frontend project that required it. Both his C++ and frontend code were among the best at our company.
Saying there aren't good fullstack engineers is like saying multi-instrumentalists aren't good musicians. Sure, the very very best violinists probably don't play other instruments at a high level. But the average multi-instrumentalist (who plays the violin) is a lot better than the average violinist.
What actually is your point? Reading between the lines, it seems to be:
"Anyone who calls themselves a full-stack developer is garbage - it's just a matter of what side your garbage is on."
It seems that the world clearly lacks a definition of what Full-Stack Engineering really means ...
In my spare time I also had to create some new admin screens and do a bunch of back end work. I also created a bunch of new svg images for the admin screens.
Basically I'm expected to do everything from setting up and managing linux servers, security, install and configure software, set up oracle and postgres databases, do DDL and DML work, write server-side code, write web services, create images and do layout work, write test cases, write html, js, css, and know a bunch of JS libraries like vue, vuex, vue-router, webpack, jest, bluebird, lodash, async, tailwind, scss, etc. ad naseum.
I consider myself a “full-stack” programming language engineer because I’m equally comfortable with type theory, user experience design, practical implementation, and instruction-level optimisation. Am I a full-stack web developer because I’m equally comfortable with front-end design & development, server-side infrastructure, and networking protocols?
Some would say yes, some no—but I can readily develop, maintain, and optimise a whole application by myself if I need to. I may not do as good a job in any particular narrow area as a specialist in that area, of course.
Ah yes, I love cleaning up the mess every "architect" I've ever worked under has left on the front-end. Front end development is an arcane art, full of a million gotchas that have nothing to do with intuition, intelligence, or programming skill. It's just years and years of running into stupid mistakes and API quirks to build that domain knowledge. Anyone who doesn't respect and accept that is sorely mistaken.
I like coding and I definitely find programming enjoyable. But, importantly, I don't write software for the hell of it. If you actually give a damn about software development, I don't understand how you could simply dismiss one side of software development due to where it gets executed in the stack.
You've spent enough time designing software that you can take a vague spec, design a solution avoiding common pitfalls and following a very easy path. Then you hand back a prototype followed by a complete and maintainable solution to a happy client.
At that point, your services should no longer be _required_ to keep the product working.
Of course, it's software. We can change anything!
Even better, I'm not busy trying to keep your current software working - so I can get right on it.
Junior - Needs close supervision. Can't reliably develop something more than 1k lines.
Mid level - Has learned to follow a design consistently. Doesn't keep an eye on the bigger picture. Likely to fall apart around 10k lines.
Senior - Can work in the weeds and keep an eye on the business as a whole at the same time. In my experience is likely to be able to design something that can scale to 100+k lines.
And yes, I know about "font loading, images, SVGs, animations, auditing third party scripts". Still sometimes, you have to dig deeper in the stack to find the low hanging fruit that will make the difference between meeting requirements or not.
After throwing away the nice SVGs and replacing them by inline PNG (uglier, but you need that 15% size difference and the precious milliseconds), what do you do?
My current solution is a combination of various things - the last element being VPS close to the customers to provide resources with a very low latency.
(and by the way, if anyone happens to know reliable VPS companies in South America, Japan, South Africa, I would love some recommendations. I only know about Hetzner ZA and Linode JP. I would love to find some good host quality around Uruguay or Brasil)
Sure, if you're a Fortune 500 company, go ahead and hire a DBA, Cloud Architect, Backend Engineer, UI/UX Designer, Graphic Artist, Social Media Marketer, etc.
You'll have a few million $ in salary overhead. It may take longer to produce a final product.
BUT, it will probably be way better than a product that a full stack developer knocks out.
BUT, if you're a startup or SMB or lean department and have a 100k budget and a 6 week deadline a full stack developer is a huge asset to your company.
Obviously when you take the same project and give it to a highly specialized team of people with lots of time they produce superior results. Do we really need an article about it?
PS. Giving a 10 person team a 1,000 hour time budget would not be a huge deal. Try not laughing when a single Full Stack developer asks for 1,000 hours.
The key thing to understand is that while the overall variance will be small, you don't know what the multiplier will be. For teams that you are familiar with, technology that you are familiar with, etc, etc, in my experience people do tend to come out with about the same overall multiplier. Different teams are vastly different, though. I've had teams that operated anywhere from 0.5x (i.e. they overestimated by a factor of 2) to 4.0x (i.e. they underestimated by a factor of 4). It's always best to keep measuring your team's performance to figure out what the best multiplier to use (this is what's known as "load average" in some "agile" systems -- the inverse is "velocity"). Care must be taken to dissuade people from trying to optimise the load average/velocity because it will undermine your estimations -- usually I don't tell people what it is.
Now the other scenario is also fascinating, but requires much less statistics to understand well. Basically this is when the stake holder constantly inserts urgent requests, or cancels tasks mid-development because they thought of something better. Or when your team sits around for 5 days arguing about whether to indent with spaces or tabs. Or upper management decides to "accelerate" the process by constantly inserting new members into the team. Or someone intentionally tries to sabotage your project because they have a "competing" project in the company (or possibly just because they see you as a threat to their eventually triumphant march to the heights of the org chart). Or your lead developer decides that today is the day to institute a national "bring a firearm to work" day. In those cases your schedule is fiction, no matter what process you used to create it.
BTW, all of those things have happened on teams I was on in my career :-). Incidentally, not having a firing pin in a weapon is not considered evidence that it was "just a joke", strangely enough...
Even more interesting (and I was thinking about this only 5 minutes ago), there are models for defect discovery rates. This basically means that when we write code we make software errors. The amount of time it takes before we discover the error is a random variable with a particular distribution. There are several models which try to allow you to determine how long it will take before you find 90% of the errors, for instance. I was just thinking that I bet the model for errors in requirements is probably very similar to the model for software errors and you can probably fairly easily model how long it will take you before you discover 90% of the remaining functionality that you need after you make the initial plan. Indeed, I've measured in a few groups I've worked on that for those groups they needed another 30% of the overall project time to complete tasks that were not anticipated at the start. Unfortunately I no longer have access to that data so I can' look at it in more detail.
(NB: 30% was just for those teams and those projects -- I don't for a second believe that the number is universal. The fact that it was similar for a few teams is probably coincidental.)
Few people says one person can't do it all. Few people say that nobody can do it. But we specialize in areas for a reason. It takes a lot to be an expect in an area, and multiple that by three and its even more work and time.
So sure, one person can do it all. Sure, one person can do it all well. But the later is much rarer than the former. And have specialized people for each area who can focus exclusively on their area is better.
It seems that the real approach of this article should have been to outline why hiring ONLY full-stack engineers may not be a good idea.
I work on the entire stack. Can I work with databases and write queries? Sure. Can I do it as well as a data architect? No. That's not what's expected of a full stack engineer.
We can have meaningful, productive discussions with everyone on all parts of the stack. We'll talk with the data architect, write/tweak a query if we need to, we'll talk with the product manager and collect some features, we'll communicate the requirements to a backend engineer if one exists and help prepare the API as necessary to ensure the frontend can query for only what it needs when it needs it, and we'll connect it to the frontend which we built (yes, even using data chunking, semantic UI, and accessibility, all of which are expected in professional front-end development)
To the purist engineer, none of this is part of their reality because the purist doesn't have business requirements or tradeoffs. In the real world of business, these skills generate profit and are especially useful with new products and prototypes. If you're experienced enough and have a great team with you, you can execute on this with minimal technical debt that doesn't create long-term problems while still providing users with a great experience.
A purist would cringe. I cringed a bit too. But the end result matters the most.
Like you, I would have thought SVGs would be smaller, but experimentation proved that they weren't. It hadn't be checked before, but new options had to be found around the whole stack!
So instead of the crispy SVG that scaled so well, now there are some custom-sized PNG instead - served by geographically close VPS. It seems very dirty on paper, but in practice it works much better than the previous solution that as I purist I found very cute and clever. Unfortunately, it didn't achieve the goals and had to be discarded.
I find that a funny example that illustrates how full-stack engineering is very real.
General guidance:
* Photo - Use JPG, WebP or similar
* Images used at a single predefined size, where quality matters, e.g. logos - Use PNG
* UI graphics that are displayed at integer multiples of the base size, eg 24, 48, 72 - Use SVG
* Illustration graphics - investigate trade-offs between size and quality for both SVG and PNG
Had this issue about 5 years ago. Good SVGs need to go through a manual code filtering step.
On the integer coordinates side of things, if an SVG has horizontal or vertical lines, I’ll always make sure they’re well-aligned before putting them into a UI.
As you grow, companies can and do hire specialists who do one thing and one thing well which is great. But those things still need to be communicated and coordinated with other teams which is why having someone with multiple skill sets to bridge that communication gap is so important even in larger organizations.
Its EXPECTED however that one not have all the answers.
In my experience, across general app development there are 4 specializations, and any given engineer should be able to straddle 2 of them.
Client Infrastructure | Client Product | Backend Product | Backend Infrastructure
Full stack generally stays to the product side of both. They tend to have a relatively shallow context on the current goings on of infrastructure/tooling, but can focus on one area or another when the time calls.
> across general app development there are 4 specializations, and any given engineer should be able to straddle 2 of them.
> Client Infrastructure | Client Product | Backend Product | Backend Infrastructure
I would cluster skillsets into: ops, development, and design.
Ops: making things highly available, logging, performance monitoring, reliability, deployment scripts
Development: Writing code on both frontend and backend.
Design: Visual design and CSS/HTML
Most developers I've interacted with at various companies write both APIs in the backend and user facing UI. In my experience it's becoming increasingly rare that a frontend developer doesn't also write backend code.
They typically aren't very good at making their apps deployable and highly available, and they also aren't very good at making things look good with CSS. Sure they can do it, but it isn't their specialty and it would be quite a learning curve or it just takes them much longer than someone who does just that.
When hiring people, I like to find people who are strong individually in those 3 areas (ops, programming, design). I don't try to find programmers who can do ops or design. I don't worry so much about a frontend engineer being able to do backend work and vice versa, the crossover is generally smooth and interchangeable.
It is generally easy to find ops, and programmers who specialize and are talented. Designers who can do visual design and code it up are a bit rarer, so sometimes it is needed have 1 person do design and another person code it up.
Also, a very senior person is obviously going to be stronger in each of those areas, so full stack is highly correlated with working experience.
A very senior backend person will probably know many things about ops and frontend, but probably not about design.
A very senior frontend person will probably know a lot about design, UX and have a good enough experience with backend, but is probably not going to implement good ops practices.
I'd separate the client side scripting and styling / layouts, actually. While JS and JS frameworks are fun and enjoyable to work with, and I can architect the JS stuff well to make maintainable code bases, CSS is still a mess for me. Though getting better at that as well. Flex-box and CSS Grid changes the game completely from using floats to do layouts.
Honestly, even when it is the same person doing both, I feel like it is best practice to do these activities separately anyway. As in, literally on a different day, with a different mindset.
If you design an application's looks and UX according to how the code 'should' work, particularly backend code (DB queries and endpoints etc) you'll most of the time end up with something that's suboptimal for the user without being able to see it - because you have this very detailed mental model of the system behind the curtain and it's 'obvious' that things should work in this way or that in strict accordance with how that system is organised - whereas the user knows / cares nothing about these things and wants things organised in a way that's more intuitive to them.
That is highly variable. In a world where a lot of middle management considers "tech people" fungible, this is EXACTLY what is expected from a full stack engineer.
And, you get to do the work of front end, back end, and database developers all at once for the price of 1 person. What's not to love?
Only partially "/s", because although I'm not in that kind of position at the moment, I've seen it.
I disagree mostly. I’m pretty full stack from UI down to circuit design, but that’s after almost 20y in the business.
To fully prove my point, here is a quote... also written by me. Huh?
Is that supposed to be convincing? Odd assumptions here. Like that guy on FB that always likes his own links.
At least I get paid lots of money.
A full-stack engineer is not always going to write the best front-end ever; there may be some kludgey stying and some non-semantic HTML (divs and spans!). As a non-DBA, queries may not have optimal execution paths. There may be questionable backend design decisions.
This is an obvious conclusion and does not really speak to the value that a developer brings to an organization. Development is a means to an end, and there are plenty of business cases that an experienced full stack developer can solve in a 'good enough' manner.
We run the risk of letting the perfect become the enemy of the good. Any mature developer should have one or two areas of deep expertise and have enough skill in other domains to get a job done.
Internal software usually doesn't have to be as aesthetic on the front-end (UI) such that you can maybe sacrifice there, for example.
Sometimes you can throw hardware at poor performance if performance tuning is not a person's forte, but sluggishness may snag you at a bad time before you have time to upgrade to a more powerful box(es).
Why? Because you believe the former causes the latter?
There are many valid criticisms to be levied against Oracle the company, enteprise software in general, and especially its pricing.
However, it's important to remember that, for many businesses, it's either impractical or downright impossible to hire enough engineers to make up for to lost features of replacing Oracle with even somethig as relatively feature-dense as PostgreSQL.
I personally know a "such a small development team" (i.e. a single person) who certainly has the expertise, by virtue of having trained to become an Oracle DBA after a fairly extensive career as a software engineer.
As for need, I'm no expert on Oracle's unique features, but the GP specifically mentioned "reverse-engineering stored procedures", which implies at least previous developers thought there was a need to use an arguably advanced database feature.
In fact, even just having a substantial quantity of stored procedures written in PL/SQL, perhaps at a time when that company had (or contracted out to) a larger development team may make it prohibitive to switch to any other language. Reliably implementing business logic as-is is a pretty big feature.
I would have granted you this if you'd said "for a few specialized businesses", but you're waaay overselling it. 99.9% of businesses using Oracle would do just fine with a "lesser database".
And I would grant you that if you could make the credible argument that a "lesser" [1] database could be a suitable replacement on a drop-in basis, without significant engineering effort.
As I pointed out in a downthread comment, a very useful feature is that existing stored procedure that encode business logic already work.
Are you really saying that only 0.1% of business database users fall into even that category? My second-hand (DBA I know) experience contradicts this, but if you have a better source, I'm certainly interested.
[1] I don't actually intend to make any overall value judgment, since my point isn't that Oracle has feature/performance superiority over any other database. Instead, I'm saying that it has specific features that the business needed at the time it was chosen that may not be offered by a different one.
But Oracle doesn't sell their product with the pitch "hahaha too bad you're stuck with us". They try to convince the next generation of ill-informed technology leaders that it would be a mistake to choose anything else. I've heard the pitch, and by the third time I heard "invest in Oracle RAC" I was consciously suppressing the urge to punch the salesman.
I'm saying that 99.9% of Oracle customers would have been significantly better off from a cost, flexibility, and support perspective going with an alternative like Postgres when they started building their product. And most of the remaining 0.1% would have been better off with MSSQL.
Although I agree that some huge proportion [1] of businesses today would do very well to seriously consider Postgres as the first option before even looking at Oracle, I don't recall this being true 17 [2] or even 10 years ago.
Remember, we're likely talking about non-tech businesses here, ones where they're sustaining operations with a single developer. You mention "ill-informed technology leaders" but it's hard to imagine there are any technology leaders actually involved on the buyer's side.
I don't think it's helpful to look back at such a decision through the lens of today's technologies and the kind of talent/expertise that is, today, available to a business whose core competency is tech.
I'm no fan of "enterprise" anything, so don't mistake my critique as cheerleading Oracle. I just feel the context of technology decisions is paramount. It also seems especially germane to the overall thread topic, which is whether a generalist can possibly have enough depth in key areas to be considered competent enough in them.
[1] your repeatedly asserted claim of 99.9% is extraordinary, requiring extraordinary evidence.
[2] Oracle 9i was released in 2001. EnterpriseDB wasn't founded until 2004.
It reminds me of the early 2000s when IBM and WebLogic were selling 5-figure appserver licenses hand-over-fist into enterprises. I would have to dig, but I do recall a study sometime later finding that almost all of these customers were just using them as servlet containers. It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
To whom? This particular business? 999 out of 1000 businesses (each of whose needs you evaluated and found only one of whom really needed Oracle and therefore excluded)?
What was the argument? That they could do it cheaper by hiring (possibly then non-existent) Postgres DBAs and using Postgres instead of Oracle DBAs and spending exorbitant amounts of money on Oracle?
To us, technical people, that argument might sound perfectly reasonable, but to a non-tech executive it might sound cuckoo-bananas crazy.
> It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
This strikes me as a dismissive stereotype. As you admit, it's not as if they made a choice that failed to function at all. Social proof is a thing. They merely paid a very high price.
Where were all the people who did have an idea of what to do, those 20 years ago? Busy trying to educate them, or separate them from their money? How about you?
I'm not quite sure what your point is. It's all understandable because nontechnical people were making technical decisions? That doesn't make it ok.
And yes, quite a lot of those overpriced appserver installs failed to function. Let me tell you about the time I wrote the backend for Sprite's Sublymonal campaign; their IBM-operated datacenter couldn't provision WebSphere capacity in time (lead time > 2 months), so I ran the thing off a couple VPS nodes (IIRC rackspace), hiding the whole project from their IT staff.
My point is also that making sweeping, moralizing statements like "doesn't make it ok" (nor the repeated forays into other enterpise software topics) isn't helpful in general, and it certainly isn't helpful in furthering understanding or intellectual curiosity on the specific topic, as it relates to Oracle and a single, generalist (arguably "full-stack") engineer performing a sustaining and development role.
We are talking about 10000s of dollars per CORE (not even per cpu).
Also for that matter, I've never met a company that uses oracle features that aren't available in Postgres or can be made with MySQL and another service such as Redis or ElasticSearch.
It also impractical to maintain without a dedicated DBA.
Which usually means that if a company uses OracleDB they are loaded with money.
Amortized over what period of time, though? Is that today's price, or 17 years ago? Is that list price or the price an actual small user would pay?
> I've never met a company that uses oracle features that aren't available in Postgres
I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
> can be made with
Businesses whose core competency isn't tech and/or who aren't located in a tech hub aren't likely even to consider the "make" option.
> It also impractical to maintain without a dedicated DBA.
That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I suspect there's another growth/tech-centric bias at work in this assertion.
All that said, I'm not a proponent of Oracle (or enterprise software in general), but I am a proponent of fact-based discussions.
> I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
As somebody working on PostgreSQL full time, I very much agree on that. Neither today nor back in the 9i days has PostgreSQL implemented everything Oracle provides. Nor the reverse, for that matter. And I'm not just talking about features nobody uses.
> > It also impractical to maintain without a dedicated DBA.
> That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I do think it's easier to operate several databases, including PG, without a dedicated DBA in comparison to Oracle. Obviously it's entirely possible for both.
http://www.oracle.com/us/corporate/pricing/technology-price-...
Today's prices. 10s of thousands it is still whether you get it at retail price (which is unlikely) or if you amortize it for several years (including yearly support of course).
An actual small user is still likely to pay 10s of thousands of dollars a year.
> I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
Can you provide me with such a feature that Oracle has but Postgres doesn't and is in demand?
Oracle db is a masterpiece and has the best performance of any database I'm aware of , sometimes several times more if properly configured. That was it's big selling point in days of vertical scaling - the hardware was often a lot more expensive then oracle's licensing.
Why are you bringing up a version from 2001? Was that mentioned in parent posts?
> Businesses whose core competency isn't tech and/or who aren't located in a tech hub aren't likely even to consider the "make" option.
Business without tech as a core competency outsource.
> That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I suppose you could run an oracle DB with no or little DBA support. But the companies I know who use it use features that require constant DBA support - replication being the biggest one.
Perhaps not relevant, then.
> Why are you bringing up a version from 2001? Was that mentioned in parent posts?
Yes, Oracle 9i was specifically mentioned, which is why I find it bizarre, if not inappropriate, to criticize (let alone laugh, as an upthread commenter did), with not just "20/20 hindsight" but also with today's technology availability.
> Business without tech as a core competency outsource.
That's just a synonym for "buy" in the "buy vs build" decision, whereas "make" is a synonym for "build".
> writing brute-forcer to crack P12 private key because someone forgot password
LOL
Later, in highschool, the first real programming language I learned was Java, and I did some personal projects with that on my own.
After graduating college without any marketable skills in the height of the recession, my sister (a SWE) introduced me to Python and then JavaScript. I weighed my options and found that going into front-end development would be ideal for me; I had an eye for design and it was simple enough to begin. I learned JavaScript through-and-through, but contemporaneously I learned backend web-development (via Python, Django and Flask). When an opportunity at work opened up, I transitioned to doing backend development (of which I was already familiar from personal projects).
Having done both, I do not see why they are mutually exclusive. I think the issue is that most people who call themselves full-stack engineers do not actually fit the description; it sounds like a good thing to label oneself. I see this often with bootcamp grads who know JavaScript only, and can run their code with Node, so they believe that they are now backend developers.
To learn the backend, I built from scratch: * a simple (and crappy) ORM * a simple (and crappy) db-backed session system * a simple form-generator (similar to Django forms, for flask) * login / user handling (etc)
To learn the frontend, I built a simple single-page-application, using vanilla JavaScript.
I have worked for years doing both backend and frontend development (JS visualizations for SVG/canvas, data-heavy SPAs, backend APIs, Golang services to process data, work with AWS, docker, etc), and I doubt that I am unique. Full-stack developers do exist, though of course one only has so much time and "jack of all trades, master of none" will apply to many.
Many of these new-bootcamp grads build a simple Node web-app without realizing many of the problems (and solutions) inherent in the backend and label themselves full-stack. That's the problem; not that the frontend is somehow too difficult to master, or that the backend is somehow out of reach.
I'd defer to a specialist in essentially every field, but if you require a broad range of work to be done without hiring a half-dozen people, I'm who you're looking for. The best title we have got that kind of experience is Full Stack.
(It's also a well-understood recruiting buzzword you can use to quickly indicate the work you want and the salary you expect.)
The guy talked about having beautiful SCSS. At some point, you are talking about design and less about engineering.
Full stack is a job to be taken on by a small team. Having a large team with lots of full stack makes 0 sense.