|
Munkeymon posted:If y'all work at Twitter, tell the web UI teams they suck TIA In order to pass on your feedback I'd have to admit to a coworker I paid money for an SA forums account.
|
#
?
Oct 29, 2020 18:32
|
|
|
|
| # ? May 9, 2024 07:10 |
|
|
Inacio posted:if you work at reddit and you have anything to do with their new site, i really don't like you reddit's new layouts are total trash. I have no idea how that stuff gets greenlit, prototyped, and rolled out without anyone asking, 'Is this actually better...?'
|
|
#
?
Oct 29, 2020 22:30
|
|
|
Canine Blues Arooo posted:reddit's new layouts are total trash. I have no idea how that stuff gets greenlit, prototyped, and rolled out without anyone asking, 'Is this actually better...?'
|
|
#
?
Oct 29, 2020 22:39
|
|
|
Canine Blues Arooo posted:reddit's new layouts are total trash. I have no idea how that stuff gets greenlit, prototyped, and rolled out without anyone asking, 'Is this actually better...?' It pushes you to use their app, buy gold, or see ads. It's better for the shareholders.
|
|
#
?
Oct 29, 2020 22:49
|
|
|
Canine Blues Arooo posted:reddit's new layouts are total trash. I have no idea how that stuff gets greenlit, prototyped, and rolled out without anyone asking, 'Is this actually better...?' Lots of people probably asked that internally, but decision makers don't get a lot of career credit for deciding not to change things. Someone probably got a nice promotion for leading the redesign.
|
|
#
?
Oct 29, 2020 23:14
|
|
|
Canine Blues Arooo posted:reddit's new layouts are total trash. I have no idea how that stuff gets greenlit, prototyped, and rolled out without anyone asking, 'Is this actually better...?' Early on in the redesign they asked for feedback a lot, and then they stopped asking for feedback because they never got the answer they were looking for.
|
|
#
?
Oct 30, 2020 00:18
|
|
|
I really like my job for the most part, is a big multinational company but when I started out in January I was part of a fairly self-managing dev team. I liked my colleagues, the work was on a good level, and when we were doing things in ways that could improve I could bring them up and we'd try to improve things (like how pull requests and code reviews just weren't a thing we did until I explained why I thought we should, and since then we do). We did three week sprints, continuous releases, you know the drill. A good workflow, for the most part. Then the company at large started its "agile transformation journey". I was skeptical from the start because, well you know, big companies bringing in expensive agile coaches and presenting it all as some big revolutionary change with complicated charts and poo poo, but I tried to stay hopeful. Well, now instead of being part of just that dev team, I'm part of a "pack"* which is one of several in a "flock"* (I think maybe around ten in ours? We don't interact that much better packs most of the time), and there are four "flocks" in the company at large so far. My pack has sixteen members - the devs I've worked with from the start, a different dev team that works on a project ours has dependencies on, a couple of full time manual testers, a bunch of business people, a PO who doesn't know how to say no to stakeholders and a scrum master who's incapable of running a meeting. We're now doing two week sprints in the pack, where much of the planned work is stuff I'm not involved with because it's specific to the other project or it's business poo poo. Everything goes on the board, we have "user stories" for writing requirements, starting new A/B tests, fixing bugs and for developing new features. Oh and also one of the testers and some of the business people (including our UI designer, which is apparently considered a business role) are members of more than one pack so they have to split their time between them and it's obviously really stressful for them. It seems like roughly 30% at least of every week is spent in meetings, we never finish the work we plan in a sprint and we don't even estimate it anyway so the plans are a joke. I've suggested that we shouldn't all be considered the same team on a day to day basis and our sprints shouldn't be shared, but that gets shot down because business people like being involved in everything. I've suggested that two week sprints are too short when there's this much administrative overhead and that we should try three weeks, but that gets shot down because, and I quote, "I can see where you're coming from. However coming from the Big Room Planning I find it highly unlikely that we will have diverging sprint lengths to the other [packs] and [flocks] since it seems the motivation from management for setting up agile like this is increased transparency and alignment between business areas and countries in [company name] - in order to focus our efforts where it matters most". And maybe I'm just being dogmatic here, but this sounds like the opposite of being agile to me. Oh and that bit about the"Big Room Planning" in the quote? Yeah, we had two full days of meetings and presentations with all the members of all four flocks (some 400+ people I think) to plan work for the upcoming four months, or a "super sprint", so that's cool and definitely not just waterfall in disguise. I still like my actual work enough to just keep my head down and accept that this is how it is for now, but I'm not wrong thinking this sort of scenario is where people used to go  in these threads in the past, right? Any advice for someone who's terminally incapable of keeping it to myself when I know we can do better? I suspect I know some of the advice is gonna be "look for a new job", but this is my fifth developer job since finishing university and the first one that's not making me depressed, stressed to the bone or feeling like I'm about to get fired at a moment's notice so I really don't want to throw that away. At least not yet, maybe if it keeps getting worse on this front I'll reconsider, but I'm seriously hoping I'll just stay here pretty much indefinitely to be honest. It's also the first job where I was clear from the first interview that I'm trans, even though my ID and SSN indicate that I'm male I'm actually a woman, and it's just not been a problem at all, ever. Nobody's weird about it, nobody misgenders me even on the days when I'd be at the office without having shaved, it's just... I'm just seen and acknowledged in a way that's pretty rare. Plus my boss is understanding of my other mental health poo poo and doesn't question if I need a day or a few hours because of depression or sleepless nights or whatever. So really, apart from the "agile transformation" situation it's probably the best job I've ever had. * I replaced the corporate bullshit terminology with my own bullshit terminology to keep it anonymous-ish. The words we actually use are just as clear about their order in the hierarchy, and as a bonus the one I replaced with "flock" is iffy in a "this seems kinda racist if you think about it for two seconds" way. ** There's no double asterisk in the post referring to this, I just wanted to say sorry for going long and ranting here at the end.
|
|
#
?
Oct 30, 2020 11:37
|
|
|
Woebin posted:Any advice for someone who's terminally incapable of keeping it to myself when I know we can do better? I suspect I know some of the advice is gonna be "look for a new job", but this is my fifth developer job since finishing university and the first one that's not making me depressed, stressed to the bone or feeling like I'm about to get fired at a moment's notice so I really don't want to throw that away. At least not yet, maybe if it keeps getting worse on this front I'll reconsider, but I'm seriously hoping I'll just stay here pretty much indefinitely to be honest. I'm right there with you with the "terminally incapable of shutting up when people are inefficient". It's so grating to have to attend meetings where you're setting goals for things that depend on everything in the prior month going exactly right when you know that will never happen. But it's also nice to have continued employment at a place that respects you for who you are. At the same time, staying at any job "indefinitely" should not be your goal. Instead, you should stay as long as the balance of factors works for you. You're making a tradeoff right now (stupid corporate "agile") for something you need (basic human respect and $$). What if you channelled some of your frustration mental energy into looking for other jobs? Not a full search with submitting resumes or anything, but asking around, networking, trying to figure out where you could go next. Places that you know treat trans people right, and might have decent management practices as well. You'll feel more confident knowing there are 2-3 places out there you can apply to if corporate decides to get really stupid. Big corporate changes take a few months to settle in, and who knows, it could end up better than before, or most likely similar to before with a few different pieces. Or it could end up really stupid forever, and you'll be glad you looked around.
|
|
#
?
Oct 30, 2020 13:53
|
|
|
Safe sucks. You are completely correct in your diagnose of the issues. I too am driven insane by how ineffective companies are and despair to find an org not running at about a C+ level on it's best day. As above: prepare your resume, whatever leetcode interview skills you need and see what's out there. There's a bias for loss-aversion so don't let fear of moving on limit you.
|
|
#
?
Oct 30, 2020 14:44
|
|
|
Woebin posted:we never finish the work we plan in a sprint and we don't even estimate it anyway so the plans are a joke. This hits so close to home for a client I work with. That and the client's team lead/manager is so incompetent they literally don't add issues to a sprint/iteration so issues just kind of float out in a nether world. That doesn't matter because they're incompetent at setting up the infrastructure for their new system so nothing makes it passed Q/A as the test engineer literally has nothing to do related to their job.  I used to care, but now I'm jus there to see how far this poo poo is going to last. As long as I can shadow project manage and deliver to get paid, the client is too terrible to notice anything's wrong.
|
|
#
?
Oct 30, 2020 15:02
|
|
|
Sometimes it improves! Stuff like that might just need some time to settle. I think it's not uncommon that such transformations start with too much overhead. In the past 1.5 year the team I'm in changed from "3 hour sprint meeting, half hour scrums" when it was introduced to "1 hour sprint meeting, 15 min scrums" with way less overhead now.
|
|
#
?
Oct 30, 2020 15:25
|
|
|
I appreciate the advice! Definitely not about to start actively looking for options now, but I might start telling recruiters who get in touch that I'm open to hearing what they're offering at least. I think I might have misused the word "indefinitely", though. I don't mean that I hope to stay at this job forever, more that I hope for it to last a long time, until I choose to move on for whatever reason - I mean, positive reasons like "I've learned what there is to learn here and I feel confident enough in my abilities to seek out new things", not " this place is draining me and I hate it, I must escape". I dunno how much sense that makes? I'm not a careerist and I don't care much about getting paid a ton (I already get paid more than I really know what to do with, to be honest), all I ever want is to do work I can tolerate or ideally enjoy and not working more than I have to - I work to live, I don't live to work. Walh Hara posted:Sometimes it improves! Stuff like that might just need some time to settle. I think it's not uncommon that such transformations start with too much overhead. I try to respect and understand that, it's just real frustrating that they drag us developers down in the process. That and the fact that they're cargo-culting so much poo poo that they don't understand the purpose of. We've had several "backlog refinement" meetings that take forever and absolutely don't leave us with a more refined backlog most of the time, for instance, and I don't think that's even something that should be done in meetings. Just tell everyone to spend something like ten minutes every day looking through the top of the backlog and clarifying anything that's unclear, or flagging it if it's unclear in a way that person can't fix themselves. It's not hard! But I guess everything needs to be a meeting for some people.
|
|
#
?
Oct 30, 2020 16:40
|
|
|
Woebin posted:. We've had several "backlog refinement" meetings that take forever and absolutely don't leave us with a more refined backlog most of the time, for instance, and I don't think that's even something that should be done in meetings. Just tell everyone to spend something like ten minutes every day looking through the top of the backlog and clarifying anything that's unclear, or flagging it if it's unclear in a way that person can't fix themselves. It's not hard! But I guess everything needs to be a meeting for some people. Ughh I really feel you here. I think the trick is that the meetings are arranged to deliberately conceal the real problem: whoever’s meant to be in charge doesn’t have a clue about the backlog/tickets. Getting everyone in a room to discuss them spreads the blame around. That’s why they don’t take the absolute no-brainer move of telling people to look at tickets outside of a meeting. In that situation someone would have to actually answer the clarification questions, and nobody wants that, they want a confusing clusterfuck of a meeting where it’s not clear who’s responsible for anything. I try really hard to just stay quiet during these dumb meetings because the reasons they’re being held are all political and zero percent practical, but I agree it’s impossible.
|
|
#
?
Oct 30, 2020 17:09
|
|
|
Prism Mirror Lens posted:Ughh I really feel you here. I think the trick is that the meetings are arranged to deliberately conceal the real problem: whoever’s meant to be in charge doesn’t have a clue about the backlog/tickets. Getting everyone in a room to discuss them spreads the blame around. That’s why they don’t take the absolute no-brainer move of telling people to look at tickets outside of a meeting. In that situation someone would have to actually answer the clarification questions, and nobody wants that, they want a confusing clusterfuck of a meeting where it’s not clear who’s responsible for anything. I try really hard to just stay quiet during these dumb meetings because the reasons they’re being held are all political and zero percent practical, but I agree it’s impossible. I've also noticed that some managers are in so many meetings that the only way they know how to do things is to Schedule A Meeting for it. Then you end up watching someone triage their email for an hour without realizing they could've done this without having an audience. Usually these are the same people who have to think out loud. I was much happier in a former job after realizing that my manager was incapable of thinking things silently. He needed to talk them out to an audience and it actually slowed him down if I responded. I figured out how to just say "Mmhmm" the correct amount and then could just tune him out until he figured out whatever he needed.
|
|
#
?
Oct 30, 2020 17:27
|
|
|
Good point. I’m the opposite. Can’t think and talk. Backlog refinement is my major bugbear at the moment for that reason. Lead pulls up a ticket created by some product guy which says “We want to make the fizzbang widget spin around.” Somehow we’re supposed to be able to divine how to implement multiple tickets of that sort and estimate them during the meeting, even if it turns out nobody knows what the fizzbang widget is. Next sprint we get told off because the estimate was “inaccurate”. No poo poo! Nobody could look at the code because everyone was talking!
|
|
#
?
Oct 30, 2020 18:07
|
|
|
I have only ever experienced being on multiple teams at once as an enormous clusterfuck for a person, so I don't envy those UX-Designers. Our sister company also tried to split designers so that they'd work for more than one development team, which means they had even more meetings, and continuously clashing requirements. A bunch of them are no longer working there, and I don't blame them. The other way round, trying to do scrum with different people each working on multiple projects (few of which overlapped) was also a problem for us (consulting...), so now the company reverted to a weird hierarchical system, which is bad in many different ways, and still didn't get anything planned or aligned properly.
|
|
#
?
Oct 30, 2020 18:07
|
|
|
Hollow Talk posted:I have only ever experienced being on multiple teams at once as an enormous clusterfuck for a person, so I don't envy those UX-Designers. Our sister company also tried to split designers so that they'd work for more than one development team, which means they had even more meetings, and continuously clashing requirements. A bunch of them are no longer working there, and I don't blame them. Anyway she's on sick leave now, and in retrospect I think it was probably a combination of the stress getting to her and my own unfortunate way with words that triggered those messages of hers. That plus the design process being just as much of a mess as everything else, where she'd basically be forced to make up design sketches on short notice which were then passed to the devs as part of requirement documents without proper review, so we'd end up either starting work to implement stuff that often outright conflicted with higher level design guidelines or getting into long back-and-forths about why these designs needed adjustment and how. That probably felt more personal than it was sometimes, too. Ugh, the more I talk about this the more anxious I get. I swear there's a lot of great stuff about this job too! If it was just the dev team and the PO did her job of acting as a filter between us and stakeholders/suits it'd be pretty much perfect, but that ship has sailed by now.
|
|
#
?
Oct 30, 2020 18:27
|
|
|
Woebin posted:Oh yeah, the UI person and the others who are in multiple teams are expected to attend both teams' agile ceremonies, so they're stuck with double the amount of dailies, refinement meetings, sprint planning meetings, retros, reviews... it's a lot, really. The UI person especially seems to be getting really worn out from it, a couple of times when there have been meetings she's messaged me afterwards to say that something I said made her feel questioned or belittled. I do have a tendency to be blunt in ways that can come off as critical, and to put my foot in my mouth, and I apologized and explained how I'm pretty bad at certain social aspects but do my best, and asked her to let me know if I could do anything on particular to avoid causing similar feelings in the future. I figured it was all on me the first time it happened, but the second time it really seemed to me like she was actively reading malice into my words or something and I started thinking maybe she specifically dislikes me or something. As a UI designer myself, I do not envy the one at your company. It seems that she’s in a high stress, low psychological safety position, and having been in a similar position, I can say that you start to feel like everyone is out to get you, and you start getting hyper defensive. In my defensiveness I’d find myself lashing out and effectively picking fights with coworkers when I felt belittled/humiliated or singled out even though I’m typically easygoing and not very confrontational. I mean, I was certainly getting poo poo on for real and she might be too, but even if I wasn’t it still felt like it. The fact that she’s being pushed into generating conflicting designs that cause problems due to splitting her time between two teams/disorganized process is probably doing a number on her professional self esteem/exacerbating imposter syndrome. In an ideal world, she wouldn’t be doing double duty on overhead bullshit and would have good rapport with and respect from the dev team and you’d all work together harmoniously through well thought-out, clearly documented processes to design and implement cool UIs that are to spec. At my current company (which is waaaay better than my old company in pretty much every regard), I’m the designer and also the front end developer, so in a developer capacity I answer to the principal dev and for matters of design, they answer to me (though it’s usually me implementing my own designs). Helps that we have excellent rapport and no one has a huge ego. When everything is good and happy, it’s easy to deal with blunt criticism because there’s that underlying psychological safety and mutual respect, but when that foundation isn’t there, that sort of criticism can absolutely wreck you.
|
|
#
?
Oct 30, 2020 19:48
|
|
|
When in doubt, send your coworkers a chat message that says, "Sorry I got frustrated. (Boss nobody likes) was being a real rear end in a top hat." and then everybody's on the same side!
|
|
#
?
Oct 30, 2020 20:17
|
|
|
Oof, I definitely led some lovely refinement meetings before, but as a person who doesn't like to think out loud, it was super uncomfortable and as soon as I realized what was happening I stopped it. I'm sure I've made a million other mistakes as a lead but I didn't need any agile certifications to figure out I needed to prepare more (and get everyone else to help prepare) rather than everyone watching me type for 90 minutes. Although there's that one guy who seems allergic to writing a complete sentence/thought, so asking for context makes me feel like a 2-year-old playing the "why" game. That doesn't help. Thankfully we have a few engineers who set a good example and I think our team is improving. Anyways... reason I'm here is because we just hired a product owner (10th engineering hire), which, thank god, hopefully I can spend more time on stuff I'm actually good at. The PO detected we have a knowledge management problem, with docs scattered all over Google Drive and every previous attempt to organize them ending in failure. He started to recommend youneedawiki.com because it integrates with Drive until he realized it's been unsupported for a year or so. He came up with a list of alternatives but it's hard to find any good options. A lot of our info (maybe 75%+) is in Sheets or Slides so that means a lot of solutions will be inadequate. And a lot of them seem more focused on project management than knowledge management (e.g. favro) whereas I'm pretty happy with issue management in Gitlab, for now at least. Anyways, any advice on something along these lines? Anyone tried happeo for example? In short, the scope of this decision has grown far beyond "organizing our google docs" and I'm not sure how I feel about it. Yes, it would be good if we had something more visible than Gitlab for non-technical people to see the status of the work, but I like Gitlab and would like to give it more of a shot now that we have a PO. On the other hand we do have a knowledge management problem and maybe that means a whole new platform. I didn't realize how much knowledge management and task management are intertwined but it makes sense. Should I just stop being stubborn, bite the bullet and realize that probably we'll be on JIRA + Confluence someday and it might as well be now? Edit: sorry that this is regurgitating a tired topic and probably no one has enough insight into our team to give real advice, but  I guess I just needed to think out loud 
SurgicalOntologist fucked around with this message at 20:29 on Oct 30, 2020 |
|
#
?
Oct 30, 2020 20:25
|
|
|
SurgicalOntologist posted:Oof, I definitely led some lovely refinement meetings before, but as a person who doesn't like to think out loud, it was super uncomfortable and as soon as I realized what was happening I stopped it. I'm sure I've made a million other mistakes as a lead but I didn't need any agile certifications to figure out I needed to prepare more (and get everyone else to help prepare) rather than everyone watching me type for 90 minutes. Although there's that one guy who seems allergic to writing a complete sentence/thought, so asking for context makes me feel like a 2-year-old playing the "why" game. That doesn't help. Thankfully we have a few engineers who set a good example and I think our team is improving. This area is one that constantly pops into my head as something I could try to make a good version of as a little side project but every time I think about it for more than an hour I begin to realize why no one has really succeeded in making a Really Good knowledge management system. And those reasons all live outside of the realm of any particular company beyond a certain size having a probably impossible time getting all of their teams to use one platform. So please report back if you find one.
|
|
#
?
Oct 30, 2020 20:48
|
|
|
Prism Mirror Lens posted:Good point. I’m the opposite. Can’t think and talk. Backlog refinement is my major bugbear at the moment for that reason. Lead pulls up a ticket created by some product guy which says “We want to make the fizzbang widget spin around.” Somehow we’re supposed to be able to divine how to implement multiple tickets of that sort and estimate them during the meeting, even if it turns out nobody knows what the fizzbang widget is. Next sprint we get told off because the estimate was “inaccurate”. No poo poo! Nobody could look at the code because everyone was talking! There's a bunch of problems there... 1) Refinement is not estimating, it's a step before that. 2) Is the Product Owner there? Are they explaining what the fizzbang widget is? 3) Do you know these tickets ahead of time? Are you able to async ask questions like what is a fizzbang widget? 4) Do you have a ready for Grooming/Refinement tag? And are you empowered to remove that tag when you realize that no one knows what it is? Fix those 4 if I'm reading it right. Best thing I've done with my PO hat is said, "My commitment is that I'll give you the list of stories at least a week before refinement and answer any questions posted in jira/confluence in at least two hours. Your commitment needs to be that you'll read those stories and ask the questions prior to the refinement meeting."
|
|
#
?
Oct 31, 2020 01:49
|
|
|
Hughlander posted:There's a bunch of problems there... We've done this with a Tick-tock system as we call it. During a tick refinement meeting the PO introduces new tickets. He explains what's wanted and we discuss a very general approach for each ticket. At the very least we identify what components of our stack we'll need to touch to complete the ticket. Then we'll appoint team members to investigate further. Usually the main expert on the component, and one other person, to prevent that expert from being the only one to understand the ticket properly. Outside of the meeting, the appointed team members fill out the ticket with a proposed approach and any other relevant technical details. During this time, if any further questions about the functionality come up, we can always ask the PO and he's usually quick to answer. In the tock refinement a week later, the appointed team members present their proposed approach to the theme, there's time for the rest of the team to ask questions or suggests tweaks to the approach if they make things simpler. If there's no or only minor tweaks we estimate the size right away, if the discussion leads to changing the approach in a major way, those theme members get one more week to update the ticket, and we'll resize it the week after. Of course none of that is possible if you refine all your tickets last second. We use Scrum together with the SAFe Big Room Planning, and I'm as unhappy with SAFe in general as most of you, but we've managed to mold the BRP into a form where we tell stakeholders if they don't bring their tickets at least 2-3 weeks before the next BRP, they'll have to wait at least two more months for them. During the BRP we make a general schedule of the next 4 sprints, see if there's no conflicts with other teams, and we only plan about 50% of our velocity. The rest is divided between our maintenance budget, the ~25% of time developers get to keep our (older) software in a decent, up to date state, and for fixing ad-hoc bugs, or if there aren't any, for taking up some small nice-to-have features for our stakeholders to fill up our time. I think why this works so well for us and why the management is fine with this whole approach is because we began as a tiny little startup some years ago where everyone was responsible for ten different things at once. Like, before I got my job here, the same person could be the PO and the sales/marketing manager. And Scrum was introduced not to make a stale company full of suits "agile", but to bring order to the chaos and being able to tell the customers they had to wait for features until we could properly plan them, instead of us trying to work on everything at once. I haven't heard of many companies that used Scrum to get from complete agile chaos to a form of agile order, but we did. It was what allowed the company to grow beyond the startup phase without losing its soul.
|
|
#
?
Oct 31, 2020 08:28
|
|
|
Hughlander posted:There's a bunch of problems there... Completely agree with you. Thanks for breaking it down like that, it will help my argument. Our previous lead used to do all the heavy lifting of actual refinement and clarification himself, and our ‘refinement’ meeting was mostly just estimating. (That may have been a bad thing that he did it on his own, but at least all the steps were getting done by someone.) New lead doesn’t do any of that and, when I ranted about how it was impossible to estimate when nobody had ever seen this half-written ticket before and even the lead sounded like he was reading it for the first time, he told me “we should be comfortable with some uncertainty”. I was... not pleased. The battle for sanity continues.
|
|
#
?
Oct 31, 2020 11:16
|
|
|
We use GitLab as our primary storage/source of information, but things like our docs are written in markdown, and we have a CI build that renders them and pushes them to a server, so you can click through from the project's page... We also use GitLab's project planning for most things, but we are in somewhat "inmates running the asylum" situation, as we are 7 man technical team with grand total of 2 non-tech people in the company, so we get to decide on tools that we like working with and the rest of the company has to adapt.
|
|
#
?
Oct 31, 2020 21:39
|
|
|
Halloween in development: some guy in brazil is spamming our feedback system with nonsense and attaching pics of MTG cards with upside down crosses drawn over them. Also some porn with the crosses too
|
|
#
?
Nov 1, 2020 00:16
|
|
|
Prism Mirror Lens posted:Completely agree with you. Thanks for breaking it down like that, it will help my argument. Our previous lead used to do all the heavy lifting of actual refinement and clarification himself, and our ‘refinement’ meeting was mostly just estimating. (That may have been a bad thing that he did it on his own, but at least all the steps were getting done by someone.) New lead doesn’t do any of that and, when I ranted about how it was impossible to estimate when nobody had ever seen this half-written ticket before and even the lead sounded like he was reading it for the first time, he told me “we should be comfortable with some uncertainty”. I was... not pleased. The battle for sanity continues. The answer to "We should be comfortable with some uncertainty" is to give the max estimate allowable. Particularly if the estimate is reserved for "This should be broken up it's too big." The reason being of course, "The level of complexity is extremely uncertain as written, It could be a 3, it could be a 21, so 21 it is."
|
|
#
?
Nov 1, 2020 01:25
|
|
|
Xarn posted:We use GitLab as our primary storage/source of information, but things like our docs are written in markdown, and we have a CI build that renders them and pushes them to a server, so you can click through from the project's page... We also use GitLab's project planning for most things, but we are in somewhat "inmates running the asylum" situation, as we are 7 man technical team with grand total of 2 non-tech people in the company, so we get to decide on tools that we like working with and the rest of the company has to adapt. I'd love to manage docs with git in general although we do have some there. I never thought of using a static site generator, that's a no-brainer. At least for internal engineering stuff or docs the non-tech people don't need to edit. I might just set that up now... But yeah, we're more like half and half, and apparently for some people participating in a discussion on a Gitlab issue is some kind of black magic way above their pay grade. For general company docs coda.io looks like an interesting option, though I guess making "smarter docs" isn't necessarily the same as organizing them. I wonder if these "smart tables" type platforms will also be too difficult for our non-tech people. Anyways, regarding Gitlab, what features do you use for project planning and how do you supplement? We make heavy use of boards, naturally, and milestones. We use epics a bit and the epic roadmap seems like it has potential as a view to show to non-technical stakeholders, but unless we put every issue into an epic it doesn't makes sense. The new feature of iterations seems like where they want to put velocity-tracking functionalities but it's not there yet.
|
|
#
?
Nov 1, 2020 11:46
|
|
|
SurgicalOntologist posted:I'd love to manage docs with git in general although we do have some there. I never thought of using a static site generator, that's a no-brainer. At least for internal engineering stuff or docs the non-tech people don't need to edit. I might just set that up now... We use https://www.mkdocs.org/ with the material theme for all our project / internal documentation and everyone likes it. Every team gets their own sub-site, etc, for catch-all docs.
|
|
#
?
Nov 1, 2020 17:23
|
|
|
SurgicalOntologist posted:For general company docs coda.io looks like an interesting option, though I guess making "smarter docs" isn't necessarily the same as organizing them. I wonder if these "smart tables" type platforms will also be too difficult for our non-tech people. We've started using coda a lot and it's really good for the kind of general-purpose sometimes prose, sometimes tables, sometimes random embeds from other web based saas stuff that in other contexts ends up being like a page of links, or a half google doc and half google sheet, etc etc. The only thing I can really say it's missing is a robust change tracking system and other multi-party-editing nice to haves. Like the comment system isn't great, you don't have the kind of versioning information that google docs does, you don't have a "suggesting" input mode, that sort of thing. Other than that though it's really good.
|
|
#
?
Nov 1, 2020 18:20
|
|
|
quote:From a Product perspective, we want something as soon as possible Wow no waaay 
|
|
#
?
Nov 2, 2020 19:38
|
|
|
SurgicalOntologist posted:But yeah, we're more like half and half, and apparently for some people participating in a discussion on a Gitlab issue is some kind of black magic way above their pay grade. That's a firing  Seriously though, just posting some simple text to GitLab issues is not complicated. If someone refuses to do it, because it's new and scary, treat them the same way you would someone telling you that they won't learn how to use google docs, because they only use MS Office (or vice versa). SurgicalOntologist posted:Anyways, regarding Gitlab, what features do you use for project planning and how do you supplement? We make heavy use of boards, naturally, and milestones. We use epics a bit and the epic roadmap seems like it has potential as a view to show to non-technical stakeholders, but unless we put every issue into an epic it doesn't makes sense. The new feature of iterations seems like where they want to put velocity-tracking functionalities but it's not there yet. We use epics quite a bit, but only for things that are meaningful. Things like refactor X, update dependencies, etc, are usually not put into an epic, those just happen. We are not actually doing stuff like estimating velocity though.
|
|
#
?
Nov 2, 2020 20:41
|
|
|
Is it an overstep to give a junior/intermediate or even peer IDE tips when you're pairing? Sometimes when I'm watching others drive they're just doing stuff real slow/ineffectively (i.e. using the file browser pane to find files instead of cmd+t, never using split pane editing, etc.) but maybe that's just their preference?
|
|
#
?
Nov 3, 2020 04:48
|
|
|
prom candy posted:Is it an overstep to give a junior/intermediate or even peer IDE tips when you're pairing? Sometimes when I'm watching others drive they're just doing stuff real slow/ineffectively (i.e. using the file browser pane to find files instead of cmd+t, never using split pane editing, etc.) but maybe that's just their preference? I think it’s totally ok but always phrase it in terms of your workflow - “I find it really helps to see the code and the tests side by side. You can easily get into split pane view with (shortcut)” or “ahh there’s a really great shortcut to do (thing) that I use all the time”. It is frustrating to watch someone drive really slowly but I guarantee someone else watching you would think you do things weirdly too. Just think about your tone and language as if you were on the receiving end of the advice and you’ll be fine. I always find it awesome to learn about a new workflow trick or shortcut.
|
|
#
?
Nov 3, 2020 04:58
|
|
|
Showing them how you prefer to do things when you're driving is generally going to be the easier way to pass along tips.
|
|
#
?
Nov 3, 2020 05:10
|
|
|
Plorkyeran posted:Showing them how you prefer to do things when you're driving is generally going to be the easier way to pass along tips. This. I would try to avoid backseat driving. Also, the examples you gave sound much closer to preference than actually doing anything wrong IMO.
|
|
#
?
Nov 3, 2020 05:51
|
|
|
rujasu posted:Also, the examples you gave sound much closer to preference than actually doing anything wrong IMO. I would never say this to a co-worker but flipping through the file browser trying to find a file whose name you know is extremely wrong. File browser is for when you know where the file is but you can't remember what you called it.
|
|
#
?
Nov 3, 2020 06:14
|
|
|
prom candy posted:Is it an overstep to give a junior/intermediate or even peer IDE tips when you're pairing? Sometimes when I'm watching others drive they're just doing stuff real slow/ineffectively (i.e. using the file browser pane to find files instead of cmd+t, never using split pane editing, etc.) but maybe that's just their preference? Time saved using keyboard shortcuts cuts off noise levels of your time spent as an engineer. It doesn't matter. Teaching someone how to stay focused on important features, not over-engineer, write maintainable and testable code and debug issues effectively will do them and your team orders of magnitude more good now and in the future than any silly IDE nits.
|
|
#
?
Nov 3, 2020 06:17
|
|
|
I'm a notorious keyboard shortcut forgetter and some people who'd prefer to hang out in vim all day get quite frustrated by my workflow involving some clicking around. It's kinda funny when they try to be helpful and just don't seem able to realize that keyboard shortcuts fall right out of my head again after the conversation. I don't seem to be any slower than them at finishing features though. Maybe the exact way you control your computer isn't nearly as important as the way you think out new code and write it and test it and stuff.
|
|
#
?
Nov 3, 2020 08:18
|
|
|
|
| # ? May 9, 2024 07:10 |
|
|
Indeed. The amount of time gained by using keyboard shortcuts is infinitesimal compared to the time it takes to think of a working design and writing the actual code.
|
|
#
?
Nov 3, 2020 08:53
|
|