|
Mega Comrade posted:So my company is switching to "Shapeup" . Anyone got any experience with this, I've read the shapeup doc on it. And mostly seems sensible although I have concerns about this company actually sticking to some of the principles, mainly not pulling Devs of work cos some minor bug has been reported by a customer with a lot of clout. The company that recently laid me off tried it. It was a pretty spectacular failure. It sounds really nice, but in practice it’s kind of a mess, especially if leadership isn’t strong about defending the tech org. The biggest issue I observed was that product was terrible at writing pitches and engaging tech leads and sr engineers about the technical side of the pitch resulting in either overly specific or overly broad requests resulting in pitches never finishing in six weeks. This resulted in the two weeks of downtime being spent trying to finish pitches or working with product to refine the pitches that weren’t finished. Additionally, there was an assumption that devs would suddenly only take time off during downtime, which, lol. Ultimately, the failure happened because product and tech could never come to an agreement on what expectations for the entire process would be and the CTO was too weak to provide any direction on the project management framework they decided we had to do. Oh, and he laid off all the project managers deeming them non-essential because suddenly devs will manage themselves! Guess what, devs hate managing projects.
|
#
?
Feb 13, 2023 23:48
|
|
|
|
| # ? May 11, 2024 08:29 |
|
|
Anyways, the company bought another company and then used the “looming recession” to have two rounds of layoffs, and now the company has almost no one left between layoffs and brain drain and those that do remain are from the purchased company. No, I’m not bitter at all that I found out I was laid off from a coworker who didn’t even still work at the company while I was on parental leave.
|
|
#
?
Feb 13, 2023 23:51
|
|
|
FlowerRhythmREMIX posted:The company that recently laid me off tried it. It was a pretty spectacular failure. It sounds really nice, but in practice it’s kind of a mess, especially if leadership isn’t strong about defending the tech org. The biggest issue I observed was that product was terrible at writing pitches and engaging tech leads and sr engineers about the technical side of the pitch resulting in either overly specific or overly broad requests resulting in pitches never finishing in six weeks. What was company’s previous process?
|
|
#
?
Feb 14, 2023 01:20
|
|
|
FlowerRhythmREMIX posted:
Can you even legally be fired on parental leave?? Or did they pay out your leave and tell you to not come back
|
|
#
?
Feb 14, 2023 01:53
|
|
|
“Agile” I believe the WARN act allowed them to lay me off since I got 60 days notice when my leave would have expired. Honestly, I maybe could have pressed it, but it turns out newborns are exhausting mentally and physically and I didn’t.
|
|
#
?
Feb 14, 2023 03:08
|
|
|
DHH had one good idea and that was almost 20 years ago.
|
|
#
?
Feb 14, 2023 06:22
|
|
|
Nybble posted:I figured most people would have bailed from that idea after the writer’s conservative views caused a huge blowup at Basecamp, and then DHH went even farther than Ryan did in public. caused plenty of consternation in the Rails community and placed plenty of doubt whether any of their management books are actually good or were followed internally While all very funny, I'm not sure it completely invalidates their ideas. Just shows they aren't the special unique flowers they thought they were and are actually no different from any other well known tech bros. FlowerRhythmREMIX experience is spot on some of my concerns though. Oh well nothing I can do, better just update my LinkedIn and start doing a little light prep just in case! Mega Comrade fucked around with this message at 09:06 on Feb 14, 2023 |
|
#
?
Feb 14, 2023 08:38
|
|
|
Shape Up is like any other method or approach: it's full of good ideas that can work well in the right context, and it's also full of bad ideas that only worked out well in Basecamp's specific context. It's important to note a few things about Basecamp's culture:
The reason I say all this isn't to paint an awful picture of Basecamp. I think its founders and leadership do that by existing, or opening their mouths about virtually any topic. I say this because I think that most companies that follow FAANG models are like this, to some degree. The company I work for is a lot like this (minus the first point, where we do bias towards culture adds). Spotify is like this, despite Henrik Kniberg's rosy depictions of agile there. At the end, the thing you should take away is that management wants teams to show results. They've decided that this specific process, and this specific feature cadence, gets them the results they want predictably, so they can make top-down decisions about the company. Think about who has the power in your company, and how they come to the conclusion that things are moving in the right or wrong direction—it might be management, or IC engineers, or architects/principals, or a technical governance committee, or a very deeply involved COO. Some of the things in this tract might help you structure work in a way that gets the right results and communicates those results to the right people at the right times. Vulture Culture fucked around with this message at 15:50 on Feb 14, 2023 |
|
#
?
Feb 14, 2023 15:46
|
|
|
Judge Schnoopy posted:Can you even legally be fired on parental leave?? Or did they pay out your leave and tell you to not come back As long as it's not targeted, yep, they sure can.
|
|
#
?
Feb 14, 2023 22:13
|
|
|
I swear to loving god, the people who moan the most about code reviews and quality checks are always the dicks who gently caress up the most. "Oh the peer reviews slow me down, it's such a hassle" That's because Colin you pushed untested broken code to production, you loving arsehole. These checks are needed because of people like you.
|
|
#
?
Feb 20, 2023 11:50
|
|
|
Mega Comrade posted:I swear to loving god, the people who moan the most about code reviews and quality checks are always the dicks who gently caress up the most. There are degrees though obviously. The other day our designer found a visual bug, showed it to me, and I fixed and deployed it all within 10 minutes or so. In an overly process-driven org he might've had to raise it with a PM, who would decide whether it was in need a hotfix or if it should be added to the next sprint and then it would go into Jira and hopefully without any context lost between the designer, the PM, and the developer who would eventually work on it. Then the fix would get made and code reviewed and who knows when it would get pushed to prod. That said, with tighter processes and longer delivery times maybe we never would've shipped that bug in the first place.
|
|
#
?
Feb 20, 2023 16:10
|
|
|
Mega Comrade posted:I swear to loving god, the people who moan the most about code reviews and quality checks are always the dicks who gently caress up the most. And I'll do it again, too!!
|
|
#
?
Feb 20, 2023 17:07
|
|
|
Mega Comrade posted:I swear to loving god, the people who moan the most about code reviews and quality checks are always the dicks who gently caress up the most.  I know that's not what you intended, but I can't help but picture process-obsessed managers with this sentence
|
|
#
?
Feb 20, 2023 17:10
|
|
|
prom candy posted:There are degrees though obviously. The other day our designer found a visual bug, showed it to me, and I fixed and deployed it all within 10 minutes or so. In an overly process-driven org he might've had to raise it with a PM, who would decide whether it was in need a hotfix or if it should be added to the next sprint and then it would go into Jira and hopefully without any context lost between the designer, the PM, and the developer who would eventually work on it. Then the fix would get made and code reviewed and who knows when it would get pushed to prod. For each new release we usually add a “Cleanup” issue in Jira for small issues that have effectively no customer impact. All the small corrections like the one you described get lumped in there and don’t need approval. Hasn’t been abused (yet). prom candy posted:That said, with tighter processes and longer delivery times maybe we never would've shipped that bug in the first place. 
|
|
#
?
Feb 20, 2023 18:04
|
|
|
Macichne Leainig posted:
prom candy posted:There are degrees though obviously. The other day our designer found a visual bug, showed it to me, and I fixed and deployed it all within 10 minutes or so. In an overly process-driven org he might've had to raise it with a PM, who would decide whether it was in need a hotfix or if it should be added to the next sprint and then it would go into Jira and hopefully without any context lost between the designer, the PM, and the developer who would eventually work on it. Then the fix would get made and code reviewed and who knows when it would get pushed to prod. Yes for sure. I got brought on partially because I had introduced these sorts of processes at my last place that had none. They had none here too. Most of the team have welcomed them eagerly, they are tired of fixing very silly easy to catch mistakes in production or being blocked from working because someone has broken dev branch carelessly. But then a few don't view it that way. I've always believed these things can help devs but its a balancing act and should never become a hindrance. For context though (and because I really need to vent) I have put code reviews and mandatory PRs in dev. I didn't do this for dev -> master because of reasons like Prom Candy mentioned. But there is this one dev we have. Every release he would push stuff into dev and into testing moments before the cut off for release. It failing testing and having to pick it out was almost a weekly ritual. Its like he just would context switch between stuff all sprint and then commit it all right on the day of release. With the new processes that has stopped. However last week he had two hotfixes, these can skip the PR process at present. Somehow he pushed in changes that not only contained his stuff but also undid a load of other peoples tickets. He has no idea how this happened. he claims to not have noticed that his 1 line hotfix contained diffs in 71 files. I only noticed this when he had forgotten to backmerge his hotfixes into dev, so I created a PR for it and noticed things didn't look right, marked as draft with "do not merge" on it and asked him to take a look cos his changes made no sense and something was wrong. I had lunch and walked the dog, by the time I returned he had approved and merged the PR into dev, even though the raiser (me in this case) should always be the one who merges. So now I have a master and dev branch missing multiple peoples work. When I ask him why he did that, he claims he didn't. When I show him the PR with his name stamped on it he blames the tool for being confusing. Seems he came in, smashed merge on 3 PRs that were waiting for him and then did that one too. Not actually reading any of them. Unpicking this has been a nightmare because hes been using various 'base' branches to hold his work and then merging between them, which are named after JIRA tickets he hasn't even started yet. So a merge of branch 'Jira-1002' might actually be ticket 1020, and 1002 is still marked as backlog, despite it being in production 
|
|
#
?
Feb 20, 2023 18:58
|
|
|
Mega Comrade posted:But there is this one dev we have. Every release he would push stuff into dev and into testing moments before the cut off for release. It failing testing and having to pick it out was almost a weekly ritual. Its like he just would context switch between stuff all sprint and then commit it all right on the day of release. With the new processes that has stopped. These guys are a problem because you can introduce a bunch of process to hopefully contain their stupidity but in doing that you probably slow down a bunch of other people who don't need such rigid rules to stop them from doing extremely dumb poo poo. Not that it's the same thing but it reminds me of my job a number of years ago that wanted to end WFH and Flex Time because "some people" (one guy) were taking advantage and not pulling their weight. Changing the policy fixed the problem with the one lovely performer but it pissed off a bunch of good developers.
|
|
#
?
Feb 20, 2023 19:18
|
|
|
At least in my company the ones annoyed aren't the 'good developers'
|
|
#
?
Feb 20, 2023 19:20
|
|
|
prom candy posted:There are degrees though obviously. The other day our designer found a visual bug, showed it to me, and I fixed and deployed it all within 10 minutes or so. In an overly process-driven org he might've had to raise it with a PM, who would decide whether it was in need a hotfix or if it should be added to the next sprint and then it would go into Jira and hopefully without any context lost between the designer, the PM, and the developer who would eventually work on it. Then the fix would get made and code reviewed and who knows when it would get pushed to prod. There's an acceptable middle ground here in your specific example: you could have made the fix and put it up for code review in 10 minutes and sent out a slack message about a "simple one-liner, can I get a review rq?" Maybe it would have taken an hour or two for someone to get to it to review so they don't churn too much, but would that have affected the rest of your day? And no matter how simple a fix something seems, there's always the danger that you do it wrong in haste. You can still skip all the other stuff you described and fast track a small deployment. Obviously at the end of the day it's all about using your best judgement. Personally I find it's better to not take a step down the slippery slope of deciding that a particular piece of work doesn't need reviews at all.
|
|
#
?
Feb 20, 2023 20:06
|
|
|
I think the simple solution here is no merging without a review, even for hotfixes. How often have you needed to merge a hotfix and there was nobody around to toss a quick review your way? Edit: also that person needs to be fired posthaste.
|
|
#
?
Feb 20, 2023 20:26
|
|
|
Harriet Carker posted:Edit: also that person needs to be fired posthaste. Or at least have a come-to-Jesus talk with their manager.
|
|
#
?
Feb 20, 2023 20:27
|
|
|
Che Delilas posted:There's an acceptable middle ground here in your specific example: you could have made the fix and put it up for code review in 10 minutes and sent out a slack message about a "simple one-liner, can I get a review rq?" Maybe it would have taken an hour or two for someone to get to it to review so they don't churn too much, but would that have affected the rest of your day? And no matter how simple a fix something seems, there's always the danger that you do it wrong in haste. You can still skip all the other stuff you described and fast track a small deployment. I'm the only developer right now. When there were 2 of us we did always review each others changes, and yeah a ping in slack like that is exactly how we would do it. Navigating being a solo developer the past few months has been pretty interesting.
|
|
#
?
Feb 20, 2023 20:45
|
|
|
Mega Comrade posted:Yes for sure. I got brought on partially because I had introduced these sorts of processes at my last place that had none. They had none here too. Fire him, preferably into the sun. Also Harriet Carker posted:I think the simple solution here is no merging without a review, even for hotfixes. How often have you needed to merge a hotfix and there was nobody around to toss a quick review your way? this. The main repo of my team allows people to merge their PRs without reviews (but there has to be a PR, direct push to main is disabled), but nobody is stupid enough to do this outside of very specific circumstances. If they were, we would talk to them and then fire them if they didn't stop their poo poo.
|
|
#
?
Feb 20, 2023 21:05
|
|
|
Sort of same - we require two approvals (although I am personally ok with one) but there's an "Override approval requirements" button for emergencies. If you push it, you better have a good reason.
|
|
#
?
Feb 20, 2023 21:17
|
|
|
GitHub drives me nuts with that setting to relax checks for admins. If you want to merge a PR without proper checks, it’s this whole good process to make sure you know what you are doing. OTOH if you are making an edit with the website editor, it’s just a button that says “commit directly to main?” with no confirmation.
|
|
#
?
Feb 20, 2023 21:22
|
|
|
Mega Comrade posted:When I ask him why he did that, he claims he didn't. When I show him the PR with his name stamped on it he blames the tool for being confusing. Seems he came in, smashed merge on 3 PRs that were waiting for him and then did that one too. Not actually reading any of them. You have my sympathies
|
|
#
?
Feb 20, 2023 21:53
|
|
|
Mega Comrade posted:However last week he had two hotfixes, these can skip the PR process at present. Somehow he pushed in changes that not only contained his stuff but also undid a load of other peoples tickets. He has no idea how this happened. he claims to not have noticed that his 1 line hotfix contained diffs in 71 files. revoke his merge permissions
|
|
#
?
Feb 20, 2023 23:36
|
|
|
Harriet Carker posted:Sort of same - we require two approvals (although I am personally ok with one) but there's an "Override approval requirements" button for emergencies. If you push it, you better have a good reason.
|
|
#
?
Feb 21, 2023 00:15
|
|
|
StumblyWumbly posted:I'd argue that understanding Git is as important as knowing how to code, but more importantly being unable to use git is just a pile of red flags. It means you can't learn well documented stuff, can't debug your poo poo, and you have too much ego to ask for help or follow the rules. Git is not the most intuitive thing, with overloaded phrases, but I very much agree with firing this guy into the sun if he doesn't seem to be able to learn from his mistakes. Requiring at least one approver should be the default imo. Break glass emergency permissions to force submit should exist, but should require an actual explanation, and emergency, instead of "oops." Any oopsie poopsies should be immediately rolled back.
|
|
#
?
Feb 21, 2023 01:11
|
|
|
Mega Comrade posted:Yes for sure. I got brought on partially because I had introduced these sorts of processes at my last place that had none. They had none here too. Sever.
|
|
#
?
Feb 21, 2023 03:29
|
|
|
StumblyWumbly posted:I'd argue that understanding Git is as important as knowing how to code, but more importantly being unable to use git is just a pile of red flags. It means you can't learn well documented stuff, can't debug your poo poo, and you have too much ego to ask for help or follow the rules. The problem is people who “use git” by hitting the commit button in their IDE and writing a commit message. And use the menu to create new branches or switch. Works 90% of the time, but leaves them hopelessly lost when they get asked to do anything that requires understanding git.
|
|
#
?
Feb 21, 2023 04:51
|
|
|
Git is definitely not as easy as it first appears. I'm not saying everyone needs to understand all the ins and outs, but knowing when to ask for help is an important part of the test. Also important is whether they say "Ah, I see how I was using the tool wrong" or "It was the tool that was wrong". The problems I've seen in other devs have been reflected in how they use git. The guy who created a repo with a weird ghost directory and couldn't figure out how to get rid of it? Absolutely useless. The guy who loved "rebase"? Always looking for the most complicated way to solve any problem.
|
|
#
?
Feb 21, 2023 05:32
|
|
|
Cup Runneth Over posted:Sever. This. At the minimum this is “okay here’s your performance improvement plan” territory of fuckups.
|
|
#
?
Feb 21, 2023 06:26
|
|
|
I'm not gonna lie. I know pretty much gently caress-all about how to use git CLI and have been working off of either Github for Desktop (which is pretty decent as far as modern software goes) or when I'm stuck on SVN, I deal with Tortoise. It is completely absurd to me though that there is some weird expectation around 'knowing git' in this world. Yes, you should probably understand what the git words mean and how they map to functionality, but to be able to use the CLI is silly (unless automation around git is part of your day to day). I'm using this as a proxy for an argument that irks me quite a bit: There is still this weird ideology around CLI software that it is somehow 'better' - it's spoken about in almost romantic terms. I find this thoroughly absurd. CLI is a great feature set for certain use cases, but rarely for a human, and I don't take the suggestion to learn the git CLI very seriously. Of all the things I could actively learn, CLIs are such an enormous waste of time...and I don't really know hot hot of a take that is anymore.
|
|
#
?
Feb 21, 2023 07:26
|
|
|
Canine Blues Arooo posted:I'm not gonna lie. I know pretty much gently caress-all about how to use git CLI and have been working off of either Github for Desktop (which is pretty decent as far as modern software goes) or when I'm stuck on SVN, I deal with Tortoise. But this was in the context of someone who pushed a new commit that reverted a bunch of other changes, and UI tools will definitely show you when you do that. It's up to you to put on your thinking cap and realize that no, you probably don't want to modify 70 files for this one-line change. TortoiseGit is very explicit about that (more so than most other tools). OPs coworker probably did a "git reset main" instead of rebase (or merge or whatever). Yeah it's silly that the commands are so similar, and I've mixed those up (and caught it). The coworker then went on to commit the change without looking at the changelist, created a PR, still didn't look at the changelist, didn't wait for a review, and merged. There were many steps where the mistake could have been caught.
|
|
#
?
Feb 21, 2023 08:32
|
|
|
I haven't used it in a while, but last time I did, GitHub for Desktop was basically app with 3 buttons and all pf them did things wrong if you ever work with multiple people, or even just from different computers. Like the sync button would happily make a merge commit with branch that has moved and then push it. Wat
|
|
#
?
Feb 21, 2023 08:36
|
|
|
I'm the resident "git guru" and I still use the ide's tools 90% of the time. But if someone goes wrong or gets hairy I can dip into the cli to fix it. I've encouraged the other Devs to try using the cli every now and again, not pushing the idea it's better, just to get them to have a better grasp of what they are doing and what happens when they push/pull etc. Gui tools are great but they obfuscate a lot of what is going on. My car tells me if my oil is low, as does pretty much every car from the last couple of decades, but it's still part of the countries driving exam to demonstrate that you can pop the hood and check the oil levels.
|
|
#
?
Feb 21, 2023 08:43
|
|
|
Git's model has fundamental complexity, and while there's room for improvement in the CLI, most of the difficulty of learning it is learning the model, not the interface - how repositories work and what the operations you can perform on them mean. Once you know the model well enough, the CLI is far more expressive and powerful than any git GUI I've ever seen. Most GUIs can do a routine workflow easily enough if that's what you're more comfortable with, of course, but it should be a matter of comfort, not inability. More generally, you should always be willing to learn more about your tools.
|
|
#
?
Feb 21, 2023 08:44
|
|
|
NFX posted:But this was in the context of someone who pushed a new commit that reverted a bunch of other changes, and UI tools will definitely show you when you do that. It's up to you to put on your thinking cap and realize that no, you probably don't want to modify 70 files for this one-line change. TortoiseGit is very explicit about that (more so than most other tools). The git gently caress ups I can completely forgive. That's a training problem. What I'm furious about is the complete lack of care and attention, he knows how to check the diff in git extensions (the tool he prefers) he knows how to correctly name a branch, he's been using git (atleast with tools) for years now. And while gitlab may be new to him he can read English, it's his native language, but he chose to open that PR and just slam that big green merge button without reading anything. Which just tells me he probably does that for every pr as well. Mega Comrade fucked around with this message at 10:32 on Feb 21, 2023 |
|
#
?
Feb 21, 2023 08:49
|
|
|
Yeah if the rear end is using Git Extensions, then no excuse. It does a real decent job with the major operations and the commit diff is great for selectively staging. That person just sucks.
|
|
#
?
Feb 21, 2023 10:12
|
|
|
|
| # ? May 11, 2024 08:29 |
|
|
Knowing the git CLI is a status signal because you can't actually use the git CLI even remotely effectively unless you understand the underlying model. You can totally muddle through committing changes and pulling down fresh ones in the GUI (as long as you stay on the happy path) without any idea what you're actually doing. Therefore, anyone who knows the git CLI probably knows how to actually use git well, while anyone who doesn't is an unknown quantity, and may well do stupid poo poo like reverting two week's worth of everyone else's changes because they clicked the wrong button by accident and didn't even notice that they'd hosed it up.
|
|
#
?
Feb 21, 2023 10:43
|
|
