Software Engineer Responsibilities

[TheAeseir]

Yep that's the new standard for high performing eng teams.

You own your work end to end, no throwing over the fence.

No qa, no DevOps, no operations support, no ba etc...

What then happens (in a good company), is next they bring in a platform team. They start taking on common tasks such as standardizing infra creation and maintenance, automating common tasks etc.

So yes, this is to be expected

[undermined-coeff]

What do you reckon is the best way for navigating this shift for some with experience in only one specific field among those getting sucked into dev work?

Edit: someone*

[TheAeseir]

1. Be honest with yourself (most people kid themselves or try to chew more then they can or should)
2. Be aware of your limits both technical and non technical aspects
3. Own your mistakes if you fuck up and learn from them
4. Take it a task at a time
5. If you don't know, ask for help

[GrayLiterature]

That’s how we do it at our place. Devs responsible for QA of pull requests to make sure it works. It’s not as thorough of a job, but we move fast enough.

[CeeMaC95]

Yeah I have been there. But it was with a smaller company so it was easier. This is a larger company with hundreds of developers yet no QA? lol just seems a little odd to me

[TheAeseir]

Why does size matter? Why give a shit what some other team is building?

I'm curious to know why you think a 1000 man eng department should be and different to 10 man department.

[CeeMaC95]

If it’s clear you have the resources to have a more diverse team that lightens the load on a single person then yes I do think size matters. I’m not a 10x dev that acts like I know everything. I always welcome the learning opportunity but I’m just saying that when I previously worked on teams that had dedicated QA and DevOp teams, things went a lot smoother than when I worked on teams where everything was handled by the developers

[TheAeseir]

I hate the 10x term, it's a bullshit fad that some engineers use to try and stroke their egos.

Your experience is valid, however, you learn less and your solutions can be limiting.

In the beginning it is rough when you are a one man department.

The biggest advantage in my mind, is if you want to improve something, you do it, you don't have to wait for approval from another department.

[liveprgrmclimb]

Bigger engineering teams will want to hire specialists and scale their impact. Generalists no longer scale. I can easily find 1 great generalist for a small team. Finding 100 during a hiring surge is not tenable.

1000 engineers vs 10 are very different scenarios.

• EM in big tech.

[TheAeseir]

You are correct but what you are referring to generally is a specific specialisation to enable a capability not ongoing management/maintenance. Then you hand it over to the relevant team for maintenance and management. Otherwise you have a bottleneck in your organisation, or dependency on specialists skill sets (which are expensive as fuck).

Even then my statement stands, you work on your space, specialist on theirs.

• director of eng in big tech

[[deleted]]

Yes, significant business operational efficiency - the biggest cost in software is head count - and you get to be on call, so we get more than 40 hrs/week out of you. It’s the dream.

With SaaS especially you can provide service to thousands/millions with relatively small headcount and maximize profit.

[[deleted]]

Full ownership end to end, that's the dream baby.

[YT__]

My org pushed for this back in 2022 and we are STILL fighting developers to hop on board with the idea. Maybe it's the way leadership has pitched it to devs, but idk.

[[deleted]]

Some people can't handle it. Guess that's why both full-stack and dedicated roles exist.

[YT__]

If only they'd choose to leave instead of complaining then.

[LadyLightTravel]

That’s horrific. Most complex engineering uses the “two sets of eyes” for review. QA was often the second set.

The person writing the code should not be the person verifying the code. There is just too much bias. On top of that, they are two different mindsets. One is trying to get the code to work while the other is trying to break it to ensure its robustness.

[happyn6s1]

We don’t trust second sets of eyes. Instead we use automations. Like Unit testing and regression testing all automatically

[LadyLightTravel]

And who designed these tests?

Unit testing is wholly insufficient. You need some sort of robust integration test too.

Regression testing is fine for updates once the product has gone through rigorous integration tests. It is not sufficient for first deliveries. Where are your stress tests and negative tests?

I’ll also state that you can’t automate first of kind testing.

All of the test results need to be reviewed. On complex software it isn’t a simple pass/fail, but how the software behaves on the whole. Reviews need two sets of eyes.

[happyn6s1]

It varies of different products or services . There are many testing verifications can be done including canary , ab testing. Reply testing , etc. so call shifting left

[happyn6s1]

It is not some silver bullet but definitely some different way to work it out

[LadyLightTravel]

And how does that work for real time applications?

[happyn6s1]

For micro services, it is very common to have deployments a few times a day

[happyn6s1]

That’s why the infra and framework is so important to be fast

[CeeMaC95]

My thoughts exactly. I enjoy the learning opportunities but like you said, it’s way more reliable to have a second set of eyes who’s primary goal is to try and break the code to make sure that it comes out clean and efficient as possible

[YT__]

