|
Hughlander posted:I’m getting close to drastic measures like that. Office has only one Ethernet port per desk. The 802.WHATEVER security will kill the port if more than one MAC address is scene from it. Pinging from the Ethernet to a Mac-mini on my desk on wifi was giving ~120ms MEAN latency. Oh and I’m working on a low latency networking App with 3 machines 2 of which need to be on wifi. drat dude. you should talk to your shop steward
|
#
?
Aug 5, 2017 04:44
|
|
|
|
| # ? May 12, 2024 10:27 |
|
|
This week's agenda at my new job: Monday, Tuesday, Thursday, Friday: Agile training; Wednesday: new employee orientation. I'd better pack some snacks and a book or two!
|
|
#
?
Aug 7, 2017 15:23
|
|
|
Gildiss posted:Regression testing with 0 defects on my track and 1 week before my last day. The hero we deserve
|
|
#
?
Aug 7, 2017 19:42
|
|
|
So my new gig isn't terrible enough for me to quit immediately, but it's not good enough for me to stay long term. The hunt begins again!
|
|
#
?
Aug 8, 2017 12:20
|
|
|
My Rhythmic Crotch posted:Or you could just work whilst at work, instead of posting on these here forums But then I'm stuck getting help from stack overflow
|
|
#
?
Aug 8, 2017 17:37
|
|
|
Ither posted:So my new gig isn't terrible enough for me to quit immediately, but it's not good enough for me to stay long term. How do you do fellow newly anointed job hopper. I was in this spot 2 months ago and am starting a better job next week.
|
|
#
?
Aug 8, 2017 22:53
|
|
|
Iverron posted:How do you do fellow newly anointed job hopper. Congrats. Hopefully, I can find something as quickly.
|
|
#
?
Aug 8, 2017 23:23
|
|
|
I really wish my team leader would notify me of the state of his tickets/what he intends to do with them before he passes off tickets dependent on his work onto me. Just went down a wild goose chase trying to figure out how to do something before realizing that one of his PRs for a completely different tickets rolled a few others into it and that I was supposed to be working off those changes before I could get any of those tickets done.  This happens all the time and always confuses the hell out of us.This feature has been a pain to get off the ground without him being available to interrogate and I'm paranoid that the product owner/project manager is gonna blame me instead of him. Not that my focus on finding a new job and remote setup twice a week hasn't contributed to that slowness...
|
|
#
?
Aug 9, 2017 17:26
|
|
|
My team lead wanted us to do a code review of a years worth of work when we were merging release to master/dev. All of which have been reviewed separately as feature branches when merged to dev/release. Is that not ridiculous?
|
|
#
?
Aug 9, 2017 21:08
|
|
|
Why did they not go into master too already?
|
|
#
?
Aug 9, 2017 21:30
|
|
|
Ask them to pair review it with you.
|
|
#
?
Aug 9, 2017 21:47
|
|
|
It's all work for one release that began last year. We don't merge to master until it's released. When work for a release is done we make a branch off of dev for the release. The release branch is tested and any bugs are fixed on that branch. When the release branch is done and passes all testing it's merged to master and dev.
|
|
#
?
Aug 9, 2017 22:18
|
|
|
Makeout Patrol posted:drat dude. you should talk to your shop steward I just brought it up with Networking instead, they're putting an order in for a managed Cisco Switch.
|
|
#
?
Aug 9, 2017 22:39
|
|
|
You are not Google Just finished listing to an interview with this guy on The Changelog and it was really good.
|
|
#
?
Aug 9, 2017 22:53
|
|
|
Rubellavator posted:It's all work for one release that began last year. We don't merge to master until it's released. When work for a release is done we make a branch off of dev for the release. The release branch is tested and any bugs are fixed on that branch. When the release branch is done and passes all testing it's merged to master and dev.
|
|
#
?
Aug 10, 2017 04:15
|
|
|
Rubellavator posted:It's all work for one release that began last year. We don't merge to master until it's released. When work for a release is done we make a branch off of dev for the release. The release branch is tested and any bugs are fixed on that branch. When the release branch is done and passes all testing it's merged to master and dev. So master has just been sitting untouched that entire time? What even is its function, then?
|
|
#
?
Aug 10, 2017 04:23
|
|
|
master has been banned from branch names because it perpetuates the concepts inherent to patriarchy.
|
|
#
?
Aug 10, 2017 04:36
|
|
|
a foolish pianist posted:So master has just been sitting untouched that entire time? What even is its function, then? We have a similar branching strategy but a more frequent release schedule. We use Master for hotfixes or things that were completely wrong (but work as designed) and need fast attention.
|
|
#
?
Aug 10, 2017 04:36
|
|
|
Master is just supposed to reflect that exact code that's deployed in production. It's this: http://nvie.com/posts/a-successful-git-branching-model/. I thought this was pretty standard. I didn't mention hotfix branching because I've only been on the project for a month and I'm not sure given the nature of the product if we ever really end up doing them, but I've done them on other projects here.
Rubellavator fucked around with this message at 05:43 on Aug 10, 2017 |
|
#
?
Aug 10, 2017 05:39
|
|
|
we use the develop branch and cut releases off that and don't even bother to merge back to master afterward because gently caress it bro that's work
|
|
#
?
Aug 10, 2017 07:08
|
|
|
I really wish that all of our xtag knowledge wasn't concentrated in our team lead. I have to keep reaching out to him with questions, and asking questions like this got people mad at me at my last job...I still have a bit of a complex over that. I also hate that we keep running into the problem where one of us approves a PR, we go ahead and merge it in, then afterwards the team lead dashes in with some other criticism and problem that he didn't bring up before but means that we have to reopen the ticket. It's inevitably some obscure poo poo that only he knows about. He's become the only person who can sign off on a PR and we're all secure that it'll be fine, but he continues to complain that he's the only person doing PRs yet won't help spread knowledge around the team, maybe making some token Confluence pages that nobody can actually find. 
Pollyanna fucked around with this message at 14:48 on Aug 10, 2017 |
|
#
?
Aug 10, 2017 14:41
|
|
|
Pollyanna posted:I really wish that all of our xtag knowledge wasn't concentrated in our team lead. I have to keep reaching out to him with questions, and asking questions like this got people mad at me at my last job...I still have a bit of a complex over that.
|
|
#
?
Aug 10, 2017 17:30
|
|
|
toiletbrush posted:What is this obscure knowledge that stops a PR going through? Are there secret requirements or something he's not telling you all about? A lead who deliberately silos knowledge sounds pretty awful. Anything that has to do with AWS, Jenkins, core architecture, integration with the rest of the site via x-tag, webpack, and validation. This includes edge cases, unspoken reasons why things are done a particular way, obscure knowledge that's more a result of his implementations than the tech we use, and whatever requirements are being passed down from product owners/design. Basically, anything that isn't a specific subset of our React components is all him cause he cowboys the gently caress out in making stuff and never pulls the rest of the team in. This means that the rest of the team has massive knowledge gaps and the only person who really knows how the whole application/codebase works is him. We end up having to rely on him to double check all our work cause there's inevitably some poo poo we don't know that he does but never told us about, and we don't want to break poo poo. When he's out of the office or remote (and even sometimes when he's in), he's either extremely hard to get a hold of or just plain inaccessible. Development basically stalls when he isn't around. It's extremely unhealthy and dangerous, and as a result I feel like I haven't learned anything in the past 8+ months. I hate it and it's one of the two major reasons that I want to leave - the other reason is that almost everybody else already left. 
|
|
#
?
Aug 10, 2017 18:00
|
|
|
Is anyone telling anyone else there this stuff? I'm sure people above him can see the pattern with people leaving but if they don't know why nothing will change.
|
|
#
?
Aug 10, 2017 18:52
|
|
|
He's part of the old guard that was first here (all of whom except him have since left, senior leadership and all). He's kinda revered to the point where my other coworker is hesitant to bring up her proposed changes to our deployment pipeline/strategy out of a sense of respect/appeal to seniority(?). It's kinda weird and I'm not sure it's entirely warranted, but whatever. And yeah, I've brought up the issues of siloing and lack of knowledge transfer and being difficult to get ahold of and all that before. No real progress, I doubt he will change. Aren't team leads expected to be, like, available if we have questions? Or is that just me being a bad mid-level/junior engineer? Pollyanna fucked around with this message at 19:25 on Aug 10, 2017 |
|
#
?
Aug 10, 2017 19:21
|
|
|
Pollyanna posted:Aren't team leads expected to be, like, available if we have questions? Yes.
|
|
#
?
Aug 10, 2017 19:46
|
|
|
I've been team lead before and because I got tired of being asked the same questions repeatedly I spent more time writing docs than coding so that I could delegate as much of my decision-making to others
|
|
#
?
Aug 11, 2017 05:17
|
|
|
Some companies just pile team-lead responsibilities on top of the usual devloper duties, expecting them to still deliver their usual amount of coding as well as answering every questions and leading a team.
|
|
#
?
Aug 11, 2017 12:29
|
|
|
necrobobsledder posted:I've been team lead before and because I got tired of being asked the same questions repeatedly I spent more time writing docs than coding so that I could delegate as much of my decision-making to others My habit has always been to document and make available things when they are explained to me, and now that I'm in a position to be explaining things to other people, I have them document what I'm telling them and put it in confluence with good indexing. If someone else needs more info than what is in confluence, they update the page, and so on. Eventually we get reasonable documentation and team leads don't have to keep explaining the same things over and over.
|
|
#
?
Aug 11, 2017 12:41
|
|
|
AskYourself posted:Some companies just pile team-lead responsibilities on top of the usual devloper duties, expecting them to still deliver their usual amount of coding as well as answering every questions and leading a team.
|
|
#
?
Aug 11, 2017 14:53
|
|
|
Vulture Culture posted:A lot depends on circumstance. For matrix-managed organizations, team lead responsibilities shouldn't amount to a huge time investment versus a senior engineering role; they may even float around the team depending on the specifics of the active projects. For flat organizations, the position may be more informal, and just encompass things like extra sway in code reviews and tiebreak votes in implementation decisions. But for typical hierarchical organizations, you're dead on, it's problematic. I worked for a matrix organization as a team lead. I hated it. I answered to 6 different people and each had to have their own individual meeting with me - it was really repeating the same meeting 6 times. gently caress that noise.
|
|
#
?
Aug 11, 2017 21:55
|
|
|
I'm a tech lead right now and it's great. I encourage my team (and everyone else too) to come to me with questions anytime, because if I can answer something in 30 seconds that would have taken a teammate 30 minutes of frustration, then everybody benefits. And if I don't know the answer, I'll know who will. I report to a Director (and kinda but not officially to his boss the VP), who trusts me to do my job and leaves me alone unless he needs something from me. I get to say how long stuff is going to take the team to implement*, and people actually listen to what I say. Then I get to take the most difficult/interesting bits for myself, and everything else I get to delegate! What could be better?! * Note well, the answer to this question is always at least as long as it would take me to implement by myself.
|
|
#
?
Aug 12, 2017 04:11
|
|
|
JewKiller 3000 posted:I'm a tech lead right now and it's great. I encourage my team (and everyone else too) to come to me with questions anytime, because if I can answer something in 30 seconds that would have taken a teammate 30 minutes of frustration, then everybody benefits. When I started as a junior dev it took me a while before I found a good balance between "asking everything" and "trying out some more stuff/googling some more". I think I got it now but I still feel unsure sometimes whether I should go bother someone with a stupid question.
|
|
#
?
Aug 12, 2017 08:53
|
|
|
Carbon dioxide posted:When I started as a junior dev it took me a while before I found a good balance between "asking everything" and "trying out some more stuff/googling some more". I think I got it now but I still feel unsure sometimes whether I should go bother someone with a stupid question. This is why slack or IRC or whatever deliberate async messaging is wonderful, because if you ask a dumb question while I'm busy, I'll just ignore you. So ask away, who gives a poo poo!
|
|
#
?
Aug 12, 2017 12:34
|
|
|
30 minutes of frustration can be very educational.
|
|
#
?
Aug 12, 2017 13:58
|
|
|
That's something I appreciated about being a government contractor when I was getting started in development. If I had no clue what I was doing I had all the time in the world to figure it out myself and minimal pressure to get it done, plus everyone who knew what they were doing spent most of the sprint chilling out waiting for more scope work and were eager to answer questions if I gave up or wanted feedback since it gave them something to do.
|
|
#
?
Aug 12, 2017 14:18
|
|
|
Brain Candy posted:This is why slack or IRC or whatever deliberate async messaging is wonderful, because if you ask a dumb question while I'm busy, I'll just ignore you. So ask away, who gives a poo poo! On the other hand, mentorship and some degree of pairing can mean the mentor can decide when it's of value to you to find the solution, or save you some time straight up. Excessive reliance on async comms is something I think to be wary of, especially early on. All the humanising conversations don't tend to happen in terse async comms, and they can sort of block someone truly joining a team.
|
|
#
?
Aug 12, 2017 14:34
|
|
|
AskYourself posted:Some companies just pile team-lead responsibilities on top of the usual devloper duties, expecting them to still deliver their usual amount of coding as well as answering every questions and leading a team. Or equally bad. The lead expects themselves to deliver the same amount of coding while taking on the additional responsibilities. Brain Candy posted:This is why slack or IRC or whatever deliberate async messaging is wonderful, because if you ask a dumb question while I'm busy, I'll just ignore you. So ask away, who gives a poo poo! This is probably good advice for Pollyanna ask your questions in a public channel with time stamps. @mention them if it's gone a few hours without an answer. Keep an audit trail of the questions and the turn around time for the answers. Bring it up in 1:1s. "We were block on X and it took 30 hours for an answer, we were blocked on Y and it took 6 hours for the answer, how do we get unblocked with these type of situations?"
|
|
#
?
Aug 12, 2017 15:01
|
|
|
Maluco Marinero posted:On the other hand, mentorship and some degree of pairing can mean the mentor can decide when it's of value to you to find the solution, or save you some time straight up. Oh sure, but this Keetron posted:30 minutes of frustration can be very educational. is absolutely true, and moreover making people type out the question solves the problem very frequently. (Sometimes I'll just respond to a message with "quack")
|
|
#
?
Aug 12, 2017 15:44
|
|
|
|
| # ? May 12, 2024 10:27 |
|
|
Brain Candy posted:This is why slack or IRC or whatever deliberate async messaging is wonderful, because if you ask a dumb question while I'm busy, I'll just ignore you. So ask away, who gives a poo poo! "Is now a good time to ask a question?"
|
|
#
?
Aug 12, 2017 16:09
|
|