|
Hadlock posted:What if I replace the word standup with "daily status meeting with manager and team of 8" Is this implying it can't be async? That's your best bet with the only other option being to ask to move it, maybe 11:30 pacific works better for everyone. asur fucked around with this message at 01:49 on Apr 16, 2022 |
#
?
Apr 16, 2022 01:31
|
|
|
|
| # ? May 27, 2024 21:05 |
|
|
We have standup in slack and 30 minutes to chat, talk about important things, and socialize for the first 5 minutes in the morning over zoom. I don't know how to explain that I don't give a poo poo about socializing with any of these people and not sound like an rear end in a top hat, so I give short answers about how my baby is doing or the weather or some other insane smalltalk and wish I could be working. Remote working has turned me into an antisocial troglodyte, and it's the future 
|
|
#
?
Apr 16, 2022 02:25
|
|
|
The only reason I supply Wordle guesses in the weekly department meeting is so it ends sooner. I've complained about that meeting consistently blowing past the end of its timeslot, but the only person I can complain to is my boss, who runs the meeting, so welp. Maybe I'll complain to my boss's boss lol
|
|
#
?
Apr 16, 2022 02:42
|
|
|
Smugworth posted:We have standup in slack and 30 minutes to chat, talk about important things, and socialize for the first 5 minutes in the morning over zoom. Hell, I felt that way even more before 100% remote. At least now I can turn my volume off when someone who is chronically long winded is at minute 5 of their excessively detailed, rambling and off-topic status report in standup.
|
|
#
?
Apr 16, 2022 02:48
|
|
|
CPColin posted:The only reason I supply Wordle guesses in the weekly department meeting is so it ends sooner. I've complained about that meeting consistently blowing past the end of its timeslot, but the only person I can complain to is my boss, who runs the meeting, so welp. Ah, hello comrade, you speak my language  I followed my boss here from another company so I'm sort of having to tow the line as we work really well together and it's a financially mutually beneficial situation, but 35-45 min stand up meetings daily are brutal even if it's Highly Effective at meeting deadlines etc We mostly do infrastructure so there's a lot of interrupt driven break work and it's not predictable CRUD feature building so there's a little more collaboration involved, I suppose Hadlock fucked around with this message at 05:00 on Apr 16, 2022 |
|
#
?
Apr 16, 2022 04:57
|
|
|
Any basic Microsoft stack stuff I should brush up on before I start in my new job? It seems like I will get to choose my own assignment to a certain degree, so hopefully I can find a project that uses some third party stuff I know well (like Elastic/Solr), but I have been Linux only until now so onboarding will probably be more painful than I am used to.
|
|
#
?
Apr 16, 2022 16:12
|
|
|
Powershell is good, open source, and worth learning. Windows Server comes with openssh installed but disabled. If you learn Powershell, you can enable ssh and skip all the RDP bullshit. Desired state configuration looks cool and may be important, but I haven't actually used it yet.
|
|
#
?
Apr 16, 2022 16:26
|
|
|
Jeez these 30+ minute stand up stories sound like hell We blitz through 12 of us in 15 mins, including a quick review of outstanding PRs. Anyone going off piste is told p quickly to take it offline with anyone who needs to be there.
|
|
#
?
Apr 16, 2022 17:06
|
|
|
When we switched to fully remote, I tried to keep things moving and under 15 minutes in the morning. Pretty quickly, I got a lot of feedback that the vast majority of my team prefers to not be rushed in the morning, which usually results in 30-45 minutes. Requirements clarification happens there, design discussion happens there, as well as personal chit-chat and making fun of the executives after their latest all-hands announcements. Everyone seems to want the interaction that we don't get as much of during the work day since we're all remote. At my last job, when we were in the office and all standing around a projector while the manager went down the extremely long list of in-progress tickets one at a time, it was 45 minutes of hell. But oddly enough, in this situation, it doesn't feel bad. I think I'd personally prefer to keep things short and deal with the other questions in other, smaller meetings, but ultimately it works for us. We're one of the more successful teams in the company in terms of meeting goals, building products that function in time for the people that need them (usually the larger project is months behind and we get to say "yeah we've been ready for the last 3 weeks" when someone asks why thing isn't done).
|
|
#
?
Apr 16, 2022 19:05
|
|
|
15 minute standup and 20 minutes shootin the poo poo is not 35 mins standup
|
|
#
?
Apr 16, 2022 19:11
|
|
|
instead it's a 35 minute meeting
|
|
#
?
Apr 16, 2022 20:07
|
|
|
Ours are about 10-15 for 8+ people. Officially it's blocked to 30 min, but usually we'll blow through our updates and if someone has an "11th minute" thing or "hey can we sync on this" people will stay on who care and the rest just drop off. We used to do Geekbot for async updates but turns out people didn't read it. It's a bit of a pain though since we're half east coast, half west coast + one central time person, we do it at 11am pacific which sucks for like, everyone.
|
|
#
?
Apr 16, 2022 20:09
|
|
|
10 minutes to get through 10 people across 4 timezones. We park discussion for folks who want to talk after and it seems to work well.
|
|
#
?
Apr 16, 2022 20:37
|
|
|
Blinkz0rz posted:10 minutes to get through 10 people across 4 timezones. We park discussion for folks who want to talk after and it seems to work well. Yeah, this is how I've always done it. Most updates are to the tune of "Worked on X yesterday, working on Y today, would like to talk with Z at the end to iron things out". Less than a minute for most.
|
|
#
?
Apr 16, 2022 21:11
|
|
|
thotsky posted:Any basic Microsoft stack stuff I should brush up on before I start in my new job? gonna have to be a little more specific than 'microsoft stuff'. do you know what technologies they use specifically? or at least what sort of role you'll be doing/where your focus will be? cum jabbar posted:Powershell is
|
|
#
?
Apr 17, 2022 05:06
|
|
|
Powershell is like Ruby's object-orientedness, with Python syntax I'm glad it exists, cmd/bat scripts are a nightmare, but it would of had a lot more impact had it been released in like, 2000 and was rolled into XP from the very beginning so people actually knew to use it. It was actually usable by v3 and v4 was pretty pleasurable to use, v5 introduced actual user definable data structures. Looks like they're up to v7 now? v5 in ~2015 was a really usable windows shell language for hacking together all kinds of windows admin automation/tasks, kind of curious to see what v7 has added over the last ~7 years
|
|
#
?
Apr 17, 2022 06:19
|
|
|
redleader posted:gonna have to be a little more specific than 'microsoft stuff'. do you know what technologies they use specifically? or at least what sort of role you'll be doing/where your focus will be? Software development. I will be a developer/architect, but as a consultant it depends a lot on which project I get. I know they will be moving to MAUI for multi platform apps and stuff, but other than that not a lot of specifics. I guess .Net/C#? I started playing around with Visual Studio a little and it might be worth dipping a toe in Azure just to learn a few differences from AWS/GCS.
|
|
#
?
Apr 17, 2022 08:51
|
|
|
thotsky posted:Software development. I will be a developer/architect, but as a consultant it depends a lot on which project I get. yeah, c# would be the single .net thing that you will use everywhere. vs is a good ide, but if you want to use a linux i believe vs code with extensions isn't too bad for doing c# dev. if you like flangs, f# is microsoft ocaml.net. i think there's a bit more friction using f# - it's a bit of a second-class citizen as c# is far and away the most popular lang, and most platform development targets c# first. you can also in theory use visual basic my personal impression of .net is that microsoft's goal has been to build a batteries-included application development 'ecosystem', which supports a number of different application models out of the box. there are different 'hosting models' - web, service (think daemon or windows service), console - and a set of common plumbing/core infrastructure components that work nicely in each scenario. for example, .net comes with a lightweight dependency injection framework and a basic logging framework that both work well for all app types out of the box. both of these can be easily swapped out if you want to use a different DI container or logging library. it looks like maui can also use the DI container thing easily, from a quick google. you'll encounter most of this in the context of asp.net, which is (i think) far and away the most popular framework on .net, but they are core .net libraries, and i think ms either implicitly or explicitly recommends using them no matter what you're developing the .net standard library (the BCL - base class library, if you want to be formal) is also very batteries-included. there is some cruft (e.g. something like 3 or 4 ways of doing json and/or xml stuff each), but nothing insurmountable. a lot of .net uses async/await for ~scalability~. since you're doing UI stuff, i think there are some considerations with async code that you'll need to be aware of to avoid deadlocks and stuff? there are 3 (at least) common testing frameworks incl one from MS, but all integrate into .net and VS itself just fine .net releases happen about once a year, alternating between long term support and 'regular' releases. upgrading generally isn't a big deal nowadays (it was more painful in the past). c# is a good lang, but it's been growing for >20 years now and it has a lot of features - some are just quite new, some are pretty niche. especially when starting out you'll run into funny syntax and odd features all over the place. you get used to it, and in general reading code that uses new stuff isn't terribly hard to understand. there is a little pain around the transition from the old .net framework to .net core, and between early versions of .net core, but things have settled down nowadays a note on naming - back in the day, you had the .net framework. when ms decided to go all-in on cross-platform dev, they released .net core, named to distinguish it from the old windows-only framework. at this point the writing was on the wall for .net framework (current version 4.8.something, only receiving security updates). .net core releases went from .net core 1 -> 2 -> 3. then ms skipped .net core 4 entirely and dropped the 'core' part from the branding, so the next versions were .net 5 and .net 6, with net 7 in development. this is quite confusing. it gets worse when you need to think about supporting both .net framework and .net (core) apps BUT you shouldn't need to think about this you'll notice that an absolute shitload of libraries etc are first-party from microsoft. this is weird. the ms things are generally pretty well supported and documented, but it does seem a bit culty at times any web backend will use asp.net. it's a solid web framework for both web apis and old school server-side rendered pages. if you're doing any web at all, it'd be a good idea to give this a spin. .net 6 introduced a new way of writing web apis - the so-called 'minimal apis'. this isn't a big deal but is worth noting if you need to work with existing .net < 6 aspnet apps. aspnet is, again, very batteries-included. it's got authN/authZ things, validation, serializers out the wazoo, all sorts of web things. it also has a lot of extension points to build on or entirely replace parts of the framework - and indeed a lot of aspnet is built using these extension points. there's also blazor, which is a web thing that lets you write .net for the frontend and it will either (1) render the page on the server and stream updates to the client over web sockets or (2) run the entire thing client-side by compiling to wasm, but both of these things are insane and i'm not familiar with them in terms of cloud poo poo, azure has all the basic cloud things you'd expect, so you have your vms on demand, your infinite cloud hard drive, your special queue, etc. i don't know know much about IaC tooling for it though. most cloud things will try to integrate with app insights - the azure cloud logging/performance monitoring thingy. i don't have any experience with alternatives to app insights but it's a pain to use often database-wise, the default in the ms ecosystem (incl cloud) is sql server. it's a good db, if you're willing to pay for it. entity framework (ef core) is the de facto orm within .net. it is certainly a thing that you can use, but this will come down to your feelings on orms in general. a good alternative is dapper, which is a lightweight sql-query-to-object mapper thing since .net and some of the core libraries have been along for a while, it's worth keeping an eye out when googling things because you can sometimes end up looking at stack overflow questions for older frameworks and libraries. i semi-regularly find old entity framework answers even when i search for 'ef core'
|
|
#
?
Apr 18, 2022 01:13
|
|
|
Volguus posted:Just get out of there. Jesus, that's insane. I want to make absolutely sure I've tried all I can first. I don't think it would be fair to leave without first trying everything I can think of. And maybe I can turn into some kind of super awesome rockstar if I manage to crush it in this environment. That said, I was tempted to leave for a while because the hiring manager told me I'd have a project from day one but I have only been asked to work on small 2-3 day tasks for six months. I was also told this would be mostly backend work with some frontend work and it's been almost entirely frontend, to the point my TL called us a frontend team. And now it seems like I'm getting complaints for doing something I was asked to do but I guess that one's on me since I probably wouldn't be here if I said something after day 1 of fruitless debugging. Still, this is a team that works differently than I'm used to with a much greater emphasis on short-term results than I've seen since my first job, and it's also a frontend team which is not where my experience lies, so I'd like to get better at dealing with both those things rather than just run away. Jabor posted:Have you actually produced anything? ... I have some walls of text showing the closest I've gotten to the root cause that I used to ask the our POC about but yeah, I never anticipated being in a situation where I'd need to show docs in an easy-to-read format because every other team I've ever been on would just say "oh wow, that sucks. the expert didn't know? wow, that must be a hard one, good luck". Now I know that some teams want that, which is good to find out, and a reason why I think I can learn from staying. Hargrimm posted:Setting aside the absurdity of a team generating time estimates for fixes to a codebase they don't have familiarity with, if the estimate was 2-3 days, day 4 of fruitless debugging with nothing accomplished would probably have been a good time to reach out to the TL proactively I communicated it in a standup and said I'd reach out to our PoC on day 5. The only place I worked where people got concerned over the time spent on such small tasks was my first job, where devs did manual testing and there weren't any automated tests whatsoever. Then there would be a sort of panic because someone promised a customer we'd deliver by some time date and we'd be expected to show up and work 8am to 1am on a Saturday if that was what it took to deliver when promised. Here, though, we're not working on anything that has been promised externally. The deadlines are made up and my manager has confirmed that. Funnily enough, we do have some problems with testing too. I stubbed out an object's private methods in a test today because I didn't understand it well enough to stub out its collaborators (or, ideally, set up real collaborators) and that's a common pattern here. It seems bizarre to me but I'm trying to trust that it's for a good reason. asur posted:Even earlier than that, if an estimate is 2-3 days and you don't know the root cause by end of day 1, or have a strong reason to believe you're close to identifying it, then you need to revise the estimate and communicate that. 1 day out of 2-3 days, or roughly 1/3 of the initial estimate, sounds like a nice rule of thumb for communicating on timelines. I'll use that from now on. Thank you! I don't know why the PoC is debugging. My TL suggested maybe they started debugging because they didn't know the answer to my question. It's probably not their responsibility. I did tell them their root cause was wrong and they kept debugging and wrote a doc about it and still didn't figure it out but suggested a temporary fix that tbh I was already thinking of. My lead did mention I could try asking our PoC's TL but he initially suggested I seek a higher level of engagement with our PoC before apparently letting my manager believe I got stuck and needed to be rescued, so I have no idea how reaching out to the PoC's TL would be perceived. Motronic posted:You need to know your audience. Yeah, that seems like one of the bigger lessons here. This is the first time at Google that I've worked with people who care about the timing of small tasks when the issue isn't time-sensitive. oliveoil fucked around with this message at 02:28 on Apr 19, 2022 |
|
#
?
Apr 19, 2022 00:55
|
|
|
oliveoil posted:I want to make absolutely sure I've tried all I can first. I don't think it would be fair to leave without first trying everything I can think of. And maybe I can turn into some kind of super awesome rockstar if I manage to crush it in this environment. I don't know what to make of your broader situation but this sure sounds like sunk cost fallacy. if your biggest issue is communication/rapport with your TL/manager, you're not going to code or debug yourself out of that. I'd suggest having a respectful but direct conversation with your manager about the situation and see where it goes. if your manager isn't supporting you, you should start making plans to switch teams or companies
|
|
#
?
Apr 19, 2022 01:55
|
|
|
take boat posted:I don't know what to make of your broader situation but this sure sounds like sunk cost fallacy. if your biggest issue is communication/rapport with your TL/manager, you're not going to code or debug yourself out of that. I'd suggest having a respectful but direct conversation with your manager about the situation and see where it goes. if your manager isn't supporting you, you should start making plans to switch teams or companies Yeah, but I think it's safe to assume not everyone on my team is thinking of leaving because of a weird rapport, so the problem is probably related to something I did or have been doing. I think my TL just wants stuff done as fast as possible and I'm still not sure how to tune my decision-making for that. I see most people on my team seem to debug faster than me, with one in particular getting way more done than anyone else, and I wonder if I can improve my processes by copying some of what they do too. The reason I'm not sure my decision-making is calibrated for this team's focus on speed is I keep coming across situations where all my prior TLs had various preferences or just didn't their state preferences and never complained. E.g. updating a test case to use objects instead of mocks is a recent case where a previous TL would want me to just do it and never asked nor apparently cared how long it takes vs another previous TL who never asked and apparently didn't care if I was to spend a day on it vs my current one who only wants me to do it if the fix is obvious just from looking at it and I can do it within a few minutes. I'm just not sure how much effort they want spent on one thing vs another. Another example is my TL wants me to manually perform regression testing for related functionality for some of my changes because we have a responsibility to minimize defects but then we seem to accept that there are some issues with our testing strategy that can also let us miss defects. That one seems contradictory and I feel confused when I think about it. If I could understand his thought process or the thought process of someone they think is doing really well then I think this issue would disappear. oliveoil fucked around with this message at 17:20 on Apr 19, 2022 |
|
#
?
Apr 19, 2022 17:12
|
|
|
oliveoil posted:Another example is my TL wants me to manually perform regression testing for related functionality for some of my changes because we have a responsibility to minimize defects but then we seem to accept that there are some issues with our testing strategy that can also let us miss defects. you have to run some manual testing. the automated + manual testing is not complete. if you push a bug that would've been caught by the manual testing, that looks bad and is preventable. if you push a bug that falls into this weird gray zone, it also looks bad but is understandable. are you, in the span of this bug fix, able to completely eradicate that gray zone? no? then run the available tests and don't break the obvious poo poo
|
|
#
?
Apr 19, 2022 17:45
|
|
|
Yeah, sure, run the manual tests but maybe also clean up a little as we go? Preventing bugs is clearly valued because we do some manual testing but then I see us pass on some stuff that seems helpful toward that end, in spots where previous TLs would want me to go ahead.
|
|
#
?
Apr 19, 2022 17:46
|
|
|
Different leaders have different priorities, different projects have different priorities, different situations result in different priorities. Your TL might not be prioritizing this specific thing at this point on this project even if other leaders you had in different circumstances would do so.
|
|
#
?
Apr 19, 2022 19:26
|
|
|
Yes. I'd like to understand how they prioritize in this team's context so I can stop doing things they don't want me to do and focus on the things they do want. I do not have that understanding right now.
|
|
#
?
Apr 19, 2022 19:30
|
|
|
oliveoil posted:Yes. I'd like to understand how they prioritize in this team's context so I can stop doing things they don't want me to do and focus on the things they do want.
|
|
#
?
Apr 19, 2022 19:50
|
|
|
oliveoil posted:Yeah, sure, run the manual tests but maybe also clean up a little as we go?  who the gently caress made you TLbut sure let's think your way through: if you're slipping into the 2nd week on a 3 day deadline, maybe, perhaps, this one loving bug that's just been assigned to see if you can shove code through a CI system like everyone else on the team's been doing for years, MAYBE this isn't the time to dedicate extra effort to that "little" cleanup?? if the "cleanup" was included in your PR and they were trying to carve it back out that would be one thing, but blocking your actual deliverable on "ACKSHUALLY, im going to patch a massive testing infrastructure hole, brb it'll only take a couple months" is asinine if, hypothetically, someone viewed tech work as disdainful stuff for degenerates and thought they could game an interview for fat stacks and no work? how would they be handling this situation differently? because I swear "I'd contribute buuuuuuuuuut the tests might be insufficient" is straight out of the CIA workplace sabotage handbook
|
|
#
?
Apr 19, 2022 21:08
|
|
|
1. document how much time/money is wasted dicking with manual tests 2. document released bugs that are caused by manual tests 3. provide an estimate and timeline for fixing testing strategy 4. get people to agree that the cost of (1) and (2) is greater than the cost of (3) by a sufficient degree 5. get "increase developmental velocity as measured by..." or "reduce released bug rate by n%" or whatever as an OKR come planning time 6. implement (3) refactor-as-you-go works when everyone agrees to it, but changing an entire team's testing culture is harder and generally needs an agreed-upon plan with a clear cost/benefit. you're not gonna have great luck blowing up estimates because you want to re-write your testing methodology without including the people who have planned the next quarter or half or whatever of work you're almost certainly not the first person to think "hey test suites are cool and will help us." there's a reason it's not there. have a talk with your TL about why it's not and see what you can do to change that
|
|
#
?
Apr 19, 2022 21:25
|
|
|
it's also on you to push back on estimates that are too rosy. like, if you need 5 eng days because you need to refactor something, scope it at that. then if/when TL pushes back, you go "ok i can do it in 3, but the other option is i take 4 days to refactor and then 1 day to make the change, and future changes to this part of the codebase will benefit from the speed increase. and you can see that we're making changes here all the freakin time so this'll pay off within like one quarter". and then TL makes their decision. if they go for refactor great, and if they don't, you make a note of it and see if it really does bog people down in the future. if it doesn't, then you were wrong so you drop it; if it does, you have more data for your "we should refactor" pitch next time.
|
|
#
?
Apr 19, 2022 21:30
|
|
|
JawnV6 posted:amazing that this is befuddling the poster who wanted to waltz into a L6 role and still sucks up so much air from this thread Oh my, it's the same person. I just had to go back and check. oliveoil posted:Maybe I could jump to L5 via company switch then jump to L5 via another switch? oliveoil posted:Think I'll keep studying and try to get into a crypto company with L6 comp in like six months. oliveoil posted:Yeah I do things the long way and it's a bumpy road but if you think about it the other way, if everyone here thought more like me, this thread would be full of multimillionaires. oliveoil posted:Yeah it's a new team. L4. Based on recent posting, I'm not sure this person would make it as an L4 in any org I've worked for. None of these problems are things an L4 should have to ask about how to navigate. L5 is a very, very long way away from this type of behavior. But, oliveoil posted:That's alright. Most won't make L6 and the comp at L5 isn't worth striving for anyway.
|
|
#
?
Apr 19, 2022 21:40
|
|
|
Just a month ago:oliveoil posted:Yeah, I don't care whose responsibility it is but I want to do something less monotonous. This feels like somebody else is chewing food for me, there's nothing to think about by the time I get a ticket. Not a good sign when you flub it entirely the moment you get a task that isn't sufficiently pre-chewed.
|
|
#
?
Apr 19, 2022 21:54
|
|
|
bring back downslotting
|
|
#
?
Apr 19, 2022 21:58
|
|
|
person who gambled it all on meme stocks and lost it all to the point that they couldn't afford to eat meat does not make good decisions: vol 4
|
|
#
?
Apr 19, 2022 22:13
|
|
|
oliveoil posted:Yes. I'd like to understand how they prioritize in this team's context so I can stop doing things they don't want me to do and focus on the things they do want. Don’t let perfect be the enemy of good. Focus on closing out some work well, within the way the team operates first, you’re not in a position to challenge people to justify their thinking to you when you can’t close a bug ticket or properly communicate the challenges with the ticket in a timely manner. It sounds like you may be a difficult person to work with based off what’s been shared. Chill out and stop trying to big brain everything. Do make sure you raise flags as soon as any estimate is at risk and make sure you can explain why biceps crimes fucked around with this message at 22:19 on Apr 19, 2022 |
|
#
?
Apr 19, 2022 22:16
|
|
|
I like how
|
|
#
?
Apr 19, 2022 22:22
|
|
|
Listen to bi crimes. A thing that was drilled into me from my distant youth was "Managers hate surprises." This goes triple when you're a new team member. When you realize that a task can't be done in three days, alert your lead right then and there. Do not wait until you've already slipped past it by weeks. The mail looks like: [to lead] Team Z says they don't own this code, I'm slipping a week to talk to Team Q [later, to lead] I notice this branch of the code has had bug reports 5 times in the last six months. I can patch this inside the deadline, or I can refactor it to save us all Z% effort in future. What's your call? There is a band between not being able to work independently, and thus bugging your lead way too much, and working too independently, and giving your lead nasty surprises. Right now you've crossed outside the band.
|
|
#
?
Apr 19, 2022 22:27
|
|
|
bob dobbs is dead posted:person who gambled it all on meme stocks and lost it all to the point that they couldn't afford to eat meat does not make good decisions: vol 4 i think it's most likely that oliveoil is stymie's new gimmick or something. oliveoil themself is either purely fictional or so incredibly dense that no advice will help them. but it's kind of worth responding to them 'cause lots of juniors and midlevels have similar issues to figure out. tbh i think im just saying something you said to me the last time oliveoil got the thread goin' so now once again i guess i'm posting more to other people than the actual stated recipient of my post posting is weird 
|
|
#
?
Apr 19, 2022 22:28
|
|
|
I liked the gimmick for a bit, but it's getting too predictable IMO
|
|
#
?
Apr 19, 2022 22:58
|
|
|
post the bug
|
|
#
?
Apr 19, 2022 22:59
|
|
|
|
| # ? May 27, 2024 21:05 |
|
|
My biggest bottleneck to my promotion now is getting a specific director as an ally - one who basically just said he thinks my team should be disbanded. Not asking for advice, just lamenting the state of things and wishing the soft skills weren't so goddamn hard.
|
|
#
?
Apr 19, 2022 23:39
|
|