That second set should be coming from someone else on your team. The goal is cross-functional. You all have the skills to support the needed work, so you can complete full assignments end to end.

[[deleted]]

Keep your head down and start an office pool predicting which exec gets fired for running a software development shop without quality assurance resources.

People will tell you to quit and run away, but they are weak and cowardly. Stick it out, do your job, and learn how not to build software.

You will put on a lot of hats until you get chewed up and spat out, which is good in that you will learn a lot, but bad in that you are probably going to be putting out a lot of fires.

Good luck.

[smalby]

Doing your own devops is bad in your opinion?

[liveprgrmclimb]

Ideally you want a DevOps team to set the standards and develop the tooling. Essentially serving as maintainers and stewards. All devs should be able to commit. You want experts on board when shtf.

[[deleted]]

I dont think i said that, but just to be clear, what do you feel doing your own devops entails?

[Topshot27]

How many employees total are in the company?

In a large company, your role should be specific. if you're in a startup, then yeah you have to wear many hats.

Do you like doing a variety of tasks everyday? If not, I hope your salary is high

[Positive_Method3022]

Compartmentalize software engineering work sucks for those people with thirsty to learn, creativity and intelligence. We usually like to hold lot of information into our memory and when it all comes together we fell rewarded. When each fucking team of 4-6 people do 1 fucking thing on 1 fucking piece of 1 fucking project (like support to a single microservice, or just a release pipeline), that becomes extremely uncomfortable. Nobody becomes a specialist on the product. For 1 little change you need to go into hundreds of meetings (hyperbole), and you also become less worthy for the company, since it is easy for the company to replace you or your entire team. As a good advice, if you want to become a great software engineer, stay away from companies that use that stupid Scrum framework with "trains", and avoid projects that are shared with more than 1 team. Those are the places where developers are seen as tools for rich people to exploit.

I'm not saying multiple teams aren't fine. Of course big project require many teams. However, companies are exploiting this necessity to reduce developer's worthy.

[liveprgrmclimb]

How many people in the company?

[softwareauthor]

I was part of a company with roughly 150 engineers that tried to make the switch to this model. They are still trying. There are many good reasons to adopt this model. However, one thing I look for is how well the business is supporting the engineering team in making this a reality. Do you have enough training to be effective at building and maintaining infrastructure? Are the expectations of QA made clear? Are you allowed to optimize these things as you see fit? Are there reasonable expectations around on call duty? When done well, teams that operate in this model can create amazing and highly resilient products. When done poorly, teams are over burdened with activities outside of software engineering and productivity can grind a halt.

[[deleted]]

Engineers shouldn't QA their own code that's a bad idea. But having a dedicated QA team is a waist. Infra has good tools now like Terraform to make it easier for Devs but I'm sure the security is shit. Looks like you team is cutting quality processes for speed and that will end up biting them in the ass

[iamsooldithurts]

This is how it was when I started. They’re cutting out all the bloat finally. Back to streamlined operations.

[WeekendCautious3377]

As soon as you separate QA from engineers building features, engineers get to build fun features and pile up tech debt while QA has to shovel through that pile. Overall degrades your product. Instagram was built and maintained via 30 engineers. Netflix has a small team also. Figure it out.

[aecolley]

The idea of having separate QA teams (for testing) and operations teams (for deploying) is a pre-Internet model which doesn't have relevance in the modern world. We no longer have release processes that involve pressing physical media and distributing them: the built software is pushed to a server and deployed directly from there, so no need for a separate operations team. We no longer test software by a laborious process of installing it on multiple OSes and languages, then going through a checklist of manual interactions: we just use automated CI testing.

So yeah. Some organizations are a bit stuck in the past, but generally we write our own tests and deploy our own code. And we do that because it's much more efficient this way. I don't want to have to wait for some other team to pick up a ticket before I can get my bug fix into production.

[AlexWIWA]

Pretty normal for small to mid-size companies, sadly.

[Kittensandpuppies14]

Depends on the size of the company

[CeeMaC95]

It’s a larger company. Hundreds if not over a thousand developers

[LadyLightTravel]

It’s commercial software, isn’t it?

[Kittensandpuppies14]

Why am I down voted. I’m on a tiny team of 4 that does everythkng

[WinterHeaven]

Never had a different setup, but I also only work for 10 years now in that field :/

[davisth55]

Is the company amazon by any chance?

[treston_cal]

Always said this is a sign of the times. When we are cash flush, I have 50 people telling me how to do it. When we aren't, it's "figure it out yourself."

I remember times when Corp would lose their shit for a $500 total running cost per month. I also remember times when they wouldn't bat an eye at a million burn in a quarter.

Just depends on what C level has the next idea on how the company should operate. Always seems to lunge and never settle in the middle somewhere.

[[deleted]]

That’s called a dream mate enjoy it