Experienced Devs

3977 readers

3 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 1 year ago

MODERATORS

snowe

jmk1ng

drewsiferr

155

Senior Devs in huge corps: Do you even code? (self.experienced_devs)

submitted 1 year ago* (last edited 1 year ago) by van2z to c/experienced_devs

36 comments fedilink hide all child comments

I have been working at a large bank for a few years. Although some coding is needed, the bulk majority of time is spent on server config changes, releasing code to production, asking other people for approvals, auth roles, and of course tons of meetings with the end user to find out what they need.

I guess when I was a junior engineer, I would spend more time looking at code, though I used to work for small companies. So it is hard for me to judge if the extra time spent coding, was because of me being a junior or because it was a small company.

The kicker, is when we interview devs, most of the interview is just about coding. Very little of it is about the stuff I listed..

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

[–] catch22 1 points 1 year ago* (last edited 1 year ago) (1 children)

I started out where everyone else did and worked my way up so I've "been in the trenches". After doing this for 20 years and shipping multiple consumer and internal products I've seen it all and know what can make or break a project and what works and doesn't when introducing or using a new technology to a dev group. Also, I definitely don't throw it over the fence, it's a team effort and we all agree on what sounds like the best approach. Along with code reviews, part of the coding I discussed is sitting down and creating a skeleton of tests and an initial architecture that others can build off of and give me feedback on. If someone is having trouble implementing something I sit down with them and work through it. It's also about trust, people also trust me and know that in general I know what I'm talking about. The thing is most people would read my resume (or even this quick summary) and say I'd make a great development manager. But the problem with being pigeon holed into being a manager just because your a great dev is that it doesn't reflect what developers are good at, making software. More and more companies are realizing this when they shove their best dev engineers into the position of a manger and it crushes their souls, and makes them leave. So they are creating these principal or staff positions which at most companies are laterally equivalent to a director of software engineering without the people/staff managment. There's a great podcast episode on this by Stephen Dubner who wrote the book Freakonomics https://freakonomics.com/podcast/why-are-there-so-many-bad-bosses/

[–] fabian 2 points 1 year ago* (last edited 1 year ago)

The crucial point to me, which I could not read out of your first post, nor will I implicitly assume it as a given, is that there still is a feedback loop from product development to the staff/principal level.

I've been burned by a code base that was created by a principal engineer, who tossed it over for maintenance and moved on to greener pastures (still in the company though). It is more to blame on the organization, than on the engineer, but still such an experience leaves a slightly bitter taste.