abraxas's recent activity
-
Comment on New to Leading a Team of Software Developers in ~comp
-
Comment on Post something that you want to get into but don't know how, and have other people give you advice in ~hobbies
abraxas Link ParentInteresting you say chardonnay is inoffensive. It's basically the only wine I don't like. I'm still starting out on the Wine journey, but chardonnay feels to me like it's a white wine pretending...Interesting you say chardonnay is inoffensive. It's basically the only wine I don't like.
I'm still starting out on the Wine journey, but chardonnay feels to me like it's a white wine pretending to be a merlot.
-
Comment on Fun, relaxing, singleplayer games in ~games
abraxas Link ParentI need to restart every 4-5 hours of play due to FPS drop on my PS4. I've had that several patches in a row. Have you had the same? If not, I wonder why.I need to restart every 4-5 hours of play due to FPS drop on my PS4. I've had that several patches in a row.
Have you had the same? If not, I wonder why.
-
Comment on Fun, relaxing, singleplayer games in ~games
abraxas Link ParentTotal agreement. I still don't think it's AAA-quality. It's now like a Minecraft. You pay <30, and you can get hundreds of hours out of it. But it'll always be missing some polish. And that's ok...Total agreement.
I still don't think it's AAA-quality. It's now like a Minecraft. You pay <30, and you can get hundreds of hours out of it. But it'll always be missing some polish. And that's ok because you didn't give your entire paycheck for it.
Manager and former team leader here... You're already to a good start by giving a damn.
A few suggestions.
First. Try to setup weekly or semi-weekly "one-on-one" meetings with your team members. Just a half hour will do. Some teams love this, others hate it. The goal of those meetings is almost 100% to make sure they have everything they need, and that you understand what's going on with their job/career. I had a boss that asked 3 questions, and then opened up to chat. I love them. His 3 questions:
99% of the time, the answer is always "yes, yes, nothing" even if it's not 100% true... but if you keep asking it and meaning it, you start to hear "yeah you know this damn service is making me lose sleep and I don't have the time to go fix it" or "I feel like every project is just writing data models, just because I've done a lot of that", etc... Suddenly you know something that improves the company and helps you make the team member happier.
Second, while you want some percent of hands'-on time, you really have to understand that every hour you spend helping your team out pays back 4-5 hours of your dev time or more. You'll have weak team members, you'll have overconfident team members. Your job is to help everyone be (and stay) better than you are at coding your project.
Finally: Process is king. It should be simple, but there should be process for almost everything. When something goes wrong, you blame the process or yourself for failing to maintain the process. It's not necessarily that a good process is really that good, but a good process helps you insulate your team members from mistakes. Everyone makes them, and at even the best company, someone is going to want to crucify a really good coder because he let a minor bug through and it cost $50k or more. At the end of the day, a programmer afraid of rebuke is not going to code well.
Also, everything @webgambit said. He's spot on, so not worth repeating.
As for your direct questions:
Honestly, a good team peer-reviews anyway. Get Code Review going. If they don't yet, start with PRs for features, or voluntary review. PRs are a poor-man's code review. Almost all git apps support em. For projects/processes, look for documentation and consistency. And more importantly, does it work?
I'd stick it out a month before you start suggesting changes. Try to get plurality buy-in from the team, but realize you might not always get that. When you don't, make any run a trial run. If something is unpopular and can't demonstrably improve things, drop it.
Not quite sure how you're asking here. Examples of what goes right/wrong?
Not sure. I'm still learning my "democracy/mandate" balance, but am sure it differs team to team. Communication is always king, and the rest of your job is more about keeping the team from getting blocked or becoming slowed than anything else.