|
Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do. Yadda yadda points are abstract, I know, but when you have somebody else saying that your story points have to be Fibonacci and can only go as high as 13 points, whether they're more like weeks or hours suddenly matters a lot more for deciding when you have to break down work more.
|
#
¿
Apr 18, 2016 17:41
|
|
|
|
| # ¿ May 10, 2024 15:02 |
|
|
Okay I'm not too surprised by the answers. I think I have a better question anyways. Once the smoke clears on planning and you have closed the story, how much time do your smallest stories tend to take, and how much time do your largest stories tend to take? I'm curious if there's a common granularity here. Note that I am saying nothing about points here, but I suppose I will just show my hand for full disclosure. I'm thinking too that 1 point roughly corresponding to a week is way to coarse. You can argue it doesn't matter, but I'm not allowed to do 0.5, and zero is troublesome for calculations. I'm suspecting that a lot of people wind up with the smallest user stories being about a man-day of work. That's not even necessarily a full 8 hours.
|
|
#
¿
Apr 18, 2016 19:02
|
|
|
Vulture Culture posted:There's no such thing as an 8-hour person-day of development work unless your team members don't talk to each other or their management, don't have meetings, don't do code review, don't meet or talk with users, don't work with vendors, don't respond to emails, don't support production issues, and don't context-switch. Get this dumb fallacy out of your organization immediately, because it's one of the easiest to disprove. Sorry, I was trying to say that but I wasn't specific enough. What I was meaning is that I figured the smallest stories were a full "man day" of work, which is even finer than a full 8 hours specifically because of all that overhead. In contrast to being forced to make user stories be a full week long, it's quite a difference. In fact, I just had to deal with some confusion that arose from having to make really large user stories that would have normally been paced differently due to having to aggregate everything into a giant, one-week-ish block.
|
|
#
¿
Apr 18, 2016 19:27
|
|
|
Cicero posted:How do you measure how complex a programming task is if not in how much time it will take? Points are nice for being able to roughly assess the complexity of different work in relation to each other without necessarily knowing how long any one of them will take. So I might not know if activity X may take 2 hours, but it sounds like it is half as complicated as activity Y. I eventually figure out activity Y will take 4 hours, and hence I can make a base assumption that activity X will be something like 2 hours. Well, it may not be a linear correlation like that; practice will show what it really is. At the end of the day, people do want to know how long it will take to do something, and they're asking that from people that either don't know and/or don't want to commit to a number right away. Having points gives planners some currency to use that keeps everything moving. My situation with this is I'm being compelled to have my lowest possible number for a story point correspond to the kind of work that normally takes us a week. It's kind of loving up some stuff because now we're throwing stuff together that would normally be three user stories that get interwoven with other work. It starts to look like two user stories have circular dependencies when those dependencies are completely managed.
|
|
#
¿
Apr 18, 2016 19:40
|
|
|
Cicero posted:But why does it sound half as complicated? Because to me, when I think something sounds half as complicated, that's because it feels like it'll take half as long. I guess to me "complexity of a task" and "how long it will take" are effectively the same thing. Yeah, you thought it would take "half as long," but you never said exactly how long. That's where the points come in. They give planners some relative method of sizing work without having to get into a war over the actual time. Now, in practice, you are making the plans and you are doing the work, so you have a pretty good idea of what it means. However, the points help with the program managers and like that make this thread's title unfortunately appropriate. 
|
|
#
¿
Apr 18, 2016 20:31
|
|
|
Vulture Culture posted:There's no benefit to shoehorning a couple of Agile buzzwords into a waterfall development process to pull the wool over the dev team's eyes. If the business is going to insist on waterfall, they're going to get waterfall. The terrible thing about the hybrid processes is if somebody doesn't like what you're doing, they can try to shoot it down as either being too agile or too inagile. Set up some work to go through Agile? Wait a minute, we need to talk about this and plan it out first. Give them a plan? Wait a minute, this isn't Agile.
|
|
#
¿
Apr 18, 2016 23:26
|
|
|
Messyass posted:As long as your projects never take longer than two weeks you'll be fine.
|
|
#
¿
May 3, 2016 15:40
|
|
|
I wanted to set up some chat system for my side of the organization, but I knew that would be herding cats a few years ago. I tried to experiment with moving discussions onto an internal NNTP server, but it never caught on. They apparently have an IRC server, but it's for coordination between internal teams and external developers and customers, and it was heavily controlled. So I just gave up. But I looked into Slack to see the deal. Some people wanted to get it supported by IT without, you know, any of the security policies or anything else IT would have to do. So somebody is doing a pilot with Rocket.Chat. Can somebody contrast it with Slack? It seems good enough for us to do general, archived chat. We have stuff for just about everything else.
|
|
#
¿
May 16, 2016 06:06
|
|
|
Hur hur we can't use TeamCity for CI/CD because it's Java and it's too easy to call it "TeamShitty." Instead we'll send off cron jobs to poll our git repositories, and trigger a rebuild on deltas using a Cygwin runtime. I know, to make it cross-platform-compatible we'll also use autotools! Rocko Bonaparte fucked around with this message at 23:24 on May 23, 2016 |
|
#
¿
May 23, 2016 23:22
|
|
|
Mniot posted:I think you've found the real TeamShitty. Ahh but at least it doesn't use slow Java! (previous job was benchmarking and analyzing Java code generation quality for semiconductors) Want death.
|
|
#
¿
May 23, 2016 23:54
|
|
|
revmoo posted:Jokes on them when you pull those scripts seamlessly into a real CI setup. That would violate the very clear and robust standard we are adopting! Edit: After getting some rough build instructions, because of course nothing built: Me: I'm doing a git reset to clear out all the stuff autotools made... .... Me: Wow this is taking awhile? Them: Are you on Windows? Me: Using Cygwin. Them: Are you on Windows? Me: I guess so. Them: Everything is slower on Windows.  I am working with Slashdot posters from 2002. This all probably runs on a Beowulf cluster of Linux xboxes. Rocko Bonaparte fucked around with this message at 00:24 on May 24, 2016 |
|
#
¿
May 24, 2016 00:09
|
|
|
B-Nasty posted:You can get a jump on your new role by blocking out 8:30-18:00 on your calendar in 60 minute intervals, Monday through Friday. Just use the placeholder 'meeting'; you can fill in the specifics as you learn them. As an individual contributor trying to write software in a large corporation, this is what I already have to do.
|
|
#
¿
Jun 17, 2016 20:16
|
|
|
ratbert90 posted:Like, they don't understand you have to free memory that you allocate. That there are efficient ways to use memory. God help you if you try to mention stack vs heap. Ahh but do they at least try to initialize or write to it before they read and make decisions off of it? That's progress!
|
|
#
¿
Jun 28, 2016 19:26
|
|
|
return0 posted:If I had to work at a place that used SVN, I would checkout the SVN repo into a Git repo and work in that. Until the git repo explodes because they're storing gigabytes of binary files in it too.
|
|
#
¿
Jul 21, 2016 22:44
|
|
|
Portland Sucks posted:Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I got an amazing offer to rebuild a business application, good pay, remote work 4/5 days a week. The project itself though, I'm not sure how to approach it without literally asking the guy who wrote this mess to just sit next to me all day and explain why Contains("Tf") means good and Contains("TG") || Contains("56") && Contains("LOL") means bad. There are like 50 classes of this that need to be refactored. Somebody already posted the book, so I'll just post some anecdotes from having to do literally the same thing--refactor lovely EE code--for a living: 1. Get all that stuff in good source control. I say it because EE trash heaps usually aren't, so I assume nothing. Being able to easily create throwaway branches in git will make it less intimidating to mess with it. 2. Also start to get some unit and integration tests in there so you can start to reign in the whack-a-mole game you'll inevitably play. 3. Encapsulate the globals before you try to deal with any objects that are in there. The data flow problem of getting that global state passed around will drive most of your refactoring decisions. 4. It will probably also help to review and revise the entire source layout of the project. 5. If there was any prior source control, try to get all the binaries out of it. I had a 16GB subversion project inflate to 48+GB when migrated to git, and then collapsed to 20MB after rewriting out all the binaries in the history. 6. Consider added a usage statistics agent for marking code paths that actually aren't dead. You might be afraid to flatten some code because something might use it, but you don't have proof. So put a phone-home call in there that goes somewhere that you can find a report of it. Put another line in the normal path. If after some time in the next release, you see the normal path but not the dead path, then you can assume the risk of killing the dead stuff. If you get no usage information, you know that mechanism is not working. 7. The good news is that most of the refactoring is collapsing ten-page-long if/else clauses that have 95% of the same code in them. 8. When people give you poo poo about it, tell them you're "adding functionality by removing code." 9. Rest assured that any incomprehensible math you see was probably done either from iterative guessing and/or poor notions of premature optimization, and listen to the voice in your head. At the least, you can encapsulate the mathematical model and write unit tests against it to verify that a revised model computes the same. 10. If you are second-guessing why they didn't use a function/method native to whatever language they're using, it's because that isn't native to the basic C code they learned in that one semester of C crap they might have gotten in college. They just didn't know about it and it's probably safe to use the library. 11. There's also a good chance that the parts that are very EE-centric and out of your domain of expertise are also poo poo and you shouldn't second-guess yourself with them. Good EE's are fully capable of writing clean code. It took me years to figure out most of the EEs I was working with couldn't even do core EE stuff. Meanwhile, the ones that could write this stuff cleanly are now your best friends at work. So don't paint with a broad brush--like I just did. 12. Watch out for version 2.0 syndrome after you comprehend the code base and know enough to blow it all up and start over. The 2.0 may end up taking far too long and discredit you.
|
|
#
¿
Jul 27, 2016 22:45
|
|
|
Portland Sucks posted:Great timing. I've been working on #7 for the last day and its enough to literally give me iterative nightmares. I talked to my boss about doing a lot of this and he told me "you know sometimes it is better to just rush it and get the product out rather than taking the time to do it the right way the first time -- we don't want to miss our window of opportunity. Maybe we can revisit doing it your way once we've got a working product." As for the timetable thing, if it's that compressed of a schedule, then just refactor the parts that are already proven to be broken. The whole thing might be broken, but you can readily justify the parts currently blowing up in people's faces. After all, you have to spend the time to comprehend and adjust that code already. Dealing with the other sections is picking extra battles.
|
|
#
¿
Jul 29, 2016 17:20
|
|
|
Iverron posted:So we're apparently doing a "DiSC Assessment" course as an office next week (devs, designers, social media, etc). After some preliminary googling this appears to be the same Myers Briggs psuedoscience bullshit I've dealt with in far more corporate-y environments. You have to roll with it, but I wouldn't take any stock in what the tests end up concluding. Real personality tests--like a properly administered Myers-Briggs test--are too expensive and too rigorous for a basic corporate exercise. Sure, there are 100-question tests or whatever that lump you into categories, but they're just about as good as Facebook quizzes that determine which anime character you are. For one, a real personality test will factor in context and try to reduce its effect in order to better reflect your consistent personality attributes. When you go into work, as your role as a worker, sit in some quiet room or whatever, and take this test, then all of that stuff factors into the results. As an anecdote, I remember actually getting tested twice on the same pseudo-Myers-Briggs test. On the first time, I was in my home office, alone, with headphones on. I was rated as an introverted cave troll that would turn to dust if exposed to sunlight. A little later, I had to take another one after getting out of a Toastmasters club meeting where I was the club president. I was then apparently an extroverted social butterfly that would turn to dust without the vital life energy of social symbiotes. You will self-report differently on a test based on the context. Consider those retail tests that want you to swear up and down that you'd throw your parents in jail if they walked in the store and walked out with a gumball they found on the floor or whatever. It should be no surprise with anybody that does technical work that they like to be mostly left alone in a quiet environment when doing that kind of work. If you asked people what they wanted when they were in that context, nobody should be surprised. That doesn't entirely define the person, their passions, and particularly how to frame their careers. Some of this stuff can have some merits. I remember having to do some strength finding thing. They made us all read a book. The different categories, the testing, and the exercises were bunk. However, thinking about people just outright having particularly good strengths in certain areas is a worthwhile message to remind people sometimes. They could have just sent around the foreword. Edit: If somebody wants to really get their mind blown, look at The Organization Man. Personality testing and how its abused is mentioned in there, and that book is from the 1950s. Hell, just hearing him observing people complaining that college needs to be more skill-oriented in the 1920s, and lamenting that colleges are slowly becoming just a corporate training ground so companies don't have to put in multi-year orientations is a mind-binder. Rocko Bonaparte fucked around with this message at 06:20 on Jul 31, 2016 |
|
#
¿
Jul 31, 2016 06:17
|
|
|
TimWinter posted:I feel like this is a problem we have, as I work with an inherently sequential process (launching and deploying test clusters) and figuring out state is either a matter of a) give up and go ask our platform's api surreptitiously or b) write statefiles everywhere and cry when they fall out of sync or need to be updated, also ask our platform's api surreptitiously but only for the bits you can save to a statefile. Any good place to read up on global state re data flow? I imagine it'll use some awful java program as its examples but the underlying issue rings similar. The stuff I was most recently dealing with here didn't really have any rationale for being a global at all. People just started instinctively declaring everything as globals. There were a few cases where I put them in an object and didn't really have to do anything else; all the stuff was being used in a scoped way anyways. Before getting into writing any code at all: isn't your kind of problem something that can be handled with configuration management tools? So if that's a no-go, you can at least wrap all that stuff up in some kind of container representing context, and pass that around to all the different steps in the sequence. At least that way, people can look at that object's definition to determine what all is available to them in one place. This is a stark contrast to globals where they could be vomited all over the place, redeclared with type-o's, or declared in nested scopes. You might then be able to do something like the State pattern or whatever to describe how to add new sequences to the process. You'd pass the context to each state.
|
|
#
¿
Aug 2, 2016 19:14
|
|
|
Vulture Culture posted:Lean methodology doesn't say anything about redundancy in roles. In fact, the first bullet point under Eric Ries' Lean Startup principles is "eliminate uncertainty," which welcomes risk management where appropriate. Lean is not a cost-reduction strategy. Eliyahu Goldratt's The Goal itself, which developed much of modern Lean methodology out of the Theory of Constraints, focused on properly identifying and resolving production bottlenecks. Certainly, having a situation where a single human can go out and tank the entire production line is not a good strategy for reducing bottlenecks. The respond might have been inappropriate because the OP was using lower-case "lean" instead of upper-case "Lean," but I concidentally got to read a thread today about upper management adopting a scaled agile model "not for efficiency."
|
|
#
¿
Aug 8, 2016 23:15
|
|
|
necrobobsledder posted:I take it that you were introduced to SAFE then? Run I've had that gun pointed to my head for a few years. They're now trying to roll it out to a hardware QA organization, where it's really bonkers. I'm writing code so it at least makes a little bit of sense. I'm not saying it's the smart thing to do, just that it at least makes sense. For the other folks, I have been struggling to try to get them advice. I don't know how the hell they should scrum.
|
|
#
¿
Aug 9, 2016 01:31
|
|
|
I end up having to use reflection when doing something with plugins. It looks like the right thing to do then. Is there a better general approach?
|
|
#
¿
Aug 19, 2016 15:13
|
|
|
Yeah okay. Plugins are fine, but cramming a square peg into a round hole in your application is a whole different thing. I've done some dynamic loading with Java a long time ago IIRC, but most of my stuff was .NET. I'm not sure if I ever actually even looked at MEF for that. I want to think I did and got killed by the knights who say, "NIH."
|
|
#
¿
Aug 19, 2016 19:16
|
|
|
ToxicSlurpee posted:At work I had to come up with a set of goals that I'd try to work at. It should be the absolute value of lines of code. How else can you add functionality by removing code?
|
|
#
¿
Aug 22, 2016 16:25
|
|
when I read that because it's just so profoundly stupid. That and I'm negative on that metric because some of the first tasks I got at work were along the lines of "there is a poo poo load of bad, old code for bad, old features we don't use anymore. Spend a few days being a software janitor and yank that crap out."
|
necrobobsledder posted:Never forget that the code you bust your rear end writing today is the code that will be the legacy code of tomorrow. Everyone that's written Perl at odd hours of the night is intimately familiar with this reality. Ugh. This reminds me that everybody on LinkedIn vouches for my skill in Perl, so it's the highest ranked language in my LinkedIn skillset. The last time I wrote Perl was when I was home with a sinus infection sometime in 2010.
|
|
#
¿
Aug 22, 2016 23:01
|
|
|
Hughlander posted:You can manage that I think. Or at least prevent new ones from showing. Ahh yes! Yes you can! And I just did! ("debugging" is now my most-vouched skill. =/)
|
|
#
¿
Aug 23, 2016 03:04
|
|
|
PT6A posted:How do you get up to 10KLOC in a single class unless your design is extremely subpar? The answer is probably Minecraft modding. I saw a crash before from a class that had more byte code than the JVM allowed. In a single method.
|
|
#
¿
Aug 26, 2016 19:28
|
|
|
More tales (or is it tails here?) from Dinosaurland: We wanted to create a web portal to expose to end users all the stuff we have. They can search for and select things they want from it that would go in a virtual shopping cart. That way, they can get it all at once at the end after aggregating everything together. I now have to entertain the whims of the dinosaur that didn't want to use TeamCity because "it's Java." Also, he has a "superior" solution using cron and autotools. I was thinking that given our organization's experience, we could use Django or ASP.NET. I expect when I brought up the activity with him that he'd want to use a LAMP stack because that existed before 1999--the magic year after which this guy thinks everything is poo poo. I mean, he won't say that, but it just works out that way. Okay, he was partially receptive to Markdown, which was invented in 2004 or something, but only because it reminded him of something older. So yes, he wants a LAMP stack. Okay. The P there can mean many things. I assumed he wanted to use Perl, which would make my puke a little. He wanted to use PHP. loving PHP. For a new project. Nobody else here does PHP. It's either C# or Python. Well, he has a framework for it he wrote already that can do the basics in a day. Somehow, I'm even less reassured. He volunteers to write it all. I don't volunteer to plug up its hemorrhaging butthole when it eventually bursts. Well, Django and ASP.NET have the basics to do it in a day too. But ASP.NET is Microsoft, so that's a no-go. Remember that the dinosaur is the personification of a Slashdot poster from 1999. Django is bad because he worked in web hosting for 10 years and "you own everything you put up there--including the entire framework." Me? I'd much rather by glomming through Django to figure out when something went wrong rather than 10,000 lines of some god-knows-what PHP framework that I am quite sure is a far cry from an MVC pattern. Oh and what about more difficult use cases? Well, we will talk about that after we implement the 80% necessary stuff in PHP. At that point, we will just pray nobody wants to do anything more with it since I'm sure that framework will fall on its rear end. Meanwhile, a Django implementation would be eating it for breakfast. My life.
|
|
#
¿
Sep 8, 2016 22:15
|
|
|
My Rhythmic Crotch posted:Medical software by any chance? Nope--I have been marooned on the Planet of the Electrical Engineers.
|
|
#
¿
Sep 9, 2016 07:36
|
|
|
leper khan posted:PHP has maintained MVC frameworks. I wouldn't use them, because PHP, but they're there.
|
|
#
¿
Sep 9, 2016 15:39
|
|
|
I have discovered the term "system engineer" is apparently very volitile in particular. It general implies integration, but it could be a weak technical, customer-facing position. If I were defining the role, I would consider it a system engineer role if it is dealing with a lot of plumbing to make things that are usually oblivious to each other. So it is broader where an architect would be deeper.
|
|
#
¿
Sep 18, 2016 05:54
|
|
|
CPColin posted:Thanks, all. I was getting the impression, during our conversation, that "Systems Engineer" was closer to DevOps than I wanted my role to sound. My boss even said, "The role would be a developer who supports DevOps." and I suggested the term "DevOps" already encompasses that. That is a new one to me, but after the goofy Amazon interview I had for a systems engineering position, I am absolutely unsuprised. I guess a lot of places have decided that a systems engineer is to a sysadmin as a custodial engineer is to a janitor. So yeah, DevOps is DevOps. I hate having to get into semantics and establish taxonomies, but people keep coming up with their own interpretations of words that should be an industry standard. So is life. It is worth fighting over because it will lead to more misunderstanding later if you do not clarify this stuff now.
|
|
#
¿
Sep 18, 2016 07:04
|
|
|
revmoo posted:Home Depot uses that word too. One of my first jobs was "Lot Associate" which is somehow more demeaning than "Cart Bitch" I read that two times as "Lost Associate." I don't know what is worse.
|
|
#
¿
Sep 19, 2016 19:47
|
|
|
Greatbacon posted:Yeah, assuming you use git, you should be able to configure things so that all code going into your develop branch needs to be merged in from a feature branch, and that merge can't occur until at least 1 or 2 other develops have looked at and approved the merge. You can make it a +2 rule with the CI infrastructure providing one of the votes.
|
|
#
¿
Sep 29, 2016 19:22
|
|
|
necrobobsledder posted:Schedule slip was most frequent from needing more and more check-offs for any form of change in software or infrastructure and perfect JIRA usage and guru-level agile training won't turn waterfall across cross-functional teams into agile. A lot of meetings got delayed from so much decision-making needing top-down approvals and not enough availability of SPOF decision-makers. In one case a really low-risk, 2-line bug fix that took a guy 2 days took 14 sprints to get approval to deploy in prod and during the 14 sprints I clocked 500+ man hours dealing with it (we didn't have the approvals to do the automation for that part either, it was that fix or manually fix 200+ servers daily).
|
|
#
¿
Oct 1, 2016 19:13
|
|
|
Pollyanna posted:Just got a (small) PR for caching Bundler gems via a Docker container rejected, with the reason "Please bring this as a part of the improvement ideas for the team to prioritize".
|
|
#
¿
Oct 5, 2016 16:40
|
|
The PR alleviates an issue with a branch that was recently merged into staging that also requires a new gem, and people's Docker containers blew up as a result. I understand the importance of prioritizing changes, but this seemed like a critical issue.
|
It sounds like a typical bureaucracy of technical people with terrible social skills who don't trust each other.
|
|
#
¿
Oct 6, 2016 19:29
|
|
|
AskYourself posted:With one integer variable there is 4 biliions possible scenario. 2 integer ? that's 4 billion square... How can you really test all possible scenario of any function that has 18446744073709551616 possible scenarios ? Even if you can test a billion time per second it would take over 200 thousand years to test them all. Your tests just have to verify you can correctly go through the different code paths as much as possible. You'll find plenty of bugs just dealing with that. You're not worried about a cosmic ray flipping a bit in RAM and wrecking your program. Okay, you're not normally worrying about a cosmic ray flipping a bit in RAM and wrecking your program. Generally, if you have something that does X, you first just verify it can do X in its most controlled way possible. You can then handle more evil scenarios as necessary. You generally shouldn't have to worry about people violating the contract of what that thing does. So if you take in floating point numbers, you normally don't have to worry if they pass in a bunch of NaN or whatever. There may be a context where you do, but it should be very apparent. Or in dynamic languages, you may be testing a method that takes an int and suddenly it's passed in an instance of SomeDumbClass(). That is generally not your problem unless you have some specific knowledge that it is. Even with those training wheels and handholding, the project will eventually be extended and those tests will fall on their rear end. They will have done their job.
|
|
#
¿
Oct 10, 2016 16:38
|
|
|
ChickenWing posted:Do any of you use linter information for code cleanup at work, and if so how helpful do you tend to find it? I spent the majority of today working on paying down tech debt as reported by Sonar and I got to wondering how much of this was stuff people actually worry about overmuch. I imagine it's at least partly domain-dependent - I'm working in java, so a lot of stuff I fixed was along the lines of "use isEmpty() rather than size > 0" or "use the diamond operator rather than redundantly respecifying generic parameters". However, stuff like reducing cyclomatic complexity seemed like it would be more widely applicable. Ehh let's say we have 100 files that mostly just have a little bit of dumb poo poo like those isEmpty() shenanigans. Then you have one file that has hundreds of things going off in it. That file probably contains a cesspool that needs some attention. The rest can probably be ignored.
|
|
#
¿
Oct 17, 2016 22:34
|
|
|
I am personally more in agreement with revmoo's take on this business, but I'm working with a fairly small group right now. I especially hate people committing stuff with the equivalent of "WIP: Did stuff." Mostly I hate WIP becuase, well, of course it's a work-in-progress. Do you think you will be making the last commit to this project forever? A problem I had recently is that a few of us agreed to start working on somebody else's branch to do integration of different components before sending it back to master. What became implicit here was that branch was a master among us. In practice, that meant I had to wade through a pile of "WIP" and broken tests before I could even stir in my contribution. My complaints about this really frustrated the owner of that branch because, well, it was their branch and it was a work-in-progress. However, that person signed the social contract too. Well, I suppose they didn't really understand what they signed. I tried to explain that when other people started working on a branch together, then the code that reaches that branch should be runnable at least for the bits we all are caring about. It's not just me getting butthurt about fetching new code and discovering none of it works. I am obligated to pass along code that works to everybody else. I feel like there's a kind of evolution for source control. I kind of want to use that brain-expanding meme for this, but I might shoot myself for having done it: 1. Source control is a necessary evil so that multiple team members can work on code at the same time. 2. Source control is useful for me because it lets me back up my poo poo off of my computer. 3. Source control is good for me because it lets me take a shot at something without fear that I'll pain myself into an irrevocable corner. 4. Source control is great for me because it helps me manage all the little changes and nibbles I make while I'm thinking through stuff. Unfortunately, I deal with a lot of people that are still in number 1 and will probably stay there forever. My local team is at least in number 2, but I don't know how far they've gotten beyond that. So I have to read up on policy stuff online to figure out what the grown-ups are doing. I found the whole rebase flow to be confusing. Personally, I'd rather use merges instead of rebasing because I really do want to see how all the sausage is being made. If somebody's making incremental, broken, WIP changes, rebasing that into the branch isn't going to magically fix it. Well, if they squash in the process, it will, but I rarely see that. I'd rather all that poo poo sit in a side branch so I can inspect and bisect the master first before I try to find a smoking gun in a topic branch--if I ever even feel compelled to do that. However, all our tools here are set up to block merges by default, so we're kind of stuck in a rebasing hell hole. It's funny to me because the other team members have the damdest time wrapping their head around rebasing and would rather merge too. So does Linus like rebasing for combining branches now? When I first heard about the religious war, I tried to look up what the Word of God had to say, and came across this. Disregarding possibly cargo culting on something Linus said, I generally hate having a fully-linear, rebased history where different branches of commits end up getting woven together because sometimes the different changes aren't even sequentially cogent. The way I see people getting around that with Gerrit is just squashing their entire branch into a single commit for review. I am also unsettled by that because those single commits can get huge. IMO I think a lot of methodologies end up being molded by external tools like GitHub or Gerrit, and people end up just take the limitations from them back into git. The strangest thing I've seen BTW is somebody merging by basically cherry-picking their stuff on to the target branch. However, the best I could muster in reaction to it was to point at it and kind of mutter, "Yeah uhhh I don't ever see that, but, uhhhh you do you, I guess?"
|
|
#
¿
Apr 18, 2017 17:35
|
|
|
|
| # ¿ May 10, 2024 15:02 |
|
|
Clearly you contact the API author for each and every time that came up in the error message.
|
|
#
¿
Apr 26, 2017 00:41
|
|