HN Explorer

Ask HN: Software Engineers – How to overcome being assigned tedious tasks

6 points by hershyb_ ↗ HN
I'd really appreciate some advice here. I've been working for about 6 months on a project and everyone on the team has about the same tenure as myself at the company/project. Initially, I was assigned to write tests for our end-end pipeline and completed the assignment, but eventually that was the only type of work that I was given. No real coding, just testing. Maybe software engineers that haven't been performing at high levels are mostly given the job of testing code, or it's just a standard to have certain developers do all of the testing, but it's really eroded my confidence and passion for developing. I've tried to bring this up with my manager (admittedly passively) and he keeps suggesting that I will be able to work on different assignments after a couple months. In addition, the team is so large that it's often easy for him to lose track of an individual developer. Any suggestions on how I can improve myself to get out of this rut when everyone else in the group seems to be enjoying the new types of experiences they are learning from.

P.S. hope I didn't complain too much, but if I am just let me know :)

9 comments

[ 4.8 ms ] story [ 30.7 ms ] thread
jonaldomo
when i am distributing work to software engineers, i try to assign work based on strengths, preferences and business needs.

if i were you and wanted to work on something different, i would first understand the business needs and the project and then tell the person who is managing the work what i wanted to work on in a polite manner.

e.g. if the contract is for QA work on a desktop app, then asking to redesign the thing on mobile isn't going to fly.

bckr
1. Look for what interests you most about what you are doing now. Focus in on that and do the best you can at it. Learn some things around it. So, if you're writing tests for something but you realize the thing you're testing could be better, lean into that.

Alternatively, just do your work but pay attention to what others are doing and talk to them about it. See what their pain points are or what they don't have time to do, and see if that lines up with something you're interested in. Either way...

2. Come up with some interesting ideas that can benefit the business. Keep it simple and do your due diligence. Do some little experiments using around 10% of your time, or during time you're not expected to work (yeah, it goes against the anticapitalist program, but it's a great way to get ahead.... Anyway, you're a knowledge worker not an assembly line person).

3. Try to get buy-in. Bring up the problem that you're solving and be ready to provide the solution along with your due diligence or even a prototype. You might only get a "keep looking into this" but that's your toe-hold :)

This was my basic strategy at the job I had before officially becoming an engineer. I was sooo tired of filling in simple reports, and I realized that I could probably automate it. I took a risk and spent some of the time I had alone at the office writing a script to make some batch edits.... And it worked! Then I was able to get buy-in to build a GUI for it. So if I was able to do this when my job description wasn't even "engineer", I know that you can do it as a SWE :)

luthfur
So you are assigned to write tests which you consider tedious, but you want to work on the main code base presumably on features. Here are my thoughts:

1. Always deliver the goods: Execute your assigned work to the highest quality. To help with mindset, instead of thinking of your work in terms of "effort", think in terms of "contribution". Great tests contribute substantially to the quality of the product and prevent future regression. Find ways to deliver some bonus improvements, for example: improving coverage, improving test speed. Demonstrate that you create value in the team beyond what is assigned. Again thinking in terms of your contribution helps ie. contribute above and beyond what is asked.

2. Document the value you add and highlight it to your team and manager. Don't be passive about it. Building a reputation of quality and reliability as an engineer will help you navigate this project and beyond.

3. Be direct and clear about asking for work that you are interested in. Don't be passive. Passive is weak. Top performers are not passive, they are clear about their goals and direction and go after it directly.

Hope this helps. Good luck!

ariosto
This hits hard. I entered a new position being passive/humble and now it's difficult to turn it around
stray
Write the best tests possible. Believe it or not, the other work is tedious too.
trowmeaway1
Testing is real coding! It's just not glamorous, but testing is one thing that every developer should do although many don't. Maybe you could carefully refactor scary parts of the code base after writing lots of tests for it. Like others have said, make a case for the refactor to your direct report. Good luck!
Jugurtha
Recycling some replies. More context on https://news.ycombinator.com/item?id=26182988:

- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)

- https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates)

- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)

- https://news.ycombinator.com/item?id=22827841 (product development)

- https://news.ycombinator.com/item?id=20356222 (giving a damn)

- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)

- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)

- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).

- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)

- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)

- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)

- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)

- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).

- https://news.ycombinator.com/item?id=24177646 (communication, alignment)

- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)

- https:/...

softwaredoug
Want interesting work? Don’t expect to get it assigned to you, you have to find those ideas. Then you have to convince others it’s a valuable investment. In short you need a little bit of sales skills to put yourself in a position to propose and “win” the cool work.

The best way to do this is with “show don’t tell”: make quick and dirty demos of what you’d propose. A demo with kinda working code is far easier to make decisions about than some giant proposal of an idea. And don’t just sit on it until you see your boss: get feedback from colleagues about your idea before anyone else. Either the enthusiasm will snowball, and you’ll have allies when going to management on why doing this work is essential. Or it’ll sputter out, and that’s a valid signal too!

Also:

> the team is so large that it's often easy for him to lose track of an individual developer.

This jumped out as a bit of a red flag. Sounds like you’re doing your best but can’t get anyone’s attention. That’s frustrating. In many work environments this isn’t the norm.