Experienced Devs

4033 readers

12 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago

MODERATORS

[email protected]

Our tooling saps my will to work (lemmy.dbzer0.com)

submitted 3 weeks ago by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

I hate every interaction with our tooling. I loathe our older-than-dirt source control system. I hate our 4+ hour build times from scratch. I can't stand our "never plan shit" development process. I despise waiting 3+ months to see my changes in prod. I'm baffled by our RTFM onboarding process when the "manual" is some document written at project launch that's never been updated in the 10 years since.

My current task is simple, took a short time to write my code. But I've had so much trouble with tooling that the process of submitting a code review has stretched over a week. At this point, I know what I can do next to fix it, and it would take maybe 20 mins to do. However, I can't bring myself to even do that.

As cruel as it feels to say, my manager is like some NPC. I am on two teams, one of which I meet with every day who doesn't understand the work I'm doing for team #2. Team #2 meanwhile consists mostly of people I've never met, not even on video calls.

The company is huge and I don't feel like I can make any impact. My plan at this point is to try and hold out for my 1 year shares to vest and then bounce. Take 6 months to brush up on dev-ops skills and then look for a new line of work.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 0 points 3 weeks ago (4 children)

4h build times... ouch! I'm betting this is Rust or TypeScript.

[–] [email protected] 0 points 3 weeks ago (3 children)

Actually, C++. An enormous codebase plus we build all dependencies from source. I asked my dev lead why we don't have access to pre-compiled dependencies and he answered with a mix of embarrassment and "that's just how it's done".

A 4h build would be OK if I only needed to do it once. However, our source control system lacks even a basic conception of branches, so each new ticket requires destroying and regenerating your workspace.

[–] [email protected] 1 points 2 days ago (1 children)

so each new ticket requires destroying and regenerating your workspace.

Now I don't understand that. Complete your ticket, pull in changes from other and carry on.

What SCM are you using?

[–] [email protected] 1 points 1 day ago* (last edited 1 day ago)

Perforce

We manage branches by taking an existing path on the perforce server, duplicating its contents, and then copying them to a differently named directory while registering that new path serverside.

So on paper, I can tell my local client to map my files to that new remote path, and then trigger a sync. In my experience, the sync treats my branch jumping as pulling completely new files. It touches everything in my work directory. As far as our makefiles are concerned, this means everything has to rebuild.

load more comments (1 replies)