|
Daviclond posted:we spend a few hours each day hanging out in a video call while working and will passively chat about stuff. prom candy posted:To me this is a nightmare, I wouldn't be able to get anything done. You and me both. OP's situation is absolutely bananas to me. I wonder if OP is being as productive as they think they are. At previous jobs, I had co-workers who would sit around and "talk about work" for hours every day. They never got anything done and people mentioned how productive I was compared to others on my team. I'd put on headphones and do work, and happily chat at lunch or at team happy hours or whatever, but I can't imagine trying to do difficult dev work while people are "passively chat[ting]" away in the background. Like OP mentioned, to each their own, but this certainly seems like a recipe for not getting very much done. Daviclond posted:I think these beliefs are pretty extreme and are holding you back. Nobody cares what a bunch of goony devs look like, and chatting with teammates should not seem like "a nightmare" that will deprive you of all productivity. I want to address this specifically. I turn on my camera for meetings here and there, especially when it's something like an architecture review that I am either presenting or have a lot to say about, but there's a time and place for chatting, and I don't believe not usually turning my camera on and not spending hours a day chatting is holding me back in any way. This is a pretty ludicrous accusation.
|
#
?
May 21, 2022 20:58
|
|
|
|
| # ? May 17, 2024 10:39 |
|
|
Daviclond posted:I think these beliefs are pretty extreme and are holding you back. Nobody cares what a bunch of goony devs look like, and chatting with teammates should not seem like "a nightmare" that will deprive you of all productivity. "Zoom Fatigue" is real. We have a policy of not requiring videos to be on unless you want to have it on. Video calling is not a natural act and its worse than phone calls, which are an awful way to communicate. I appreciate that it's what we have, but to claim not wanting to use them is extremism is.... well... crazy.
|
|
#
?
May 21, 2022 21:23
|
|
|
Current employer has a "cameras on" policy and I simply do not follow because I don't give a poo poo, I will keep my camera off if I feel like it, and I extend this extremely basic courtesy to every other human on the planet.
|
|
#
?
May 21, 2022 21:45
|
|
|
I work with a bunch of boomers so every "chat with teammates" almost always revolves around the news cycle hot topic of the day. No thanks, man.
|
|
#
?
May 21, 2022 23:01
|
|
|
They're trying to gauge if your politics are similar enough to theirs that you're a friend, or different enough that you're an enemy.
|
|
#
?
May 21, 2022 23:41
|
|
|
Daviclond posted:I think these beliefs are pretty extreme and are holding you back. Nobody cares what a bunch of goony devs look like, and chatting with teammates should not seem like "a nightmare" that will deprive you of all productivity. I don't think not wanting to spend hours every day in a video chat while I'm trying to do software development is an extreme belief at all. I'd rather get my work done and then socialize with my wife or my friends. I honestly can't focus on coding very well if people are having conversations around me. When I worked in an open office I had to wear headphones most of the day. I don't think that's really that unusual since probably 2/3 of the devs and designers there did the same thing.
|
|
#
?
May 22, 2022 01:33
|
|
|
Harriet Carker posted:I wonder if OP is being as productive as they think they are. lol at giving a poo poo about being productive for your employer’s benefit
|
|
#
?
May 22, 2022 02:33
|
|
|
csammis posted:lol at giving a poo poo about being productive for your employer’s benefit I was responding to: Daviclond posted:I think these beliefs are pretty extreme and are holding you back. Nobody cares what a bunch of goony devs look like, and chatting with teammates should not seem like "a nightmare" that will deprive you of all productivity. I'm productive for myself, because being good at my job and getting poo poo done has so far been a great path toward more $$
|
|
#
?
May 22, 2022 03:44
|
|
|
Daviclond posted:since COVID and going near-fully remote, we spend a few hours each day hanging out in a video call while working and will passively chat about stuff reinventing open plan offices for remote workers. visionary
|
|
#
?
May 22, 2022 10:49
|
|
|
In the early days of the pandemic, everyone was trying to figure out ways to get the same benefits of working in an office, one of which was the organic/passive conversation point, and we tried the open zoom meeting thing too. It was a disaster. Hanging out on a zoom with a bunch of people only acted as a distraction, because whoever is talking is directly in your ears, no matter if they're talking to you or about a problem you're working on. It's far more disruptive than being in an open office with headphones (also distracting, but you can tune people out somewhat), unless you're going to mute zoom entirely and then what's the point of being in the open zoom in the first place? After my team being completely remote for a couple of years now, we've stopped trying to replicate the feeling of being in an office together. We get together for lunch every now and then, now that it's relatively safe to do so. We have a lot more small (not whole-team) zoom meetings to talk about specific issues. And we still have coffee break style conversations with personal anecdotes or venting about this or that, we just do that more at the start/end of zoom calls or slack. It's not the same as before, but the people on my team still feel like part of a team, not just a series of disconnected randos. People are no less productive, and at least some of us are a lot happier with the flexibility and general comfort of being home.
|
|
#
?
May 22, 2022 15:55
|
|
|
I did a Toastmasters humorous speech in Zoom during the Pandemic and got a splitting headache afterwards from trying to read everybody while they were muted. I needed to pop some pain meds and lay down. And that was something like my third project before DTM (the highest level in the program). I took at as a lesson in over-relying on sound cues instead of needing everybody else to be available.
|
|
#
?
May 22, 2022 19:50
|
|
|
My in-laws are retired opera singers and coaches. They've performed on some pretty big stages. Their advice was that if you're really performing,don't read the room. But do prepare and practice to the ^n degree. I think I've improved the consistency of my presentations following that advice.
|
|
#
?
May 22, 2022 20:13
|
|
|
I can see that being good advice for an opera singer but it's a pretty lousy approach to teaching.
|
|
#
?
May 22, 2022 22:55
|
|
|
We theoretically have a "cameras on" policy but in my experience, other than 1-on-1 meetings, R&D completely ignores it (including upper management).
|
|
#
?
May 23, 2022 00:03
|
|
|
ultrafilter posted:I can see that being good advice for an opera singer but it's a pretty lousy approach to teaching. That wouldn't be performing though, would it.
|
|
#
?
May 23, 2022 00:06
|
|
|
IME presentations are a lot more like teaching than performing.
|
|
#
?
May 23, 2022 00:34
|
|
|
Harriet Carker posted:I'm productive for myself, because being good at my job and getting poo poo done has so far been a great path toward more $$ I also just find that the day goes a hell of a lot faster if I'm actually doing stuff that whole time. I mean I enjoy talking to people but I only have so much energy for the kind of forced conversations that occur between me and the random BAs that sit nearby on the rare occasions I go into the office. The devs are as a whole a lot better at just being polite and catching up when they first see you and then letting you get to work because they have their work to do too. (You can probably tie this anecdote into many stereotypes about software engineers and you probably aren't wrong)
|
|
#
?
May 23, 2022 07:56
|
|
PEPSI for TV-GAME
|
I started being camera on a few months back and it's lead to management thinking I should take on more team lead roles. I think it's just they pop their heads into meetings, see me with camera on and assume I'm leading it?
|
|
#
?
May 23, 2022 08:37
|
|
|
Mega Comrade posted:I started being camera on a few months back and it's lead to management thinking I should take on more team lead roles. if that's not a powerful argument for camera off 24/7 then i don't know what is
|
|
#
?
May 23, 2022 12:24
|
|
|
Mega Comrade posted:I started being camera on a few months back and it's lead to management thinking I should take on more team lead roles. Is there a promotion and pay raise involved? Lol
|
|
#
?
May 23, 2022 15:23
|
|
|
There will be if I take it on yes. Its a new role for the company, we have a department head and at the moment he takes on way too much so the idea is to break up some of his responsibilities and divvy them out a little. So it's kind of team lead lite as we don't need full team leads really.
|
|
#
?
May 23, 2022 16:03
|
|
|
Mega Comrade posted:it's kind of team lead lite Yeah that’s how the get you
|
|
#
?
May 23, 2022 16:31
|
|
|
That's a hard pass without a significant pay raise 
|
|
#
?
May 23, 2022 16:50
|
|
|
The real trick is to placate your boss by saying you want to further your career at ${company} while doing the bare minimum for 2 - 4 years and then job hopping for a 35%+ raise.
|
|
#
?
May 23, 2022 16:51
|
|
|
FlapYoJacks posted:The real trick is to placate your boss by saying you want to further your career at ${company} while doing the bare minimum for 2 - 4 years and then job hopping for a 35%+ raise. 
|
|
#
?
May 23, 2022 16:54
|
|
|
How do other people actually do design? The lead has been complaining about mine but his advice in the past has been "use design patterns", "follow SOLID", and to show the other devs whatever I made and see if they think it's bad.
|
|
#
?
May 27, 2022 06:08
|
|
|
Get lots of practice. Keep using your own code, as well as others', so that you can understand what parts of it are easy or hard to use and understand. Expose yourself to many different types of problem and pay attention to when a new problem shares structural characteristics with problems you already know how to solve well. Read others' code. Seek code reviews, and ask for more detail on the things that can be improved - and especially seek specific feedback, rather than generalities like how to get better at design. Perform code reviews, possibly under the supervision of someone else, and ask for explanations of things you don't understand. Use shadowing or pair programming to get a sense of how your more experienced colleagues approach problems. Even talk theory with indulgent seniors. Being good at design basically means knowing all the tools in your toolbox, knowing what tradeoffs each of them entail, and internalizing the sense that helps you identify when each of them would be appropriate. It's just a lot of knowledge, and there are no shortcuts to just learning it all. It will fall more easily into place as you proceed. Asking for help or mentorship is one of the most effective ways to learn - and you'll get better results from asking more specific questions as you come to understand their significance. Getting instruction in this way can be difficult because programmers are more often hired for their ability to do than to teach, even though teaching is in theory one of the responsibilities of senior programmers. Don't be bashful about asking, though: most good programmers I've known would much rather work with someone curious and willing to improve than with someone who tries to do it all on their own.
|
|
#
?
May 27, 2022 06:29
|
|
|
My design process is: - understand the system - understand your goals - do whatever feels right - solicit opinions from other people to validate what your gut told you and see if there's anything you missed about the problem space Which is really hard to teach, because it comes down to having a good instinct for good design, so that good designs "feel right" while bad designs have you feeling that something's off somehow. Does your team as a whole share design docs with each other before working on projects? If so I'd recommend reading your coworkers' designs - are they how you'd go about solving that problem? If not, why did they choose this way rather than your way? Is there a concrete advantage to their way or just a difference of opinion? If you have historical designs available, then it's also worth looking through the designs for the shittiest part of your codebase that everyone hates having to work on. Is the pain you currently experience an inevitable outcome of those designs? If you saw a new design that was going down the same road, would you recognize it and be able to push back on it? The most important part of design sense is experience, but you can accelerate gaining that experience by making the most of the lessons that you're presented with.
|
|
#
?
May 27, 2022 07:28
|
|
|
A great way to gain experience is by loving up a lot and then going back and figuring out why you hosed up.
|
|
#
?
May 27, 2022 08:11
|
|
|
Bongo Bill posted:A great way to gain experience is by loving up a lot and then going back and figuring out why you hosed up. Learning by doing (lots of stupid poo poo) 
|
|
#
?
May 27, 2022 09:03
|
|
|
Bongo Bill posted:A great way to gain experience is by loving up a lot and then going back and figuring out why you hosed up. the trick there is loving up enough that you can learn useful things from it, while loving it up little enough that you can still see a way out of the hole you dug for yourself me, i'm mostly just piling more trash onto the heap. even if i had time to try to correct some of the mistakes, i don't know what to do about them
|
|
#
?
May 27, 2022 11:25
|
|
|
Bongo Bill posted:A great way to gain experience is by loving up a lot and then going back and figuring out why you hosed up. This is how I operate. Never be afraid to YOLO in Prod, it's a learning experience, and you should position it as such when you're Director starts yelling at you.
|
|
#
?
May 27, 2022 14:59
|
|
|
Jabor posted:My design process is: I don't know what a design doc looks like. What they want us to do is come up with and explain a design on the open issue, and then have someone else review that design.
|
|
#
?
May 27, 2022 15:26
|
|
|
brand engager posted:How do other people actually do design? The lead has been complaining about mine but his advice in the past has been "use design patterns", "follow SOLID", and to show the other devs whatever I made and see if they think it's bad. If your lead is complaining you should ask them to sit down and show you how they would structure the feature. You can have some real ah-ha moments seeing someone with more experience solve the exact problem that you just solved. If your lead is just sending it back and saying "not good enough" with no elaboration your lead sucks.
|
|
#
?
May 27, 2022 16:23
|
|
|
brand engager posted:I don't know what a design doc looks like. What they want us to do is come up with and explain a design on the open issue, and then have someone else review that design. A "design doc" is just a document explaining a design. If you're making something new, a typical design doc will open with the problem you're trying to solve, any relevant context that puts constraints on your possible solutions, and the design you intend to go for. Frequently your design doc will also have alternative designs that could have been used, and reasons why your preferred design was chosen. Also frequently your design doc will start with a bunch of possible designs along with their positive and negative aspects, and actually choosing which design to use is done as part of a discussion with the team. I would recommend writing these sort of docs - not only are they a good way of soliciting input and review from your coworkers the way your boss wants you to, just the act of writing down all the stuff you're thinking about helps you really understand the problem you're tackling and the design you plan to build. Often in the process of writing down your design you'll identify issues that would otherwise have only surfaced after you'd spent days or weeks trying to implement it.
|
|
#
?
May 27, 2022 16:53
|
|
|
If someone starts asking for 'designs' that are less discussing context and rationale and more "write the code before writing the code, but in pictures and UML" then run for the door.
|
|
#
?
May 27, 2022 17:25
|
|
|
If they want you to write design documents, tell them to show you existing design documents to help understand what they want. We have an ever-increasingly large number of design doc templates to use, but they all boil down to - 1(ish) Paragraph summary of what you're doing and what it solves - Context (what is the current situation, and why does it need changes) - Glossary (optional) - High level description of proposal - Specific details, with table structure / network timeline / proto structure as appropriate and necessary - Alternatives considered, with reasons why and why not to use them - (Security|Accessibility|Stability|etc) concerns Also, you should show your document to coworkers, but mainly to solicit feedback, not to self flagellate. If the criticism you get isn't constructive, your coworkers are bad. FWIW I absolutely hate writing design docs, and they're one of my major weak points, but I do understand how and why they're useful. Sucks to suck but it's still a skill you'll need to go further. Volmarias fucked around with this message at 19:00 on May 27, 2022 |
|
#
?
May 27, 2022 18:57
|
|
|
It's already been said, but it bears repeating: The best way to architect stuff is to just do it, suck at it and feel the pain, attempt to solve the pain with better solutions (which means homework), and then redoing it. You'll eventually default to 'good' solutions and have a sense for when something is going the wrong direction.
|
|
#
?
May 27, 2022 19:05
|
|
|
Lately, my process is "fart around doing other things until you can't avoid it any longer, then pick the easiest design".
|
|
#
?
May 27, 2022 19:17
|
|
|
|
| # ? May 17, 2024 10:39 |
|
|
Volmarias posted:- 1(ish) Paragraph summary of what you're doing and what it solves I really like this as a generic template.
|
|
#
?
May 28, 2022 00:19
|
|