Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›8 »

Hughlander: May 11, 2005

GlitchThief posted:

I tried proposing this approach in my team and the lead developer balked at the idea that anyone might do anything even remotely differently from someone else on the team. I wasn't surprised. I knew there would be trouble the first time we had a team-wide meeting about how to capitalize object names in our code.

That sounds like an argument in favor then. "Since we will all do the same thing anyway let's just do it."

# ¿ Feb 5, 2016 21:04

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 07:18

Hughlander: May 11, 2005

The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before.

Dogmatism of any sort is just bad.

# ¿ Feb 7, 2016 18:30

Hughlander: May 11, 2005

evensevenone posted:

I guarantee the comment would have ended up like this:
code:
foo_setup();  // must setup before init
foo_init();  

He spent twenty minutes trying to rename the methods into what would make sense.

# ¿ Feb 8, 2016 01:18

Hughlander: May 11, 2005

I had an ex at Raytheon on a navy contract. 6 minute increments on the time sheet. (1/10th hour obviously). That was a bunch of bullshit. They also worked 3 shifts which is why she was there since second shift was her standard.

# ¿ Mar 7, 2016 03:21

Hughlander: May 11, 2005

Our way of handling that is just a 2 point spike. The acceptance criteria of any spike is that the user stories to do the actual work are refined, and it's time boxed to usually three days. Anything scoped over 5 points is an admission that we need to break it up better so yah that would be an 8 with us with a two pointer to fix it.

# ¿ Mar 9, 2016 05:51

Hughlander: May 11, 2005

CPColin posted:

This is not the first time it's happened!

Sadly, there wasn't a cake anywhere. We have enough people where there's only one cake per month. The person whose birthday it was was the person who usually orders it, so there probably won't be an April cake for a while.

Clearly you can't have layoffs if you have more than 400 employees.

# ¿ Mar 31, 2016 19:47

Hughlander: May 11, 2005

KoRMaK posted:

I have hope, dammit!

But also, yes I get it. I'm working on it.

I also have faith in my manager because he has collaborated with me previously to make changes for the better, and we have a good working relationship because of his openness and our rapport.

So tell him "In what way aren't you incentivizing the team to high ball story estimates and low ball their velocity?" You can even keep it in vague "the team" when hopeful you mean "me"

# ¿ Apr 13, 2016 04:10

Hughlander: May 11, 2005

Plorkyeran posted:

A proper transition to Agile takes like a week (followed by a few months of ironing out the quirks), so pretty much by definition any team in the middle of a drawn-out transition is going to be a shitshow.

What do you consider that transition then? I'm just trying to go from zero to PO writing good user stories with proper acceptance criteria plus teams going through several refinement cycles to get a properly sorted backlog in a single week and I can't do it.

# ¿ Apr 16, 2016 23:16

Hughlander: May 11, 2005

KoRMaK posted:

Spent two hours today arguing with my boss in a loop about the stupid rear end way he is measuring metrics, and to stop doing the loving math of story points to hours.

He did do a senisble thing though and used our last sprints completed points and divided it up amongst developers amongst days, but god drat do I hate that math to.

Just wait. He'all look at the story points in the backlog and muse, "If each developer just stayed two more hours a day for this sprint look at all the additional stories we can squeeze in!"

# ¿ May 4, 2016 05:53

Hughlander: May 11, 2005

Erwin posted:

We were in the beta and continued to run an on-prem Hipchat server up until about a month ago. We went with Hipchat at the time because Slack didn't have compliance retention we needed (Hipchat barely did). Hipchat updated their client a few months ago and it's a buggy piece of poo poo that crashes literally dozens of times per day, and Slack now has a plus plan that has everything we need for compliance. We switched, and part of me was utterly satisfied explaining to the Hipchat sales rep why we weren't renewing. We use and love Confluence and JIRA, and Slack integrates with them just as well as Hipchat did, if not better.

That's where we are now. Hipchat for compliance but the effort to swap to Slack hasn't been eclipsed yet by the pain of hip chats outages.

# ¿ May 15, 2016 00:45

Hughlander: May 11, 2005

a foolish pianist posted:

We make sure never to push anything new on Friday, even.

Friday or after 4pm! Which has the common joke of, "We can only push after 4pm on Fridays right?" when product people inevitably want to push something out this moment.

# ¿ Jul 3, 2016 14:18

Hughlander: May 11, 2005

Cuntpunch posted:

