Live data from Hacker News

I Don’t Believe in Full-Stack Engineering

robinrendle.com

191–199 of 199 posts

Re: I Don’t Believe in Full-Stack Engineering

#191

Earlier quoted context omitted.

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.)

Re: I Don’t Believe in Full-Stack Engineering

#192
post #12

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…

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".

Re: I Don’t Believe in Full-Stack Engineering

#193
post #136

Earlier quoted context omitted.

> 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…

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 tha…

> 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?

Re: I Don’t Believe in Full-Stack Engineering

#194
post #76

Earlier quoted context omitted.

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/…

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…

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.

Re: I Don’t Believe in Full-Stack Engineering

#195

Earlier quoted context omitted.

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…

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.

Re: I Don’t Believe in Full-Stack Engineering

#196
post #143

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 :)

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.

Re: I Don’t Believe in Full-Stack Engineering

#197
post #193

Earlier quoted context omitted.

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 tha…

> 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 amo…

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.

Re: I Don’t Believe in Full-Stack Engineering

#198
post #193

Earlier quoted context omitted.

> 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 amo…

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 tel…

My point is that overall context matters.

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.

Re: I Don’t Believe in Full-Stack Engineering

#199
post #74
post #23

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…

More than that, we can talk to designers, product people, leads, etc and have a better holistic view of the glue that holds everything together. 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 Infrastructur…

very good mental model for developer activities ..

> 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

Post reply on HN