|
My old company did a “hackathon” once. It sucked. It wasn’t even a real hackathon, just a mandatory evening continuing education session in which we learned new stuff we were to implement in our new version (no hacking or experimenting involved) and were only given lovely cheese pizza and Mountain Dew and no alcohol (because the lead dev had the palate of a seven-year-old and the higher ups were being tightwads about beer or something). We had to vote on an evening that worked for us, and lead dev seriously thought Friday and Saturday were appropriate options. I’m not spending one of my weekend evenings venturing to the sketchy neighborhood in which our office was located after dark by myself just so I can learn the intricacies of Redux or whatever over greasy pizza while sober with coworkers I don’t like - gently caress that poo poo. My current company is an entirely different story. Most folks here are 30s+ and have families and lives, including the C-levels, so late night hackathon poo poo is regarded as disrespectful of employees’ time and work-life balance and we don’t do it. Any special activity takes place during normal work hours on company time. I’m so happy I changed jobs.
|
#
?
Sep 3, 2020 16:43
|
|
|
|
| # ? Apr 25, 2024 13:52 |
|
|
My last company did a hackathon where we spent a day (during regular business hours) working on technical debt rather than business priorities. Yay?
|
|
#
?
Sep 3, 2020 16:48
|
|
|
ultrafilter posted:My last company did a hackathon where we spent a day (during regular business hours) working on technical debt rather than business priorities. Yay? This tells me your company had poo poo standards from the beginning.
|
|
#
?
Sep 3, 2020 16:50
|
|
|
There's a reason I'm not there any more. Don't worry though, they're just building critical infrastructure for modern society.
|
|
#
?
Sep 3, 2020 16:54
|
|
|
Protocol7 posted:I dunno, think there’s confusion around something else. The other goon mentioned pet projects which sounds like a PM trying to exert control during hackathons to me. Yeah, if it's PMs deciding what things are being worked on, then it's a work day, no matter what they call it. Queen Victorian posted:My old company did a “hackathon” once. It sucked. It wasn’t even a real hackathon, just a mandatory evening continuing education session in which we learned new stuff we were to implement in our new version (no hacking or experimenting involved) and were only given lovely cheese pizza and Mountain Dew and no alcohol (because the lead dev had the palate of a seven-year-old and the higher ups were being tightwads about beer or something). gently caress ALL of that. This is the kind of situation where enforced WFH saves the day, because you can sign on, mute and do whatever.
|
|
#
?
Sep 3, 2020 17:18
|
|
|
One thing I really like about my company’s hackathons are that they’re not restricted to engineering, which means nobody tries to get on my calendar.
|
|
#
?
Sep 3, 2020 17:30
|
|
|
A company I used to work for a long time ago did one weeknight per week where they would provide beer and you could come in and hang out and work on your own stuff or work stuff or whatever. It's the kind of thing that would send me running if I heard about it now but this was a small company with people I really liked and free beer in my early 20s was a pretty good motivator.
|
|
#
?
Sep 3, 2020 20:16
|
|
|
As long as it is genuinely voluntary, I see no problem with that.
|
|
#
?
Sep 3, 2020 21:54
|
|
|
Che Delilas posted:Are these product features that the business explicitly does not want in their product? Otherwise, why would you stop engineers from improving your product if that's what they want to do? What's the goal of the hackathon, to produce specifically useless things? it's more that we're trying to optimize for different things - a lot of drama the past few iterations has come because people would get a chance to work on their pet project that didn't fit into the roadmap, do a bunch of prework, come out with a great demo and wow everyone in the company... and then it would sit there for a year, because it wasn't actually a useful feature (or, the cost of actually implementing it at scale was too prohibitive, or the support plan was unworkable, etc. etc.). the people who did the work got mad because their brilliant idea didn't actually ship, the sales/cs people got mad because omg this is so useful why arent we doing this already!!, etc. etc. also, we want product management to actually prioritize things that they think are important and have people work on them, rather than trying to windmill dunk poo poo in. other considerations - people have complained in the past about very good projects that would have made a real difference (developer productivity stuff, as an example) getting set aside because of the way voting happened (people always basically bandwagon voted for the "shippable product feature"), people outside engineering feeling like they didn't really get to make any contributions because engineers were all cliqued up working on pet projects... our hackathon is company-wide, so we don't like it when people feel like they can't participate. it's tough, because we do want interesting product improvements, but we want people to think bigger about them rather than try to snipe things that are already on a roadmap (or things they believe should be on the roadmap), if that makes sense? kitten emergency fucked around with this message at 22:13 on Sep 3, 2020 |
|
#
?
Sep 3, 2020 22:10
|
|
|
All that makes sense, thanks
|
|
#
?
Sep 3, 2020 23:29
|
|
|
Che Delilas posted:gently caress ALL of that. This is the kind of situation where enforced WFH saves the day, because you can sign on, mute and do whatever. I retrospect it seems as though the founders cargo-culted the implementation of “tech startup culture” because they went through the motions and used the terminology but the results never quite matched up with expectations. Hence the continuing education seminar hackathon. When the company culture wasn’t absent it felt superficial and forced. Which was weird because the CEO (who I’m still buds with despite leaving on not the best terms) is a sociable, amiable guy who’s pretty fun to hang out with  . I guess the dev team leadership was what dragged everything down. CTO was kind of aloof and the lead dev he hired was seriously one of the most dour fucks I’ve ever met, so no wonder being on the dev team there was so miserable.prom candy posted:A company I used to work for a long time ago did one weeknight per week where they would provide beer and you could come in and hang out and work on your own stuff or work stuff or whatever. It's the kind of thing that would send me running if I heard about it now but this was a small company with people I really liked and free beer in my early 20s was a pretty good motivator. Yeah if this was voluntary it seems fine. Just so long as the voluntary nature of it isn’t used to covertly gauge “team loyalty” or some bullshit metric like that and worm its way into performance reviews and poo poo. Which I wouldn’t put past a lot of tech startups.
|
|
#
?
Sep 4, 2020 01:40
|
|
|
Queen Victorian posted:I retrospect it seems as though the founders cargo-culted the implementation of “tech startup culture” because they went through the motions and used the terminology but the results never quite matched up with expectations. Hence the continuing education seminar hackathon. When the company culture wasn’t absent it felt superficial and forced. Which was weird because the CEO (who I’m still buds with despite leaving on not the best terms) is a sociable, amiable guy who’s pretty fun to hang out with They couldn't afford to fire me (I had too much knowledge and experience and leadership responsibility) but they could afford to deny me a promotion, which is part of why I left (the other part is the culture that created that). I highly doubt anything like that is really voluntary, and it will at least color how management sees you.
|
|
#
?
Sep 4, 2020 03:36
|
|
|
Ghost of Reagan Past posted:I highly doubt anything like that is really voluntary, and it will at least color how management sees you. My current company takes great care to avoid having extracurricular stuff color management’s perception of you, and that’s the thing - it’s a conscious effort. Also, these extracurriculars never have anything to do with work by design. I got in trouble at my old company for not taking my laptop home with me in the evening because by not taking it home, I was showing the rest of the team I wasn’t dedicated enough to the company and setting a bad example or someshit. I dragged the loving thing home every night and dumped it in the foyer because I sure as gently caress wasn’t going to waste my evenings checking in on work stuff when I could be drinking heavily in order to decompress from work. They constantly let little things like that color the perception of your performance and “dedication” and it seriously wore me down after a while. If you weren’t an antisocial workaholic sperglord, you couldn’t win. But that’s small potatoes in the great scheme of tech startups with lovely cultures - friend of mine got fired from Uber ATG for balking at being asked to work 70 hour weeks while being salaried at 40 and then having the gall to ask to be paid for 70 hours a week. That whole place is amazingly hosed up.
|
|
#
?
Sep 4, 2020 06:05
|
|
|
You can get in quite serious trouble here for working after hours. It's not expected of you, you won't get paid for it, and if management notices you doing this more than once they will have a concerned talk with you about you hurting your mental health by overworking yourself, which may well lead to worse performance overall.
|
|
#
?
Sep 4, 2020 07:06
|
|
|
Carbon dioxide posted:You can get in quite serious trouble here for working after hours. It's not expected of you, you won't get paid for it, and if management notices you doing this more than once they will have a concerned talk with you about you hurting your mental health by overworking yourself, which may well lead to worse performance overall.
|
|
#
?
Sep 4, 2020 14:30
|
|
|
Vulture Culture posted:Many people think this is fine, but also, there's nobody less equipped to gauge their own mental health than people who put in extra hours at work for fun Yeah this conversation basically has to be "you need to chill" not "we're worried about your mental health" I work with a guy who is incredibly dedicated and frequently pulls late nights at home and weekends to get stuff done and his manager has had multiple conversations with him along the lines of "I get that you want this done but you're a Sr engineer and you're setting a bad example for the people you're supposed to be mentoring" and honestly I think that's the way to go about it
|
|
#
?
Sep 4, 2020 18:02
|
|
|
Queen Victorian posted:
Yeah we didn't have performance reviews or management really. Everyone was either a designer, a developer, or maybe sales/admin. Once we started growing into having stuff like managers and reviews most of the developers and designers left (including me). I don't think I ever want to work in a company larger than like 15 people.
|
|
#
?
Sep 4, 2020 18:20
|
|
|
ChickenWing posted:Yeah this conversation basically has to be "you need to chill" not "we're worried about your mental health" - My preference is that you invest the tech time into something unrelated to work. Learn Rust or something - If you must use work-related tech, try to do it in a homelab - If you can't do it in a homelab, let's try to get a group of people together, make it explicitly extracurricular, and give you company resources to do it - If you must work after hours, reduce the optics of you working hours. No commits with midnight timestamps and nothing that's going to generate notifications for your coworkers unless it's planned work - Every line of code you write is someone else's tech debt, and probably yours too, so try not to go nuts unless the team agrees
|
|
#
?
Sep 5, 2020 16:15
|
|
|
Vulture Culture posted:Truth. I get that some folks love tech, and rapid growth trajectory is an actual hobby for some others, but I try to set the following ground rules: This is the problem I had early on with my current job and basically the same rules I followed to separate work from the rest of my life. As a result I've been much happier and learned a bunch of cool new stuff. My boss, however, is all in on the company: he'll update jira cards, post troubleshooting remarks in slack, make commits, send emails, open (and review) pull requests at all hours and on weekends. He also refuses to accept that it sets a bad precedent for everyone else.
|
|
#
?
Sep 6, 2020 03:07
|
|
|
whats for dinner posted:This is the problem I had early on with my current job and basically the same rules I followed to separate work from the rest of my life. As a result I've been much happier and learned a bunch of cool new stuff. A "Clueless"/sucker according to the Gervais theory, one might say. https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/
|
|
#
?
Sep 6, 2020 03:20
|
|
|
I don’t have a problem with folks working extra if (1) they enjoy it, (2) they don’t need to do it to meet expectations / keep their head above water and (3) that the culture isn’t one where it becomes the bar everyone else needs to meet. It’s very good for a manager to be explicitly clear about their personal interest in work/life balance and the expectations that their team members maintain it.
|
|
#
?
Sep 6, 2020 06:03
|
|
|
Working off hours can often be a reaction to a culture of too many meetings, where “there is no time to do anything” during the workday. Especially if you are in management.
|
|
#
?
Sep 6, 2020 13:59
|
|
|
Sounds like you need extra managers to manage your managers.
|
|
#
?
Sep 6, 2020 14:00
|
|
|
smackfu posted:Working off hours can often be a reaction to a culture of too many meetings, where “there is no time to do anything” during the workday. Especially if you are in management. Selfishly, as an engineering leader, I'm terrified of one specific danger posed by people in my line working long hours: the more people think late hours are great, the more it lengthens the feedback loop I rely on to know if I'm loving up. Protocol7 posted:Sounds like you need extra managers to manage your managers.
|
|
#
?
Sep 7, 2020 02:49
|
|
|
Vulture Culture posted:Too many meetings can be a trigger, but a lot of technology managers/organizations don't pay sufficient attention to any of the preconditions of flow state, where 80% of real authorship gets done. Insufficient attention to documentation, bad planning/coordination making everything urgent, stressful on-call cultures are all torpedoes that leave people feeling insecure about how much they're accomplishing versus what they know they're capable of. It hits ADHD people even harder than neurotypical folks, between the time blindness, people-pleasing behaviors, unsteady biorhythms, et cetera. But I actually wanted to ask the thread something else! Mostly for folks doing frontend stuff to some extent: our sprint board at work is all "user stories" (never actually written as user stories or necessarily describing a use case at all), which in turn contain tasks. When they get to testing, bug tickets are added as issues are found. My question: when the work differs in appearance from the design sketches used as requirements, is it really appropriate to file that as a bug? These designs are pretty much initial sketches with inconsistencies, lack of detail and sometimes features and elements that are flat-out in conflict with decent UI/UX and the company-wide visual identity, so devs are encouraged to take some liberties and personal initiative when implementing them. Thus the solution to "final product doesn't match initial design" is sometimes to change the implementation, but sometimes the solution is to talk to the designer and either get the implementation approved or prompt design revisions. Basically this seems like something that ought to be considered different from a bug. Also the whole process ought to be more structured, but that's more of a long-term issue that needs work (I'm gently pushing towards it).
|
|
#
?
Sep 8, 2020 10:18
|
|
|
That is absolutely not a bug. We tend to do design review phases on our product where after a batch of related stories are submitted a designer will go through and make a list of any tweaks. Generally that same designer would have been working tightly with the developer during the building of the feature so if something looks wildly different from the mockup they were probably already involved in the discussion of why. But sometimes the developer also just misses a detail from the mockup and the designer wants it the way they want it and that's ok (assuming it's not a major effort to achieve.)
|
|
#
?
Sep 9, 2020 04:51
|
|
|
speaking of after hours and on-call I’m closing in on defeating my people pleasing nature and declining client calls during a rotation that don’t have clear goals and problems to resolve it’s almost always a recipe for some busybody psychopath who has demanded to speak to an engineer and mostly wants a verbal punching bag all respect to folks who do that poo poo for a living but it makes me want to walk into the sea
|
|
#
?
Sep 11, 2020 05:36
|
|
|
quote:Basically this seems like something that ought to be considered different from a bug. It sounds like you are just making up your own process, so what you call things are kind of arbitrary. Ideally everyone in your team would agree on the definitions. You could call them “change requests” if it would make people feel better.
|
|
#
?
Sep 11, 2020 13:04
|
|
|
Iverron posted:speaking of after hours and on-call I’m closing in on defeating my people pleasing nature and declining client calls during a rotation that don’t have clear goals and problems to resolve Why in the world would you be on-call for client calls? That's a " pay me, exorbitantly" compromise.
|
|
#
?
Sep 12, 2020 16:08
|
|
|
Does anyone have some constructive feedback on what makes for a useful product manager in your experience? I looked for a thread on product management, but I guess there aren't many goons in that role. I am going to be transitioning into a product owner role soon (my background is in academia) and I know most devs have very mixed feelings about product managers. So I'd be interested in feedback on "doing it right" from a dev perspective. There are plenty of long-form essays on doing it right from other product managers, but it is never clear to me how much of that is just self-serving bias...
|
|
#
?
Sep 13, 2020 08:04
|
|
|
I've had a mix of PMs. My current one is really great and IMO a PM's most important role is removing blockers to development. I get handed well-written user stories and can escalate anything blocking dev (missing info, dependencies on other teams, whatever) to her and they get quickly resolved. In contrast, a bad PM adds a bunch of extra work ("Can you just create a dozen tasks on this story to break everything down?") without really helping. It makes a big difference.
|
|
#
?
Sep 13, 2020 08:22
|
|
|
When thinking back to the best PM I ever worked with, I think the standout attributes were being a domain expert and being on top of prioritization and handling the back-and-forth between the stakeholders (internal users) and the devteam. It resulted in someone who *knew* what the users wanted and *why* they wanted it and *how* important it was to them, such that developers always had a single point of contact for any questions. It also meant stories were well described, and in a way that cut out almost the entire need for some sort of long back-and-forth about every new feature. Take stuff from the top of the queue, get it built, possibly have some back-and-forth about edge cases and get immediate direct answers - no 'well let me check on that I'll get back to you in a week'. Almost every other PM I've ever worked with has failed in one of these areas: They've not been domain experts - which means that any question about a story they wrote/prioritized became a hugely delayed thing because they'd have to go figure out the answer. They've not been much for prioritization - so while we had a pile of tasks, there was no clear idea of what was actually important. Or they failed to fill in that 'analyst' role of interfacing with the stakeholders, such that we kept swinging wildly from sprint to sprint because we kept building what the PM thought the users wanted while speaking minimally to them and just letting the dev team sort it out.
|
|
#
?
Sep 13, 2020 14:00
|
|
|
^^^ Domain expertise is the big one. Having the authority to make decisions about the product is another. Also, for a far softer skill, a product owner has to be super organized. Programmers can get away with being a bit messy and late to meetings and missing emails. Product owners can't.
|
|
#
?
Sep 13, 2020 14:45
|
|
|
The product owner that I work with is so busy with management and/or business issues that they don't have anything to do with the day to day dev tasks, but they do use their power to block any tasks that are not directly being requested and paid for by a customer. Pretty much every day is spent chasing down the issues that are caused by the fact that the product is utter garbage but you are not allowed to improve anything because that's not good business and this is how we have always done things around here. Uh anyway. Good PMs that I've seen are people who have been communicating with the stakeholders and know the domain so that when there's ambiguities they can resolve those quickly either by knowing the answer by themselves or by knowing who to contact. Bad PMs are people who don't know anything so you quickly learn that you shouldn't even bother trying to talk to them first, which leads to them knowing even less about what's going on in their projects.
|
|
#
?
Sep 13, 2020 15:00
|
|
|
A good PM is a lot like a good IT team in that the better they do their job, the more invisible their hand in it. Your job is to be the oil in the project process - you coordinate, plan, and provide sufficient detail to your teams to make sure they're empowered to do the nitty-gritty, and deflect bullshit so that they're not getting bogged down more than absolutely necessary. Ideally you should be: - able to answer as many questions as possible about current or near future work in detail (with regards to business requirements) - flexible with priorities and upcoming work (i.e. knowing when something absolutely needs to be moved up/down in priority, or whether dev needs to take a new direction) - able to deflect information requests in either direction, so that people outside dev aren't interrupting dev flow time, and the dev team isn't waiting on management/clients for information - as organized/prepared as possible so that meetings are kept efficient as a bonus, it really helps to understand dev jargon and a little bit about how things work under the hood so that when devs get into the weeds a bit you can answer questions that come up and also help guide them back out 
|
|
#
?
Sep 13, 2020 16:40
|
|
|
Mostly what I want from a PM as a dev is attentiveness to what’s going on with the engineering team, which feeds into keeping priorities straight. A PM who no shows stand ups, doesn’t look at the board, and only asks what’s happening with things as deadlines (that eng may not know about) approach is gonna be surprised and you’ll see things shift in a panic rather than as a smooth response. If this is not possible your team is probably too big to manage well and should be split. If possible, saying no to projects that don’t seem worthwhile can be an amazing strength - my team gets stuff pushed down to it which are straight up over complicated and don’t seem likely to move the needle on anything. My team’s job is not to do the MOST engineering. Nor is it to just do whatever our design team mocked up without any critical thought about the ROI. This is the fault of eng leads on my team as much as anything but please don’t treat a sprint as some magical container where all work will get done as long as it goes in the sprint, regardless of what it is, if we’re told to work really hard. I don’t think our PM is necessarily this naive but at the very least there’s a feeling of being able to add more stuff and more stuff will get done, in practice we just get very confused about what’s even important. Otherwise flexibility in the face of new information (surprising complexity, dev team working outside of their comfort zone) is key. If things are slipping and you’re not trying to find ways to improve team focus, pare down features, etc., you’re not doing product management, you’re doing product dictation and you will be disappointed in the results.
|
|
#
?
Sep 13, 2020 17:01
|
|
|
A good product owner is a bullshit umbrella for the team. Other people have covered the specifics of what that means pretty well, but that's an important high-level understanding to have.
|
|
#
?
Sep 13, 2020 17:06
|
|
|
Agreed with all of the prior statements. In addition, I like to think of the product lead as being someone who has a high level understanding of the current state of the product and how customers are using it. As a dev, it's really hard to context shift between the nitty gritty details I need to keep track of to make sure my current task is moving along and the customer use context of how all the features fit together to create a sellable solution. The context shift between different programming tasks is an order of magnitude smaller than trying to shift into a product design / business needs context. I currently have to do a lot of that as a senior dev at a small startup and it's the reason I'm far less productive than our juniors - I've been shifted into a hybrid role of product manager / team lead / developer and am inefficient at all. It's a huge roadblock for me if I'm trying to figure out how to create the most performant / clean / bug-free version of a feature and I have to stop to figure out the business tradeoffs. Everything grinds to a halt if I have to go and find stakeholders myself or even demo the feature to them in depth so they understand the situation I'm dealing with.
|
|
#
?
Sep 13, 2020 18:08
|
|
|
I am an experienced PM and now a manager of PMs. I don't think we have a thread for it on SA. I have considered starting something but I don't think there's enough people to keep it active.I mostly lurk in this thread. These posts are correct, obviously there's other things PMs do (or should do) that devs don't necessarily see. They for sure feels the results though so it's good advice. two things: 1) sometimes the PM or product person is positioned by the org as an empty suit. Those jobs suck and you should not stick around longer than what it takes to get a better resume. However, It's sometimes hard to even tell what authority you actually have. You might not realize how much you can do just looking at things on paper or even comparing to peers. So, learn your domain and try to take as much responsibly for the product vision and value as you can. 2) don't end up as the project manager. If you're only managing dependencies, deadlines and reporting that out - sorry your product in name only. That stuff is part of a product job but it shouldn't be the only or primary piece of work. If that is what the company expects from their "product" people then you're probably better off jumping ship. Assuming you have a true product role, it's very possible to get sucked too far into that stuff, especially if eng or business management is weak. I'm happy to chat here if others don't mind or via PM (pun!).
|
|
#
?
Sep 13, 2020 20:03
|
|
|
|
| # ? Apr 25, 2024 13:52 |
|
|
There is a project management thread already, not development specific but might be interesting all the same: https://forums.somethingawful.com/showthread.php?threadid=3853180&perpage=40
|
|
#
?
Sep 13, 2020 22:47
|
|
