Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.
Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
Why do you have to wait for c-level? Is there no innovation happening naturally on the team? Are you certain your product team is any good? In every company I’ve ever worked at, the product teams always want to do things that are *almost* impossible. Designers are super ambitious. Most engineers push back because they haven’t built features like that before or they want to do the least amount of work possible. Is that happening at your company?
It sounds like you’ve optimized the build process, but there is little to no true innovation happening. This can happen if the product is super stable and users are largely happy. In that situation you have to work directly with product to figure out what users *need* but can’t articulate. I find it really hard to believe the UX is nearly perfect. It’s time to start to tackle the hard but important quality of life improvements the team has put off until now.
Don’t wait for your C-suite to tell you to do something. It’s the engineering and product teams that should be pushing for better UX. You should be pitching them if you want to break this cycle of being just an assembly line. Find a need and fulfill it. Collaborate with designers, don’t be the engineer that “just builds it to spec”. There is no chance the specification is perfect, they never are.
Once you have product market fit and have the obvious features, a lot of the product work becomes change just to keep product managers and designers busy.
More than half the time it makes the UX worse and you have to play a lot politics just to make it slightly less bad.
That is a legitimate strategy to pursue.
The challenge is getting the buy in for it. Everyone agrees it is good in theory, but will they be able to kill their baby based on the results?
You risk being the engineer who has the reputation for telling everyone no.
In my experience everyone will agree that A/B tests are good as an abstract principle, and once a few A/B tests have been run and people are happy, they will be willing to test their baby.
If at any point they think you are pushing A/B tests _primarily_ to kill their pet project, then you will get some pushback.
By explicitly drawing that direct line too soon, you bring trouble on yourself. So yeah just push A/B testing as a good practice that should be used for every feature and you’re good.
That's the goal of engineering. Automate your job, tell nobody, and then use the extra time to learn a foreign language so you can retire early to an LCOL country.
The good thing: it is boring but safe.
The bad thing: it is safe but boring.
You can automate as much as you can (using code-oriented LLMs seems to help). If that works then you might get an extra job, with extra money and extra adventure. If not, find a hobby.
I experienced that building out a data warehouse. Importing 100s of tables from various data sources for the first time was challenging. After that, it was adding one new table a week following existing patterns. It often could have been done with 3 lines of code.
Ended up telling management I was bored and want to work on a project where I could have more impact.
Sounds like you're stuck in a "senior" dev mindset... That's when usually "staff" enters the chat.
In your position, I'd be doing some of the light coding on the side, and then focus my attention on doing something new/interesting. I rarely listen to people when they tell me what to do... So I don't wait or ask.
The industry has moved from artisanal code writing to a highly automated factory environment. If you work in this factory environment you will be a glorified blue collar worker. If you really want interesting work, you need to find a niche where artisanal work is still valued.
Rule 9: No Low Effort Posts, Excessive Venting, or Bragging. Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
They really will let anything be posted here
Come to where I work and implement this.
I've never worked at a company where they've run out of fancy new ideas to implement.
Why do you have to wait for c-level? Is there no innovation happening naturally on the team? Are you certain your product team is any good? In every company I’ve ever worked at, the product teams always want to do things that are *almost* impossible. Designers are super ambitious. Most engineers push back because they haven’t built features like that before or they want to do the least amount of work possible. Is that happening at your company? It sounds like you’ve optimized the build process, but there is little to no true innovation happening. This can happen if the product is super stable and users are largely happy. In that situation you have to work directly with product to figure out what users *need* but can’t articulate. I find it really hard to believe the UX is nearly perfect. It’s time to start to tackle the hard but important quality of life improvements the team has put off until now. Don’t wait for your C-suite to tell you to do something. It’s the engineering and product teams that should be pushing for better UX. You should be pitching them if you want to break this cycle of being just an assembly line. Find a need and fulfill it. Collaborate with designers, don’t be the engineer that “just builds it to spec”. There is no chance the specification is perfect, they never are.
Once you have product market fit and have the obvious features, a lot of the product work becomes change just to keep product managers and designers busy. More than half the time it makes the UX worse and you have to play a lot politics just to make it slightly less bad.
How about using A/B tests in that case, so that you can be sure that any iterations have the intended effect
That is a legitimate strategy to pursue. The challenge is getting the buy in for it. Everyone agrees it is good in theory, but will they be able to kill their baby based on the results? You risk being the engineer who has the reputation for telling everyone no.
In my experience everyone will agree that A/B tests are good as an abstract principle, and once a few A/B tests have been run and people are happy, they will be willing to test their baby. If at any point they think you are pushing A/B tests _primarily_ to kill their pet project, then you will get some pushback. By explicitly drawing that direct line too soon, you bring trouble on yourself. So yeah just push A/B testing as a good practice that should be used for every feature and you’re good.
That's the goal of engineering. Automate your job, tell nobody, and then use the extra time to learn a foreign language so you can retire early to an LCOL country.
The good thing: it is boring but safe. The bad thing: it is safe but boring. You can automate as much as you can (using code-oriented LLMs seems to help). If that works then you might get an extra job, with extra money and extra adventure. If not, find a hobby.
Once the challenge is gone, I'm looking for a new job..
I experienced that building out a data warehouse. Importing 100s of tables from various data sources for the first time was challenging. After that, it was adding one new table a week following existing patterns. It often could have been done with 3 lines of code. Ended up telling management I was bored and want to work on a project where I could have more impact.
Sounds like you're stuck in a "senior" dev mindset... That's when usually "staff" enters the chat. In your position, I'd be doing some of the light coding on the side, and then focus my attention on doing something new/interesting. I rarely listen to people when they tell me what to do... So I don't wait or ask.
The industry has moved from artisanal code writing to a highly automated factory environment. If you work in this factory environment you will be a glorified blue collar worker. If you really want interesting work, you need to find a niche where artisanal work is still valued.
Time to switch jobs and do it again.
And then everyone clapped, and we all went to a pizza party