Management reshuffle means the new boss doesn't understand the team dynamics yet. He's got the contractors with him(because he'll spend 8 hours a day with them dealing with their "could you please show me how to write functions? ok great, could you please check that in for me?") and I'm outnumbered for the time being. The fact that we regularly have "oh hey I just blindly updated a nuget package because Nuget packages are 100% safe to update by major versions and wait what do you mean ASP is delivering assembly binding errors....uhhhh sorry I'm busy looking at stuff can you please fix that?" isn't really understood very well yet.

It's a matter of time, since he got kicked off a different project to join ours because he consistently tended to go "two week sprints mean I can deliver to QA at 2PM the day before the sprint ends!", and he's doing the same thing again. But really wants to push the issue with management to argue about how he is doing *all* the work for the project and he thinks that's unfair. Except that everyone pretty much knows he goes "oh I'm working so hard I'm putting in 4x9's!!! ok it's 10AM on a Friday by guys can't OT!" as he rapidly checks in all his work and suddenly there are bug reports within 30 seconds of anybody looking at it

Easy solution.

Accidentally wait until 10:00:01AM

code:

git fetch
git checkout master
git pull
git reset HEAD^ --hard
git push --force origin master

Monday Morning:
"Weird you checked in before you left? We didn't see anything, well just merge latest and push now QA is all ready for you!"

# ¿ Jul 21, 2016 02:44

Hughlander: May 11, 2005

Pollyanna posted:

I don't like it either, but the manager really just kinda got cornered by the rest of the team some afternoon, so it wasn't exactly planned. Either way, it's a good way to start getting paranoid about whether the company talks about you the same way.

Manager should have said this isn't an appropriate platform for this issue and killed it at that point.

# ¿ Jul 22, 2016 23:44

Hughlander: May 11, 2005

melon cat posted:

I have a question about mobile development careers. I work in video/multimedia production. And it seems like quite a few employers these days are starting to ask for "After Effects/Maya professionals with mobile development experience".

Is it really becoming common for companies to expect people to know high level video development/3D asset creation AND mobile development? Or is just a case of recruiting departments these copy/pasting long bulleted lists of job responsibilities that they don't know very much about? Because if anyone were to ask me, video/3D object development and mobile development are two very different skillsets.

Mobile games can be in 3d? We use Maya for our asset creation pipeline.

# ¿ Aug 16, 2016 15:50

Hughlander: May 11, 2005

melon cat posted:

That's what I thought as well, but a lot of the postings I'm seeing seem to expect more than Maya for mobile game asset creation. As in, they expect you to know how to code/create a mobile app from scratch AND create videos for marketing it.

Can you link a handful? All I can imagine is a weird wording for a technical artist or a tools engineer.

# ¿ Aug 16, 2016 16:38

Hughlander: May 11, 2005

ChickenWing posted:

Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based

I'm confused by that last part. I say 1 or you say 12 we just go with 1 rather than discuss why there's such a variance and see what our assumptions are? Or were you before just saying ok 6! Consensus during estimations seems rather key or there are probably vastly different expectations in the task.

# ¿ Aug 16, 2016 17:36

Hughlander: May 11, 2005

rt4 posted:

Maybe he's just a 10x developer

Points are a level of effort not time. Even if they do it in 1/10th the time there should be an agreement to the effort required.

# ¿ Aug 16, 2016 18:06

Hughlander: May 11, 2005

ChickenWing posted:

I'll talk to my tech lead about it, because your points are all pretty pertinent and would probably ameliorate some of the friction that estimation creates among the team. I think a bigger problem is that the "1 point = 1 dev day" is coming down from on high as well a bit. I don't foresee anything changing (this is for fintech, after all, so we're only working with a close approximation of agile at the best of times), but at least I'll feel better about myself.

Oh man. Just wait until someone o. High says the magic words then, "Wait, I can get 40 story points from the team now? If they just work 2 hours more that'll be 10 more points! Look what 10 points would give us!!!" (Actual words spoken by someone on high.)

# ¿ Aug 17, 2016 04:25

Hughlander: May 11, 2005

mintskoal posted:

I am going to murder my QA guy. Seriously. I am completely baffled how this guy got hired. He simply does not comprehend that his job is to test the acceptance criteria in a story. That's all. He just sent something back to me because a sprite sheet was missing in an entirely different section of the application. This happens with every single story. I tell him to file a bug and get back "Well, I already sent to back to you so can you fix that?" My boss gets notifications of story status changes and then asks me why so many of my stories fail QA.

Go to his manager with every single story for the past 4-5 sprints (or 2-3 months) showing a pattern of scope creep and time wasting.

# ¿ Aug 17, 2016 20:51

Hughlander: May 11, 2005

Rocko Bonaparte posted:

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.

You can manage that I think. Or at least prevent new ones from showing.

# ¿ Aug 23, 2016 00:21

Hughlander: May 11, 2005

ChickenWing posted:

Today I learned what it looks like when a git merge commits messy suicide.

Actually it was more like a branch was just sorta drawn and quartered over a series of 10-15 commits and merges.

I have no idea what the gently caress happened and my brain feels like a fully extracted tube of toothpaste after trying to decipher the whole goddamn mess. It's like our universe combined with an alternate universe where all my work on a particular API never happened.

Sometimes you just gotta know when to apply:

code:

git merge --abort
git rebase --interactive
git merge
git merge --ff-only

In the right orders...

# ¿ Sep 6, 2016 19:42

Hughlander: May 11, 2005

revmoo posted:

Someone correct me if I'm wrong, but I think this is pretty simple; if you're doing unit testing then you mock the API out. If you're doing integration testing then you test the actual API connection.

I look at it a bit different. During a smoke test that blocks a commit integration tests run against a dummy API you don't want to block someone's commit based on an external resource being unavailable. However then there should be a scheduled test run against the real API. Either scheduled in response to the push, or a nightly job against master.

# ¿ Sep 28, 2016 16:56

Hughlander: May 11, 2005

Greatbacon posted:

Yeah, there is only one category of person in a company who should get upset enough about stuff to scream (the people with equity) and there is only one place they should actually scream.

Being threatened or belittled, or screamed at are pretty much my pure quit on the spot. It's best for you long term and sends the message to everyone else that it's not acceptable in any regard.

# ¿ Sep 30, 2016 15:23

Hughlander: May 11, 2005

necrobobsledder posted:

I was meaning that nothing could get people to be flexible (if you stay later, no big deal coming in later, for example) in an environment where there were constant fires and one of the biggest problems with schedule slip was because nobody had any urgency to finish their tasks and low performers just couldn't get canned. The situation was how people think government employees work, except this is private sector.

So far it all sounds like management issues not employee issues.

Why were there fires? Was code shipped without adequate QA?

Why was there schedule slip? Did the employees estimate their time correctly? Was there iteration to understanding the full team velocity?

Or in both cases did a manager/pm/po say "we are shipping on x date with y features" and it's the employees job to warp reality to match?

# ¿ Sep 30, 2016 22:47

Hughlander: May 11, 2005

necrobobsledder posted:

That part is mostly about addressing the "any hours more than 40 / week means you're slime" crowd rather than team impedance mismatches that I was addressing.

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).

But from these two paragraphs you'd be a moron for an individual contributor to work 50-60 hour weeks. It's not going to fix the disfunctional processes you outlined there. It's not the ICs fault that half a year deployments are considered ok. If he put in 10'hour days and the fix got out after 11 sprints it's not a win for him. And there's no reason to basically slutshame people for following their employee contracts.

# ¿ Oct 1, 2016 18:44

Hughlander: May 11, 2005

necrobobsledder posted:

Something wrong with using the term "mob boss"?

I push for pair-programming to be 'Wonder-Twins' and mob should be 'Form Voltron'

# ¿ Oct 4, 2016 22:52

Hughlander: May 11, 2005

pugnax posted:

How do you guys treat documentation in your ~agile flow~? An extra story per feature? Treat it like a feature in itself?

Part of the definition of done for each story is that it's documented, it passes a functional review, it's on a master branch, it has automated tests, it's passed a code review, etc...

# ¿ Oct 7, 2016 15:33

Hughlander: May 11, 2005

Vulture Culture posted:

8 hours isn't fine for one step (if the interview is based entirely on technical prowess and 0% on team fit, run the gently caress far away). It's fine if you're already between jobs because you can afford to be, or because you're an unencumbered twenty-something or early thirty-something with no other demands on that time. It's not okay for people with multiple jobs, people with children, people with elder care responsibilities, etc. This will be reflected in the demographics of the workplace.

Exactly, the problem is that it's a self-selection issue. Only people who have no problem with giving up multiple days will apply to that company, so it will be stocked with people who think that's ok and normal. You're completely limited in the number of places you can apply for at a time. I remember a few jobs ago I had two weeks of flying around the country to WA (twice), MD, and MA from CA. If one of those wanted the day or two of travel for a f2f and another day or two of a test, I'd drop them off the list. This line of thought makes me really glad i'm not an artist or designer where their take home tests run 20-40 hours routinely.

# ¿ Oct 7, 2016 20:50

Hughlander: May 11, 2005

Gounads posted:

This would be ideal. Unfortunately I don't know where to send invoices yet.

It really isn't. I had that happen to me at the start of my career and it destroyed my work ethic for the next few years. I was paid 6 figures to play Everquest and go to the gym.

# ¿ Oct 14, 2016 17:15

Hughlander: May 11, 2005

Doc Hawkins posted:

You should do this. Being able to create/refresh a development environment with a single command is a huge advantage, especially with explicit configuration files brought under version control.

If you already enjoy Puppet, maybe check out Boxen.

No you shouldn't do it. Because then you become desktop support for every change. Any time there's a new so release you get to update it. My group was responsible for that in the past and I couldn't get rid of it fast enough.

# ¿ Nov 10, 2016 15:49

Hughlander: May 11, 2005

Doc Hawkins posted:

Well, both of the teams I've seen it work well on were command-line centric, and everyone self-serviced the changes they wanted via pull-requests, so maybe those were important factors too.

But if you'll be punished for improving things, that might be something more important to fix than development environment provisioning.

It's not punished it's rewarded with ownership!

And the culture that sprung up was, "We can't update to X because that team didn't update the scripts yet!" Yes anyone could have since it was in git same as anything else, but they didn't want to be responsible for it in the future either.

# ¿ Nov 10, 2016 17:41

Hughlander: May 11, 2005

smackfu posted:

Who has a holiday production freeze? How does that work for you with sprints and continuous delivery?

We have retail clients so our freeze starts the week before Black Friday until January 2nd. So that's nice.

We do because first party shuts down, and out of 18!developers the last workweek of the year has one present. We plan sprints for the number and velocity present and continue delivering. Other groups do product integration and I'm not sure their plans but ops have put a stop to deployments for not having spare capacity for self inflicted prod fires.

# ¿ Nov 23, 2016 03:06

Hughlander: May 11, 2005

My Rhythmic Crotch posted:

I just want to say "STOP" every time I hear new lingo like this. Stop creating 20 dollar words for 50 cent concepts. (I know you didn't create it yourself, just sayin')

I wouldn't consider it new lingo. It's been part of agile sprint lingo as long as I've been aware of the system. And honestly the concept needs a term. It's not something you would do in some other methodologies.

# ¿ Dec 15, 2016 08:12

Hughlander: May 11, 2005

Pollyanna posted:

I randomly got drafted as our team's "team leader"

Random or dilbert principal?

# ¿ Dec 16, 2016 01:48

Hughlander: May 11, 2005

I work tangentially with another team a continent away and it's interesting in different approaches we take. Here we have 50 provisioned nodes in AWS for QA and dev. Need to test something, sign out a node, deploy to it and test it. There, one backend serving for all possible branches that design, QA and dev will use. Hope you don't change anything too major!

# ¿ Dec 18, 2016 21:46

Hughlander: May 11, 2005

My preferred way is WIP limits for Scrum and Kanban for teams with large amount of support contingencies but that still deliver projects do so in a Kanban style with a velocity burn down.

# ¿ Jan 2, 2017 01:22

Hughlander: May 11, 2005

Makeout Patrol posted:

My team assigns all bugs story point values of zero on the grounds that they represent work left over from the original story. Since this work belongs to that ticket, their story point value has already been captured in that ticket. This is a stupid system that doesn't do anything except reduce the quality of our metrics.

It also intrinsically encourages crunch. You have 40 new story points and 10 bug points to do when 40 hour weeks get you 40 points of velocity. Guess everyone needs to do 50 hours this sprint to meet the story goals!

# ¿ Jan 4, 2017 05:25

Hughlander: May 11, 2005

Mniot posted:

Covertly introduce new languages into everything you touch. They will learn to appreciate the way your Node.js script shells out to both Go and Eve! Your code should install all the tools it needs as a side-effect, to reduce friction.

Die. I have a list of languages in use in our tech stack on my whiteboard (17) with the adage "To add one you must remove two."

# ¿ Jan 25, 2017 08:18

Hughlander: May 11, 2005

leper khan posted:

Ok. I'll add Algol 60 and remove c++ and java. You don't need two algols, so I'll just give you the ancestor. hth

Go for it! Should only be about 1MM LOC. And I'd get a kick out of Algol 60 emscripten cross compile...

# ¿ Jan 25, 2017 14:19

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 07:18

Hughlander: May 11, 2005

Pollyanna posted:

"I'm sorry but the reality is that story points ultimately reflect a unit of time and I just won't accept less than 35 points per sprint."

Sounds like every story is estimated at 35 now to account for uncertainty and making the sprint commitments! Gotta love optimizing for the wrong thing.

# ¿ Jan 30, 2017 21:51

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›8 »