|
Mniot posted:"Commit code on your first day" is not a goal for new developers; it's for the existing ones. If a new person can make a non-breaking change to the code on the first day, then it implies that you're keeping things pretty clean. You can use "how long does it take a developer to get productive on your code-base?" as an interview question to try to avoid companies with lovely code, but I think there are code-bases that I'd enjoy working on that are just more difficult to comprehend than a half-day of skimming well-written code can get you. That makes more sense. Though, given that as soon as I become a new developer, I also become an existing developer, I feel like I should give some feedback on that... quote:No, you will not get used to it. It's difficult and massively important. You should consider a kitchen timer or something to enforce not spinning your wheels on a problem: after 10 minutes of trying to solve it solo, go looking for help. With remote work, you need to figure out how to ask for help. I do like this That’s my exact process when running into a blocker while working remotely - minus the “move onto something else” part. I find it hard to switch contact like that, especially when the answer I’ve been trying to get comes in after an hour or two of working on the new problem. Timeboxing myself sounds like the best skill to work on right now, thanks!
|
#
?
Nov 27, 2017 19:00
|
|
|
|
| # ? May 9, 2024 21:54 |
|
|
Pollyanna posted:That’s my exact process when running into a blocker while working remotely - minus the “move onto something else” part. I find it hard to switch contact like that, especially when the answer I’ve been trying to get comes in after an hour or two of working on the new problem. Timeboxing myself sounds like the best skill to work on right now, thanks!
|
|
#
?
Nov 27, 2017 22:15
|
|
|
(in one email thread) Coworker: QA has a newer build than Production. Do we want to deploy the new build to Production? (in another thread, minutes later) Coworker: Something looks funny on QA. I want to get a fresh copy of the database from Production and put it on QA. Me: Sounds good. (in first thread) Me: We shouldn't push the new build until we're sure QA is okay. Coworker: Shouldn't we have the same version on all environments? I have a feeling somebody is working through way too many emails on his first day back from vacation!
|
|
#
?
Nov 29, 2017 17:54
|
|
|
CPColin posted:(in one email thread) Coworker: QA has a newer build than Production. Do we want to deploy the new build to Production? What are you talking about, running around in circles is a time honored tradition of software development. 
|
|
#
?
Nov 29, 2017 17:58
|
|
|
Disclosure: I'm the one in SRE (yay bullshit padding title) and I was originally a technical lead/senior developer, previously part of the teams that are now causing the poo poo. On QA: I just had my meeting about load testing hijacked by a manager who wanted to treat any problem in our staging environment the same as a production issue. Essentially pinning these issues on Ops/SRE because his teams have been whining that the environment has been unstable. poo poo developers did to cause problems - Taking too many instances out of the load balancer; causing everything to fail health checks. This then prevents deployments from bringing instances back as there's no healthy state to recover to. - Not transforming their configuration for the new QA environment, everything was in dev mode and pointing to to the wrong SQL instances and RabbitMQ virtual hosts. - Not handling enough error states when saving customer data, meaning we had half saved JSON which needed manual intervention to recover. TWICE. Usually triggered by untested deploys. poo poo Ops/SRE have done to cause problems  I dunno, built the drat environment and only activated it when everything worked end to end.But now SRE have been given the task of "self healing data" to paste over developer mistakes "Because its about reliability is it not?" Cancelbot fucked around with this message at 21:32 on Nov 29, 2017 |
|
#
?
Nov 29, 2017 21:26
|
|
|
Sounds like they want an additional UAT environment then, production reliability but non-production.
|
|
#
?
Nov 29, 2017 21:39
|
|
|
This is the pre-live environment (staging), but we're just being blamed for developer cock ups because its new and SRE built it... not that they've been careless and ignored what we told them to do. I hate the "last person who touches it" game.
|
|
#
?
Nov 29, 2017 21:49
|
|
|
Then there’s what we’re doing, which is testing in-development code on live prod data, and encouraged to do so.
|
|
#
?
Nov 30, 2017 00:58
|
|
|
Pollyanna posted:Then there’s what we’re doing, which is testing in-development code on live prod data, and encouraged to do so. Aside from the data which we replicate and anonymise; I have no problems with that. I'm still a developer and all the crap comes out in staging as that's where your interaction points become more real. We can take real payments in staging and ship orders so it's ideal for checking for gently caress-ups without impacting customers. But what this manager wants is for something going wrong in a QA environment to be treated like the production environment, and I'm not doing a "P1 root cause analysis" for "poo poo worked in our mainline environment but promoting it broke". That's just the cycle of development which is always going to be faster than ops can keep up. That is until the teams "embrace autonomy and the devops mentality", yeah, right after they learn how IIS bindings work 
|
|
#
?
Nov 30, 2017 08:57
|
|
|
I don't think he meant "we copy our prod data to Dev", I think he meant "There is only one data store, and it is prod."
|
|
#
?
Nov 30, 2017 14:54
|
|
|
Cancelbot posted:Aside from the data which we replicate and anonymise; I have no problems with that. I'm still a developer and all the crap comes out in staging as that's where your interaction points become more real. We can take real payments in staging and ship orders so it's ideal for checking for gently caress-ups without impacting customers. But what this manager wants is for something going wrong in a QA environment to be treated like the production environment, and I'm not doing a "P1 root cause analysis" for "poo poo worked in our mainline environment but promoting it broke". That's just the cycle of development which is always going to be faster than ops can keep up. Yep. We've developed a lot of tools around taking data from prod to test/dev environments cleanly due to the scale of users. 1 in a million things can happen 10 times a day at 350M MAU. Just getting the forensics to get the data into a debuggable state and replaying what the user did has fixed so many odd edge bugs that it's paid for itself over and over again.
|
|
#
?
Nov 30, 2017 17:28
|
|
|
Pollyanna posted:Then there’s what we’re doing, which is testing in-development code on live prod data, and encouraged to do so. If it's read-only, why is that bad?
|
|
#
?
Nov 30, 2017 18:08
|
|
|
Nope, no dev dbs, test data, or prod dumps. Not any up to date or useful ones, at least. Point we pack to the prod API and we’re good to go! Admittedly it’s hard to outright drop a database from a front end, but when I expressed concern and declined responsibility for prod data loss, I was just told it wouldn’t happen  Given my luck, though...
|
|
#
?
Nov 30, 2017 18:08
|
|
|
Pollyanna posted:Nope, no dev dbs, test data, or prod dumps. Not any up to date or useful ones, at least. Point we pack to the prod API and we’re good to go! Admittedly it’s hard to outright drop a database from a front end, but when I expressed concern and declined responsibility for prod data loss, I was just told it wouldn’t happen The number of people that say "it wouldn't happen" when they mean "it hasn't happened yet" just totally blows my mind.
|
|
#
?
Nov 30, 2017 18:18
|
|
|
If the IT threads taught me anything is that you should try to get that in writing and file that away under a CYA folder.
|
|
#
?
Nov 30, 2017 18:45
|
|
|
So asinine. I'd be so petrified of doing something bad to prod that I would get like half the work done I otherwise could.
|
|
#
?
Nov 30, 2017 19:16
|
|
|
Lumpy posted:If it's read-only, why is that bad? It’s as read-only as our prod code is 
|
|
#
?
Nov 30, 2017 19:22
|
|
|
Could you grab a recent backup of the prod DB and restore it somewhere else, and use that as a "it's less bad than the alternative" dev environment?
|
|
#
?
Nov 30, 2017 20:07
|
|
|
Pollyanna posted:Nope, no dev dbs, test data, or prod dumps. Not any up to date or useful ones, at least. Point we pack to the prod API and we’re good to go! Admittedly it’s hard to outright drop a database from a front end, but when I expressed concern and declined responsibility for prod data loss, I was just told it wouldn’t happen "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair." - Douglas Adams
|
|
#
?
Nov 30, 2017 22:09
|
|
|
Excuse me while my time machine catches up:Pollyanna posted:What’s a reasonable expectation for how long it takes to get used to a codebase? Although it’s nice to think of someone being able to submit a bugfix and PR on the day they start, that’s not always the case, and I personally still don’t feel like I have a good grasp on how the systems work with two days under my belt. Is this normal, or do I need to pick up the slack? I thought the notion of posting a review on day one is to put in a bullshit thing like a spelling fix. This makes sure you have all your permissions and has you reach out and touch the reviewers. From your side, it lets you start a clock to see how long it takes even the most trivial thing to get approved in the codebase. "Meaningful" changes is a whole other ballgame and is probably correlated to the average good developer's daily LOC count. If it is a small thing then you might actually nail something day one, but huge crap could be months.
|
|
#
?
Nov 30, 2017 22:42
|
|
|
Mine was a bugfix that’s already on prod, though a fairly involved one. I guess that’s not bad for 3~4 days in.
|
|
#
?
Nov 30, 2017 22:52
|
|
|
Cancelbot posted:On QA: I just had my meeting about load testing hijacked by a manager who wanted to treat any problem in our staging environment the same as a production issue. Essentially pinning these issues on Ops/SRE because his teams have been whining that the environment has been unstable. Getting rage-flashbacks from this one. We had the whole company on the qa/test/integration/whatever environment to dogfood and check things out before it went to paying customers. I kept the test environment above 97% uptime and never lost a significant amount of data (good test suite, smart and sane development team, decent alarms on all environments). Any time there was an outage, I'd email the company to say so and when I expected it to be fixed (on two occasions, the message was "things are broken right now and we're in the middle of working on something really important so do not expect a fix until noon tomorrow"). But everyone would come tromping over to tell me that it's broken. Why is it broken? Is it broken in production, too? What's wrong with the development team that they wrote a bug like this? Why can't I use the production system instead? Nobody seemed to understand the idea that this is how we make sure the paying customers don't see bugs. Actually, they probably understood that but wanted some magic way for it to never have any negative impact on their own lives.
|
|
#
?
Nov 30, 2017 23:17
|
|
|
HardDiskD posted:If the IT threads taught me anything is that you should try to get that in writing and file that away under a CYA folder. Someone please find that post about the guy who was hired as an intern, wiped their data on day 2, then said that the company wanted to sue him because he destroyed their company.
|
|
#
?
Dec 1, 2017 01:54
|
|
|
The biggest argument in favor of automating and abstracting common tasks away as much as possible is so you don’t have to deal with my dumb rear end using you as a guinea pig to get something working just to find a typo in the address bar.
|
|
#
?
Dec 1, 2017 01:58
|
|
|
Volmarias posted:Someone please find that post about the guy who was hired as an intern, wiped their data on day 2, then said that the company wanted to sue him because he destroyed their company. Authenticity of story not verified https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/?st=JAN7JJ22&sh=3cdfe61d
|
|
#
?
Dec 1, 2017 02:06
|
|
|
.
Pollyanna fucked around with this message at 16:51 on Dec 1, 2017 |
|
#
?
Dec 1, 2017 04:40
|
|
|
Mniot posted:Getting rage-flashbacks from this one. Precisely! They'd commit stupid poo poo and because somehow prod was still working (because we block broken releases) they'd blame the environment for being broken, except no. You're pointing to a SQL database that only exists in your dev VM dummies!
|
|
#
?
Dec 1, 2017 09:17
|
|
|
Pollyanna posted:In more positive news, at our welcoming dinner, we identified one of our front end engies’ 2D and 3D waifus. Shinji Ikari and Alizee. Uh? Cancelbot posted:Precisely! They'd commit stupid poo poo and because somehow prod was still working (because we block broken releases) they'd blame the environment for being broken, except no. You're pointing to a SQL database that only exists in your dev VM dummies! I mean, it shouldn't be too hard to automatically rewrite connection strings in config files as part of deployment to prevent that specific sort of thing, I would hope.
|
|
#
?
Dec 1, 2017 14:29
|
|
|
Pollyanna posted:In more positive news, at our welcoming dinner, we identified one of our front end engies’ 2D and 3D waifus. Shinji Ikari and Alizee. I'm noticing something about your new company, a kind of trend. The Fool posted:Authenticity of story not verified Oh yeah, that's the good stuff right there. I don't care if it's true or not, it just feels right.
|
|
#
?
Dec 1, 2017 14:41
|
|
|
What? It’s just a funny anecdote. This is the Working in Development thread, right?
|
|
#
?
Dec 1, 2017 15:35
|
|
|
Pollyanna posted:What? It’s just a
|
|
#
?
Dec 1, 2017 16:12
|
|
|
I don't even understand it, nor do I think I want to
|
|
#
?
Dec 1, 2017 16:16
|
|
|
...Yeah, it is actually pretty creepy, now that I think about it. I’ll redact that post.
|
|
#
?
Dec 1, 2017 16:51
|
|
|
Don't redact it, but do realize that the signs we're seeing so far don't point towards a well adjusted organization. So, post about your company, a lot, please.
|
|
#
?
Dec 1, 2017 16:57
|
|
|
Working in Development: You don't have to know about anime to work here, but it helps
|
|
#
?
Dec 1, 2017 16:58
|
|
|
One of our new hires told us that he is only interested in supernatural beings with a straight face.
|
|
#
?
Dec 1, 2017 17:13
|
|
|
It's OK to have in-jokes with your co-workers, but don't expect us to get them.
|
|
#
?
Dec 1, 2017 17:26
|
|
|
Munkeymon posted:I mean, it shouldn't be too hard to automatically rewrite connection strings in config files as part of deployment to prevent that specific sort of thing, I would hope. It isn't! web.environment.config is how it's done as we're a .NET shop. Our deployment pipeline will detect that and automatically apply an XML/JSON transform over them based on the deployment target, just their "staging" one was a cut & paste of the dev one with zero modifications. I'm pushing consul or at the very least environment variables as configuration so that I can remove that layer of silliness anyway.
|
|
#
?
Dec 1, 2017 17:28
|
|
|
Supernatural beings, waifus, whatever! Give us all the gossip
|
|
#
?
Dec 1, 2017 17:29
|
|
|
|
| # ? May 9, 2024 21:54 |
|
|
You named something after Shinji? Is it the most useless, error prone, crybaby software module in the building?
|
|
#
?
Dec 1, 2017 17:31
|
|