15 ms·
>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database ad
by blueslurpee 5y ago
>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport.
I find actually the opposite to be true. The leverage of individual engineers is only growing with the advent of SaaS and the proliferation of API's. Then of course there are the stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc.
- hadsed 5y agoi agree. the overhead of teams and external dependencies is often just too high--you're far better off if you can keep things small but mighty
- Oddskar 5y agoWe didn't have APIs 10 years ago? I agree with the article. As we build more complex products we need to be more specialized and work together. Maybe not the case if one is working at a startup trying to cobble something together that looks like a working product by customers and investors.
- pjmlp 5y agoWe had APIs since Sun RPC, they just keep being rebooted. The 2021 version is REST/gRPC for SaaS products.
- Oddskar 5y agoREST? Didn't you get the memo? We've all moved on to GraphQL because Facebook use it and that means we all should use it. It also enables our UI components to easily fetch data themselves. Because that's a great architectural pattern that we've discovered.
- pjmlp 5y agoYeah you're right, silly me.
- theshadowknows 5y agoI was on a call just yesterday about how we should consider moving from one solution to another simply because the new one 'uses graphql which is so much easier and so much more powerful'
- nawgz 5y agoIt's unironically true that GraphQL in combination with database introspection & query tools like Hasura is a far superior pattern to REST-based CRUD. Additionally, as a UI developer, I understand you are trying to make it seem like GraphQL promotes anti-patterns, but being able to make a single query which is deeply nested and therefore can maintain state for an entire sub-tree of your app is a really good state management pattern. Less coupling, separation of concerns, and usually significantly reduced network activity since you just need to keep the GraphQL state aligned, which is actually specified unlike how to sync a REST resource. Do you actually have any experience with this tool?
- handrous 5y agoHasura is great. GraphQL on its own, unless you're offloading all of it to something well-maintained and capable like Hasura which will (hopefully) automagically save you from the time cost and risk of GraphQL, is almost always a bad idea.
- nawgz 5y ago"Using a protocol you don't understand without a tool that implements it is a bad idea" Listen, I get it, we all want to hate on NIH and cutting-edge stuff, but what you've said is not an objection. GraphQL is a complicated protocol, but it offers a very clean interface between clients & servers, and when you put in a strong implementation you can generically access data that before you needed to specifically access. I don't even know what else to say. There's a time cost and risk of every single thing you'll implement, you haven't given any insights into what tips GraphQL into a superbly expensive and risky area... Especially because Hasura is completely free and open-source...
- brabel 5y agoWe can build very complex products today so much more easily than 10 years ago. There are services that will give you everything, from a managed DB to distributed CDN around the world, to one-command deploys... I feel like, if I only knew a business idea that didn't totally suck, I could create a whole new product that could scale to millions of users on a weekend.
- pjmlp 5y agoSomehow it feels like a marketing leaflet for a CORBA/DCOM based product.
- isaacgreyed 5y ago"I could create a whole new product that could scale to millions of users on a weekend." Sounds like an extremely appealing business idea.
- zerkten 5y agoIt's not that we didn't have APIs, but it's the reality that they have penetrated every sector beyond early-to-medium adopters. Even regulated companies are moving to the cloud and using public web services at this point. Ten years ago these companies would have been playing around with these things for sure, but not using them for their core business. This is creating demand for generalists within that huge section of the economy that isn't a top-tier pull for talent because the demands are different. These demands can't sustain frontend devs who could be working at Facebook. Eventually they will need specialized folks, but for now that continues to come from outside consultancies, just like it always has for this set of companies.
- coding123 5y agoYes, this is more accurate. 10 years ago most of the stuff was JSPs / JSFs and other UI+Backends that were fused by it's platform.
- soperj 5y ago>stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc. Are there others? Seems to be a common theme with those 2.
- sillysaurusx 5y agoFound the engineer that needs a project manager. :) I think most devs just haven’t had a good product manager. It can be shockingly effective, but only when they care about you, rather than managing you.
- deviaan 5y agoGoing to echo this sentiment. The project I'm on now is the first time I've worked with a PM that gets whats going on and actually manages the product instead of just sending PMs after hours asking for some "small" feature to be squeezed into the sprint. It makes a HUGE difference, and I can honestly say I'm much less stressed out now than in previous projects.
- lowercased 5y agointeresting. i've cycled through some projects with and without PMs. I've not found 'good' PMs to make a huge difference compared to 'without', but definitely 'bad' PMs impact things negatively. It's hard to define what the 'bad' is, but micromanaging, forcing process where it doesn't need to be, arbitrarily enforcing rules when convenient, etc are all just negative impacts. It would be more beneficial to just not have that person at all. I've had some good PMs, and while I didn't notice much difference in my own performance/delivery/stress/etc, I think it gave some other folks somewhat more confidence/assurance.
- kthejoker2 5y agoAs someone else eloquently put it, "With people management, the ceiling is low, but the floor is lava."
- nonameiguess 5y agoIt specifically says in what you quoted "or with a vendor or service provider." If you're able to get away with only hiring people who don't understand the intricate details of filesystem drivers, overlay networks, and hardware virtualization because you just consume your infrastructure from a cloud provider, you're included in "team sport," where your team includes the cloud provider who hires a whole bunch of people with expertise totally different from your company. WhatsApp didn't stand up its own networks or build its own phones. It stood on the shoulders of giants who knew how to do that.
- blueslurpee 5y agoWell said, I agree with you.
- softfalcon 5y agoI want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engineer" myth seems to live on and prosper in far too many teams I've worked on. Despite how discouraging it is for the rest of us who want to play a "team sport".
- opportune 5y agoHow much of that is because those people aren’t being team players vs them learning things differently? In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does. As such I am not sure those people who know everything are secretly zealously guarding their information. Any brief explanation of something technical is simply too low-res compared to reading its implementation. So even if that person is super nice and tries to help as much as they can, I doubt anybody would learn as much as them just from secondhand information, as opposed to reading/writing/modifying the source themselves.
- riskneutral 5y agoI share my screen and do an initial source code walkthrough of the overall structure of the project / component, and make sure they can build and run the code, before asking a junior team member to read the code themselves and figure the rest out on their own. It's worked really well, in my experience.
- RNCTX 5y ago> In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does. Depends on the shop. The trend is toward people trying to standardize and automate as much of the development process as possible (so that they can get rid of domestic employees who cost to much and fetch it all over to people in exploitable-countries with less valuable currencies). People who ask questions, push less ambitious changes, push buggy stuff that barely squeaks past the unit tests and then go back and improve it later if someone complains.. all of that leaves activity metrics that check boxes on the reports of people who don't care whether devs read and understand the existing code or not.
- blueslurpee 5y agoSome interesting & fruitful replies in here. There is definitely some nuance that deserves to be unpacked. Yes, a well-oiled team with competent leadership and an effective culture can do more than an individual alone. However the premise of their statement is that it used to be more feasible for one person to "do it all", whereas now things have transitioned towards a more team-oriented environment. I observe this trend patently in reverse.
- 908B64B197 5y agoAny article that uses the terms "coders" and "IT" is a red flag to me. I've never seen that terminology inside organizations that are actually capable of shipping software. > Then of course there are the stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc. I'm surprised the author didn't consider these as well. Some of these stories are almost a decade old at this point, they should be well known by now.