|
Carbon dioxide posted:I'm a notorious keyboard shortcut forgetter and some people who'd prefer to hang out in vim all day get quite frustrated by my workflow involving some clicking around. It's kinda funny when they try to be helpful and just don't seem able to realize that keyboard shortcuts fall right out of my head again after the conversation. It's fun being able to fly through an environment like a bird, but the fact is once you progress past junior level you're probably going to be spending the vast majority of your work time doing anything but writing code. If I run into someone who spends all day in VIM my first thought is, "is this one of those people who never documents or diagrams, and is going to hand off their lovely happy-path-only code to someone else because they can't be bothered?" Someone completely owning VIM is a sight to see though, I admit it.
|
#
?
Nov 3, 2020 08:56
|
|
|
|
| # ? May 11, 2024 08:21 |
|
|
I'm a backseat driver. Whenever pairing I always let the junior person drive and half the time I'm just telling them what files things are in and guiding them through making changes. It's the way I learned the codebase. It lets juniors get their hands on more complicated parts of the codebase and keeps everyone engaged. So I tell them all kinds of IDE junk just alongside doing that. Although I never phrase it as "You MUST use these shortcuts", I always try to present it as "fun fact! You can select multiple non-sequential lines with this One Weird Trick!" I knew a guy who refused to pair unless you downloaded and installed his own personal dotfiles of aliases and that guy suuuucked.
|
|
#
?
Nov 3, 2020 13:28
|
|
|
alright, I think i'll continue sharing it as "hey if you want to you can do <nifty little thing>." personally I think being good with my IDE helps me stay in flow state, but I also have huge issues with focus and if something minor like not being able to find a file can really throw me off track.
|
|
#
?
Nov 3, 2020 14:42
|
|
|
Ah the best is when you say "OK, let's open up the browser dev tools", and they just look slack jawed for a bit. And you remember how awesome it is to have to hand-hold a senior dev with basic debugging! But hey it's cool, I mean this is going to come up in the annual salary/compensation conversation.
|
|
#
?
Nov 3, 2020 16:00
|
|
|
One time, I was in an interview and needed to open the dev tools, but they'd handed me a MacBook ("Our whole department switched to Macs!") that didn't have an F12 key, so I had to ask what the shortcut was. They either didn't know or weren't allowed to give me ANY help, so I had to use the menu like a caveman.
|
|
#
?
Nov 3, 2020 16:06
|
|
|
downout posted:Ah the best is when you say "OK, let's open up the browser dev tools", and they just look slack jawed for a bit. And you remember how awesome it is to have to hand-hold a senior dev with basic debugging! Do you mean just F12? Because trying to debug with just dynamic page updates for debug prints sounds awful.
|
|
#
?
Nov 3, 2020 16:16
|
|
|
CPColin posted:One time, I was in an interview and needed to open the dev tools, but they'd handed me a MacBook ("Our whole department switched to Macs!") that didn't have an F12 key, so I had to ask what the shortcut was. They either didn't know or weren't allowed to give me ANY help, so I had to use the menu like a caveman. *hangs head shamelessly while frantically trying to find the file menu button*  I feel your pain, I never use mac stuff. Every time I'm trying to do something on someone else's mac I just flail around uselessly hitting hot keys for windows.
|
|
#
?
Nov 3, 2020 16:31
|
|
|
Carbon dioxide posted:I'm a notorious keyboard shortcut forgetter and some people who'd prefer to hang out in vim all day get quite frustrated by my workflow involving some clicking around. It's kinda funny when they try to be helpful and just don't seem able to realize that keyboard shortcuts fall right out of my head again after the conversation. It wouldn't matter if you knew all the key bindings. Who ever is watching you drive will be annoyed that you're using the wrong key board shortcuts, you don't have things configured how they would, dammit, it's faster if you just.... can I see your keyboard?
|
|
#
?
Nov 3, 2020 16:43
|
|
|
Paolomania posted:Time saved using keyboard shortcuts cuts off noise levels of your time spent as an engineer. It doesn't matter. Teaching someone how to stay focused on important features, not over-engineer, write maintainable and testable code and debug issues effectively will do them and your team orders of magnitude more good now and in the future than any silly IDE nits. Learning how to use your IDE is a big part of debugging issues effectively. I've seen people waste very large amounts of time debugging because they didn't know about a debugger feature which was directly relevant to what they were doing. Even trivial things like effectively navigating files can be a big deal; perhaps this is just an ADHD thing but I have absolutely spent a while looking for the definition of a function while trying to understand some code only to forget why I was looking for it when I do find it. Minimizing distractions from the thing I'm actually trying to do is very important for me to stay thinking about the important details.
|
|
#
?
Nov 3, 2020 16:58
|
|
|
Plorkyeran posted:Showing them how you prefer to do things when you're driving is generally going to be the easier way to pass along tips. I've had talks at places about this. Part of the problem is that generally outside of pair programming the construction phase is solitary. The debug is mostly solitary. Everyone of us could have these awesome productivity saving things that we know and do but we don't have a good way of sharing it. Many times when working with people even with the same toolset you can walk away learning something new and useful even in products you've used for years.
|
|
#
?
Nov 3, 2020 17:03
|
|
|
The time saved by keyboard shortcuts doesn't matter, but if there's a common function that you can habituate yourself to do without thinking about how to do it, that's one less thing to think about while you're trying to think about the actual work. Sometimes that matters. And knowing what your tools can do definitely affects your ability to come up with an effective strategy.
|
|
#
?
Nov 3, 2020 17:05
|
|
|
captkirk posted:The SRE book is good, there are some additional books (SRE Workbook, Pursuing SRE) which could also be helpful. There's also Implementing Service Level Objectives which I can't fully recommend yet as I haven't finished it but if you aren't satisfied with the treatment of SLI/SLO in the SRE book, it does have a more thorough treatment. Last year, I interviewed a guy for a position in my org who implemented SLOs throughout his whole division, and he was really proud of it. But when I asked him to point to a business decision that was made differently because those SLOs were in place, he couldn't name a single one. This is where overfocus on SLOs runs a high risk in organizations that aren't actually good at making decisions. The SLA is supposed to be a part of a workflow, a trigger for an if-then: if our availability is too bad and we're violating our SLA, we prioritize Thing A and we deprioritize Thing B until we're meeting our availability commitments again. A lot of orgs don't focus the right level of attention on the "then" part of the SLO if-then. Now the SLIs are just expensive vanity metrics. The most important thing an organization can do around availability is understand the actual impacts of downtime. Disrupted activity, missed work, frustrated users, churned users, lost/incomplete/corrupted data, brand damage, frustrated engineers, frustrated executives. It's people who rely on each other and rely on the systems those other people build. Sometimes, the impact is trivially mitigated. Sometimes it naturally works out close to zero. The guts of SRE is a couple levels detached from the SLO itself: work with the business, determine the real impact, and use your knowledge of numbers and your intuition of complex system behavior to advocate for people who aren't being heard.
|
|
#
?
Nov 3, 2020 17:31
|
|
|
Hughlander posted:I've had talks at places about this. Part of the problem is that generally outside of pair programming the construction phase is solitary. The debug is mostly solitary. Everyone of us could have these awesome productivity saving things that we know and do but we don't have a good way of sharing it. Many times when working with people even with the same toolset you can walk away learning something new and useful even in products you've used for years. I am not a big fan of pair programming in general, but I have had some very positive experiences pair debugging specifically because it's a chance to learn from each other. Debugging is something that's not really ever explicitly taught, and there's huge differences in the basic approaches people take.
|
|
#
?
Nov 3, 2020 18:34
|
|
|
Plorkyeran posted:I am not a big fan of pair programming in general, but I have had some very positive experiences pair debugging specifically because it's a chance to learn from each other. Debugging is something that's not really ever explicitly taught, and there's huge differences in the basic approaches people take. Yes, my college didn't have an explicit class on debugging. Which at the time I noted to my primary professor that I thought it'd be really helpful to have a class devoted to it. He at the time said that he didn't think it was necessary to have a whole class on just debugging. I think we ended up getting into a conversation about the usefulness of a class devoted to tooling/dev tools, etc. I'm not sure if other college's CS programs have classes devoted to debugging/tooling, but I still think there's a space for it. Even if from an academic POV. It'd be a great opportunity to introduce and explore options on repos, debugging, maybe some devOps-ish stuff, documentation concepts, basically all the support infrastructure underlying writing code.
|
|
#
?
Nov 3, 2020 18:49
|
|
|
Vulture Culture posted:SLI/SLO are interesting, but I feel like they're of principal use to business that already have pretty robust decision-making processes. Where they really shine is when you want to transition operations away from central ops and onto product teams, and you need the right guardrails in place to ensure product teams can own their own availability while keeping reliability and feature development in tension. This is really well stated and helpful, thank you.
|
|
#
?
Nov 3, 2020 21:58
|
|
|
downout posted:Yes, my college didn't have an explicit class on debugging. Which at the time I noted to my primary professor that I thought it'd be really helpful to have a class devoted to it. He at the time said that he didn't think it was necessary to have a whole class on just debugging. I think we ended up getting into a conversation about the usefulness of a class devoted to tooling/dev tools, etc. The issue is that what you're describing is all important for Development/Software Engineering, whereas most university programs are Computer Science. The program is not designed to teach you how to deliver software as a career. Granted, the other side of that coin is that whenever you tell a counselor that you want to be a developer, they'll say "well then, take our computer science program!" System's kinda busted.
|
|
#
?
Nov 3, 2020 22:48
|
|
|
I would argue that in order to be a decent computer scientist, it would help if you had some basic development skills, but what do I know
|
|
#
?
Nov 3, 2020 23:02
|
|
|
In on the ground floor of "computer science is not software engineering" / "so it's worthless then" posting party #48839
|
|
#
?
Nov 3, 2020 23:56
|
|
|
Che Delilas posted:The issue is that what you're describing is all important for Development/Software Engineering, whereas most university programs are Computer Science. The program is not designed to teach you how to deliver software as a career. Good point, although I think I agree with vonnegutt. Additionally, I think a class could look at many of those types of things from an academic perspective, still be useful to both engineering and science. Perhaps the difference between various repository architectures, introduction to various development methodologies, various version of documentation, light cost and disaster recovery analysis for devops architecture. Maybe tie it all together under the guise of the analysis and evaluation. I get that all of this is very separate topics, but they do this poo poo all the time with intro classes. "Here's a bunch of broad topics and tools covering light EE and CS", call it 'Intro to EE', and require all EE and CS students to take it. downout fucked around with this message at 00:59 on Nov 4, 2020 |
|
#
?
Nov 4, 2020 00:47
|
|
|
I mean, yeah, it would be nice to have a course that covers all sorts of tooling that you're likely to use on the job, but there are a couple issues with that. First and foremost, what do you teach? If you teach whatever tools are popular now, you run the risk that they're going to fall out of favor by the time people graduate. It's better to teach principles that are useful for picking up new tools, but in some cases it's not 100% clear that there are any. Second, what do you cut in favor of a tooling class? There are limits on how much you can require for a major, and on how many classes you can teach given your faculty. There's already demand in most programs for more classes than there are people to teach them, and adding something else won't make that better. I do think that we should be teaching some of those tools where they fit into the curriculum. A programming class should introduce debugging, any class with a large programming project should use version control, and a software engineering class can at least survey some of the problems out there and tools that cover them. vonnegutt posted:I would argue that in order to be a decent computer scientist, it would help if you had some basic development skills, but what do I know Why?
|
|
#
?
Nov 4, 2020 00:50
|
|
|
ultrafilter posted:I mean, yeah, it would be nice to have a course that covers all sorts of tooling that you're likely to use on the job, but there are a couple issues with that. My program had a full foreign language requirement (2 semesters) as a hold-over from the time CS was under the arts dept. So at least for them, they could drop half of that. Maybe it was the way my program was; perhaps other universities (and newer programs) have better implemented introductions to the topics in classes that make sense.
|
|
#
?
Nov 4, 2020 01:02
|
|
|
Just judging by some of my peers, some kind of class related to debugging seems like would be helpful. No idea what it would look like though as I'm a largely self-taught college dropout, and I'm not sure how to actually explain my mental process of debugging. Actually figuring out what's broken in a mass of code is something I've seen lots of otherwise good programmers struggle with more than I'd expect.
|
|
#
?
Nov 4, 2020 01:10
|
|
|
ultrafilter posted:Why? I just imagine it would be more difficult to do any advanced CS theory without a basic nuts-and-bolts understanding of how to create and release/package code. Learning how to debug, test, and some form of version control also seems like a massive productivity boost for writing any code longer than a shell script. Perhaps I am overestimating the amount of coding that actually get done in a CS education. I admit this is not my background. I have a fine arts degree, and alongside art history and theory we were taught a lot of basic stuff like "how to dispose of solvents and oily rags" because otherwise the studios caught fire. vonnegutt fucked around with this message at 01:37 on Nov 4, 2020 |
|
#
?
Nov 4, 2020 01:34
|
|
|
Computer science classes have you do things like prove Myhill-Nerode, which requires zero debugging skills (and zero regex skills, even though it is a theorem about regular languages).
|
|
#
?
Nov 4, 2020 02:03
|
|
|
Releasing software is what grad students are for. Seriously, though, the extent to which anyone writes code in a CS department can vary a lot. Most people don't write that much, particularly after grad school. That's just not what the field is about.
|
|
#
?
Nov 4, 2020 02:15
|
|
|
Academic CS can be done with pencil and paper. Early on, I believe most of it was.
|
|
#
?
Nov 4, 2020 02:55
|
|
|
cs is either just a dumb form of pure maths and hence doesn't need a computer, or else a dumb form of applied maths and hence needs a computer
|
|
#
?
Nov 4, 2020 03:46
|
|
|
Yeah, and not having to actually release code, debug it if it breaks and so on tends to show. OTOH my 2 yo daughter recently showed better debugging skills than half the people I worked with in the industry, so 
|
|
#
?
Nov 4, 2020 09:28
|
|
|
Are you sure it wasn't just beginner's luck?
|
|
#
?
Nov 4, 2020 10:44
|
|
|
I've been doing this for fifteen years professionally and every time I debug a problem I've never seen before it feels like beginner's luck. Get that kid some figgies!
|
|
#
?
Nov 4, 2020 15:26
|
|
|
Sadly I don't think that you can get figgies for debugging cooking process  What happened was that I was making potato pancakes, and my daughter tried helping, so she got her own grater and bowl. When she couldn't grate a potato (she is 2 yo, she has nowhere near enough strength and motorics for that), she put down the potato and tried different one. When that didn't work, she switched her grater for mine, and when that didn't work either, she switched bowls... meanwhile I have to tell people who have been programming for 5+ years that when debugging, they should only change 1 thing at a time to systematically narrow down the problem 
|
|
#
?
Nov 4, 2020 21:14
|
|
|
Today I learned that a low quality/old micro-usb cable can cause an external board (Jetson Nano) to power up for a minute and then shut itself down. I guess as it turns chips on the board it eventually exceeds its power supply? I didn't realize that was a possible failure mode. I expected the cable would either provide enough power, or the external board wouldn't turn on at all.
|
|
#
?
Nov 4, 2020 23:27
|
|
|
Xarn posted:Sadly I don't think that you can get figgies for debugging cooking process This is relatable because most of my problems end up being traced back to a lack of ability too
|
|
#
?
Nov 4, 2020 23:57
|
|
|
LLSix posted:Today I learned that a low quality/old micro-usb cable can cause an external board (Jetson Nano) to power up for a minute and then shut itself down. I guess as it turns chips on the board it eventually exceeds its power supply? I didn't realize that was a possible failure mode. I expected the cable would either provide enough power, or the external board wouldn't turn on at all. The company I work for used to make USB cables with a current limiting fuse in the cable which would blow at something ridiculous like 100mA, so that the device wouldn’t draw too much from the host because even the 500mA basic USB limit was too much for it. Any chance something like that is happening?
|
|
#
?
Nov 5, 2020 01:09
|
|
|
csammis posted:The company I work for used to make USB cables with a current limiting fuse in the cable which would blow at something ridiculous like 100mA, so that the device wouldn’t draw too much from the host because even the 500mA basic USB limit was too much for it. Any chance something like that is happening? It could be. I've had the cable for more than five years so no idea where it came from anymore. Your theory is as good as any. Fixing the issue was as simple as swapping out the cable. It was just the last thing I tried because it was such an unexpected failure mode.
|
|
#
?
Nov 5, 2020 02:40
|
|
|
LLSix posted:It could be. I've had the cable for more than five years so no idea where it came from anymore. Your theory is as good as any. Tbh the thing that ends up fixing the issue will always be the last thing you tried to fix the issue.
|
|
#
?
Nov 5, 2020 03:15
|
|
|
BabyFur Denny posted:Tbh the thing that ends up fixing the issue will always be the last thing you tried to fix the issue. if you think about it this is a tautology
|
|
#
?
Nov 5, 2020 18:41
|
|
|
Fixing the issue and then trying more things because you didn't like the fix isn't unheard of.
|
|
#
?
Nov 5, 2020 20:13
|
|
|
Plorkyeran posted:Fixing the issue and then trying more things because you didn't like the fix isn't unheard of. What you would have to do to make the statement untrue is to come up with multiple candidates for a fix that could fix the issue, and make it so the last fix you test isn't the one you actually check in. Which has happened to me when considering bug-fixes before.
|
|
#
?
Nov 5, 2020 21:34
|
|
|
|
| # ? May 11, 2024 08:21 |
|
|
It's more like, when something goes wrong, you instinctively think of about four or five or six things it could be, and it is always the sixth one. Or, if it's none of the first six, you sit and think for a while and come up with a seventh, in which case it will invariably be the eighth.
|
|
#
?
Nov 5, 2020 22:15
|
|