|
prom candy posted:In an ideal world: yes. In practice: fart huffing. A company's culture and values aren't determined by what they paid someone to stencil on the wall, it's what they actually choose to do day in and day out. We spent months on my old companies values and I can't remember a single one. What you’re talking about is an in-group. That probably works fine in small companies where everyone knows everyone else and can self-organize around a set of shared values. It’s much harder as you scale a company because all of a sudden there’s no consistent thread of communication; teams silo around functions or locations and suddenly you have a bunch of de facto little companies that have competing values and can’t find a common thread to work off in order to collaborate. Company values are a solution to a problem of scale but as usual it’s been cargo culted to death in the same way agile has.
|
# ¿ Feb 17, 2022 01:52 |
|
|
# ¿ May 20, 2024 14:57 |
|
HappyHippo posted:Presumably they could be donated or given away? MacBooks retain their value for an absurd amount of time. They also work great even after many years. I have a 2013 MacBook Pro as a spare personal machine that can pretty much do anything I can do on my work laptop.
|
# ¿ Feb 24, 2022 01:43 |
|
12 rats tied together posted:That's interesting because I have pretty much the exact opposite opinion, including an opinion where I question why anyone would use terraform for AWS because it is strictly worse than the platform native comparison of CloudFormation, including and especially the documentation. CloudFormation used to be absolute dogshit and I don't blame anyone for avoiding it even if it's a lot better now.
|
# ¿ Mar 16, 2022 00:13 |
|
Coffee Jones posted:I don't know about any such goddamn virus checker they'll install. Run npm install - which touches a few hundred thousand files, the virus scanner will go berserk and turn a three minute operation into a seven minute one, just corporate hamstringing its own systems for some bullshit. SentinelOne is absolutely miserable for this and whenever I run a git checkout or git pull my laptop sounds like a jet engine taking off.
|
# ¿ Mar 20, 2022 22:20 |
|
I mean that sounds a lot less like a slack problem and a lot more like a "your company" problem
|
# ¿ Apr 3, 2022 16:44 |
|
Oh sure but that's not a tool problem it's a policy problem
|
# ¿ Apr 3, 2022 18:48 |
|
Monorepos can work well provided you have strong tooling to handle building/versioning/incremental changes to specific artifacts/etc. Working in monorepos without good tooling can be a miserable experience, especially as the codebase grows.
|
# ¿ Jul 7, 2022 17:15 |
|
You miss 100% of the shots you don't take
|
# ¿ Feb 2, 2023 05:24 |
|
Bruegels Fuckbooks posted:as near as i can tell the previous chief architect at my company just spent all day in his office playing doom and going to meetings (he was a seventy year old japanese guy). i saw him pass the time in a meeting by getting shenmue to work on a dreamcast emulator on his phone. That's the dream tho
|
# ¿ Jun 20, 2023 19:39 |
|
Love Stole the Day posted:This is one of the things I've been interested in seeing with Golang and Rust: because they don't do classes, I see people using OOP patterns in there... but since classes and inheritance work so differently, it feels like a round peg in a square hole. I wonder what patterns will be evangelized as those things become more ubiquitous. Then again, we should separate concerns and organize things in a way other engineers can understand... and OOP patterns are what they understand, so it's not wrong, but culture changes faster than language specs. Go has something similar which is to embed structs and/or interfaces but yeah that’s full of awful footguns especially when using anything from the atomic or sync packages and definitely if the type has custom marshaling or unmarshalling behavior. Go’s equivalent in terms of bad stuff that’s cargo-culted is micro-interfaces repeated everywhere because idiomatic Go says you should “accept interfaces and return structs.” Each accepted type that’s not a primitive becomes a ThingDoer and the compiler complains if you’re not passing a struct that implements it rather than complaining that a type doesn’t explicitly implement an interface. It makes actually finding implementations of an interface extremely painful even with an IDE that has “go to implementation” because guess what gomock does when you’re generating mocks? Yeah
|
# ¿ Jul 16, 2023 17:51 |
|
Judge Schnoopy posted:There's some bad idiomatic go, and this is absolutely the worst one. Luckily I've never seen people actually doing this because it's just so insane and hard to work with. It’s not awful when you think about DI and being able to couple use to behavior rather than identity but it can absolutely miserable to jump into a codebase where it’s been applied everywhere.
|
# ¿ Jul 17, 2023 00:51 |
|
Jabor posted:Test fakes are superior to mocks in just about every single way. The only exception is the "nobody has written a test fake for this particular inconvenient dependency yet and I don't wanna do it just for this test" scenario. If it weren't proprietary code I'd post an example of just how awful test fakes get in a Go codebase. That's not to say they're not useful for simple logic but they have a tendency to balloon miserably and can end up taking a lot of work to maintain the internal bits that actually allow you to validate the expected behavior under test.
|
# ¿ Jul 17, 2023 13:11 |
|
Love Stole the Day posted:Instead of mocking literally every dependency of literally every class, you're mocking only the stuff that talks to external things... and so you're actually running the end-to-end code of the component itself, in the same way that it's actually used in reality. So, you're covering more lines with fewer tests, you're writing your unit tests in the almost the same way you write your integration tests, and you don't have to worry about fixing your broken unit tests every time you want to make a code change. That’s how mocks work, though?
|
# ¿ Jul 17, 2023 15:56 |
|
Like, why would you write a test that requires mocking everything? Mocks are for the dependencies of the things you put under test as a way to control complex upstream behavior.
|
# ¿ Jul 17, 2023 15:57 |
|
Jabor posted:Kind of true, but generally you have one fake implementation used everywhere (and fixed everywhere when one person finds any significant unintentional difference with the real system), vs. every single test configuring their own mock behaviour. Or you have a fake per package/module/whatever that all have slightly differing behavior but which one is the correct one?????
|
# ¿ Jul 18, 2023 01:57 |
|
I’m worried that it might need to be said: don’t loving “well actually” your colleagues.
|
# ¿ Jul 19, 2023 18:19 |
|
Team cohesion and shared responsibility. It makes the structure of a team a web of information rather than a hub-and-spoke.
Blinkz0rz fucked around with this message at 04:18 on Oct 8, 2023 |
# ¿ Oct 8, 2023 03:04 |
|
Aramoro posted:People come to me to whine about PR comment now, it's the worst. Yeah the PR comment very politely told you that you fuckin suck and now I have to rephrase that in such a way that you understand that you fuckin suck but without saying that. This isn't the flex you think it is.
|
# ¿ Oct 25, 2023 14:09 |
|
StumblyWumbly posted:There are times when this is fine and times when it isn't. When its fine, you may as well say "Can you send me the minutes" or "I'll work in the corner until my part comes up" if it were in person, but yeah remoting in to that kind of meeting works better. When it isn't fine, it means you've checked out of a meeting where your input would have been valuable. This is a skill issue tbh I'm one of like 20 principal engineers in an engineering org of around 800 or so, am full-time remote, and I spend the vast majority of working hours on calls. Everything you point to as being better in-person has never been an issue in my org because we're globally distributed and our default condition is that all of our meetings always include some remote communication even if it's office-to-office. Really the issue comes down to people who don't want to spend time thinking about how other people work and respecting that difference. If you wanna work in an office that's cool, you do you. But you can't convince me that there's something inherently superior about it just like I won't try to convince you that working from home is better.
|
# ¿ Mar 9, 2024 20:44 |
|
StumblyWumbly posted:It is a skill issue and you can work around it if you invest some time and practice in it, but there's a cost associated with that and you'll find people outside software or young-ish engineers are less likely to pay that cost, so good luck having useful meetings with the Mech E team or production folks who really don't have a WFH option. The cost of working from home is the same cost as having multiple offices and having teams work across time zones, which is to say it's a combination of investing in communication tools and process, not forcing everyone to do their job the way you want them to. To your second point, it's a bit naive to claim that pressure from commercial real estate has no impact on the WFH conversation. They may not be paid by CBRE but you can be drat sure execs are keeping an eye on a huge line-item in their budget, especially if the ~~vibes~~ make it feel like that expense isn't worth it. Is it easier to force their employees back into the office or renegotiate a multi-year lease and incur all the costs associated with moving or downsizing?
|
# ¿ Mar 9, 2024 22:48 |
|
I prefer to just trust people to get their work done rather than micromanaging their away from keyboard time. If you need something so urgently from a coworker that you can't handle an async delay your coworker probably shouldn't be the only person who can answer that question.
|
# ¿ Mar 10, 2024 23:32 |
|
|
# ¿ May 20, 2024 14:57 |
|
redleader posted:we can simply train an ai only on good code there is no good code
|
# ¿ Mar 13, 2024 22:59 |