|
Virigoth posted:That is why you make your culture and pipeline robust enough that your devs ARE the team on-call for their individual services and if they want to deploy over Christmas they can but they are responding to the pages. Our UI team decided to not deploy over the holidays but I saw a couple deploys going to Prod on Friday in our system. Code freeze is a relic from waterfall that needs to die. As the dev oncall over Christmas I'm really glad we have a company wide holiday freeze because I'm not the only dev on the team and I don't want to spend Christmas debugging someone else's gently caress up and also because our service has dependencies on other teams and I don't want to get paged over their gently caress ups either
|
#
?
Dec 23, 2018 16:13
|
|
|
|
| # ? May 23, 2024 12:05 |
|
|
It still weirds me out to look at the Scala Center meeting minutes. Scala Center is the organisation behind the Scala programming language and they make Scala Center Proposals (SCPs), and they are numbered like SCP-001, SCP-019 and so on. https://scala.epfl.ch/minutes/2018/12/05/december-5-2018.html Keeps reminding me of the other SCPs.
|
|
#
?
Dec 24, 2018 11:14
|
|
|
scala's kinda like an SCP so that makes sense
|
|
#
?
Dec 24, 2018 15:36
|
|
|
Gildiss posted:I'm not sure there is a process that can fix most of the tech department being on vacation for the better part of a month this time of year. Boiled Water posted:This doesn't help if the person in charge of managing what you spend time on is a piece of poo poo. Vulture Culture fucked around with this message at 16:09 on Dec 24, 2018 |
|
#
?
Dec 24, 2018 16:03
|
|
|
Vulture Culture posted:I can come up with a very simple and highly unpopular one without thinking very hard about it
|
|
#
?
Dec 24, 2018 16:05
|
|
|
Vanadium posted:Do you want your tech department out of the office for the rest of the year, or do you want your tech department out of your office indefinitely next year?
|
|
#
?
Dec 24, 2018 16:10
|
|
|
Vulture Culture posted:If you're an engineer who's good at what you do, there's a good chance you're more important to the company than your boss is. Start fights over whatever you've got to do to move the company ahead. Nothing gets better without lighting a fire under a bad boss's rear end to get their poo poo together or get out of the organization. I wouldn't go so far as to say you should start fights but 2 way communication is important for organizations. Managers aren't mind readers and they only know as much as you tell them. If something is truly bad and you have the leeway to speak up and try to do something about it, talk to the PM/PO/whoever and help them to understand what is bad and the compromises that will have to be made to make it better.
|
|
#
?
Dec 24, 2018 16:44
|
|
|
Blinkz0rz posted:I wouldn't go so far as to say you should start fights but 2 way communication is important for organizations. Managers aren't mind readers and they only know as much as you tell them. If something is truly bad and you have the leeway to speak up and try to do something about it, talk to the PM/PO/whoever and help them to understand what is bad and the compromises that will have to be made to make it better. There are bad bosses, though, ones who want authority for its own sake and do nothing for the good of either their company or their directs. Those are the people who you, if you care about the organization, should shoulder-check until one of you is out of the organization. In most organizations, PMs/POs are powerless and often live outside any org structure that matters to you existentially, often belonging to PMOs or marketing departments. Play the Game of Thrones. Make friends with your boss's peers, ingratiate yourself, get owed favors. Do you know how hard it is to fire someone when there are half a dozen people with your boss's boss's ear saying "definitely don't fire this person because I need them"? It's a bad look.
|
|
#
?
Dec 24, 2018 19:30
|
|
|
I just want to write some loving code, go take your poo poo politics elsewhere. Yes, I have had many jobs and employers, why do you ask?
|
|
#
?
Dec 24, 2018 20:41
|
|
|
Making software is a collaborative activity.
|
|
#
?
Dec 24, 2018 22:07
|
|
|
Bongo Bill posted:Making software is a collaborative activity. Collaboration shouldn’t have to involve mandatory office politics
|
|
#
?
Dec 25, 2018 01:17
|
|
|
Office politics at my current workplace involves the two teams bickering over how to accomplish something, a bunch of do-nothing upper-management types interjecting themselves into the bickering process, then no decision ever being made because "we don't want to pick favorites, can't you guys just figure it out?" At this point I just do whatever will lead to the least amount of code being rewritten when they inevitably come up with a terrible compromise decision no one wants a few weeks from the deadline.
|
|
#
?
Dec 25, 2018 03:18
|
|
|
Politics is when people are doing things that are in their own best interest at the expense of the company's interests. Sometimes that's a manager taking credit for their team's work, or a director usurping a key project from a peer, or someone micromanaging because it makes them feel in control or feel superior. Sometimes it's someone keeping their mouth shut because it's so much safer or more comfortable than speaking up and doing the right thing. People should be striving to reduce politics. But there's a point where shutting up and doing what you're told so you can produce value for an rear end in a top hat boss is the same thing as buying beer for an alcoholic. Vulture Culture fucked around with this message at 03:35 on Dec 26, 2018 |
|
#
?
Dec 26, 2018 03:32
|
|
|
Politics is what happens whenever there are multiple people involved in something and their interests don't exactly align. What's in the company's interest is a bit of red herring, because people always act to benefit themselves (the famous principal-agent problem).
|
|
#
?
Dec 26, 2018 04:34
|
|
|
ultrafilter posted:Politics is what happens whenever there are multiple people involved in something and their interests don't exactly align. What's in the company's interest is a bit of red herring, because people always act to benefit themselves (the famous principal-agent problem). People don't always act in their own interest. If people always act in their own interest, where do fat goons come from? I guess you could say that people will always act on their desires, but even then I can think of a couple of examples from this forum where people seem to be actively trying to ruin an activity that they presumably enjoy (because they're participating in it). To tie this back to development, when I see a change that would make for a better user experience I'll argue for it even if it means more work for me. I think all good developers would. Good companies/bosses have systems that encourage employee feedback. Great ones actually act on that feedback to reduce pain points and improve productivity. Bad ones have no systems. Terrible ones have systems that solicit feedback but then act in the opposite direction and/or move to punish people who give negative feedback. It took working at a bad company to give me the perspective to recognize how good some of the other places I've worked were.
|
|
#
?
Dec 26, 2018 18:18
|
|
|
I guess Instagram doesn’t have a holiday freeze because they accidentally deployed a new UI to all their users yesterday, by screwing up the feature flag.
|
|
#
?
Dec 28, 2018 14:27
|
|
|
smackfu posted:I guess Instagram doesn’t have a holiday freeze because they accidentally deployed a new UI to all their users yesterday, by screwing up the feature flag. Indians don't celebrate Christmas. Why India? Because it caused a fuckup.
|
|
#
?
Dec 28, 2018 15:38
|
|
|
Keetron posted:Indians don't celebrate Christmas. Why India? Because it caused a fuckup. if I had a nickel for every time offshore was like "yeah, we're taking friday off" because of some random indian holiday, I'd get an additional buck a year. they also take our holidays off as well at my company and i think stuff like this is probably why.
|
|
#
?
Dec 28, 2018 19:21
|
|
|
I thought this was an incredibly refreshing blog to read, Dan Abramov, engineer for React talking about gaps in his knowledge though lots of people presumes he knows this kind of stuff: https://overreacted.io/things-i-dont-know-as-of-2018 they still managed to find some people who want to give him flak for it on hacker news ofc
|
|
#
?
Dec 30, 2018 03:31
|
|
|
Murrah posted:I thought this was an incredibly refreshing blog to read, Dan Abramov, engineer for React talking about gaps in his knowledge though lots of people presumes he knows this kind of stuff: https://overreacted.io/things-i-dont-know-as-of-2018 Heh I reposted this elsewhere and someone immediately started saying about how this explains why React is bad.
|
|
#
?
Dec 30, 2018 09:49
|
|
|
Murrah posted:I thought this was an incredibly refreshing blog to read, Dan Abramov, engineer for React talking about gaps in his knowledge though lots of people presumes he knows this kind of stuff: https://overreacted.io/things-i-dont-know-as-of-2018 quote:Unix commands and Bash. I can ls and cd but I look up everything else. I get the concept of piping but I’ve only used it in simple cases. I don’t know how to use xargs to create complex chains, or how to compose and redirect different output streams. I also never properly learned Bash so I can only write very simple (and often buggy) shell scripts.  Also gently caress HN.
|
|
#
?
Dec 30, 2018 13:10
|
|
|
Pile Of Garbage posted:
|
|
#
?
Dec 30, 2018 14:08
|
|
|
Murrah posted:I thought this was an incredibly refreshing blog to read, Dan Abramov, engineer for React talking about gaps in his knowledge though lots of people presumes he knows this kind of stuff: https://overreacted.io/things-i-dont-know-as-of-2018 I'm a little shocked that the guy writing web frameworks doesn't really know about networking stuff, but I guess if you don't have to work below the level of browser and JavaScript API contracts it's not that crazy.
|
|
#
?
Dec 30, 2018 14:38
|
|
|
Volmarias posted:I'm a little shocked that the guy writing web frameworks doesn't really know about networking stuff, but I guess if you don't have to work below the level of browser and JavaScript API contracts it's not that crazy. I'm currently doing infra-as-code stuff, cloud orchestration and the like, and the lack of network understanding beyond IP subnetting and simple IP routing amongst my colleagues is staggering. I guess they don't really need to understand it as the platform abstracts the majority of it away but poo poo if you're creating a security group in AWS you should at least understand the difference between TCP and UDP... Pile Of Garbage fucked around with this message at 15:01 on Dec 30, 2018 |
|
#
?
Dec 30, 2018 14:47
|
|
|
Pile Of Garbage posted:I'm currently doing infra-as-code stuff, cloud orchestration and the like, and the lack of network understanding beyond IP subnetting and simple IP routing amongst my colleagues is staggering. I guess they don't really need to understand it as the platform abstracts the majority of it away but poo poo if you're creating a security group in AWS you should at least understand the difference between TCP and UDP...
|
|
#
?
Dec 30, 2018 15:57
|
|
|
I just think about having the specialized experience significantly creating something like React would bring. its like COBOL level of job security, there will be payers wanting to maintain React apps for a really, really long time. You could be incredibly discriminating with what work you do to the point that you may never need to learn a bunch of that stuff on that list. To me that is like the ideal position to be in. Makes me a little jealous so I can see why there would be some haters. E: but I also understand frustration with coworkers tasked with networking work they aren't skilled at, etc.that affects the rest of the team. Murrah fucked around with this message at 20:22 on Dec 30, 2018 |
|
#
?
Dec 30, 2018 20:16
|
|
|
Feels like with microservices getting really popular, Networking is starting to compete with SQL as the biggest "developers-know-just-enough-to-do-damage" technology area.
|
|
#
?
Dec 30, 2018 21:24
|
|
|
Che Delilas posted:Feels like with microservices getting really popular, Networking is starting to compete with SQL as the biggest "developers-know-just-enough-to-do-damage" technology area. Well, we used to talk to our connecting systems by composing calls but now we moved to automated clients based on OpenApi2 specs, so networking is a thing of the past. I really don't worry about it anymore, it is great. Another example is a bunch of AWS services we use, it comes with a library so I have no worries about the calls whatsoever and can focus on not loving up the bounded context of whatever it is I am building. What we see and have seen a bunch already are tightly coupled services that are essentially forming a distributed monolith. Getting microservices right is stupid hard.
|
|
#
?
Dec 30, 2018 22:12
|
|
|
A common pattern that causes people to create distributed monoliths is they try to think of microservices like they're OOP classes and objects. You may have services for customers, accounts, and other business objects - this falls apart really fast when everyone needs to access the customer service repeatedly. If everyone needs something to be up forever to do anything, then you need to think hard about whether it should be decoupled.Che Delilas posted:Feels like with microservices getting really popular, Networking is starting to compete with SQL as the biggest "developers-know-just-enough-to-do-damage" technology area.
|
|
#
?
Dec 30, 2018 23:05
|
|
|
necrobobsledder posted:It gets worse when those that do know networking constructs from physical network design don’t learn how their cloud provider works with networking and designs stuff that’s way over complicated or paints you into a hole. At my last gig a coworker went with the approach of creating as small of subnets as necessary for each microservice and wound up with over 450 subnets in a VPC with half the IP space used by broadcast, gateway, and DNS IPs and actual services utilizing maybe 14%. You can mess around with security groups. Recreating entire VPCs and re-IPing them along with a production migration involving some downtime is now a constant theme of my job and it’s beyond frustrating to do networking 101 at my jobs again and again. necrobobsledder posted:A common pattern that causes people to create distributed monoliths is they try to think of microservices like they're OOP classes and objects. You may have services for customers, accounts, and other business objects - this falls apart really fast when everyone needs to access the customer service repeatedly. If everyone needs something to be up forever to do anything, then you need to think hard about whether it should be decoupled. This gets down to the root of microservices—they're expensive to run and deceptively expensive to develop, so you'd better be solving an even more expensive business problem by introducing them. I don't think microservices even touch on the issue of coupling. You can write loosely-coupled monoliths just like you can write tightly-coupled microservices. In the end you've got call graphs, data formats, and transports. In either case you need to treat API stability like a serious business concern, and design for it. Vulture Culture fucked around with this message at 05:33 on Dec 31, 2018 |
|
#
?
Dec 31, 2018 05:12
|
|
|
Vulture Culture posted:I'm bad at both. Is there a compelling reason to carve out subnets besides to use them to make egress routing decisions? Vulture Culture posted:I don't think microservices even touch on the issue of coupling. You can write loosely-coupled monoliths just like you can write tightly-coupled microservices. In the end you've got call graphs, data formats, and transports. In either case you need to treat API stability like a serious business concern, and design for it.
|
|
#
?
Dec 31, 2018 19:25
|
|
|
This feels like a No True Scottsman kind of thing. If loosely coupled, narrowly scoped, domain driven services that depend on other services aren't microservices, then what are?
|
|
#
?
Dec 31, 2018 23:32
|
|
|
The structures that make it possible for microservices to ever be economical can also be applied to monoliths to make their maintenance more tractable for longer.
|
|
#
?
Dec 31, 2018 23:37
|
|
|
No they can’t; not beyond a certain scale.
|
|
#
?
Jan 1, 2019 04:22
|
|
|
Sure they can, provided you accept the presence of a middle ground between one singular giant service and hundreds/thousands of completely orthogonal services. Microservice architectures are a forcing function that puts pressure on developers to modularize code and clearly define the boundaries, technically and organizationally, between different software functions. Nothing about them inherently improves the scalability, architecturally or operationally, of a software project of any size. All the same challenges exist, though microservices help engineering teams very effectively pretend that they don't.
|
|
#
?
Jan 1, 2019 08:28
|
|
|
I disagree. There are clear operational wins to be had at scale by breaking a monolith apart in any circumstance where different logical parts of the monolith have different functional characteristics. For example, a user identity service component which is called very frequently contrasted with some rarely called leaf system; a highly compute intensive component contrasted with an I/O intensive component; a subsystem with a data model best suited to a relational DB contrasted with another using a document store, etc. Isolation has benefits here.
|
|
#
?
Jan 2, 2019 11:36
|
|
|
return0 posted:I disagree. There are clear operational wins to be had at scale by breaking a monolith apart in any circumstance where different logical parts of the monolith have different functional characteristics. For example, a user identity service component which is called very frequently contrasted with some rarely called leaf system; a highly compute intensive component contrasted with an I/O intensive component; a subsystem with a data model best suited to a relational DB contrasted with another using a document store, etc. Isolation has benefits here.
|
|
#
?
Jan 2, 2019 13:34
|
|
|
return0 posted:I disagree. There are clear operational wins to be had at scale by breaking a monolith apart in any circumstance where different logical parts of the monolith have different functional characteristics. For example, a user identity service component which is called very frequently contrasted with some rarely called leaf system; a highly compute intensive component contrasted with an I/O intensive component; a subsystem with a data model best suited to a relational DB contrasted with another using a document store, etc. Isolation has benefits here. clear operational losses to be had at scale by breaking a monolith apart, where you have to put in backpressure, where you have to log the poo poo outta everything to get worse logging than what you have with the monolith and then you gotta monitor the poo poo outta everything to get worse monitoring than what you had then you still have to go traipsing through the zoo of services to find wtf it is that's the root cause of breaking, etc etc
|
|
#
?
Jan 2, 2019 13:39
|
|
|
Vulture Culture posted:I'm not arguing that there are no benefits to using a microservice architecture, especially operationally—running production services is hard and there's lots of compromises required to deliver a great user experience on the backend. I'm arguing against your assertion about non-microservice development models being inherently more of a maintenance burden when a) it hasn't been established whether or how these actually improve modularization in practice and b) nobody even understands how gracefully a 150-microservice business service will transition into a legacy operating mode 15 years down the line. My initial assertion was that the following is false: Bongo Bill posted:The structures that make it possible for microservices to ever be economical can also be applied to monoliths to make their maintenance more tractable for longer. We've established one such 'structure' that can be applied to a microservice architecture that cannot meaningfully be applied to a monolithic architecture; significant divergence in operational requirements by different parts of the system necessitating different hardware or persistence layer implementations. These divergences in operational requirement manifest at large scale (because at small scale anything reasonable works). bob dobbs is dead posted:clear operational losses to be had at scale by breaking a monolith apart, where you have to put in backpressure, where you have to log the poo poo outta everything to get worse logging than what you have with the monolith and then you gotta monitor the poo poo outta everything to get worse monitoring than what you had then you still have to go traipsing through the zoo of services to find wtf it is that's the root cause of breaking, etc etc I mean, don't do it for no reason, but don't pretend there is never a reason.
|
|
#
?
Jan 2, 2019 14:44
|
|
|
|
| # ? May 23, 2024 12:05 |
|
|
Vulture Culture posted:I'm not arguing that there are no benefits to using a microservice architecture, especially operationally—running production services is hard and there's lots of compromises required to deliver a great user experience on the backend. I'm arguing against your assertion about non-microservice development models being inherently more of a maintenance burden when a) it hasn't been established whether or how these actually improve modularization in practice and b) nobody even understands how gracefully a 150-microservice business service will transition into a legacy operating mode 15 years down the line. if you're using google cloud maybe you won't have to support legacy anything, because google drops projects like human beings drop loads
|
|
#
?
Jan 2, 2019 14:46
|
|