Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
StumblyWumbly
Sep 12, 2007

Batmanticore!
You're right that product managers definitely need to be involved with the help desk. The goal of getting folks involved with the help desk is to get a better understanding of how the customers use the product, and with that understanding developers can have more control over what they're working on and how it is implemented. If the developers don't understand the customers, then feature requests need to be more specific so the feature is useful to the customer.

I've definitely seen situations where a feature was accessible through a GUI or a JSON system, and the developers wanted to improve and optimize the JSON because that's what they use, but the actual customers all use the GUI.

I actually like helping on the help desk because the customer's questions tend to be easy and it feels good to just get something done.

Adbot
ADBOT LOVES YOU

StumblyWumbly
Sep 12, 2007

Batmanticore!

Volmarias posted:

This can be true, but also sometimes there are customers that you wish a thousand stubbed toes upon.

One thing my company does is the CS folks are go betweens between engineering and developers, so when I ask them to send me their log file, and they send a picture of them looking at their log file with a description of their intense feelings about the log file, then the CS handles the back and forth about how to do this very advanced activity.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Sometimes you choose a place because you like the people, sometimes you believe in the product.
Not sure why someone would choose to stay at Twitter right now.

StumblyWumbly
Sep 12, 2007

Batmanticore!
It was pointed out in another thread and I'm interested in the view here: Seems like Twitter doesn't really have code problems. They aren't losing hundreds of millions because their code is shoddy or unstable. They have business problems, so putting all the effort into code reviews seems a bit backwards.

StumblyWumbly
Sep 12, 2007

Batmanticore!
I've been in this story, it never gets better. My favorite part is when they say they don't realize how unpleasant they're being, but they're very sensitive about people giving any kind of correction to them.

If you want/need to make this work:
- Don't use text when there will be a back and forth, talk to them
- Realize it will be more efficient for you to suggest the exact change you want to see
- Avoid style discussions

On the bright side, we've all learned that if it is rude to tell someone to go eat poo poo, it is polite to tell them to NOT eat poo poo. Logic!

StumblyWumbly
Sep 12, 2007

Batmanticore!
The risk log should also get more and more specific as time goes on, otherwise its just fearmongering.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Me, defending a cursed senior engineer:
Week 1: Yeah, he had some trouble finding and signing all the HR paperwork, but we're past that now
Week 2: We worked through his email and log in issues, so he should be able to get moving on his first project
Week 4: He had some trouble with our standard build system, so he setup his own, but once he gets his project working we'll integrate it in with the other stuff
Week 8: He's been running into some trouble, apparently that project isn't well documented, but it will be worth it if he finishes
Week 16: Still on the same project. Hasn't been going smoothly
Week 20-26: This guy is an incompetent rear end in a top hat, the only person I hate more than him is me on week 1

The guy had a lot of good qualifications and definitely knew how to code, but was absolutely useless at actually producing anything.

Judge Schnoopy posted:

I feel like I've fallen into the trap of being a "leopards eat your face party" supporter.
Sounds like a poo poo situation. I haven't been in one like yours, but I've been in other tough ones and what I did was try to focus on the work, make it clear what are my decisions and what are handed down (eg "the boss asked me to design X"), show appreciation for their work, and ask for solutions to the problems they point out. They don't want you to ask questions to specific people? Where should the questions go.

Working through brainstorming is probably tricky, and may be worth just dropping. That's a very delicate art to get right.

StumblyWumbly
Sep 12, 2007

Batmanticore!

Rocko Bonaparte posted:

Like I know you're giving some counter example here, but the most recent case I dealt with had me giving the guy 30 pages of documentation and 30 minutes a day for three weeks to go over stuff. One of his goals was to migrate a single project build from Gitlab to Jenkins. He couldn't even get started on a hello world example in Jenkins to just kick the tires. He needed "more information."

I've seen that situation where the guy has a lot of anxiety and would rather fret about making the wrong move instead of doing nothing, and its frustrating because they end up justifying it as a problem with the world around them instead of a problem with themselves. I have more sympathy for people like that instead of folks who are just too lazy to do anything, but unless you give them a lot of therapy the end result is the same.

Saying it like this, I guess it does imply the solution is that they need comfort more than knowledge, so... let me know how that works I guess?

StumblyWumbly
Sep 12, 2007

