|
Munkeymon posted:Or just find the shortcut configuration that makes it work like Atom - editors are mostly fungible that way. Along this line, is there a way to get Visual Studio to use the same keyboard shortcuts as Visual Studio Code, outside of manually setting them up one by one? I use both a lot at work and it's getting frustrating having to juggle shortcuts between the two.
|
#
?
Nov 22, 2017 16:39
|
|
|
|
| # ? May 10, 2024 21:02 |
|
|
jetbrains good, do a jetbrains incredibly not hot take: writing wrapper classes is the worst and makes me want to die e: and that's with maximum use of autogenerated code
|
|
#
?
Nov 22, 2017 16:56
|
|
|
ChickenWing posted:jetbrains good, do a jetbrains the most correct of all opinions
|
|
#
?
Nov 23, 2017 00:16
|
|
|
ChickenWing posted:jetbrains good, do a jetbrains I just hope Jetbrains brings in live code sharing / programming. I won't switch to VS Code full time, but I will to program with my coworkers.
|
|
#
?
Nov 23, 2017 00:21
|
|
|
Good feels: getting maximum caffeine and some good music and crushing a bunch of backlog in an afternoon 
|
|
#
?
Nov 23, 2017 20:12
|
|
|
ChickenWing posted:Good feels: getting maximum caffeine and some good music and crushing a bunch of backlog in an afternoon You're working on Thanksgiving? 
|
|
#
?
Nov 23, 2017 21:30
|
|
|
Pollyanna posted:You're working on Thanksgiving? Proper Thanksgiving already happened 2 weeks ago. 
|
|
#
?
Nov 23, 2017 21:44
|
|
|
Skandranon posted:Proper Thanksgiving already happened
|
|
#
?
Nov 23, 2017 21:51
|
|
|
no wonder my kids didn't call...
|
|
#
?
Nov 23, 2017 21:52
|
|
|
Client is deploying our newest release today. At 7pm. This is a major release. It's also been buggy as hell. I'm on incident management this weekend. 
|
|
#
?
Nov 24, 2017 20:12
|
|
|
what's the ritual to ward against Sev 1s?
|
|
#
?
Nov 24, 2017 20:13
|
|
|
ChickenWing posted:what's the ritual to ward against Sev 1s? Light all the fingers on your Hand of Glory.
|
|
#
?
Nov 24, 2017 20:30
|
|
|
ChickenWing posted:what's the ritual to ward against Sev 1s? Appendicitis
|
|
#
?
Nov 25, 2017 00:25
|
|
|
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?
|
|
#
?
Nov 26, 2017 19:39
|
|
|
It depends on how complicated the system is and how complicated the change is. There's no good answer.
|
|
#
?
Nov 26, 2017 19:53
|
|
|
It definitely takes only one day. You're falling behind and people on the street who stare at you when you aren't looking can tell.
|
|
#
?
Nov 26, 2017 19:58
|
|
|
The codebase at my last job was extremely complex and my manager flat out told us (me and the other guy who started the same day) she expected us to be useless for 6 months.
|
|
#
?
Nov 26, 2017 20:10
|
|
|
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 don't usually expect new hires to be a net benefit for the first 6-12 months depending on how complicated our environment is. The first few days are usually spent on setting up your computer(s) and work area. I wouldn't worry about someone not getting anything done in the first two days. Don't slack off, but don't feel bad about taking a few days to get your feet under you. If you feel like you're stuck, definitely ask your coworkers for help, but as long as you're making progress I wouldn't worry about not having something ready to submit yet. Shoot, most of my office took the whole week off for Thanksgiving (USA). So if you got anything at all done last week you're ahead of curve.
|
|
#
?
Nov 26, 2017 20:23
|
|
|
Well, I’ve already got 5~6 bugs assigned to me and I’m not sure what their expected fixby date is, is why I ask. I’ll clear it up with the team. My experience is basically the same, a codebase takes on the order of months to truly understand, I’ve found. I hope that’s well understood by the entire industry...
|
|
#
?
Nov 26, 2017 20:31
|
|
|
Pollyanna posted:What’s a reasonable expectation for how long it takes to get used to a codebase? As long as it takes to re-write it.
|
|
#
?
Nov 26, 2017 20:32
|
|
|
Skandranon posted:As long as it takes to re-write it.  I’ve learned by now not to beat the “flatten and redo” drum as soon as I get hired. A re-write is not that trivial...though the insights that come from attempting one can be valuable.
|
|
#
?
Nov 26, 2017 20:34
|
|
|
Pollyanna posted:
You've learned the wrong lesson. You need to play a better tune, not put the drum down. https://medium.com/feature-creep/the-software-engineer-s-guide-to-asserting-office-dominance-ddea7b598df7
|
|
#
?
Nov 26, 2017 20:37
|
|
|
Pollyanna posted:What’s a reasonable expectation for how long it takes to get used to a codebase? I don't think it's time frame but more, "Hey Random Coworker, I have this bug, and getting used to the codebase and where everything is, can you point me in the right direction?" Then with a good IDE, you can go anywhere that file is affected. Maybe look at the jira history and see who was assigned to it before you and ask them? Once you find the files, the git annotate could help you more.
|
|
#
?
Nov 26, 2017 21:11
|
|
|
It shouldn't be necessary to understand the entire codebase in order to fix any single bug.
|
|
#
?
Nov 26, 2017 21:22
|
|
|
And if you were paired up with an experienced programmer from your new team, then you - as a pair - would be productive immediately. Just saying.
|
|
#
?
Nov 26, 2017 21:25
|
|
|
Doom Mathematic posted:It shouldn't be necessary to understand the entire codebase in order to fix any single bug. Code can turn into a ball of spaghetti reaaal easily... Doom Mathematic posted:And if you were paired up with an experienced programmer from your new team, then you - as a pair - would be productive immediately. Just saying. Ideally, yes, but this is a small company that has to move quickly, and they’re focusing on getting things out the door. Still gonna be taking people aside when they’re available, of course.
|
|
#
?
Nov 26, 2017 21:36
|
|
|
Pollyanna posted:Code can turn into a ball of spaghetti reaaal easily... There's a difference between a company moving quickly and moving incorrectly.
|
|
#
?
Nov 26, 2017 21:55
|
|
|
A good way for a company to move quickly is to spend time bringing their new developers up to speed, rather than leaving them spinning their wheels for six months plus.
|
|
#
?
Nov 26, 2017 22:08
|
|
|
Doom Mathematic posted:It shouldn't be necessary to understand the entire codebase in order to fix any single bug. Right, but sometimes bugs are indicative of a larger design problem. Like for instance, we had a class that would propagate the effects of an operation to other views on the same screen that contained similar data. A class "propagation handler" sprung up that was full of awful procedural code that would iterate through everything on the screen and try to find the entities that were similar. Offshore just kept hacking that class until it worked - however, the underlying cause of the problem was that the cardinality of the relationship between the data and the view was inappropriate, and that they were doing procedural-style copying the data to the view rather than having all the views point at the same underlying data, which is loving stupid. The point is that when doing maintenance work, you need to do a second-level "why" - too often you throw an inexperienced (or even an experienced) developer at a large project, and they just fix the bug. I made a mistake as a lead because I saw there were a bunch of bugs related to propagating operations, but I was busy and didn't own that area of the code, and now I have a loving mess on my hands. If you work with large codebase long enough, being able to detect issues like these and mentally fill in the relationships between the classes yourself (don't work off the diagrams, they're all bullshit) will greatly accelerate your ability to contribute. But don't just fix the bug, figure out the cause of the bug and the cause of the cause.
|
|
#
?
Nov 26, 2017 22:10
|
|
|
Bruegels Fuckbooks posted:Right, but sometimes bugs are indicative of a larger design problem. Like for instance, we had a class that would propagate the effects of an operation to other views on the same screen that contained similar data. A class "propagation handler" sprung up that was full of awful procedural code that would iterate through everything on the screen and try to find the entities that were similar. Offshore just kept hacking that class until it worked - however, the underlying cause of the problem was that the cardinality of the relationship between the data and the view was inappropriate, and that they were doing procedural-style copying the data to the view rather than having all the views point at the same underlying data, which is loving stupid. Yeah, this. Just fixing the bug isn’t enough, I need to also understand what’s going on behind the scenes and why so I can 1) not make a similar bug down the line and 2) advocate for improvements to the system. That takes a good bit of time and effort, though, hence the friction.
|
|
#
?
Nov 26, 2017 22:17
|
|
|
It primarily depends upon number of lines of code - number of tested lines of code with a multiplicative factor depending upon how well architected the codebase is (most places simply aren't architected even if you have 4+ people with architect titles around). It's easy to figure out how things are supposed to work if you have a bunch of tests explaining how things should work. In the absence of tests, you wind up doing a lot of reverse engineering. Even for a small company I have to emphasize that moving faster means working slower and more deliberately.
|
|
#
?
Nov 26, 2017 22:31
|
|
|
Pollyanna posted:Yeah, this. Just fixing the bug isn’t enough, I need to also understand what’s going on behind the scenes and why so I can 1) not make a similar bug down the line and 2) advocate for improvements to the system. That takes a good bit of time and effort, though, hence the friction. You've been at your new place for what, a week? No one's expecting you to take ownership of fixing deep architectural flaws or whatever. Calm down, take your time, learn by doing. You'll pick up the problems in the codebase organically - and don't assume that the other devs are unaware of the issues.
|
|
#
?
Nov 27, 2017 00:30
|
|
|
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? Just some meta feedback about some of your posts in here, but they frequently seem to ask questions that can't be objectively answered. You should talk to your team about those kind of things, instead of internet people. Your code base could be arbitrarily complicated or simple, we would have no idea.
|
|
#
?
Nov 27, 2017 00:34
|
|
|
Bruegels Fuckbooks posted:Right, but sometimes bugs are indicative of a larger design problem. Like for instance, we had a class that would propagate the effects of an operation to other views on the same screen that contained similar data. A class "propagation handler" sprung up that was full of awful procedural code that would iterate through everything on the screen and try to find the entities that were similar. Offshore just kept hacking that class until it worked - however, the underlying cause of the problem was that the cardinality of the relationship between the data and the view was inappropriate, and that they were doing procedural-style copying the data to the view rather than having all the views point at the same underlying data, which is loving stupid. Hopefully they aren't assigning those kinds of bugs to the new guy who's only been there two days. I mean sure, sometimes you find a bug that's down to a fundamental limitation of the design of the systems involved and one or more will have to be largely rewritten. On the other hand, sometimes you find a bug that's just a typo, or someone forgetting to account for a potential state, or something like that - and those kinds of bugs are great for learning how various parts of the codebase work. Nothing will teach you the codebase as fast as getting in there and actually working with it. If Pollyanna's team has any sense at all, they're assigning them minor bugs that aren't expected to have major implications, and I'd expect them to open to explaining bits if Pollyanna runs into something they suspect might have major effects. Only lovely idiots expect someone in their first week on the job to have a comprehensive understanding of the codebase already. Their job is to work around that, assigning small stuff that gets you poking around without requiring a pre-existing knowledge of how everything ties together. I mean, it's possible that the new co-workers are lovely idiots who honestly expect you to go mucking around in deep architectural issues on day 1, but that's not your fault. Either way, that's no excuse to sit around spinning your wheels - learn by doing and ask for help if you need it.
|
|
#
?
Nov 27, 2017 02:13
|
|
|
KoRMaK posted:Just some meta feedback about some of your posts in here, but they frequently seem to ask questions that can't be objectively answered. You should talk to your team about those kind of things, instead of internet people. Your code base could be arbitrarily complicated or simple, we would have no idea. 
|
|
#
?
Nov 27, 2017 11:18
|
|
|
This is why I say that a newcomer should be paired up with experienced existing team member. I don't think pair programming is a panacea or even generally a good way to code, but in this case it is 100% the way to go. Nobody benefits from a newcomer struggling along by themselves. It's a waste of everybody's time.
|
|
#
?
Nov 27, 2017 13:57
|
|
|
100% talk to people. Not only is this the best way to get the information you need, it's also the best way to get to know your coworkers
|
|
#
?
Nov 27, 2017 15:22
|
|
|
Talking to people is the exact reason I’m in Cali for the week. I getcha, though...I’ve actually found it a little harder to talk to other employees when remote, but maybe that’s just a matter of getting used to it. And yeah, it’s very subjective. I guess what I’m asking is more for what other people’s experiences have been.
|
|
#
?
Nov 27, 2017 15:46
|
|
|
Be careful saying "Cali" around Californians; some of them may get offended. (Like me! How dare you!)
|
|
#
?
Nov 27, 2017 16:20
|
|
|
|
| # ? May 10, 2024 21:02 |
|
|
"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. You should ask your boss, "when do you expect me to be able to fix mid-sized bugs without any help?" to get an idea of their expectations. And your boss should be telling you those expectations without being prompted. Pollyanna posted:I've actually found it a little harder to talk to other employees when remote, but maybe that's just a matter of getting used to it. 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 1. Direct-message to the person I think would know best, or skip this if I'm not sure 2. Message in group-chat 3. Direct-message to my boss, saying I'm stuck on this thing 4. Message in group-chat with some more things I've tried while waiting and an @here 5. Message in group-chat saying that I'm giving up and moving to something else for now If I get a hold of someone and it's not completely trivial, I usually switch to voice-chat. If I don't get a response from anyone I'd probably escalate through those steps in 20-60 minutes depending on how much progress I feel I can make banging my head. When I started and was totally unfamiliar with the code I'd give 15 minutes from first asking for help to giving up.
|
|
#
?
Nov 27, 2017 18:46
|
|