I agree with you. Even if you never touch it, it’s nice to know what the libraries you’re calling are doing under the hood.

maybe this will work

...

...

...

linting and unit tests

A thing that hallucinates uncompilable code but somehow convinces your boss it’s a necessary tool.

Steps to test: “Idk try some shit”

Yep. This is the way. Also, you’d be surprised how many devs don’t run through their own QA steps before asking other people to verify.

Yuck.

At some point, they’re gonna have to debug it.

If you’re trying to pull your weight, and it sounds like you are, the problem is either with the tasks, the codebase, or the teammates:

Potential problems with the tasks:

• they’re not researched sufficiently
  • is this doable?
  • should we we even be doing this?
  • have we actually thought about how hard this will be, or did someone say “well that should be trivial” a bunch?
• there’s not enough info on the tickets
  • inexperienced leads tend to just shit out tickets with zero info and underpoint them
• they’re not broken down into small enough pieces
  • are you working “implement X” tickets while everyone else is working a series of “implement X: step N” tickets?

A ticket needs: clear repro documents (if necessary), screenshots, and clear steps to reproduce. It needs more than “Title: Add X to Y. Description: We need Y in X. Implement it.” unless you’re intimately familiar with the codebase. And even if you are, you still need a paper trail to back up what you’re doing. If you’re not closing tickets, be very chatty in the comments. Share where you are, problems you’re running into, and who you’re waiting on for help. If there’s a consistent theme to the things you’re fighting, keep a list of them and bring them to your manager. Be your own advocate and be very transparent about all the research you’re doing because other people didn’t.

Potential problems with the codebase:

• someone preemptively optimized it
• it’s not documented well
• it’s spidery bullshit code that someone has deep emotional attachment to

Hey, it works. But it’s not documented, someone decided to be clever instead of elegant, the local story sucks, or it’s optimized to such a degree that you have to refactor just to add a simple option ("lol why would we ever need that data here? It’s inefficient!)

Potential problems with teammates:

• they’re not supporting you
• they’re grabbing easy tasks because you’re the “code whisperer”
• they didn’t know what they were doing either so they’re vague when you ask them questions

Everyone pulls their weight. Everyone communicates in clear, declarative sentences and provides examples if necessary. “I don’t know” is an acceptable answer. Evasiveness, vagueness, specialized jargon, or acronyms point to the dev being insecure about their knowledge in that area. Be very suspicious of the word “should”: “that should work”, “that shouldn’t be hard”, “you should be able to…”

And, as an aside, I’ve seen this happen a lot. A new dev or contractor comes on, blows through tickets, gets good marks, and an existing dev or two get called out for not contributing with the same frequency. One of two things are happening here: the new devs are getting softballs, or they’re creating a lot of subtle tech debt that someone else will have to fix because they don’t have a full picture of the codebase. Eventually, those devs will be where everyone else is, but it’s still frustrating.

Hang in there.

It’s funny how soon they realize they want a good one.

I use a car analogy for these situations: You need a mechanic (IT professional.) I’m an engineer (coder.) They’re both technically demanding jobs, but they use very different skillsets: IT pros, like mechanics, have to think laterally across a wide array of technology to pinpoint and solve vague problems, and they are very good at it because they do it often.

Software engineers are more like the guy that designed one part of the transmission on one very specific make of car. Can they solve the same problems as IT pros? Sure! But it’ll take them longer and the solution might be a little weird.

Sometimes, very rarely, I tell my squad that today’s our unlucky day and we’re actually going to have to do math to the problem.

Oh hey, it’s a list of everything I’ve been ranting about for the past three years.

It’s been ages, but we’d done rough calculations for the three controls so we roughly knew what we needed. Our teacher was big on manually tuning instead of just using formulas since he thought just running numbers “lacked artfulness.”

So we grabbed a point and started searching around manually. I think we were just tuning the derivative portion at that point, trying to get a fast response without the system without it going chaotic and noisy.

The final project in my instrumentation class was to tune a PID controller for a hot/cold mixing valve. I (CS/ENG) was paired up with an engineering student and a lot of it was throwing parameters in, seeing if weird shit happened, and then turning down or up based on the result. I had a programming final and something else I was supposed to be studying for, so I just started doing a binary search with the knobs. We got the thing tuned relatively fast and my partner acted like I was a wizard.

Yeah, I swear it’s part of the culture at some places. At my first full-time job, my boss dropped the production database the week before I started. They lost at least a day of records because of it and he spent most of the first day telling me why writing sql in prod was bad.

Yep. If you’re in a situation where you have to write SQL on the fly in prod, you have already failed.

Yep! Good point.

I’ve been a dev for 20+ years and yeah, learning a new repo is hard. Here’s some stuff I’ve learned:

Before digging into the code:

• get the thing running and get familiar with exercising it: test happy path, edge cases, and corner cases. We’re not even looking at code yet; we’re just getting a feel for how it behaves.
• next up, see if there’s existing documentation. That’s not an end-all solution, but it’s good to see what the people that wrote the thing say about it.

Digging into the code:

• grep is your very best friend. Pick a behavior or feature you want to try and search for it in the codebase. User-facing strings and log statements are a good place to start. If you’re very lucky, you can trace it down to a line of code and search up and down from there. If you’re unlucky, they’ll take you to a localization package and you’ll have to search based on that ID.
• git blame is also your very best friend. Once you’ve got an idea where you’re working, use the blame feature on github to tie commits to PRs. This will give you a good idea of what contributing to the PR looks like, and what changes you’ll have to make for an acceptable PR.
• unit tests are also a good method of stealth documentation. You can see what different areas of the code look like in isolation, what they require, and how they behave.
• keep your own documentation file with your findings. The act of writing things down reinforces those things in your mind. They’ll be easier to recall and work with.
• if there’s an official channel for questions / support, make use of it. Try to strike a balance here: you don’t want to blow them up every five minutes, but you also don’t want to churn on a thing for days if there’s an easy answer. This is a good skill to develop in general: knowing when to ask for help, knowing when an answer will actually be helpful, and knowing when to dig for a few minutes first.

There’s no silver bullet. Just keep acquiring information until you’re comfortable.

• extends Object

That would be pretty easy.

return "Why are you even trying to do it this way?\n$link_to_language_spec\nThis should be closed.;