Ask HN: Advice for tolerating the "corporate" aspect of software jobs?
Looking for some advice from more experienced engineers on here:
I’ll preface this by saying I’m relatively new to the industry (couple years of experience) as an engineer. I’ve loved coding and working with cool tech since I was younger but I’ve only recently started working in a professional setting at a mid-size startup.
I’m grateful that I have the opportunity to work on software full-time but I’m getting increasingly tired of the other aspects of the job (endless meetings, agile “ceremonies”, back-and-forth on Jira processes, etc.)
I know that I need to work on getting better at the other non-tech related aspects of the job in order to grow as an engineer but I’m having a hard time forcing myself to care about the things that seem to only slow everyone down without providing a lot (if any) value most of the time.
How can I change my mindset to get more out of the “corporate” aspects of software careers?
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.
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
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.
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!
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.
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 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.
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.
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.
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’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/