One thing to keep in mind. When you're interviewing for jobs, you're also interviewing them. You've discovered some of your preferences on what I generally lump into the 'process' bucket --- when you're considering changing jobs, or selecting from multiple available jobs, you need to know about how they handle all of this, so you can guess which job will make you happier.
There's a spectrum of process from cowboy to multi-decade space mission, and as an experienced engineer, I know where I want to be, and I can grudgingly accept that other places on the spectrum can be appropriate if there's a real business justification.
Since it sounds like you're more on the cowboy side of the spectrum, one thing to be aware of while you're interviewing is that 'best practices' seems to be more process, so when you ask, most people aren't going to just come out and say they YOLO editing PHP on prod... you've got to ask and refine your probing questions so that you get to something close to accurate, while sometimes not revealing your preferences.
The other thing is that generally, the more experience and tenure you have, the more clout you have to skip process. Skipping meetings has consequences, of course, but sometimes it's better for you to have an hour of sanity and accept that decisions will be made without your input. IMHO, when you intentionally skip meetings, you should not re-litigate the decisions of the meetings, unless they're really infeasible or damaging to the business.
Ticket tracking tools and processes are like the IRS and taxes, just something you have to deal with and do compliantly. They are just a part of the process for working in a software organization. No ticket tracking tool or process is going to magically make software projects suddenly be delivered on time and on budget and have high quality. If the industry knew of a tool, it would be getting investigated by the federal government for having a monopoly because everyone would be using it. Its the people that are most important, not process or tools.
Nobody is going to reward you for becoming an expert at JIRA or for activities in various ceremony meetings, etc. unless you want to become a PM. Focus on delivering working software, working well with others and following the processes. If something being done is just dumb, like if someone is demanding a ticket per every file changed, talk to them about it and the overhead/issues it causes. If you don't own the process the best you can do is ask for changes.
You’re not getting paid to “code”. You are getting paid to bring business value to the “corporation” by either making the company more money or saving the company more money than they are paying you.
The corporate aspects are the entire reason that they put money into your account.
I have used those “corporate” aspects to go through the promotional ladder, gain experience in them and then share the best parts with others in new roles/orgs.
The challenge is that you can’t avoid them and you need to work within the boundaries of those processes. So I suggest a level of acceptance that they exist but challenging them to be as lean as possible
If you want to mess with cool tech in your own time, create your own company or do cutting edge research at a university go for it.
Otherwise if you can get a well paid job where you get up do stuff you enjoy half the time suck it up and just deal with the corporate stuff. If I could afford not to work I'd miss a few aspects of working in software, but not too many!
Not caring is key. Like so much is out of your control you have to accept that most of the company’s decisions aren’t about you or factor you into account. Including your own performance reviews - you can get lucky and have a boss you gel with - or have a boss you don’t interact well with. Or your salary is a rounding error someone had to solve for.
See if you can get into something you really want to do for at least 5 years.
And if not, find a luxury gig that pay more if you do shits, and learn to manage your managers and manage your expectations. Treat work as work and segment hobby programming from work programming.
Don't get married or kids unless you can't live without one, at least before 30.
You'll very soon see how people with the biggest impact (net positive or negative!) in your company are the ones playing the corporate game.
Without having a big impact, it's virtually impossible to grow in your career. Because of this, playing the corporation game is the most important part of our jobs.
We are first an employee for the company, then a software engineer. We mostly deliver value for the company by coding, but it isn't the only thing we do.
Working in a team and organization is very different from working alone.
In a big enough tech organization (10+ people), the impact of your "coding skills" is smaller than the impact you can have by just reorganizing the team in a more efficient manner.
How important those meetings and processes are important for the company.
Without them, you could still write software, but it would be very disorganized. The company needs to figure out what to focus on, focus on it, and moving Jira tickets across the board is a way to coordinate it.
Meetings and work relationships are the only way to get your organization to improve.
It's normal to feel frustrated at first, just don't let it become your personality or be too cynical about it otherwise you won't be able to have an impact.
Soon your emotions will adapt so you will feel less fed up by those things. For me.
It was only after a decade of experience I stopped getting triggered by those inefficiencies and understood how hard it is to actually run a team, much more an entire department / company.
Meetings are mostly counterproductive. Everyone knows that and any good manager will aggressively eliminate them for you.
As for agile ceremonies, some of them are needed for smooth operation of the team. Some of them are pure fluff. A good manager will know the difference and make real-time adjustments to the process to find the balance. A team of 7 doesn't need to spend more than 4 hours a week in meetings.
Back-and-forth is a result of poorly worded AC or people not reading the AC. Sometimes it can be avoided, sometimes not.
You just need to understand that in corporate jobs, you're on a team. Everyone works for a paycheck just like you, so there's a social give-and-take that must take place.
You just want to code, I get, I'm the same way. What helps me is recognizing that in the 'corporate' environment, the challenge is not merely solving technical problems, but also coordination problems. Negative work is real, and avoiding it _requires_ coordination. That's what the 'corporate processes' are directed at.
Now, understanding this fact enables us not only to better understand why we do these things, but also provides a concrete way to criticize and improve those process. You can use data to figure out which processes aren't actually improving quality, velocity, and coordination.
I think the negative spin of the title is indicative of what you ultimately need to do: try not to be above corporate beaurocracy and red tape, or do your own thing where you control what the process is like.
Not all software jobs are like that. If, like myself, you have a very low tolerance for that stuff, then you need to sniff it out during the interview process so you know that the company is a poor fit for you before you accept a position.
One thing to keep in mind. When you're interviewing for jobs, you're also interviewing them. You've discovered some of your preferences on what I generally lump into the 'process' bucket --- when you're considering changing jobs, or selecting from multiple available jobs, you need to know about how they handle all of this, so you can guess which job will make you happier.
There's a spectrum of process from cowboy to multi-decade space mission, and as an experienced engineer, I know where I want to be, and I can grudgingly accept that other places on the spectrum can be appropriate if there's a real business justification.
Since it sounds like you're more on the cowboy side of the spectrum, one thing to be aware of while you're interviewing is that 'best practices' seems to be more process, so when you ask, most people aren't going to just come out and say they YOLO editing PHP on prod... you've got to ask and refine your probing questions so that you get to something close to accurate, while sometimes not revealing your preferences.
The other thing is that generally, the more experience and tenure you have, the more clout you have to skip process. Skipping meetings has consequences, of course, but sometimes it's better for you to have an hour of sanity and accept that decisions will be made without your input. IMHO, when you intentionally skip meetings, you should not re-litigate the decisions of the meetings, unless they're really infeasible or damaging to the business.
Ticket tracking tools and processes are like the IRS and taxes, just something you have to deal with and do compliantly. They are just a part of the process for working in a software organization. No ticket tracking tool or process is going to magically make software projects suddenly be delivered on time and on budget and have high quality. If the industry knew of a tool, it would be getting investigated by the federal government for having a monopoly because everyone would be using it. Its the people that are most important, not process or tools.
Nobody is going to reward you for becoming an expert at JIRA or for activities in various ceremony meetings, etc. unless you want to become a PM. Focus on delivering working software, working well with others and following the processes. If something being done is just dumb, like if someone is demanding a ticket per every file changed, talk to them about it and the overhead/issues it causes. If you don't own the process the best you can do is ask for changes.
You’re not getting paid to “code”. You are getting paid to bring business value to the “corporation” by either making the company more money or saving the company more money than they are paying you.
The corporate aspects are the entire reason that they put money into your account.
There was a saying at Google, I code for free, they pay me for XYZ (literally everything else).
I have used those “corporate” aspects to go through the promotional ladder, gain experience in them and then share the best parts with others in new roles/orgs.
The challenge is that you can’t avoid them and you need to work within the boundaries of those processes. So I suggest a level of acceptance that they exist but challenging them to be as lean as possible
Gratitude is the best attitude.
If you want to mess with cool tech in your own time, create your own company or do cutting edge research at a university go for it.
Otherwise if you can get a well paid job where you get up do stuff you enjoy half the time suck it up and just deal with the corporate stuff. If I could afford not to work I'd miss a few aspects of working in software, but not too many!
Not caring is key. Like so much is out of your control you have to accept that most of the company’s decisions aren’t about you or factor you into account. Including your own performance reviews - you can get lucky and have a boss you gel with - or have a boss you don’t interact well with. Or your salary is a rounding error someone had to solve for.
See if you can get into something you really want to do for at least 5 years.
And if not, find a luxury gig that pay more if you do shits, and learn to manage your managers and manage your expectations. Treat work as work and segment hobby programming from work programming.
Don't get married or kids unless you can't live without one, at least before 30.
Retire early and do whatever you want.
You'll very soon see how people with the biggest impact (net positive or negative!) in your company are the ones playing the corporate game.
Without having a big impact, it's virtually impossible to grow in your career. Because of this, playing the corporation game is the most important part of our jobs.
We are first an employee for the company, then a software engineer. We mostly deliver value for the company by coding, but it isn't the only thing we do.
Working in a team and organization is very different from working alone.
In a big enough tech organization (10+ people), the impact of your "coding skills" is smaller than the impact you can have by just reorganizing the team in a more efficient manner.
How important those meetings and processes are important for the company.
Without them, you could still write software, but it would be very disorganized. The company needs to figure out what to focus on, focus on it, and moving Jira tickets across the board is a way to coordinate it.
Meetings and work relationships are the only way to get your organization to improve.
It's normal to feel frustrated at first, just don't let it become your personality or be too cynical about it otherwise you won't be able to have an impact.
Soon your emotions will adapt so you will feel less fed up by those things. For me.
It was only after a decade of experience I stopped getting triggered by those inefficiencies and understood how hard it is to actually run a team, much more an entire department / company.
Meetings are mostly counterproductive. Everyone knows that and any good manager will aggressively eliminate them for you.
As for agile ceremonies, some of them are needed for smooth operation of the team. Some of them are pure fluff. A good manager will know the difference and make real-time adjustments to the process to find the balance. A team of 7 doesn't need to spend more than 4 hours a week in meetings.
Back-and-forth is a result of poorly worded AC or people not reading the AC. Sometimes it can be avoided, sometimes not.
You just need to understand that in corporate jobs, you're on a team. Everyone works for a paycheck just like you, so there's a social give-and-take that must take place.
You just want to code, I get, I'm the same way. What helps me is recognizing that in the 'corporate' environment, the challenge is not merely solving technical problems, but also coordination problems. Negative work is real, and avoiding it _requires_ coordination. That's what the 'corporate processes' are directed at.
Now, understanding this fact enables us not only to better understand why we do these things, but also provides a concrete way to criticize and improve those process. You can use data to figure out which processes aren't actually improving quality, velocity, and coordination.
Tldr: be the change you want to see.
I think the negative spin of the title is indicative of what you ultimately need to do: try not to be above corporate beaurocracy and red tape, or do your own thing where you control what the process is like.
Not all software jobs are like that. If, like myself, you have a very low tolerance for that stuff, then you need to sniff it out during the interview process so you know that the company is a poor fit for you before you accept a position.
They are faster than software engineering in aerospace and medtech.
I’m relatively new to the industry
Developing Chesterton’s Fence humility is harder than easy if only I had a pony and could eat M&M’s for breakfast opinions about meetings. Good luck.
https://fs.blog/chestertons-fence/
[flagged]