Batmanticore!

raminasi posted:

I'm not saying that this particular person doesn't suck, and I think the most likely explanation is that a previous role trained them to do this, but I think it's good for all of us to remember if that if we feel like we're repeating ourselves without getting understood, the problem isn't necessarily entirely on the listener's end. It might be worth getting a third party from your team (a manager or peer) to give you feedback on these exchanges.

Not sure I get this point, can you just repeat it louder and angrier?

StumblyWumbly
Sep 12, 2007

Batmanticore!
I followed your advice and removed all the calls to free, and the problem got worse. Ball's in your court now, buddy.

StumblyWumbly
Sep 12, 2007

Batmanticore!

prom candy posted:

Granted I don't have a recommendation but is there nothing more up to date for today's beginners?

ChatGPT

StumblyWumbly
Sep 12, 2007

Batmanticore!
I'm always suspicious when folks talk about writing "easy to read" code because I've met folks for whom that just means they don't understand stuff unless they wrote it.
Easy to read requires metrics, and short is not necessarily the best metric.

StumblyWumbly
Sep 12, 2007

Batmanticore!

lifg posted:

Code Complete is good too, but it’s also a doorstop of a book.

It has a whole chapter on how to structure your if statements. (It's actually a useful chapter)
It's a good book, definitely worth skimming through, but I don't think anyone has read it completely, including the author.

StumblyWumbly
Sep 12, 2007

Batmanticore!

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.

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 :shepicide:
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.

You have my sympathies

StumblyWumbly
Sep 12, 2007

Batmanticore!
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.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Maybe there's stuff I'm completely missing, but understanding add vs commit vs push/pull shows you get the model. The big issue is the way git has the local vs remote repos, so what you think of as main may not be what other people have.

Submodules are weird to use but simple in theory, and other stuff are just specific tools that build on the existing model.

E: doesn't changing a pushed commit add complexity for other folks? Seems not worth doing to fix a typo

StumblyWumbly
Sep 12, 2007

Batmanticore!
I was out of work for a year during the dot com crash. I'll never forget the horrors, and all the broken bodies I saw in that year (because I was playing a lot of Diablo).

StumblyWumbly
Sep 12, 2007

Batmanticore!

Hughlander posted:

Like a place I worked tried to put all of what they covered in health care as TC to try to bring it up to an average salary around them rather than just admiting they were below mean.

For folks with a family or persistent medical expenses, this is kinda fair, as long as they list it out separately.
E: It's the inverse of folks maxing salary but having poo poo health insurance.
E2: I guess it only applies to America, too

StumblyWumbly
Sep 12, 2007

Batmanticore!

Cugel the Clever posted:

My team transitioned to a new product and handed off our previous areas of ownership to another team about a year ago. They'll rarely come to us with questions that we're happy to answer as they've been relatively easy and not required much of anything from us. Recently, an inquiry came in about finding logs for a user who reported a crash on login attempt on one of the mobile platforms. Easy-peasy—we gave a quick refresher on how to go about that and left them to it. A day later, they came back indicating they didn't find logs and didn't get much useful info from direct outreach to the user, so they were going to close out the ticket as a transient failure.

"Great!" I say, "but I looked at your ticket and your owner hasn't documented their attempt to reproduce the issue. The issue's not reproducible, right? Users can log in on iOS? On Android? Right?"

:shepicide: :suspense:
I love that game where people just ask for more information without doing any digging. Try to reproduce the problem? No, is prefer you read me info from websites I could easily go to my self

StumblyWumbly
Sep 12, 2007

Batmanticore!
ChatGPT has been great for handling dumb single purpose language stuff like regex or GitHub action YaML, and I look forward to using it for AWS permissions.
I plan to use it to help the can't-really-program folks at my company to get them up to speed more quickly.

StumblyWumbly
Sep 12, 2007

Batmanticore!

biceps crimes posted:

im using something relatively bleeding edge that doesn't have much on SO or in google results (which usually trash anyways), and chatGPT has been useful in this project so far as well

I'm actually surprised and happy to hear this, I was worried Chat would become an important tool and favor old language and tools too much

StumblyWumbly
Sep 12, 2007

Batmanticore!

biceps crimes posted:

loving kill me if i had to attend a daily hour long stand-up

They say weekly right in the post

StumblyWumbly
Sep 12, 2007

Batmanticore!
There's a lot of dumb management stuff, but one of the dumbest is that connecting with people and saying "You're actually doing the thing I asked you to do yesterday, right?" can help more than it hurts. If done correctly.

The dumb thing that works against scrum is that meetings will naturally grow and wander around unless someone tries to prevent that.

StumblyWumbly
Sep 12, 2007

Batmanticore!
One of the only benefits to remote meetings is that the folks who are absolutely crucial for 5 minutes of a 1 hour meeting can do anything else with their lives for 55 minutes.

In general tho, remote meetings where multiple folks may need to actively discuss at one time are trash compared to face to face.

Bongo Bill posted:

Suppose you're a boss. If one of your employees isn't doing their job, it'll show in other, more direct ways; if you're relying on being able to see them in order to detect goldbricking, then you have the bigger problem of trying to manage an organization without having any adequate means of knowing what is happening inside it. If you suspect an employee is cheating you and needs surveillance to deter it, then you have to ask yourself: why did you hire people you don't trust?
In my experience, remote work requires more oversight, meaning reviewing commits and PRs and end-of-sprint stuff. That's good practice in general, but my company occasionally has one person working out on their own for a while, and if they're in the office we can see, with 0 effort, they're physically at the computer looking at code. And improving hiring won't fix that. It can never be perfect, and people change.

StumblyWumbly
Sep 12, 2007

Batmanticore!
The best is when I add in a fix and a test, but the test can only be run on PR, so the commit log is 1 meaningful change and 10 commits alternating between "fixing test" and "fixing typo"

StumblyWumbly
Sep 12, 2007

Batmanticore!
I can imagine pointing being useful if there is a variety of technical specialties or no strong tech leadership, so folks need to briefly discuss the easiest way or pitfalls for a problem, or figure out if a ticket should be broken up.
Meetings where the lead says "How many points should this one be? Wrong, the answer is 4!" sound fun for maybe 1 person.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Videos / gifs to demonstrate clicking a few buttons to get a result are pretty handy and make talks less stressful, but personally I just avoid videos whenever possible.

My guess is your talks should be very high level. The expectation should be that folks should know what the tech you're talking about does well, what it does poorly, and what the other options are. For any details like specific syntax or install instructions, just point them to the documentation because nobody will remember anyway. The goal is to share knowledge within this 150 person company, so someone can hear what you're doing and follow up on it if they realize it is relevant to what they're doing, not so they can take over maintenance of it.

The talk should feed into writing up documentation on the internal wiki.

Volmarias posted:

The goal is for your to raise your own visibility and show how important you are. That's it. The actual content is mostly irrelevant, as long as everyone agrees that you appear to know things and can "knowledge share" and "collaborate". Any knowledge gained by others is a happy accident.
This except I think knowledge is cool.

StumblyWumbly
Sep 12, 2007

Batmanticore!

Doktor Avalanche posted:

shouldn't feature branches be made from main since it's the latest "clean" branch (fully or at least almost fully tested and working)

No, if you did this, you'd run into a poo poo show when you merge it into dev, unless that part of dev hadn't been changed and then why didn't you just branch off of dev?
There's also the (mostly bullshit) philosophy that things should only go into main.

ThePopeOfFun posted:

To be fair, I only spent a brief internship with the alternative. Hence sitting on my hands waiting for approval.

PR approvals are a big place to be picky on interns to get them to have Good Habits, so your experience may not have been the best.

I use GitFlow because all our stuff involves some effort to release to the customer, so we do that on merges to main.

StumblyWumbly
Sep 12, 2007

Batmanticore!
You start simple, with a square moving around a 2d map, then you just gradually add in the 3rd dimension and more polygons until you've recreated UnReal.
That is how a demo becomes a product!

StumblyWumbly
Sep 12, 2007

Batmanticore!
My two favorite things are farting in elevators and rebasing things into dev

StumblyWumbly
Sep 12, 2007

Batmanticore!
Testing simple functions is mainly good for checking situations that the dev didn't consider, like "what if the input is 0"

StumblyWumbly
Sep 12, 2007

Batmanticore!

Falcon2001 posted:

This isn't some 'PEOPLE DONT WANT TO COME INTO THE OFFICE' rant, which I addressed when I quoted prom candy; you want to WFH? That's great man, you do you; but you should still be friendly with your coworkers. This isn't about how you should be kowtowing to assholes in suits and their dumbass desires, it's about dealing with your peers.

My point is the whole 'ugh I have to TALK to people' poo poo in our industry is basically self-destructive bullshit and leaning into it is only going to make you more miserable.

I agree for 2 main reasons. On the brain health side, while it is true that some people (including me) could be very happy going for a month without actually talking to anyone, it is also true that depression can start to hit in isolation and people don't realize it or can't pull themselves out until they're wasting away in bed because they don't see the point of getting up. Diagnosing yourself is tough, so it is important to have outside contact that can speak up if you seem to be spiraling.

On the work side, you need to have contact with your coworkers, you need to know who they are and vice versa, because that makes it easier for questions and knowledge to happen. If you're in the office, at least you're forced to have some contact with coworkers, even if you hate interacting with people.

This is all separate from the absolute poo poo that open offices and remote meetings are. Just absolute poo poo.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Ok, but we're required to have two (2) hours of small talk with coworkers every day. Cameras will be used to make sure you are smiling

StumblyWumbly
Sep 12, 2007

Batmanticore!
Today I got our V2 hardware fully built up by production, in the enclosure, attached to all the peripherals, and found that, despite earlier indications, the problem from V1 was still there.
Turns out production built it up with the V1 hardware.
Really glad I checked before raising any alarms.

StumblyWumbly
Sep 12, 2007

Batmanticore!

SurgicalOntologist posted:

Has anyone come across any useful resources, blog posts or whatever, that take the ideas of Team Topologies but apply it to small organizations? I'm rereading it and it's really quite illuminating, we have lots of antipatterns they talk about it, but we only have 15 people and maybe budget for 1 more soon if we're lucky, so we don't really have a lot of room to maneuver in terms of team organization. We're too many to "just wing it" as a single team but too few to be able to draw enough lines to reduce cognitive load as much as I'd like to.

Maybe later I'll go deeper into the specifics of how we're organized now and get feedback, just wondering if someone's already written on this.

Best idea I have so far is just acknowledge it and plan for growth. I.e. treat one team as if they really are two teams. At least making explicit in their heads that there are two separable value streams they're responsible for, such that whenever growth allows it, splitting will seem natural and somewhat planned ahead for.

Edit: in before "sounds like the company itself has too much cognitive load / is it trying to do too much", yes yes of course, let's take that as a given and assume I can't change that.
A management book I'm reading now has the line "If you're managing 4 people or less that, you aren't managing a team you're managing 4 individuals". I forget the exact number, may have been 6, but it rings true for me, at small numbers you can't really balance out people to the same degree. So, considering the people you actually have and how to maximize them may be a helpful way forward, any advice may end up being idiosyncratic.

Aramoro posted:

We've been given a tool like that which connects to JIRA and GitHub so what we're doing as managers is working out how we can show we're using this 'tool' whilst at the same time, not using the tool.
I looked for something like this for a while, and Exelate got close to working, but then I just gave up and the person who was complaining about cross linking issues gave up, and things have been going really well ever since.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Does anyone know how hr/ background check would work? Companies will generally call, usually after an offer, to confirm employment, but if I was at x as a consultant of y, it would need to be clear that hr should confirm with y.

StumblyWumbly
Sep 12, 2007

Batmanticore!
Person A is retreading ground and should be referring to earlier work is very valid and helpful.
Person A is presenting stuff I could have told you is not helpful.
Getting a project going is a sales job, a mix of fact and presentation. But also, since chat gpt, ml has had a huge jump in credibility

StumblyWumbly
Sep 12, 2007

Batmanticore!
I have never heard of Python v1, and I expect it's unrecognizable and only pulled out to torture cs students.

StumblyWumbly
Sep 12, 2007

Batmanticore!
In general, if you ask a room of people to something that is more complex or time consuming than to water a plant, you will not get a response. It does not matter how many people are in the room.

Adbot
ADBOT LOVES YOU

StumblyWumbly
Sep 12, 2007

Batmanticore!
Quantity over quality has been the strategy in all sorts of applications for a while now. It's not like you're going to switch jobs because you have a warm relationship with the recruiter.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply