|
How do folks (especially devops or other split-resourced groups) go about planning tasks and all that? Any good books/etc or other resources to look into? I work in a halfway ops/dev role at Some Big Tech Company. My team is running into a big deadline and we're...frankly really going to slip this one. I think there's a few major issues, but I'm not sure what the fix is; at the very least I've asked our PM to do a retrospective after the 'launch'. I'm new to software dev in general, but I've worked in IT for quite a long time, but unfortunately I think I'm missing some concepts (and definitely my team as a whole is), so trying to be helpful about this since I know that this is one of the Big Software Dev Issues you'll have to deal with forever. My team is mostly new to the org in the last year. If it helps, we work in Python and we use sprints as our main planning tool / execution cycle. Here's the stuff I can see in retrospective: - Requirements definitions are not well done at all; tasks start as single line 'this should do X' from the lead. This leads to most people never sitting down and hashing out 'what are the actual hard reqs', which in turns leads to a lot of rework and unexpected issues popping up. - The tools we're building are a suite of improvement tools that touch a lot of internal systems; I'm not sure how to go about saying 'everyone working on this project is pretty new to the ten different clients we're using and so it's hard to estimate time' - Going on from the last two: The PM was pushing really hard for people to estimate time, but frankly it was impossible to do. I started at least tracking my time spent and found that some of my estimates were off by like 2-4x. I know from past advice that this is a thing you just get better at over time, but I suspect that the last two issues are making this worse. - At least three folks on my team had never written unit tests before (and I've only been doing it for a year or so)
|
#
¿
Apr 7, 2023 04:30
|
|
|
|
| # ¿ May 10, 2024 19:29 |
|
|
Hughlander posted:There's no snake-oil to take, just effort over time. Thanks for both responses, singling this out to say - yep, didn't expect there to be a magic bullet, just curious what other folks do. I've been in the ops sort of role for a long time and I've never been on a team that managed to do this well, so unfortunately I don't have a lot of personal viewpoints to bring to this other than a general sense of 'huh I think we're doing it wrong'. I might also chat with our principal engineers in the org as well and try and get their feedback/etc.
|
|
#
¿
Apr 7, 2023 06:52
|
|
|
Wow that's a ton of great stuff, thanks! I'm taking notes on all this and going to try and bring this up in the retrospective. I have some senior folks I can reach out to for support as well who are pretty sane; and at least my particular group now is pretty reasonable so I think we might be able to make improvements. Are there any good sources I can point to for this stuff that folks are familiar with? Like I think a lot of this is just good arguments on its face but it's always nice to be able to point to a blog post / book or something. Just in case "Hey lead my shitposting forum thinks we do scrum wrong" doesn't work.
|
|
#
¿
Apr 7, 2023 18:55
|
|
|
Bruegels Fuckbooks posted:and why do they call it a "stand-up" meeting when everyone is sitting down? As far as I'm aware, this one is because the intent is that everyone should be standing - a standup should be short enough that everyone should be able to stand and chat and give an update, not get comfortable.
|
|
#
¿
Apr 7, 2023 22:00
|
|
|
Rocko Bonaparte posted:What? Like squatting to take a poo poo? Or like the yoga pose? YOU'LL DELIVER YOUR UPDATES FROM THE TOILET OR BY GOD I'LL MAKE YOU PAY.
|
|
#
¿
Apr 7, 2023 23:12
|
|
|
Doktor Avalanche posted:standups are a chance to shitpost a bit with colleagues and last from 30-45 mins We actually just kind of set our weekly team meeting up to be like : 30 minutes - actual agenda of important items 30 more minutes - time to soapbox or just shoot the poo poo, you can leave if you have poo poo to do
|
|
#
¿
Apr 8, 2023 07:32
|
|
|
I'm getting pretty goddamn frustrated with the ongoing winnowing of work environment mixed with RTO. My company is doing a return to office (3 days/week) and like...I'm not really against working in the office; I generally like chatting with people and my coworkers/etc are nice enough and I do think some things are better in person. However: When I started working in tech it was still somewhat common for Tech ICs to have individual offices, although certainly cube farms or open seating were becoming more common. There's a whole host of words about why open seating for ICs is dumb, so I'll just move past that to the latest bullshit, which was when my org said 'oh we're not going to have assigned desks, it'll all be agile!.' MotherFUCKER if you're going to have me drive into the office, dealing with traffic and parking bullshit, the absolute loving minimum requirement is that you give me a consistent desk to work at. Like sure, a few agile / hotel seats in a building is good! It's nice to have somewhere to drop in and work when you're visiting another team or for folks who are highly mobile, but my whole floor is mostly developers of one flavor or another; we don't float around that much. And if you're doing 3 days a week in office, there's always one day that everyone is going to be there, so you can't really get away with agile! One day a week minimum you'll be at full capacity! Luckily my management chain raised a fuss and it looks like we shot it down, but this constant squeezing of 'oh well we gotta save money!' is just exhausting. The part that's the most irritating about this is that the company is the one that's really wasting effort here. If I show up to work and have to spend an hour fighting to find a desk, I'm not going to stay an hour late, I'm just going to get less done. Same with all sorts of other little bullshit like tinier desks, lovely IT-assigned hardware, etc; all of this just makes me less effective at doing my job, which I enjoy doing, and would like to do without having to jump through a bunch of bullshit hoops.
|
|
#
¿
May 25, 2023 06:18
|
|
|
Cup Runneth Over posted:If I am paid for my time then why am I not paid more when I spend more time on work? Doesn't that just prove you're paid for your time? I guess I'm lucky that I've never really been on a team where I'm invited to totally useless meetings. Either it's good for me to hear what's up, or I'm an active participant in discussion. Even during my time at Microsoft that was never really the case. Also in my experience there's a lot of people who say 'my job as a dev is just to write code' which is...not really true, any more than people who think devs should be totally asocial weirdos are right. Development is translating a need (business or personal or whatever) into computer code, and that is basically half talking to people and working with others. Like tbh, I think my current team could use one or two more meetings to actually discuss stuff and work through it instead of working in isolation and failing to learn from each other, although realtime discussions aren't the only ways to do that. Falcon2001 fucked around with this message at 19:31 on May 25, 2023 |
|
#
¿
May 25, 2023 19:27
|
|
|
epswing posted:Maybe writing documentation or attending meetings feels like a waste of your valuable time because you're some solid gold marvel of a programmer, but what do you care? Let the faceless corporation pay you software development prices to sit in meetings. Yeah the other thing is that if your manager does the 'you just need to get it done' when you tell him 'I don't have enough time to do X because you're wasting Y hours of my time each week in useless meetings', that's mismanagement and you should probably bounce or find another manager. Like sure, you can have a discussion about timelines and whatever, but fundamentally if your company wants to pay you to waste time in dumb meetings that's kind of their prerogative, and they're making a decision to do that at the cost of other productivity, and that's on them to manage that balance and you to give feedback on it.
|
|
#
¿
May 25, 2023 19:59
|
|
|
Canine Blues Arooo posted:Does anyone actually have a test suite that they'd call 'complete'? This is back a page, but I've been trying to wrap my head around testing a lot lately, and one thing that's come up quite a bit is that testing is...pretty loving complicated, and is a lot more of a tradeoff than people sometimes admit. I don't know if there's a way to write complete test suites for a product that isn't absolutely finalized, or at least has tolerance for extremely long delivery times in exchange for safety, like medical devices or NASA landers. Fundamentally the high level downside of testing is that it makes refactoring or changes harder to do, which...isn't bad, but is a tradeoff. If you had exhaustive tests and then had to make even a minor bugfix, you'd probably have to do a lot more test modification and writing than code writing. Especially early in a product's life, when changes are common, that becomes a real problem for achieving business goals if you're like 'Yeah, 4 hours to make the change and 20 more to fix the tests'. This is where things get away from 'get your code coverage to X' and into the territory of writing the 'right' tests, which are frankly highly dependent on your application. I write a lot of 'glue' stuff in my current job where I'm making a couple systems work together or otherwise interact in a safe manner, and so there's a lot of behavior we don't really care about that you would care a lot more about if you were writing a popular library, for example. None of this means testing is bad, by the way. I love testing, testing is great, and I still think a general guidance of 'get your code coverage up into the 90% range' is probably the sanest starting point, but I think anyone that tries you give you any sort of absolute dogma around it is probably wrong for most developers.
|
|
#
¿
May 26, 2023 18:18
|
|
|
Wibla posted:So you're getting your actual work done, in addition to being a visible, helpful person in the office? No wonder you got promoted twice. Yeah, I think there's a middle ground between 'boot licking corporate wageslave who thinks there is any reward for hard work other than more work' and 'nihilist rear end in a top hat disliked by all their coworkers' and I think in tech there's far too many people clustered on either side of that spectrum. Humans are social creatures; every job has stuff that sucks, but you should probably try and do a good job, and not murder yourself doing it, and try and find some sort of common ground with your coworkers to at least be polite with them. When I was younger I had a few rear end in a top hat coworkers I mostly just tried to ignore, but as I've gotten older I've found I can mostly find something to commiserate with; and I also learned to stop working myself to death to try and make the soulless corporate machine happy. Work is a cake eating contest and the only reward is more cake, but if you don't take at least some level of professional pride in your work, that's gotta be incredibly soul draining. ninja edit: Oh yeah also optics matter, but they can matter in a way that doesn't require you to flat out lie to people too. When I worked in an ops center, we had a lot of downtime because our role didn't really allow us to code stuff, and we were reactive, and I always told my guys the same thing: 'I don't give a gently caress what you do in your downtime as long as the tickets get closed and everything gets done, but if management walks in shut your goddamn 3DS for a while'. My boss knew my team would dick around when stuff was quiet, but there's a difference between knowing it happens and having it pushed as your memory of the situation, especially once leadership far enough away to not understand start showing up. Falcon2001 fucked around with this message at 04:06 on May 29, 2023 |
|
#
¿
May 29, 2023 04:04
|
|
|
raminasi posted:I think the oath to enlightenment goes “hard work is rewarded” -> “hard work combined with shrewd marketing is rewarded” -> “wait the hard work part doesn’t matter” and it’s easy to replace the third step with “nothing matters.” I don't fully disagree with you here, but here's a rant anyway, because this topic irritates me and every single job I've had has one rear end in a top hat who tries to treat it like some sort of cynical exercise in profit extraction to the detriment of all the other employees. I think that the third part is where you find corporate ladder climbing assholes. Sure, if your only goal is to get promoted as quickly as possible, then you can cynically look at it and go 'oh appearances are all that matter, so I can just do fuckall as long as I get my marketing down' and sure, it might work in the right environment, but you're going to make a lot of enemies on your way to the top. Which is kind of what I was getting at with my original point; everyone is at work to get paid, but I think if your literal only goal is to make as much money as possible, you're probably a sociopath, and frankly I kind of blame the internet for fostering this as a thing to aspire to, because it's basically the workplace analogy to pick up artist influencers. Sure, that poo poo might work, but uh, do you really want to live like that? The alternative to 'hyper-competitive corporate ladder climbing' isn't wageslave bootlicker; the alternative is a whole spectrum of stuff where you can enjoy your job. You should enjoy your job, to one degree or another. That's not to say that you should mindlessly enjoy it and suck down corporate propaganda until you're numb to the pain, and there's plenty of things you shouldn't accept, but there's a whole goddamn middle ground there. Especially when we're talking about software dev, a job that almost completely avoids a lot of the stuff like physical damage that are endemic to other jobs, there's nothing at all wrong with showing up to work, putting in a reasonably modicum of effort, having a friendly relationship with your peers that isn't really true friendship but is a form of camaraderie, and then going home and enjoying your life. Sure, modern capitalism is certainly trying to ruin that, but I think the better answer to that is to stick to your guns, set boundaries with your workplace as best as possible, and to not work lovely jobs if you can at all afford to do so. Obviously, some folks are in personal situations where they're literally stuck (small towns, etc) but I've worked some lovely jobs before and I've always been able to at least be friendly with people and try and find some upside there.
|
|
#
¿
Jun 5, 2023 02:29
|
|
|
I wish someone could explain to me what the benefit of scrum is supposed to be (over a simple Kanban priority system), as I've never worked in an environment where we weren't randomized enough the idea of 'commit to what you're doing for the next two weeks' is just ridiculous. Maybe it's just a different team setup thing? On my current team, oncall eats up a good chunk of that time, so half the time we look and go 'well I've got uh...twenty four engineering hours in the next two weeks to work on this project so I guess I'll...just keep working on the same thing I did last time.' Part of that is that our current projects are hard to decompose down into something that can be delivered in less than two weeks anyway, which I guess just indicates longer sprints would be useful? Like we need some PM rigor, but I'm worried it's going to come from extra scrum overhead and I'm going to try and push for 'Kanban but we actually try and keep the tickets updated with relevant details'. Like I can point to a bunch of things to increase our 'getting poo poo done' level, but none of it tracks back to 'fixed periods of sprint planning' compared to just 'here's the stuff I'm working on right now, you can tell because it's assigned to me and In Progress on the board' Kanban feels like a really good level of 'you can see your backlog, you can see status of things, you can see what's been completed' compared to zero organization.
|
|
#
¿
Jun 7, 2023 03:29
|
|
|
prom candy posted:As far as I can tell it's all about planning and projections on the business side. Managers need to tell their managers what's going to be done in 3 months so that those managers can tell their managers. But like...can't you do that without the sprint system? I dunno, maybe I'm just not fully on board with what constitutes scrum or agile or whatever, but: Breaking work into tasks makes sense Developing requirements for those tasks makes sense (something my current team doesn't do and boy do we waste time because of it) Estimating how long something will take (to some reasonable degree) makes some level of sense, although it's certainly not easy. Sprints = ??? Like, why not just have a weekly update on 'here's what got done, here's what'll be done next' - groom your backlog, tally up the time estimates, add 50%, delivery date? That doesn't even necessarily need to be a meeting as long as your tasks get moved along the kanban as they progress.
|
|
#
¿
Jun 7, 2023 07:32
|
|
|
prom candy posted:So the tiny startup (<10 employees) I've been running tech for got acquired by another small company (<150 employees) and I'm having some trouble adjusting. The new company has a real meetings-first culture that I'm finding unproductive. One of the things that's coming up that I feel I might be able to have some influence on is that I'm being asked to give talks or demos about parts of our tech stack. I did one already and I don't feel like it was very good or useful, mainly because I just don't think a live Zoom presentation is a very effective way to convey information. This is all personal experience stuff, I haven't read any books/etc on the topic, but: The biggest problem with making videos or stuff outside of a meeting is that (in my experience) nobody ever does pre-reads or other meeting prep stuff, especially if the company is big on meetings. Why? Because they're either busy or in another meeting/etc. Your thought process makes sense, but I would expect that if you tell everyone 'watch this 30 minute video then show up to the meeting for Q+A' you're going to have a lot of folks showing up with zero context. Videos aren't a bad thing as long as the expectation is that people will watch them when they need to know info about it. The biggest problem with videos is that you can't update parts of it easily as your documentation changes, so they become a sort of static point in time summarization of whatever topic you're talking about. Honestly, as much as I get you're not interested in doing so, this company might just really appreciate this style of communication, and it's not as though 'single person presents concept and then has Q+A' is inherently ineffective, we've been doing stuff like that since the greeks and probably beyond. I would focus more on trying to figure out what makes a presentation effective or not and less on 'how can I change this new company's culture'. You also could record the zoom meeting and then distribute it afterward, so you still get the video record. However, if you DO want to effect the culture, there are a lot of books/etc about this, so you might be able to find some sources you can use to try and influence change, but just know that it's not going to be particularly easy. My current big tech company (or at least my organization) has a few policies around this that I think are pretty smart (and might reveal where I work, but I still think these are good ideas): - No pre-reads. If you have to review a document/etc, everyone takes the first X minutes of the meeting to read it quietly, then you go through Q+A. (I previously worked at another big tech company and I can confidently say in 11 years I never saw anyone do a pre-read unless their rear end was on the line, like showing up to a meeting with their VP/etc or having to discuss the slides) - Meetings should contain as few people as possible; if you want to know about something, you can show up or request a meeting, but there's no inherent idea that everyone needs to know everything. (This is definitely a struggle with tiny companies getting bigger, which might be appropriate to your acquiring company. When you're 10 people, everyone CAN know everything, but once you start growing, companies get 'taller' org structure wise, while trying to retain the idea of 'of course the VP knows about your tech stack!', which is frankly ridiculous.) - We still have symposium / big presentation style meetings, but they're specifically separated from 'deciding/discussing things' meetings. If you show up to one of those, the idea is not to improve the product being described, it's for you to learn about it and ask some questions.
|
|
#
¿
Jun 18, 2023 20:12
|
|
|
prom candy posted:So then I guess ideally for me I'd produce the video or post or whatever and then that would be the end of it. If someone had questions they could ask me or if enough people had questions I could set up an optional meeting where only people who read/saw the thing and cared enough could come talk about it. The last thing I want to do is present to people who are only attending because it's on their calendar. FWIW: I don't think that raising a concern about this is totally crazy or anything. "Hey it sure seems like these meetings aren't that useful or that they're just looking to fill time, can you let me know where these came from?" can help you figure out why they're being run, and from there you can at least take a shot at fixing it. Like if the reason it's run is because the CEO personally thinks this is important, you just give up because that poo poo ain't changing without a riot. But it might be some random PM or manager and you might be able to let them know 'hey I work here and don't think this is very useful'. Landing that message successfully is an entire field of study so y'know, good luck, but it's not impossible. The big point is don't try and change it because of this specific problem you're having, change it because it's fundamentally not useful to you. This thing can be an example, but don't get hung up on it.
|
|
#
¿
Jun 18, 2023 22:04
|
|
|
Also way better to be asked to sometimes give a talk than eighteen stakeholder meetings with suits that don't understand what you're doing so just remember things could always be worse.
|
|
#
¿
Jun 19, 2023 02:57
|
|
|
prom candy posted:Across any two week period I have 13 recurring meetings which probably doesn't seem like a lot to some of you but before we got acquired I had 0 so it's a pretty significant change for me. Hopefully next job will be a boostrapped company with <10 employees again because I've found that's the environment I really like to work in. Yeah I definitely would raise this to your management and be like 'hey I'm wasting 13 hours here that isn't useful to me and it's not just boring but also affecting my ability to complete my work'. I have like...three a week or so outside of standups.
|
|
#
¿
Jun 19, 2023 19:45
|
|
|
Rocko Bonaparte posted:I work at a megacorp. At it's nadir when my site had the lowest organizational health scores of all sites in the world, I didn't have 13 recurring meetings over two weeks. Yep; this is useful for some things that don't need to be done regularly, but for a lot of things it just slows it down a ton.
|
|
#
¿
Jun 19, 2023 23:45
|
|
|
Best way to get a raise in a year is probably to job hop to a higher paid position. Is the pay untenable or do you just want more?
|
|
#
¿
Jun 28, 2023 07:53
|
|
|
SurgicalOntologist posted:Anyone have any good resources on how to think about the decision of rewriting a legacy code base? I have an engineer moving to a new codebase and reacting with "this is all poo poo, let's start over". Of course he's right, it is poo poo, but so will be whatever he replaces it with I'm sure. I've read some articles or heard discussions on podcasts or YT or whatever about this, but can't find them now. E.g. about taking into account the contexts of how the codebase originally evolved, especially if the original authors are no longer around, realizing that a rewrite will also face challenges, perhaps even the same ones, and also under time constraints so probably will also take less-than-optimal long-term design choices. I also remember seeing a study that an unfamiliar code base will always be rated as having a ton more technical debt than a familiar one even if they are similar quality (as difficult as that is to quantify). https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/1718501188 This book is basically a very detailed discussion of that specific topic; I can't recommend it enough for what you're asking. It specifically does a good job of talking about the risks people underestimate with greenfield solutions.
|
|
#
¿
Jun 29, 2023 02:56
|
|
|
epswing posted:I just rewrote a little internal command line tool into a proper/native windows desktop app, took about 4 hrs over 2 days, it was fun. I do a lot of sysops style coding in my team, and the thing that absolutely sucks the life out of me more than anything else is loving permissions. At my BigTech company, questions like 'how do we determine what framework a given service is using' turns into a nightmarish list of Microservices, all of which have their own dumb permissions model, onboarding systems, clients, and use cases/etc. My favorite part is that by and large, we separate permissions into Are You A Human or Filthy Robot Scum. For humans, this isn't SO bad; there's a whole system where human-driven interactive stuff can easily inherit the user's permissions that are generally easier to manage and tends to also grant access to the UX associated with a given API; so if you want to call the Service Configuration API, as long as you have perms to the Service Configuration Site, you're all good in the hood. Obviously you can still get into 'whoops need perms' but it tends to work out pretty fast. But sometimes that's not the case, and for poo poo that ABSOLUTELY should be. For example, we have an old rear end alarming platform that's used EVERYWHERE, and for some godforsaken reason it does not support the Human Auth model and only uses service auth models...and service auth models are (for probably good reasons) a loving pain in the rear end nightmare space. So if a human wants to do things like 'crawl through our alarms and see what's up' you need to basically use the service-auth model on your personal VM and then call using that. I also love onboarding when it's like 'what is the expected TPS' and I'm like 'I dunno man I'm gonna run this like a couple dozen loving times so maybe 150 TOTAL REQUESTS EVER YOU FUCKS BECAUSE YOU loving UX IS A NIGHTMARE I CAN'T TIE INTO AT ALL" Anyway all of that sucks and I hate it. We should go back to usernames and passwords for everything and passwords must always be Password1.
|
|
#
¿
Jun 30, 2023 01:54
|
|
|
Yeah I've only ever operated with a trunk-based model; the other ones seem totally byzantine to me. I suspect there's some software where it makes sense, but boy it seems like a nightmare. Like we just finished up a big milestone and so there was a flurry of merges there at the end, and sure, for that specific case it was frustrating to deal with merge conflicts, but at least you're generally only dealing with your conflicts, and it doesn't seem like gitflow would have solved that at all; someone would still have had to do all the merging.
|
|
#
¿
Jul 9, 2023 20:02
|
|
|
ThePopeOfFun posted:No pull requests rules. The Senior with Opinions About Whitespace cannot waste his time on approvals. I can imagine a terrible scenario where my coworkers deployed poo poo code and hated speaking to each other. Trunk based would not work there. As a work life, heavy scrutiny and pulls requests are nice if you're anxious, new or want a chill job doing what you are told. On the other hand, trunk based forced my still very green self to think through problems, test, and ask for help if I needed it before deploying. I personally enjoy a faster pace. I found sitting on my hands between approvals and having to bug whoever was on approval duty grating. Ye gods I cannot imagine how awful going without PRs would be. For starters, you should be using a linter of some kind as part of your workflow to avoid any sort of arguments about formatting bullshit - you can argue about the linter config as a separate topic, but once it's in there you just run it and what it approves makes it in. Once you get past that you cut away the vast majority of totally useless feedback. That being said, waiting on PRs does suck, but a lot of that should probably come down to 'prioritize reviews'. Bongo Bill posted:All code should be reviewed by someone other than the person who typed it before it makes it back to the trunk, but that is fully doable even in the most extreme "commit directly to the trunk" workflow. This. If I write code other people can't understand at all, that's probably a problem, since otherwise I'm going to gently caress up their day when they have to fix it later, and lord knows I don't want to be singularly responsible for bugfixes. Edit: Actually, wait, maybe I haven't done trunk based dev, typically I work on a task on my own for a couple days or whatever, handling it locally, and then merge directly to mainline. https://trunkbaseddevelopment.com/ seems to indicate that everyone commit at least once every 24 hours to mainline, which seems...bizarre, compared to just committing something as a solid coherent piece of code. We don't do feature branches or anything though, it just tends to be like 'one task = one bit of shared code', and we all merge straight to mainline after a PR. Falcon2001 fucked around with this message at 22:55 on Jul 9, 2023 |
|
#
¿
Jul 9, 2023 22:45
|
|
|
Carbon dioxide posted:Like, following that practice, if I'm refactoring existing code, and at the end of day I did about half of the work, which now causes the code to no longer compile because some of the function calls don't match the function signatures anymore, am I supposed to make a PR with both the original code, and an incompletely refactored copy of the code that is commented out so that the compiler doesn't complain? And where the reviewer can't make sense of my design because it's not complete yet? Yeah this is confusing to me; A lot of times my code just straight up doesn't work when I stop for a given day, or would break some poo poo other than specific code flows.
|
|
#
¿
Jul 10, 2023 07:15
|
|
|
Jabor posted:The pull requests should be complete units of work by a single developer, not half-finished garbage. You just don't send a pull request if you haven't finished that unit of work, instead you'll finish it up and send the PR tomorrow. Sometimes you'll send multiple PRs, if you finished multiple units of work on that day. Possibly it's that I've been working on stuff lately where it's like 'add X brand new thing, that has 5 subthings', and I guess I could just commit code that doesn't do anything yet, but it was taking us around 4-5 days to finish one of these. I guess it would push you to make changes that are very untouchable at first (a Class that never gets called but is built), but that feels like it would in turn make your tests harder to write for certain scenarios. Like for example, my latest thing I worked on was a click CLI program so you'd use the click CLI test runner, which in turn means you'd have to have at least a basic working class tied into the main CLI loop. I guess the answer to that is just 'well don't run that', and don't auto-promote every build to release? This would turn every fairly straightforward task into like eight more and I don't really see that being beneficial ( And I don't really mind having tasks to track meaningful work either, I use tickets as my main documentation on what I'm doing). I guess if my team all did this I'd probably just shrug and go along with it, but still, feels weird.
|
|
#
¿
Jul 10, 2023 07:53
|
|
|
12 rats tied together posted:oop isn't inheritance though. you were always supposed to be not using inheritance simply as a way to share similar looking code. it's been like 2 decades since that was widely decried as a horrible idea. Yeah, I think there's good reason as much as people are getting popular decrying OOP, not a lot is being written in modern functional languages. Inheritance is a footgun, and there's plenty of bad patterns in OOP, but the idea of 'Thing has Attributes and can do things' really makes a lot of sense. It's one of the things I like about Python: if I want to write some totally atomic functions that take in a small number of arguments and spits out stateless results? Hell yeah brother, that's great, here's a module to put them in. No weird class wrappers needed, just throw 'em in a file. If I need to hold data in a structured way, I've got dataclasses, nice and simple; and if I want to put some stuff together for reuse by a bunch of functions? Well good news, that's easy to do too.
|
|
#
¿
Jul 11, 2023 04:53
|
|
|
A recent series of meetings has me wondering if my current team is even a sane place to stay in the near future, and now I realize I don't have a lot of idea what other options I can look into. I'm currently a python dev (I've done some C# but not professionally) and I've been recently promoted at a FAANG and I'm one of the stronger devs on my team. My background is in incident management work, which has a lot of useful overlap with any sort of production service supporting team in terms of 'how do you get poo poo done in enterprise'. I haven't got any frontend experience unfortunately, but I've done a lot of infrastructure management work in one way or another (both programmatic and just general sysadmin stuff historically). What sort of job titles should I be looking for? I haven't actually had to job hunt as a dev yet, managed to get my current and previous gigs through industry contacts (and obviously I'll start talking to them again too). SRE seems promising as a general sort of 'must write code but understand uptime' sort of deal, but I'm trying to avoid getting back into massive oncall again after a decade of waking up at 3am.
|
|
#
¿
Jul 13, 2023 05:44
|
|
|
I've spent a ton of time trying to think about testing stuff, but I don't have a ton of experience and I haven't worked on products with a robust existing test suite. But here's my approach (in Python, fwiw) - I don't mock any part of our codebase unless it's extensively tested elsewhere and has a very narrow interface (one example is a ThingValidator that takes in a series of arguments and returns a simple True/False based on whether all those validations pass; we have unique tests for it. - We work with a bunch of clients for various services, and that's the only main thing I patch and mock: the client itself and the responses, which I'll use the actual response class as much as possible if it's not a super complex object (which unfortunately some of ours are, I'm trying to think of a way to build some of these for reuse and still keep them easy to modify.) Building full fakes for them would be a huge amount of effort and we don't have the time, so this will have to do.
|
|
#
¿
Jul 18, 2023 19:15
|
|
|
Blinkz0rz posted:I’m worried that it might need to be said: don’t loving “well actually” your colleagues. You can pry my pedantry from my cold dead hands. Why else would I show up to work but to endlessly irritate my colleagues?
|
|
#
¿
Jul 19, 2023 19:11
|
|
|
Sounds like these unit tests need some sort of automated way to make sure they're testing the right things.
|
|
#
¿
Jul 20, 2023 07:08
|
|
|
How many of y'all in big tech are stuck in 'Agile' workspaces without assigned desks/etc? We just got moved there on my team and I think it's honestly going to be a dealbreaker for me, but not sure how common this is in the industry.
|
|
#
¿
Jul 28, 2023 19:41
|
|
|
prom candy posted:lmao that they're like "hmm we need to rebrand making people come into the office but even shittier, what if we called it 'Agile'" Yeah like...I'm pretty fuckin' mad about this. I know slippery slope is a fallacy, but this feels like just another step in the continuous squeezing of talent. What's next? "Welcome to your team conference room! Please have a seat at any of these big tables and plug your laptop in, code monkey!" Like I'm old enough to remember a time when a private office wasn't considered strange, and juniors just had to deal with sharing with another person. The fact that Office Space is starting to look like a dream scenario for workspace setup is just loving bizarre to me.
|
|
#
¿
Jul 28, 2023 20:22
|
|
|
I like having coworkers I see in person, TBH; so I actually don't really like full WFH. I end up getting kind of goblin-ey if I spend too much time just in one place cranking out work. I don't need my coworkers to be like CLOSE PERSONAL FRIENDS, but I legitimately enjoy talking to people in the office and having in person meetings and discussions. Hybrid is totally fine by me and is kind of my preferred setup basically.
|
|
#
¿
Jul 28, 2023 20:44
|
|
|
Volguus posted:Jesus you people, you're actively looking for human interaction? WFHs best perks were that human interaction was no longer mandated. If I could get food and internet on the top of the mountain in a cave ... that's where I'd be. Gonna get real here for a second, because this is a meme in this community and I think it's super unhealthy and we should talk about it, because depression is a massive problem in society right now and this absolutely contributes to it. Like yeah, we've all seen Office Space, we've all seen dozens of movies and tv shows about how terrible humans are and how devs want to just hide in our coding caverns. That's not really how humans are meant to work, and for the majority of folks that's going to lead to pretty severe mental health problems. Humans are inherently social animals, and even introverts or aneurotypical folks still have socialization needs. prom candy posted:I think if you work remote it's even more important to have an active social calendar. I'm out of the house 2-3x/week playing sports, I live really close to my parents and sister, I jam with a band once a week, and I try to book lunches and stuff with friends fairly often. This is a good example of what healthy WFH stuff looks like. Note all the other human interaction that prom candy is referencing here. Am I saying that you should kiss your boss's rear end and be one of those hoorah work is family types? gently caress no, that's insane. But I've worked a lot of jobs, at lovely places, and I've always been able to find at least some level of camaraderie with my fellow workers to build human connections, and Covid absolutely wrecked a lot of people's habits in this space. Obvious caveat: Yeah, there are hermits, and other folks that literally would be satisfied sitting in a box and receiving instructions and food under the door; if that's literally you then congratulations: you're absolutely not neurotypical and that behavior might still not be really healthy for you either. lifg posted:One director explained the upper management’s reasoning as, “the eventual goal is to have more people than desks, so you’re forced to sometimes sit at shared tables.” How utterly loving lovely. At least they were honest.
|
|
#
¿
Jul 28, 2023 23:10
|
|
|
Other, way less nice possibility: If someone has never worked a job where they got along with your coworkers, maybe they're the rear end in a top hat.
|
|
#
¿
Jul 28, 2023 23:21
|
|
|
mark immune posted:This guy 100% owns an empty office building 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.
|
|
#
¿
Jul 29, 2023 03:48
|
|
|
In an attempt to steer the conversation away from the derail I created, where are folks using for job hunting these days? I haven't actually had to use a job board in like, twelve years so I'm not sure what's good anymore. I'm also reaching out to my contacts and the normal stuff, but figured I'd see what good looks like for tech jobs these days.
|
|
#
¿
Jul 30, 2023 20:44
|
|
|
prom candy posted:Since we're talking books, anyone have any suggestions for software related books that work well as audio books? I have a bunch of Libro credits I need to use. Doesn't necessarily need to be code books but just any good semi-related non-fiction Kill It With Fire by Marianne Belotti was a great audiobook and I enjoyed it quite a bit.
|
|
#
¿
Aug 18, 2023 21:54
|
|
|
|
| # ¿ May 10, 2024 19:29 |
|
|
Re: Interview questions, I've been shadowing phone screens and am curious about something. Our phone screens are 50% resume poking and 50% coding, and I've been in two where the candidate just utterly failed to satisfy the requirements for the coding section. Both questions were very straightforward algorithm questions that were reasonably straightforward and weren't any sort of insane 'invert a binary tree in o(n) time' bullshit. Simple stuff like 'Given an array, dedupe stuff and identify gaps in a pattern'. I get the problem with the super deep dive algo stuff that you don't use on a day to day basis, but something like this seems pretty straight forward. Candidates are told to pick their language of choice and both issues could be solved (in Python) in 8 lines of fairly verbose code, or probably 3-4 if you got deep. In both cases, we tried to follow a pattern of 'write your code, now answer some questions about it', for example for one of them I asked them 'It looks like you used a heap data structure here; what alternatives would you choose for this if heap wasn't available in your stdlib or codebase?' Both candidates should have been able to knock this out of the park and totally just broke down, even when given some gentle questioning to put them back on the path. This doesn't seem like an unreasonable step into the higher difficulty leetcode bs questions, and doesn't even involve stuff that isn't common, like 2d map traversal or pathfinding algorithms. These interviews were for devops positions and were targeted for mid-career levels, so above junior but below snenior. Does this seem like just 'yeah these folks didn't know as much as they said' or is this a breakdown in the format?
|
|
#
¿
Aug 22, 2023 00:58
|
|